오늘도 아빠는 벌레잡는 중

요즘 싱글코어 PC를 사용하시는 분은 없을 겁니다. 개인 개발 목적으로 Ubuntu나 Centos를 설치해서 사용하시는 분들이 많으실 건데요. 대부분 분들이 개발용 linux를 설치 할때 그냥 partitioning을 합니다. 그럼 왜 partitioning을 할까요? partition을 나누어 하드를 사용하면 어떤 이점이 있을까요? 저는 개인적으로 오라클 클라우드에 Centos VM을 가지고 있습니다. 무료 다보니 용량이 간당 간당 합니다. 루트공간이 거의 다차서 언제 멈출지 모릅니다. 제가 처음 이 직업을 선택했을 때가 딱 이랬습니다. 하루에도 몇번씩 서버를 리부팅해야 했습니다. process폭주 때문입니다. 지금은 process가 폭주해도 시스템이 다운되지 않습니다.
그 이유는 첫째로 거의 모든 CPU가 멀티코어에 멀티쓰레드를 지원합니다. 둘째는 그 당시 ISA 방식의 장치들이 PCI방식을 사용함으로 인해서 인터럽터를 덜 발생하게 되었습니다. 즉 OS의 발전이 아니라 하드웨어의 발전으로 인해 지금은 시스템이 멈추지 않습니다.
그런데 process 폭주시는 리눅스 계열 OS는 하드에 자신의 분신을 만든 다음 실행되기 때문에 root공간이 부족하게 되면 더 이상 프로세스를 생성하지 못하는 문제가 생깁니다. 반대의 경우도 발생하게 되죠. root공간이 꽉 차게 되면 신생 프로세스는 생성할 수 없습니다. 이 경우는 쓰레드도 마찬가지로 시스템이 폭주하는게 아닌 아이들한 상태가 발생하게 됩니다.

만약 혼자서 사용하는 개발용 PC라면 오히려 partition을 만드는게 독이 될 수도 있습니다. 그리고 기술의 발전으로 network cloud file system 제품이 많이 등장했습니다 .이 경우는 팀에서 사용하는 서버라고 해도 partition을 만드는게 좋지는 않을 것 같습니다. 예를 들면 VirtualBox에 설치된 linux의 경우 하드디스크가 부족하면 자동으로 extention이 발생합니다. 그렇지만 partitioning을 해 놓은 공간은 확장되지 않습니다.
결국 root공간이 부족하게 되어 시스템이 멈추는 경우가 발생할 수 있는 거죠. 그런것 처럼 요즘은 hypernation OS가 있습니다. OS위의 OS라고 해야 하나요? 여러 OS에서 값비싼 H/W를 공유하는 목적의 OS이죠. 그런 시스템도 partition을 나누는게 좋지는 않습니다.

그래서 결론은 구식 개발 시스템 즉 전형적인 WEB/WAS환경의 서버 개발의 팀 미션이면 /usr와 /var와 root정도는 partition을 나누는게 좋지만 그런 시스템이 아니라면 지금은 partition을 나누는 것은 별로 좋아 보이지 않습니다.
점점 더 하드웨어가 발전하게 되면 시스템을 종료하지 않고도 하드디스크를 (raid 시스템과는 다릅니다.) 늘리는 일이 일상이 될것 같습니다.
지금의 cloude 환경을 한번 생각 해 보시기 바랍니다. 수억명의 유저가 동시에 사용하고 있는 시스템의 하드 디스크를 늘리자고 시스템을 종료하고 하드 디스크를 늘리는 작업을 한다면 그런 cloude 시스템을 사용할까요?

이 전챕트에서 우리는 외부 네트워크에 실패했다. 하지만 설정방법은

<wsl2>
networkMode=Bridged
vmSwitch=가상스위치이름외부용

위 내용을 .wslconfig에 설정하는 것이 맞다. 다만 windows10-pro에서는 JSON 오류가 나고 있고 원래도 허용은 windows server와 windows Enterprise에 허용된 것이기에 추가적인 방법은 정상적인 방법이 아니다. 오늘의 이야기는 그것 말고도 wsl이 가지고 있는 장점이 있다는 것이다.
일단 cmd창을 하나 연다.

