M.2 인터페이스 쓰는 SSD 설치하기

메인보드가 M.2 지원하는지만 보고 샀다가 설치하느라 땀 좀 뺌. 그거에 대한 후기.

  • 메인보드로 Gigabyte H170 Gaming 3 (DDR3버전)을 쓴다. 이전에 펌업하다가 보드 날려먹어서(…) 급하게 업그레이드한다고 DDR4로 못 넘어갔더니 오늘의 삽질에 지대한 공헌을.
  • 새 디스크 — 더 이상 디스크 가 들어있진 않은데 디스크라고 불러도 괜찮은가? — 로 샘숭 EVO 960 (M.2 인터페이스) 구입.
  • 현재 디스크로 SSD x 2 (샘숭 830 PRO, 840 PRO 하나씩) + HDD 하나 연결. (모두 SATA3)

이 상태에서 새로 산 M.2 인터페이스의 SSD를 연결하고 부팅했더니 BIOS에서 기존 디스크 3개가 모두 사라졌다?!
급하게 구글링해보니 나만 같은 현상을 목격한게 아님.

매뉴얼을 다운로드 받아서 보니, 대략,

  • PCIe lane 을 소진해서 특정 SATA포트가 disable 된다.
  • disable 되는 포트는 M.2 인터페이스 번호와 AHCI vs. RAID 구성에 따라다름.

정도의 상황. 좀 더 확인해보니,

  • M.2 + PCIe 면 SATA 0, 1, 2, 3이 비활성화.
  • 현재 디스크 3개가 0, 1, 3을 쓰고 있던 상황
  • 근데 DDR3 말고 DDR4 지원하는 버전의 보드는 M.2 인터페이스가 2개. 이 중 한쪽을 쓰면 SATA포트를 거의다 쓸 수 있다 억울하다 ㅠㅠ

이에 따라,

  • SSD 하나를 포기하고 — 안 그래도 그냥 스팀 파티션 — 제거.
  • SATA 4, 5 번에 SSD, HDD를 하나씩 연결.
  • BIOS 에서 부팅 순서 조정

…하고나니 잘 돈다. 좀 더 잘 알아보고 살걸. 스팀용 디스크만 확보하려던 거였는데 SSD만 하나 놀리게 된듯 Orz.

몇 년 만의 가전 제품 교체

결혼한지도 이제 거의 10년이라(…) 작년 – 올해 사이에 가전 제품들을 몇몇 교체하게 되었다. 작년에 교체한 건 전부 생활 가전이었지만 올해는 다르다 올해는 (???).

이번 주에는 의도치않게(?) 모니터 중 한 대와 PC용 스피커 교체. 교체한 것에 대한 간단한 리뷰.

우선 집에서 Dell U2408 과 Dell U2410 을 각각 아내와 내가 썼는데, U2408 쪽을 LG 27UD88 로 교체.
교체하면서 느낀 점을 두서 없이 정리하면,

  • 역시 고해상도 모니터를 써야한다.
  • 현 세대 모니터들은 대부분(?) 베젤이 얇고 16:9 이 경우가 많아서, 책상 위 공간 차지하는 부분에선 Dell U2408 랑 거의 비슷함. (약간 좌우로 더 쓰는 정도?) 지금은 좌우로 좀 긴 책상을 컴퓨터 사용하는 용도로 아내와 같이 쓰는데, 다른 모니터를 1~2년 후에 27″ 혹은 28″ 로 바꿔도 딱히 더 책상이 좁아지진 않겠다 싶음. 베젤 얇은 것처럼 앞/뒤 두께도 얇아서 좀 더 시원한 것 같기도하고…
  • 사기 전에 매장에 전시품이 없어서(…) 스펙만 확인하고 샀는데, 이게 틸트, 높이 조절은 되는데 설치하고 보니 바닥판 부분이 (수평방향으로) 회전이 안됨 -_-; 이거 좀 난감하다. 보는 방향 바꾸려면 몸을 일으켜서 모니터를 들어서 틀어야 한다.
  • 이것도 베젤 얇은 탓의 연장인 것 같은데, 전원 어댑터가 따로 있다. 이거 알았으면 이 모니터 안 사고 다른 거 샀을 듯 (전원 어댑터 별개인거 개빡침)
  • 본체 – 모니터 간 USB port 연결을 USB-C로 하는데, 구성품 중에 USB-C to USB-A 가 있어서 (C to C도 있음) 그걸로 연결; 다만 기본 길이가 짧다. 모니터 옆에 본체를 두는게 아니면 연결하기 곤란할 수도 있음. 이건 1.5m 정도는 해줘야 하지 않을까
  • HDMI 와 Display Port 케이블도 좀 짧은 느낌. 아슬아슬 하게 끼웠다.
  • 요즘 모니터라 HDMI가 두 개라서 그 부분은 잘 써먹었다. 닌텐도 스윗치가 HDMI 출력을 쓰는데 U2408 쪽에는 HDMI가 없다 (DP는 있음). 그래서 부득이하게 출력을 내 모니터로 돌려서 플레이하고 그랬음 -_-;; 이건 이제 해소. 그리고 사운드 출력 선도 (본체 혹은 닌텐도) — (HDMI) — (모니터) — 3.5 ϕ 연결 — 스피커 쪽 line-in 으로 처리해서 선이 하나 줄었다. (이전에는 line-in 을 닌텐도 할 때마다 수동으로 바꿔 낌)
  • 전원 어댑터에서 전원 공급받는 부분 바로 위에 3.5 ϕ 출력이 있다. 그래서 thermal noise 가 출력에 꽤 낀다; 이건 며칠 뒤에 구입한 스피커랑 연결할 때 문제가 좀 되었음.
  • …모니터 자체 리뷰는 아니지만 Windows 10 현재 버전은 Hi-DPI지원이 꽤 멀쩡해진듯. 7 때의 그 괴로운 상태는 벗어난 것 같다.

