Docker + C++ IDE 개발환경 꾸려보기

Windows / macOS 용 docker를 이용하면 VM을 따로 띄우지 않아도 로컬 환경을 리눅스 개발 환경처럼 쓸 수 있다.
전에도 한 얘기지만, 툴은 가능하면 해당 OS 용의 GUI 도구를 활용하고 싶은게 내 심정.

그래서 (?) 요즘 나오는 좋을 툴들을 써서 Windows / macOS를 쓰는 기기에서 docker + linux 개발환경을 해당 OS 용 IDE 로 개발하게 꾸려보았다. (컴파일은 linux 컨테이너, 디버거 UI는 호스트 OS의 IDE를 쓴단 소리)

Windows

Widows 의 VisualStudio 확장 기능으로 linux  개발을 지원하는 Visual C++ Tools for Linux 라는게 있다. 지난 2016-09-06 에 업데이트.

이걸 써서 같은 컴퓨터에 띄운 docker 컨테이너에 접근하면, 디버거까지 붙여서 돌려볼 수 있다.
하재승 군의 crow 예제 하나를 디버거 붙여보면 잘 돈다.

vs-debugging

다만 고칠게 좀 많다:

  • Docker for Windows 의 volume 설정이 좀 이상한 것
  • 권한을 추가로 주지 않으면 잘 안 도는 것 (디버깅)
  • 빌드/디버깅/빌드 결과물을 한땀한땀 입력해야하는 것 (…)

macOS

macOS 용으론 Facebook 의 Nuclide 가 있다. 여기서도 crow 예제를 돌려보았다.mac-nuclide-io

macOS 에 띄운 docker 컨테이너에서 프로세스를 띄우고, lldb (GDB가 아니라…) 를 띄워 디버깅하는게 가능하다. 다만 의존성 걸린게 많아서 내가 만들어본 역대 최대 크기 (1.1 GiB) 짜리 docker 이미지가 나오더라; 용량은 차치하고, Docker for macOS 쪽이 volume 지원같은게 낫긴하지만 이쪽도 문제는 한 바가지긴 하다.

  • 설정을 한땀한땀 넣어야한다. (VS 쪽보다 아주 약간 편함)
  • 깔아야하는게 한 가득 (atom, nuclide, npm, clang, llvm, lldb, … 그리고 clang, llvm, lldb 에 대한 python 래퍼)
  • 테스트 한다고 썼던 ubuntu 16.04 에선 라이브러리 내의 경로가 잘못 박힌게 많아서 고쳐써야할 부분도 많다 (ubuntu 14.04 쪽도 크게 다르지 않으리라 생각)

이런 내용을 포함해서 이번 주 수요일 (2016-09-28) 에 넥슨 코리아 지하에서 기술 세미나를 합니다. 궁금하신 분은 와서 보시길.

Linux 용 데스크탑 앱 훑어보기

요즘은 web 대신 app 으로 나오는게 유행인 것 같기도 하다. 모바일만 그런게 아니고 데스크탑도 약간 그런 것 같은데, 내가 쓰는 툴 중에 자주 쓰는 것 몇 가지도 이런 식.

이 중 두 가지가 내게 익숙한 .deb 1 형식이길래 두 가지를 뜯어봤다. 하나는 slack 이고, 나머지 하나는 WordPress.com 이다.

dpkg-deb -R 명령으로 아카이브된 것을 까보면, 대략 다음과 같은 파일들이 있다:

  • desktop 앱을 위한 파일들 (wpcom.desktop, slack.desktop)
  • node_modules (와 .asar 파일들)
  • elctron
  • libffmpeg.so

특이하게도 slack 쪽엔 cron.d 룰이 있었는데, 여기서 apt 저장소를 설정한다. 이건 좀 이상한듯. 왜 설치 후 스크립트 (postinst) 를 쓰거나, 다른 오픈소스 도구처럼 저장소 자체를 안내하는게 더 좋아보이는데 대체 왜 이럴까. 여담으로, package cloud 란 서비스를 쓰더라. 미리 알았다면 나라도 쓸 것 같이 생겼다 (apt, yum, pypi 저장소랑 몇 가지 더를 지원하는듯)

리눅스 데스트탑이니, GNOME desktop app 형식을 쓴다. 그리고 리눅스 전용으로 만들진 않을테니 electron 을 이용해서 만든다. 자연스럽게 (?) 묶는 것도 electron archive 형식 으로 처리한다.