bash

다들 아시다시피 windows는 linux가 아니다. 정상적인 경우에서 bash는 실행될 수 없는 명령어이다. 그러나 이 명령어는 아무런 문제 없이 실행된다.

그런데 문제는 bash 가 실행한 위치이다. /mnt/c/User/사용자명/아래서 시작되었다. 이것이 의미하는 바는 크다. wsl이 실행하면 자동으로 mnt아래에 c 드라이브를 마운트 한다는 것이다.
이 상태에서 notepad.exe를 실행해 보다.

yubank@DESKTOP-9BP3BEL:/mnt/c/Users/yuban$ notepad.exe

윈도우 창에 노트패드가 실행이 된다.

그런데 보다 시피 윈도우에서 노트패드가 실행되지는 않았다. 그 대신 노트패드 옆에 팽귄앞 모습이 보인다.

yubank@DESKTOP-9BP3BEL:/mnt/c/Users/yuban$ xclock

이번에는 그 정통의 xclock를 실행해 보았다.

아무 이상 없이 xwindow의 xclock가 실행된다. 이말은 이미 두 OS사이에 벽이 허물어 졌다는 이야기 인것이다. 현재 우리는 wsl ubuntu 20.04 LTS에 cuda를 깔아서 프로그램을 돌리고 있다. 그때 마소는 완벽한 커널이라는 말을 썼다. 이 말의 의미가 무엇일까? 내생각에는 보통의 OS가 커널>shell>app의 구조로 되었다면 windows10가 windows11은 더 이상 이구조가 아니것이다. 즉 공통커널>ubuntu & win NT>shell>app의 구조로 이미 바뀐것 같다.

구글 스토어에 위의 책이 올라와 있다. 가격은 얼마하지 않는다. 아니면 다른 서점 사이트로 친절하게 링크도 걸려 있다. 4장과 5장에서는 ubuntu와 windows의 콜라보로 할 수 있는 거의 대부분의 일들을 설명하고 있다.
https://learn.microsoft.com/ko-kr/windows/wsl/tutorials/gui-apps

위글을 읽어 본다면 MS는 훨씬 많은 것을 준비한 것을 알 수 있다. 그리고 WSL2 가이드북을 읽어 본다면 어마어마한 PATH문제를 해결해야 한다. 양쪽 OS에 PATH를 다 수정해야 명령어는 작동한다. 이제것 windows에서는 잘 사용하지 않던 |(파이프)를 이용하여 우분트에서 추출한 데이터를 쉽게 윈도우 클립보드로 이동도 가능한다. 이것은 아마도 커버네티스에 대한 떡밥이 아닐까. 그렇다면 낚여 보아도 나쁘지 않을 것 같다.

일단 WSL을 사용하려 MS 의 문서와 친해질 필요가 있다. https://learn.microsoft.com/ko-kr/virtualization/hyper-v-on-windows/about/

