WSL(Windows Subsystem for Linux) 사용기 및 ArchLinux로의 전환

Windows 10에 WSL(Windows Subsystem for Linux) 기능이 추가되기 이전에는 SSH를 통해 미리 셋팅해둔 우분투 서버에 원격으로 접속하여 개발을 진행했었습니다. 하지만 원격으로 접속해야 한다는 단점을 비롯해 윈도우에서 사용할 수 있는 터미널 앱들은 24비트 트루컬러를 제대로 지원하지 않고 속도가 느린 문제점 때문에 주로 Butterfly Shell을 이용했었습니다.

여기까지의 이야기는 WSL을 접하기 전까지의 이야기입니다. WSL이 베타로 공개된 직후 이는 Bash on windows 로 불렸었는데, 베타 딱지가 붙어있는 동안은 실제로 사용하기에는 문제점이 많았습니다. 대표적으로 I/O 성능이 떨어지는 문제, drivefs(기존 windows 드라이브를 마운트 가능하게 하는 역할) 성능 문제, Ping이 되지 않는 문제 등이 있었습니다. Microsoft에서는 이러한 문제점들을 조속히 해결해 나가고자 WSL용 이슈 트래커를 운영하기 시작했고 많은 유저의 이슈 제보로 지금은 베타 딱지를 떼고(Build 1709) 정식으로 공개됐죠.

WSL의 공개는 매우 성공적이게 되었습니다. 더이상 개발을 위해 맥을 구입할 필요가 없게 되었고 Windows와의 자연스러운 연동으로 WSL에서는 런타임을, Windows 에서는 IDE를 사용하는 식의 개발도 가능하게 되었습니다 (참고: drivefs로 마운트한 경로에서만 Windows/WSL 동시작업이 가능합니다). 심지어 2016년 10월에는 INOTIFY 지원이 추가되어 Windows(drivefs)에서 변경한 파일의 변동/변경 이벤트까지 WSL에서 받을 수 있게 되었습니다. 덕분에 개발이 엄청 편해졌죠. :)

IDE는 Gogland EAP(맥에서는 vscode를 Go 개발에 사용했으나 gocode의 느린 성능때문에 Gogland로 갈아타게 되었습니다.), 터미널은 mintty(cmd보다 더 나은 color scheme 지원, 폰트 렌더링) + wslbridge(트루컬러 지원)를 사용했습니다. 실제 소스코드가 위치한 폴더는 /mnt/b인데 이는 실제 Windows에서의 B:에 대응합니다. WSL의 rootfs에서 직접 작업하면 되지 않겠냐고 생각하겠지만 Windows에서 WSL의 rootfs로 직접 접근하여 파일을 수정하는 행위는 rootfs 파일시스템이 망가질 수 있는 원인을 제공한다고 매뉴얼에 나와있기 때문에 drivefs로 마운트된 파일시스템에서 작업하는 것이 안전합니다. (성능은 조금 떨어지더라도 말이죠.)

ArchLinux

WSL을 사용하는 모든 면은 마음에 들었지만 하나 마음에 들지 않는 부분이 있었다면 바로 Ubuntu입니다. Ubuntu 레포 미러를 떠본 분들은 아시겠지만 Ubuntu의 경우 각 OS의 버전마다 패키지 버전이 정해져있고 따라서 Ubuntu 버전을 올리지 않는한 해당 Ubuntu 버전에서 제공되는 패키지보다 더 높은 버전의 패키지를 사용하기가 어렵습니다 (Pinning을 이용하면 특정 패키지만 상위 우분투 버전의 패키지로 사용하는 것이 가능해지긴 합니다). 심지어 실제 배포 환경(production)이 아닌 개발 환경에서도 LTS 버전의 Ubuntu를 사용하는 경우가 매우 많아 이 문제점은 더욱 돋보이게 됩니다.