Atom/Electron 기반의 앱들은 이제 정말 주류가 된 것 같다. MS의 Visual Studio Code나 Facebook 의 nuclide.io 도 그렇고. WordPress 는 PHP를 탈피해서 API 기반 + JavaScript 로 관리자 페이지 다시 만든다고 시작한 Calypso 프로젝트 결과물로 데스크탑 앱을 내놓기 시작했던 것 같다. Slack 쪽도 이번 데스크탑 앱 베타부터 프레임웍을 바꾼 모양…

플랫폼이 파편화되면서 오픈소스 도구나 프로그램들 — 특히 기업이 직접 개발하거나 지원하는 — 쪽이 크로스 플랫폼 라이브러리/프레임웍을 더 많이 쓰다보니 역으로 Mac/linux 데스크탑 환경 쓰는 나같은 사람에겐 더 편한 세상이 되어가는듯.

Update: libffmpeg.so 관련 – @lqez 님 제보로 업데이트 electron 이 chromium에 의존하고, chromium 이 proprietary codec 처리 때문에 libffmpeg 에 의존해서 그렇다 합니다.

 


  1. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

Docker for Mac 베타 사용기

연휴 내내 하루 빼고 일하다가 드디어 짬이 났다. 그래서 한 달 반쯤 전에 공개된 Docker for Mac 을 써보기 시작. 베타용 토큰도 지난 주에 받아서 사실 그 전엔 시간 났어도 못 써봤겠지만.

일단 내 희망 사항인 linux 툴들과 Mac 용 GUI 툴을 같이 쓰는 걸 시도해봤다. 대략 docker volume 으로 로컬 디렉터리를 컨테이너에 마운트해서,

  • MacOSX 환경에서 GUI 툴을 가져다 쓸 수 있을 것: 예를 들어 git mergetoolp4merge 를 쓴다거나
  • linux 몇 가지 distro. — 특히 ubuntu 14.04/16.04, CentOS 6/7 — 에 대해서 빌드 환경을 쉽게 불러내서 사용할 수 있을 것: 예를 들어 ubuntu 14.04 gcc4 에서 빌드 + 테스트해보고 + centos 6 (w/ devtoolset) 에서 빌드 + 테스트해보기 등.

이었다.

VirtualBOX 를 중간에 껴 넣는 대신, xhyve 를 써서 상대적으로 더 빠를 것 + volume 이 제대로 동작할 걸 기대했다. 대략 기대한대로 돌았는데 …

CentOS 7 컨테이너에서 빌드를 시작했더니 끝나질 않아서 activity monitor 를 열어보니 상태가 심각하다:

something-wrong

Docker volume 을 위한 구현체인 com.docker.osxfs 가 CPU 를 다 잡아먹고 있다. Docker volume 아닌 곳에서 빌드해보면 그 차이가 더 뚜렷함. (com.docker.xhyve 가 CPU를 다 쓴다)

something-acceptable

VMware Fusion 도 그러던데, Docker for Mac 도 CPU core 수 최대 값을 4개로 잡는다 — 12″ 맥북에서 무슨 만행을… 이것도 2개로 설정. (기본 값이 2개였는데, 메모리 늘리면서 생각없이 늘려서 Orz)

docker-setting-cpu-cores

설정 자체는 원하는 방향으로 가능해졌지만, docker volume (=osxfs) 관련은 앞으로 더 패치된 후에 성능이 나아지길 기대해야. 아니면 지금처럼 build 디렉터리를 docker volume 외부에 두는 식으로 해야할 것 같다;;;

요약

  • GUI 는 Mac에서, 개발툴은 linux 에서 이용하는 (내가 생각하는) 이상적인 휴대 작업 환경이 가능해 짐
  • boot2docker 등과 달리 정식으로 docker volume 을 지원하고, OSX 에서 직접 hypervisor 를 제어하는건 좋음 (메모리, 디스크, …)
  • osxfs 를 이용한 docker volume 의 성능 문제는 개선되지 않으면 못 쓸 정도

프로그래머의 일상: 어떤 디스크 풀

커널 보안 취약점 때문에 회사에서 쓰는 VM들을 패치하고 있는데, 디스크 풀이 뜬다.

?!?!?!?!

디스크 풀은 다른 방식으로 감지하고 있어서 대체 뭘까 하고 고민하다가, 같이 일하는 수원님이 “inode 풀 아니냐” 라고 하시기에,

$ df -i 
Filesystem Inodes IUsed IFree IUse% Mounted on 
/dev/xvda1 524288 517380 6908 99% / 
none 127041 2 127039 1% /sys/fs/cgroup 
udev 125746 388 125358 1% /dev 
tmpfs 127041 318 126723 1% /run 
none 127041 1 127040 1% /run/lock 
none 127041 1 127040 1% /run/shm 
none 127041 2 127039 1% /run/user

