Docker에서 사용할 베이스 이미지로는 레드헷 계열보다는 페도라 계열이 나은 것 같다.

블로그에서 볼 수 있다시피 나는 컨테이너 베이스이미지로 CentOS를 택했다. 하지만 그 과정에서 크고작은 이슈가 있었다. 대표적으로 systemd를 사용할 때 나는 failed to get D-Bus connection: Operation not permitted 에러가 있다. 이에 대한 해결책은 블로그에 올려뒀지만... 이 CentOS를 베이스이미지로 한 컨테이너를 쿠버네티스나 GCP에서 제공하는 컨테이너 전용 인스턴스에서 돌려보려 했는데 잡음이 많았다.
 바로 몇 줄 위에 있는 failed to get- 에러가 지속적으로 발생했던 데다가 docker-machine상에서 돌아가는 구조와 실제 프로덕션 환경에서 돌아가는 구조가 달랐기 때문에 내가 아는 방법을 적용하기에도 난항이었고 애초에 이렇게 빌드만 해서는 작동을 안한다는 것 자체가 조금 docker를 쓴다는 의미가 퇴색되는 것 같았다.
 사실 docker같은 컨테이너 툴을 쓴다는 게 여러가지 의도가 있겠거니 싶지만 그 중에서도 가장 큰 게 지속적통합(CI : Continuous Integration)때문이라는 생각이 크다. 손쉬운 빌드와 무중단배포(는 물론 docker만으로는 안되고 docker swarm이나 kubernetes등을 사용해야겠지만 그 기반이 docker container이므로). 그리고 어떤 컴퓨터에서든 실제 배포환경과 동일한 개발환경을 구성할 수 있다는 점 때문에 docker를 쓰는 것일 텐데 CentOS가 베이스인 컨테이너 이미지는 단순 docker push및 pull을 통한 이미지 공유로는 완벽하게 작동하지 않는다. 이게 가장 큰 단점이다.

 CentOS이미지를 썼을 때 단순히 privilege옵션을 줘야한다든가, 환경변수설정을 해줘야한다든가 하는 단순한 문제이면 CI툴로 해결이 되겠지만 CentOS이미지를 온전히 돌리기 위해서는 OS상에서의 어떠한 액션이 필수된다. 이게 가장 치명적인 단점이다. 사실 이런저런 방법을 강구해서 지속통합배포환경을 만드는 이유가 이 과정들을 편하게 하기 위해서인데 CentOS이미지를 쓰는 순간 이게 불편해진다. Ubuntu에 nginx가 깔린 컨테이너라 가정했을 때(포트 설정 같은 건 전부 돼있다는 가정 하에) 그냥 이 컨테이너를 커밋, 푸시해서 프로덕션 환경에서 통합시킨 다음에 안에 들어가서 nginx라는 명령어만 써주면 된다. 아니 아예 이 명령어조차 빌드되면 실행되게 만들어 그냥 신경쓰지 않아도 된다. 하지만 CentOS는 다르다. 그냥으로는 안 된다. 직접 서버에 들어가서 뭔가 액션을 취해야 한다. 여기에서 컨테이너를 사용한다는 것에 대한 의미가 퇴색된다는 점이다.

사실 나도 CentOS를 써왔고 애정도 있어서 억지로라도 CentOS를 컨테이너화해서 프로덕션에까지 적용해보려 했는데 블로그에서 보면 알 수 있다시피 애초에 로컬환경에서 systemd를 사용하는 것부터가 고역이었다. 안맞는 단추를 억지로 끼어보려고 하다가 끝에 가서야 어긋나있는 끝부분을 본 느낌이다. 프로덕션환경에서 적용이 매끄럽지 않으니 이젠 어쩔 수 없다는 생각이 들었다. 이젠 그냥 베이스이미지를 우분투리눅스로 하여 작업할 예정이다. 사실상 내가 썼던 docker로 CentOS systemd사용하기는 CentOS가 프로덕션환경인 웹앱의 로컬개발환경을 꾸리는 데에나 유용할 것 같다.

p.s : '나은 것 같다'고 제목을 지은 이유는 CentOS이미지로ubuntu이미지 처럼 간단하게 운영할 수 있는 방법에 대해서 내가 아직 모르기 때문이다. 내가 아는 지식에 한해서 이렇게 지었다.