그리고 13년째 사용한 Creative GigaWorks G500 스피커도 폐기하기로 하고, Bose Companion 20 을 구입. 아무리 생각해도 아파트에서 우퍼는 무리인 것 같고, 발치에 걷어차이는 것도 매우 괴로워서, 우퍼 없이 가기로.

  • 매장에서 청음은 해보고 (큰 기대는 안하고) 샀는데, 집에 와서 들어보니 생각 외로 유닛 크기 작은 것에 비해서 소리가 해상도가 꽤 높고 볼륨도 커서 놀랐음. (사실 직전에 사운드 바도 청음해서 그런 것 같긴함)
  • 곶통스럽게도 이것도 전원 유닛이 별도다. (전원선 – 어댑터 – 우측 스피커로 들어가는 구조) 모니터 때와 마찬가지로 이 부분은 매장에서는 안 보여서 그냥 넘어갔다. ㅠㅠㅠㅠㅠㅠ; 이전 스피커는 우퍼 유닛이 아주 커서 그 내부에 전원부가 있어서 어댑터는 따로 없었다.
  • 대체 파워 코드는 왜 각 지역별 코드를 다 포함하는가. (전원 코드가 4갠가 5개 들어있음)
  • 기본 포함한 3.5 ϕ 케이블이 왜 이렇게 노이즈를 잘 전달하는진 모르겠지만 라인-인에 넣지 않은 쪽을 손에 쥐기만 해도 스피커 쪽에 노이즈가 와장창; 그래서인지 엘지 모니터 쪽을 이걸로 연결하면 아주 그냥 혼파망.
  • 그래서 다른 PC쪽을 그 케이블로 연결하고, 새 모니터와 스피커 사이는 다른 케이블로 연결하니 노이즈가 거의 안 끼더라. (최대 볼륨 근처에서나 희미하게 들림) 일단은 이 셋업을 한동안 유지하기로…

…역시 새 물건을 써야 삶이 편하네요. 수동으로 오디오 케이블 바꿔끼기 너무나도 고통스러웠었다. 이젠 더 안해도 되겠지만.
하지만 전원 어댑터가 늘어서 이 꼴보기 싫은걸 수납할 선반을 주문함.
내일 배송 예정이라 뜨는데, 제발 로켓 배송 힘을 내 줘(…).

Linux 게임 서버 성능 평가 (eBPF + BCC)

어제 발표에 썼던 슬라이드.
어제 발표에 와주신 분들 감사합니다.

Linux 커널의 내장 트레이싱 기능인 eBPF 와 이를 위한 BCC 툴킷을 써서 동작 중인 프로세스를 분석해서 성능 문제를 찾는 방법을 설명했다.
머지 않은 미래에 안드로이드 성능 측정도 이걸로 할 수 있을 듯하니, 서버 뿐만 아니라 안드로이드 기기에서 개발하는 분들도 한 번 보시라.