그것이 실제로 일어났습니다?

뭐가 이렇게 inode를 다 쓰고 있나 했더니 신경 안 썼던 리눅스 헤더 패키지 (linux-headers-{version}, linux-headers-{version}-generic) 가 inode를 다 쓰고 있더란;

$ find /usr/src/linux-headers-3.13.0-76-generic/ /usr/src/linux-headers-3.13.0-76 | wc -l
24813

버전마다 25k 정도 쓰고 있는데, 총 inode가 520k; 근데 헤더 패키지가 20개 깔려있더라.
dpkg -P 로 몇 개 헤더 패키지를 지우고 나니 설치가 정상적으로 설치가 된다.

세 줄 요약:

  • 디스크 풀은 디스크 용량이 아니라 inode가 모자라서 날 수도 있다.
  • df -h 말고 df -i 도 보자.
  • 리눅스 헤더 패키지 싸우자 (…주기적으로 obosolete 패키지를 제거합시다 (…))

프로그래머의 일상: 소프트웨어 패키징하기

지금 일하는 회사에서 판매하는 제품은 대략 개별 linux 에서 쓸 수 있는 패키지로 생성한다. 원래는 Ubuntu 12.04 기반에서 시작한 작업이 Ubuntu 14.04가 나왔고, CentOS 7을 지원하기 시작했고, 그러다가 -_- Centos 6.x 지원도 포함된 상황.

하여간 그래서 겪는 문제가:

  •  서비스를 띄우는 방법이 다르다Ubuntu 12.04 / 14.04, CentOS 6.x는 upstart 기반 (혹은 init script를 써야); 반면에 CentOS 7은 systemd 기반
  • 패키징 방식의 차이: 아시다시피 Ubuntu는 .deb, CentOS는 .rpm 기반
  • 툴 체인 차이 (컴파일러나 cmake 류의 툴의 버전 차이)
  • 라이브러리 버전 문제 / 없는 라이브러리 문제

이걸 해결하려면 대략:

  • upstart / systemd 설정 파일을 각각 생성해 냄 -_-
  • 패키징 방식 차이는 그나마 cmake의 CPack으로 어느 정도는 해결 가능; 그렇지만 CPack도 버그가 꽤 많다 -_- (특히 RPM 패키징)
  • 툴 체인 차이는 낮은 쪽 기준으로 빌드되게 하는 수 밖에 없음. (CentOS 6.x의 GCC버전은 -_-)
  • 라이브러리 버전 문제: 별 문제 없는 경우도 많은데, 사용해야하는 기능이 더 높은 버전에 있는 경우 CentOS 6.x나 Ubuntu 12.04 용으로 패키징 해서 배포

정도의 작업을 해야 했다.

그리고 이제 Ubuntu 15.04 런치 소식을 보는데 systemd 로 옮겨간 걸 발견. LTS 릴리즈들 지원 기간을 생각하면 그냥 Ubuntu 버전 보고 systemd / upstart 중에 뭘 쓸지 지정해야 할테니 더 귀찮아지기만 할 듯. (그러니까 16.04는 systemd 일거란 얘기니까)

NDC 2014: 모바일 게임서비스를 위한 사설 클라우드 구축/운영 분투기

오늘 NDC 세션으로 발표한 슬라이드:

https://speakerdeck.com/reinkim/unyeong-buntugi

아쉬운 점:

신청할 때 내 잘못으로 50분 대신 25분 세션으로 신청해서 시간이 모자랐다.
원래는 문제 / 문제 원인 / 왜 이런 해결책을 선택했나를 설명하고 싶었는데, 시간도 짧고 해서 문제 / 대략적인 해결만 얘기한 듯.

보고 계시던 분 중 한 분이 “어디에도 낙원은 없다” 정도의 얘기를 하셨다는데, 내 감상만 얘기하자면 처음 개발/운영 시작할 때만해도 힘들었지만 지금은 꽤 편하다는 것.
하드웨어 인프라를 프로그래머 손 위에서 다루게만 해줘도 사람 손이 덜 가게되고, 자동화하는 영역이 늘었다는 얘기를 얘기할 자리가 생겼으면 좋겠음.

PS. 물론 새로 만든다면 꽤 많은 문제를 겪겠지만 저에게 컨택하시면 그런 문제를 겪지 않도록 저희 솔루션을 저렴한 가격 (하략) 에 모십니다 (?).

Linux 데스크탑에 ssd + hdd 구성이면 파티션은 어떻게?