보통 맥에서 개발을 할 때에는 homebrew를 이용해 가장 최신 버전의 패키지를 사용해 개발을 진행하기 때문에 이와 같은 문제점을 느끼기가 어렵습니다. 물론 linuxbrew를 이용하는 방법도 있지만 근본적인 원인은 해결되지 않기 때문에 결국에는 rolling release를 지원하는 리눅스 배포판을 이용하는 방법밖에 없습니다. 보통 글을 쓰는 본인은 개발 환경으로 앞서 말한 맥(+brew), Alpine(on docker, edge repo), ArchLinux를 사용하고 있습니다. 모두 rolling release로 패키지 매니저가 구성되어 있는 장점이 있죠.

계속해서 Ubuntu에서 귀찮게 개발하던 도중 Windows 10 Fall Creators (1709) 업데이트가 등장하게 되었고 Beta 딱지가 떼어진 기념으로 ArchLinux를 설치해보기로 했습니다. 다행히 ArchLinux 위키에 설치 방법이 자세히 나와있어 과정이 어렵지는 않았습니다.

과정은 다음과 같습니다:
(참고: Windows 10 1709에서 제공하는 Store 앱 대신 legacy WSL 환경으로 설치하는 것을 추천드립니다. 폴더 찾기가 너무 귀찮습니다..)

이미 WSL이 설치되어 있다면 lxrun /uninstall /full /y로 환경을 완전히 제거해줍니다.
lxrun /install /y로 WSL 환경을 셋업해줍니다.
WSL 셸에 root 계정으로 들어가 wget http://ftp.kaist.ac.kr/ArchLinux/iso/2017.10.01/archlinux-bootstrap-2017.10.01-x86_64.tar.gz 명령어로 archlinux bootstrapping 파일을 다운받습니다.
~/root.x86_64/etc/pacman.d/mirrorlist 파일을 에디터로 열어 서버 하나를 주석 해제합니다.
WSL이 자동으로 /etc/resolv.conf(DNS) 파일을 생성하도록 다음 명령어를 입력합니다: echo "# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line." > ~/root.x86_64/etc/resolv.conf
열려있는 모든 Bash 셸을 닫습니다.
%localappdata%\lxss\rootfs 경로로 가서 다음 폴더를 완전 삭제합니다: bin, etc, lib, lib64, sbin, usr, var.
이제 %localappdata%\lxss\rootfs\root\root.x86_64에 가서 위에서 삭제한 폴더를 그대로 이동(주의: 절대로 복사하면 안됩니다.)합니다. 폴더가 아닌 파일로 나올 수도 있으나 이는 WSL 파일 시스템(rootfs)과 Windows의 파일 시스템(NTFS, ReFS)이 완전히 호환되지 않기 때문입니다.
다른 리눅스 환경에서 fakeroot-tcp 패키지와 glibc-wsl 패키지를 빌드합니다. 2017년 10월 19일 기준으로 미리 빌드해둔 파일은 glibc-wsl.pkg.tar.xz, fakeroot-tcp.pkg.tar.xz 링크를 클릭해 받으시면 됩니다.

WSL 셸에서 다음 명령어를 입력합니다:

# pacman-key --init
# pacman-key --populate archlinux

위에서 빌드한 패키지를 pacman --force -U glibc-wsl.pkg.tar.xz, pacman --force -U fakeroot-tcp.pkg.tar.xz 명령어로 설치해줍니다.
pacman -Syyu base base-devel 명령어로 셋업해줍니다. (주의: 이 과정에서 glibc, fakeroot-tcp 패키지가 덮어씌워질 수 있습니다, 만약 덮어씌워진 경우 11번을 반복하시면 됩니다.)

사용자를 등록하고 암호를 설정해줍니다:

# useradd -m -G wheel -s /bin/bash username
# passwd root
# passwd username

WSL 셸에서 빠져나와 다음 명령어로 기본 사용자를 지정해줍니다: lxrun /setdefaultuser username

설치 끝! 이제 ArchLinux를 열심히 즐기면 됩니다. :)

WSL에서의 개발 환경은 실제 리눅스에서 개발하는 것과 완전히 동일하기 때문에 Windows에서도 이제 상당히 편하게 리눅스 환경을 사용할 수 있게 되었습니다. 이렇게 하나하나 맥만의 장점이 사라지는 것이 아쉽기도 하지만 더욱 좋고 다양한 환경에서 개발자가 개발을 할 수 있게된 부분은 굉장히 높게 칠만한 부분이라고 생각합니다. :)