eBFP +BCC 는 간단히 요약하면, python (혹은 go, lua) 으로 통계 처리 및 초기화, 몇줄 안되는 C코드로 커널 내부에서 후킹/통계 수집을 하고, 수집할 수 있는 범위가 넓어서 (커널 함수부터 유저 함수까지) 성능 분석 / 디버깅 쪽에 유용한 툴이다.
최신 커널이 필요하긴 하지만 재시작/빌드없이 측정할 수 있다는 점에서 매우 매력적인 툴이다.

그리고 예제로는 C++ HTTP API 서버를 만들었다. 하재승 군이 만든 Crow 와 이것의 사촌쯤될 데이터베이스 래퍼 CrowDB 를 썼다. 내가 쓴건 아직 비공개 버전.
덕분에 C++ 1y 로 매우 편안하게 짰다.

Jenkins 2.x DSL 적용기

설 직전에 사용 중인 jenkins 서버가 버전이 올라갔다. 그리고 악몽(?)의 시작…

대략,

  • 플랫폼 별 병렬 빌드를 위해 사용하던 buildflow 플러그인 결과물이 사라지는 현상
  • 프로젝트 설정에서 buildflow 스크립트를 확인하거나 편집할 수 없는 현상

이 생겼다.

근데 최악의 문제는 아니었던게, 결과물이 보이지만 않고 서버 머신의 디스크에는 남아있더란; 비슷하게, buildflow 스크립트도 display: none 로 처리하고 있어서 스타일 수정하고나니 보이긴하더라.