블로그의 내용은 WSL1의 내용은 제외하고 WSL2를 기준으로 작성된 점을 미리 말씀드립니다. 솔직히 WSL1은 세상에 너무 일찍 태어난 칠삭둥이 내지는 애초에 태어나서는 안되는 존재로 나는 생각하고 싶다. MS는 WSL1을 만든 직후 WSL2를 만들때는 Hyper-V로 다시 태어났다. 위의 링크는 Hyper-V를 소개한 문서이다. windows 10과 11에서의 Hyper-V와 Windows server의 Hyper-V는 구조가 완전히 다르다. 왜 그런 결정을 MS에서 했을까는 어쩌면 당연해 보인다. Hyper-V를 windows에 답재하게 된 이유도 너무 뻔하다. MS의 돈벌이가 더 이상 OS판매나 Office시리즈를 파는것에 있지 않음을 위 문서를 읽는 다면 알 수 있다. Hyper-V에서 만들어진 VM에서 무언가 개발되고 있다면 더 이상은 azure 에 OS를 설치하고 필요 라이브러리나 프로그램을 설치하지 않고 그대로 올릴 수 있다. 단지 내보내기 기능하나로. 내가 MS의 수장이라도 바로 OK일 것이다. 이것은 소위 우리가 흔히 말하는 생태계 생성이다. 도커니 뭐니 그런 것도 필요가 없다. 이것은 분명 혁명이다. 문제는 MS는 아직 Open project 의 정신은 없다. 다만 완전히 폐쇄적인 애플보다 조금 나은 수준이다. 애플에게는 디스크 클라우드는 있지만 AWS같은 하이퍼바이즈 클라우드는 없다. MS는 아마존보다는 느렸지만 있다. 내가 azure 를 사용해본 느낌은 일단 비쌌다. 난 클라우드를 사용하면 상면을 임대하는 코로케이션 서비스와의 장단점을 솔직히 모르겠다. 외국에 서버를 두어야 하는 경우가 아니면 코로케이션 서비스가 훨씬 저렴하다. 그렇지만 이제 Hyper-V로 인한 개발의 단축은 가히 혁신이다. 단 Windows server의 기준에서다. windows 에게 차별을 준것은 가히 가혹하다. 그 중에 기본 네트워크가 NAT라는 것은 최악의 차별이다. 그렇다고 일반 개발자나 소호 사업자들이 Windows server를 구매할거라는 착각을 하고 있는 것은 아니겠지? 의심할 수 밖에 없다. 현재 버젼의 WSL은 VS code를 사용하는 나에게는 정말 혁명갔다. 그런데 만약에 web,was,aps를 개발하는 개발자도 그럴까? GPU서버를 만들때는 분명 좋았는데 네트워크가 NAT라는 이야기에 흥이 확 사라진다. WSL2의 네트워크가 NAT라는 것은 단점만 있는 것은 아니다. 일단 해킹에 안전하다. WSL의 우분투와 로컬 windows는 가상 IP로 통신을 하고 있다. 여러분 집의 인터넷 공유기를 생각하면 된다. 안에서 밖으로는 나가지만 밖에서 안으로 들어 오려면 불가능하다. 하려면 틔윈IP라는 기술을 사용하거나 포트포워딩을 해야한다. 포트 포워딩은 말 그대로 한 포트 정도는 열어 줄게다. 그런데 WSL은 그 보다도 훨씬 심하다. 방법이 없다. 일단 버젼2에서는 방법이 없다. 하려면 다른 하이퍼바이즈들처럼 GUI툴로 가상H/W를 만들고 NAT로 할지 브릿지모드로 할지 아니면 호스트모드로 할지를 결정할 수 있어야 한다. 하지만 지금은 WSL 우분투는 windows 와 모든 H/W를 같이 사용한다. 공유의 개념이 아닌 샴쌍둥이의 개념이다. 현재로는 방법이 정말없다. Shaun Park님의 블로그(http://shaun289.blogspot.com/2020/06/wsl2-ubuntu-2004.html?m=1) 내용을 참조하여 네트워크를 설정해 보았다. 일단 결론은 안된다. 다른 방법도 시도해보았다. 네트워크 아답트 옵션에서 실제 브릿지를 형성하고 그 브릿지에 wsl의 vmSwitch와 이더넷을 같이 묶었다. 두 아답터 다 인터넷을 사용할 수 없었다. 사용자 폴더에 .wslconfig파일을 생성하는 것은 일부 효과가 있었다. 여기서 netmode=bridged는 효과가 있었지만 wsl2.vmSwitch를 설정해야 한다는 오류가 발생한다. 일부분은 분명 yaml파일을 의미하고 효과가 있었다. 인터넷에 있는 상당부는 wondows server설정이며 그기서는 아답터 브릿지 생성후 아답터를 브릿지에 포함하는 것이 동작한다. 현재까지는 windows10,11에서 정확히 동작하는 모델은 없는것 같고 net명령로 eth0:1을 추가하여 ip를 부여하는 방법은 동작은 하지만 복잡하다. .wslconfig의 전체 기능 분석이 필요해보인다. ms 문서를 뒤지는 작을 진행해야 할듯 하다

wsl이 나온지 꽤 오랜 시간이 지났지만 사실 그 동안은 쓸만한 APP(사실 뭐로 불러야 할지 모르겠다.)은 아니었다. 작년에는 노트북에 깔았다가 바로 지워버렸다. 전체 시스템이 무거워지고 알 수 없는 여러 오류들. 첨 MS STORE에서 우분투를 보았을 때는 CGYWIN이랑은 완전히 다른 느낌이었다. minix와도 완전히 다른 느낌이었다. 이제는 로컬에서 개발해서 테스트한 다음 서버에 적용하면 되겠네. '야 후' 였었지만 최 5분도 안돼서 그냥 지웠다. 욕도 하지 않았다. 그러다 불과 몇일전 윈도우10으로 머쉰런닝을 개발하다. Nvidia가 윈도우에 모든 기능을 넣지는 않은 것을 알았다. pytorch의 cnn이 상당히 무거운 엔진인 것을 안것도 사실 몇일이 지나지 않았다. torch의 CNN은 CPU로 돌릴 수 없다는 것도 마찬가지였다. 대안을 생각하다. 스토어에 있는 우분투가 생각이 났다. 나는 LTS의 의미가 무엇을 의미하는지 너무나도 잘 안다. 당근 우분투 LTS 버젼을 선택했다. 너무도 당연한 일이다. 그리고 CUDA를 설치하고 드디어 NCCL을 설치했다. 너무도 당연히 너무 탈 없이 잘 깔렸다. 이 의미를 이해하시는 분들은 상당히 많을 것으로 생각이 된다. 우리는 그냥 시간을 워퍼(웜홀 같은 곳을 지나거나 차원을 접어서 건너 뛰는 개념)한 것은 아니다. WINE를 와인으로 읽지 않는 분들 부터 VM이 무었인지 안는 사람들 windows 에 도커를 올려 보겠다고 삽질하던 그 수 많은 세월을 지나서 지금의 WSL을 만난 것이다. 프로그램을 하다보면 근원적 근본적으로 해결되지 않는 수 많은 문제와 개발만 하고 도망나온 수 많은 프로젝트가 있다는 것을 우리 또는 미래의 우리들은 알아야 한다. 그 많은 것들이 크로스 플랫폼 또는 유저가 원하는 그 간단하지 않은 간단한 포팅들을 간단하다고 거짓말하며 지금에 왔다. 서론이 너무도 길었다. 너무 감동 먹었다는 이야기이다. 참고로 지금 현재 원도우 환경에서 개발하던 수 많은 프로젝트를 WSL로 옮기는 작업을 하거나 고려 중이다. 그 이유를 설명하고저 이 글을 쓴다. 그리고 현재는 완전히 불가능한 WSL의 문제점도 같이 고민해보고자 한다. WSL1과 WSL2는 과연 무엇이 다르기에 내가 5분만에 지운 옛날의 그것에 흥분하고 있는지 이 글을 읽는 분들에게 알리고 싶다. 드디어 우리는 로컬에서 리눅스 프로그램을 개발하고 git이나 svn에 커밋을 하고 리모트에서 컴파일을 하고 리모트에서 배포가 되는 환경을 리소스에 전혀 구애받지 않고 할 수 있다는 말임을 이것이 무엇을 말하는지 알아 주었으면 한다. 필자는 수 많은 기간 동안 수 많은 솔류션 회사를 다니면서  이 어려운 환경에서 개발 또는 유지보수를 하기위해서 주말과 휴가를 반납하고 심지어는 명절을 반납해야 했다. WSL2는 완벽한 커널을 가지고 있다. 그리고 부팅하지 않는다. wsl --list를 실행하면 내가 실행할 수 있는 리눅스 배포판가 디폴트로 실행될 os가 어떤것 인지 보여준다 그리고 wsl을 커맨드 창에 실행하는 즉시 구질구질한 리눅스 부팅 메세지 없이 바로 진짜 눈을 깜을 시간도 없이 즉시 실행된다. 그리고 apt(이젠 더이상 apt-get이라고 타이핑할 필요가 없다) update를 실행하면 업데이트 대상에 커널이 떡하니 보인다. 완벽한이란 말은 거짓말이 아니었다. 이 감동을 잠시만 진정한 다음 다음 차에 WSL을 까발려 보자. 한가지 아쉬움은 WSL은 아직 많은 것이 필요하다. 그 이야기를 해보고 싶다.