내일 입사하시는 분이 사용할 용도로 데스크탑 머신 + 모니터(U2412M) 두 대가 왔다.

포장 풀고, 등록된 MAC 주소가지고 도메인 주소 설정하고, PXE 로 OS 설치 시작.

현재 설정된 preseed가 작년에 지급되던 데스크탑(i7-2600, hdd 구성) 기준이라, 이번에 지급되기 시작한 데스크탑(i5-3750, ssd + hdd 구성) 이랑 좀 안 맞아서 수동 설치를 해봤다.

좀 고민하다가 결국엔

  • / 와 swap 용으로 hdd를 (boot flag 걸고)
  • /home 용으로 ssd를

설정했다.

빌드를 하거나 뭘 하거나 대부분은 ssd에서 할테고, 프로그램 류는 한 번 page cache에 올라가선 아마 안 내려올테니 (…) 그냥 잘 돌거라고 믿기로 했다.

(먼산)

 

혹시 경험적으로, 혹은 측정치로 추천하는 구성이 있으시면 좀 알려주십시오 (…).

2012, 내 프로그래밍 언어는…

작년에 이어, 올해에도 twitter에 적은 #code212에 덧붙여 글 하나 쓰기.

올해 주로 사용한 언어는,

  • Python
  • Bash script
  • C++
  • JavaScript
  • C#
  • Go

정도의 순서인 듯 하다.

작년의 순서와는 상당히 달라졌는데 그 배경은 역시 이직.

Windows 에서 C++ 코드베이스에서 작업하던 환경에서, linux 위에서 python 코드베이스를 작업하니 바뀐 게 많지(…).

 

Python

회사를 옮긴 이후로 C++ 코드는 한 줄도 안 짜고 python을 주 언어로 작업했다.

분산 서비스 (w/ restful interface)와 그 프런트엔드에 해당하는 웹 앱, 그리고 이를 테스트하는 코드들을 다 python으로 구성했다. 올해는 정말 python은 징그럽게(?)만진 듯.

감상을 적자면,

  • 편하다; 사실 이건 작년의 주 언어가 C++이라?
  • 생각을 코드로 표현하는데 부분에 걸리는 시간엔 거의 C++ 수준에 다다를 정도로 쓴 것 같다
  • 상대적으로 “뭘 만들지”에 집중하고 “어떻게 만들지”에는 조금 덜 신경 쓴다

여하튼 python으로 작성한 서비스가 내년 중엔 아마 라이브로 전환 할 듯…

Bash script

Python으로 프로그램을 만들긴 하지만 이걸 실제로 배포하고, 설치하고, 설정하는 부분은 전부 bash script. 특히나 debian packaging하면서 갈수록 bash script 짜는 기술이 늘어가는 것 같다. 어흑

C++

이전 회사에선 주로 C++을 썼다. 그리고 2월 말까지는 C++로 코드 짰음 (사실 3월에 남은 날 수 출근할 때 C++ 코드 디버깅도 했다(…) )

JavaScript (w/ html, css, …)

Python으로 짠 서비스의 프런트엔드는 결국 html + JavaScript + css.

들어가서 바닥부터 만든 한 프런트엔드의 css를 직접 짜며 삽질하다가 bootstrap으로 바꾸고 신세계가 펼쳐졌다 (…).
내가 작성한 JavaScript는 IE에서 안 돌기도 하고 – 나중에 합류한 프런트엔드 엔지니어 분이 해결해 주심 – 하여간 삽질이 Orz.

초반엔 사람이 없어서 짰는데 요즘은 거의 손 댈 일이 없는 듯. 그래도 어제 포스팅 한 일 같은 류를 처리하려면 어느 정도 알긴 해야 할 것 같은데;

C#

작년에 C# 배우면서 짰던 프로그램을 퇴사하기 전까지 유지 보수하다가 나왔음. 지금은 그 회사의 A모 게임과 B모 게임이 쓰고 있을 거라던데 난 모르겠다 (야).

이젠 Windows 환경이 아니라서 더 이상 만질 일은 없을 듯. (작년 감상을 보고 생각해도 이건 잘 된 일?)

Go

Go로 동작하는 서비스를 작성하겠다는 야망을 품었으나… (내년에 계속?)

 

정리:

  • Python 코드베이스를 작성하는 일로 옮겨왔다
  • Linux로 옮겨왔으니 bash 나 기타 등등 만질 일이 늘어남
  • Go로 서비스 작성하고 싶다 (…)
  • 내년엔 C++ 만질 일이 생길지도…