Jenkins wiki에서는 새 DSL인 pipeline plugin으로 넘어가라고 한다. 그래서 이전 작업을 시작;

  • Buildflow 의 병렬 빌드에 해당하는 parallel 태스크는 있다.
  • Parameter 넘기는게 미묘하게 다르긴한데 — 어차피 groovy 이긴 함 — 약간의 삽질 후에는 성공
  • Artifact 복사해올 때 이전에는 buildflow toolbox 를 썼는데, “Copy Artifact Plugin” 을 설치하고야 처리할 수 있었다.
  • Gerrit trigger 메뉴가 없어서 당황; Gerrit trigger 를 클릭하고, 추가로 뜨는 gerrit 주소 설정을 추가하고 나서야 동작한다.
  • Artifact archive 관련해서, 패턴 매칭에 실패하면 오류 처리한다. [이건 이미 해결된 이슈로 있더라. 오류 처리 끄는 플래그가 있음](https://issues.jenkins-ci.org/browse/JENKINS-38005)
  • Downstream 프로젝트들을 빌드 성공 후 트리거해야하는데, 트리거하고 종료하는게 없어서 ?! 했는데, build job 패러미터로 wait: false 를 주면 되긴하더라.

이렇게 작업일 1일+를 날리면서 느낀 좋은 점을 요약해보자면.

  • 새 DSL 로 모든 플러그인 / 작업 기능을 내보내고 있어서 설정 백업이나 신규 버전으로의 이전 작업은 어느 정도 편하게 할 수 있을 듯 하다.
  • 심지어, DSL 을 Jenkinsfile 이란 이름으로 저장소에 포함하는 것도 가능하다.
  • 새로운 선언형 (declarative) 와 기존의 스크립트스러운 빌드 방식을 모두 포함한다.
  • 이 기반으로 작성하면 기존보다 훨씬 나은 시각화를 제공한다.

물론 좋기만 할리가.

  • 새 DSL은 만들었는데, jenkins 없이 이걸 시험해볼 방법은 없다. 다만 replay 기능을 쓰면 점진적으로 문제를 찾는건 가능하다. 빌드 시간이 길다면야 이걸로 나아지는게 많지 않긴 한데;
  • 선언형과 절차형 모두 지원하는데, 양쪽을 동시에 쓰면 애로사항이 꽃핀다. 특히나 모르고 문서 뒤지던 초기에 이 차이를 모르고 튀어나오는 groovy / JVM exception 에 많이 당함.
  • Jenkins 2.x + pipeline 으로 넘어가면 과거로 돌아갈 수 없다. 아주 간단한 예로, 설정 파일을 **XML 1.1** 로 바꾼다. …대체 왜? 1.1 쓰는거 처음 봄. 다운그레이드했다가 잠시 지옥을 봤다.

여하튼; 새 DSL 부터 쓰는 사람은 꽤 편할지도? 나는 크게 당했지만.

Docker 로 Linux 없이 Linux 개발하기

지난 달 말 — 이미 10월 말인 것 같지만 다 기분탓 — 발표에 썼던 슬라이드.

Windows + VisualStudio / macOS + Nuclide 환경에서 내부에 같이 띄운 docker container에 접근해서 C++ 프로그래밍을 디버깅 하는 내용을 다뤘다. 기록 차원에서 블로그 글로도 남긴다.

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. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

Interop Madness

클라이언트 서버간 암호화  관련해서 개념 증명 + 몇 가지 성능 측정을 해야해서 몇 가지 언어 + 플랫폼에서 libsodium 1 을 호출해봤다. 그 와중에 겪은 일 정리.

C++

이쪽은 평범한 C/C++ 인터페이스니 문제 없이 끝.

Python

위에서 구현한 부분을 클라이언트 쪽 구현을 (빨리) 만들어서 테스트하는 작업을 했다.

여기서부터 문제가 생기기 시작. Ubuntu 16.04 (xenial) 이 제공하는 libsodium 래퍼가 python-nacl 2 인데, 써보니 내가 쓰려는 함수가 여럿 없다. 특히 crypto_stream* 류 함수가 없더라. 그래서 다른 래퍼가 있나하고 PyPI 에서 몇 가지 써보고는 빠른 포기.

이제 cffi 를 쓸 타이밍. C 코드로 정의한 함수를 변환해서 만든  .py 파일로 동적 라이브러리 (.so, .dll, .dylib) 에서 가져오는 방식을 썼다. 3 예~전에 ctypes 로 로딩할 때 괴로웠던 부분이 확실히 줄어들었다. ABI 대신 API 수준에서 접근하는 차이는 정말 컸다. cdata의 buffer 인터페이스도 쓸만했다.

cffi 로 libsodium 에서 필요한 함수들을 가져다 쓰기 시작한 이후로는 금방 일이 정리.

…하지만 이 시점에선 어떤 비참한 미래가 기다리는지 모르고 있었다. (?)

C#

(나로써는) 슬프게도, 클라이언트 쪽 구현 중 하나는 C#으로 해야한다. (Unity3d + mono) 게다가 이건 여러 플랫폼을 지원해야 한다:

  • Unity Editor: Windows, MacOS
  • Android: 다행히도 ARMv7만. Unity가 ARMv6는 지원하지 않는다 (?)
  • iOS: 기기 + 시뮬레이터에서 모두 돌아야 한다.

Windows는 (내가) 당장 쓸 머신이 없어서 일단 미뤄두고, 나머지에 대해서 잘 도는지 시험하기 시작. 꼬박 2일 걸린 것 같다 — 생각해보니 절반은 C++ 기반인 cocos2d 랑 같이 처리하는 것 때문이었던 것 같기도?

우선 각 플랫폼 별로 크로스 빌드를 시도…해야하나 했는데, libsoidum 저장소에 플랫폼 별 빌드 스크립트가 있다. 4 iOS/Android 쪽에 내가 쓰려던 함수 중 몇 개가 빠져서 컴파일 플래그를 조금 고친 것 말고는 별 일 없이 진행. 그리고 Unity 에서 (native) 동적 라이브러리를 어떻게 가져가나 고민했는데 경험 많은 동료분이 설명해주셔서 매우 간단한게 통과.

대략,

  • DllImport 로  C에 있는 함수들을 CLR 쪽에 노출하고
  • C# 코드로 이 함수들을 래핑하고
  • 다시 이 함수들을 써서 실제 개발자가 쓸 고수준 API로 바꾸자

라는 방향으로 진행했다. 에디터(=랩탑 위)에서 잘 도는걸 보고 android  기기에 올리기 시작. 왠걸, 초기화 (=sodium_init()) 은 성공했고 몇몇 초기화도 했는데, 그 이후에 호출하는 함수에서 크래시 (SIGSEGV).  (당연하게도) 콜 스택은 native code에서 죽는 것.

원인을 추측하기 시작:

  • C 함수 원형을 잘못보고 옮겼는지 확인 시작. C는 타입 무시하고 심볼 이름만 보니 내가 잘못 옮겼다면 크래시할 수도 있으니 우선 여길 의심하고 C 함수 원형과 하나씩 대조. 별 이상 없어 보였다 (불행의 단초)
  • 크로스 컴파일을 잘못했는가 확인: 생각해보니 C/C++ 로 올렸을 때는 잘 돌았다 (…)

…대략 정신이 멍해져오는데 다시 함수 원형을 보다가 불현듯 깨달은 사실:

C 쪽의 size_t 를 C#의 ulong 으로 지정했는데 Unity + ARMv7 은 32bit ABI를 쓰니 uint 여야하는 것. Orz.

그래서 이걸 iOS / Android 플래그로 ulong / uint 처리하게 했다가, iOS도 아직 32bit인게 남아있는 걸 보고는 (iPhone 5 및 그 이전 + iPhone 5C) UIntPtr 로 처리하고 강제 캐스팅하게 수정해서 마무리했다. 그러고나니 잘 돌더라.

 

3줄 요약

  • ABI 맞추기는 삽질이다. 어떻게든 API 수준으로 해결할 수 있는 법을 찾자 — python의 cffi 처럼. 아니면 기계적으로 처리할 방법을 찾아야?
  • (부득이하게) ABI를 맞춰야 한다면 가능한 arch 목록을 잘 확인하자. C/C++에서 편했던 platform dependent type들이 대재앙
  • 여러 플랫폼 지원하는 라이브러리는 정말 인생에 도움이 된다. 잘 쓰고나면 널리 알려줍시다 (?)

 


  1. libsodium 페이지. 현 시점에 적합한 대칭키 암호화 + AEAD, ECC 함수들, system random source 를 래핑한 함수, side channel 공격을 피하는 비교, 해시, … 등등을 제공하는 잘 만든 라이브러리. 인터페이스도 보고 바로 쓰는게 그다지 어렵지 않다. 
  2. GitHub 저장소. libsodium 이 fork(?)한 NaCl 을 래핑한 것 같은 이름이지만 libsodium 을 래핑한다. 
  3. API 수준에서, 소스 코드 밖에서 정의 부분을 참고해서 작성했다. 
  4. 저장소의 dist-build 디렉터리 의 스크립트들이 이에 해당한다. 

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 의 성능 문제는 개선되지 않으면 못 쓸 정도

프로그래머의 일상: 험난한 python 패키징

제목처럼 거창한 건 아니지만.

웹 페이지에서 JSON web token (jwt) 를 쓸 일이 있어서 pyjwt 를 가져다 쓰기 시작했다. 근데 이걸 서비스 중인 vm들에 배포하려면 .deb 패키지로 묶어야 한다. Python 라이브러리를 .deb (간단하게) 패키징 할 때는 python-stdeb 패키지를 이용해서 간단히 묶어 버리고 있다 – 이건 기회가 되면 나중에 설명할 일이 있었으면 한다.

하지만 문제 발생:

$ python setup.py  --command-packages=stdeb.command bdist_deb
...
Traceback (most recent call last):
  File "setup.py", line 77, in 
    'jwt = jwt.__main__:main'
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/dist-packages/stdeb/command/bdist_deb.py", line 23, in run
    self.run_command('sdist_dsc')
  File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/lib/python2.7/dist-packages/stdeb/command/sdist_dsc.py", line 139, in run
    remove_expanded_source_dir=self.remove_expanded_source_dir,
  File "/usr/lib/python2.7/dist-packages/stdeb/util.py", line 1061, in build_dsc
    -- %(maintainer)s  %(date822)s\n"""%debinfo.__dict__)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

문제의 원인이 좀 어이 없었는데 – 달력을 확인한다면 데미지 두 배,

  • 저자 이름에 non-ascii 문자가 포함되어 있고 (저자의 이름이 José)
  • stdeb 에서 문자열 치환할 때 이 처리를 하지 않고 있는 것

해당 버그는 아직 처리 중인듯.

그래서 문제를 우회할 방법이 두 가진데,

  1. stdeb 버그를 수정한다; 이 경우엔 저 위의 오류난 곳의 __dict__ 의 unicode 타입인 걸 하나 하나 찾아서 encode('utf-8') 하는 것
  2. 문제를 부정한다 (?): …이러면 안될 것 같지만 저자 이름을 수정

일단 2로 우회했는데 – stdeb 도 우분투 패키지라 이걸 덮어쓰게 배포하기가 찜찜해서 – 외부에 배포할 일이 생기거나 하면 결국 1안으로 가야할 듯 하다. 혹은 더 복잡한 다른 패키지 .deb로 만들 때 처럼 debian 파일들을 다 만들거나.

요약 (?)

  • Python 모듈을 .deb 로 변환하는 python-stdeb 패키지가 있다.
  • 근데 이 패키지가 unicode 를 제대로 못 다루는 부분이 있다.
  • 엄한 우회책은 있지만 매우 괴롭다. 지금 2016년인데…