開発環境をDockerコンテナでまるっと用意出来たらいいなぁと思い、最近ヒマがあったら9zillaというコードを書いてます
その過程で覚えた事をそろそろ忘れないようにメモ
Dockerfileを書く際のベストプラクティス
Best practices for writing Dockerfiles
よく読む。（ある程度作り終えてから途中で読んで目からウロコがボロボロ落ちた）
自分用Makefileを作る
Dockerfileから外部のDockerfileをインポートしたり、といった事は出来ないので、その実現方法としてMakefileを使う方法が推奨されています
Makefileを作る事により、以下のようなメリットがあります
- パーツ化して、再利用可能なDockerfileが書ける
- 長いdockerコマンドをMakefileに書いておく事で効率化
注意点として、Makefileを使ってDockerfileをビルドする場合、コード内の「//」は、C言語のコメントとして扱われるため、たとえば、
RUN git clone https://github.com/foo/bar.git
こんな行があった場合、make後に
RUN git clone https://
「//」以降が無視されるため注意。ダブルクォートで囲ったりするクセをつける。
RUN git clone "https://github.com/foo/bar.git"
Docker Volumeはuid=1000で統一する
Dockerはマウントしたvolumeをuid=1000,gid=1000で統一するため、これを意識して設計しておくとなにかとPermissionまわりの悩みが減る
HANDLING PERMISSIONS WITH DOCKER VOLUMES
また、今後マウント時にuidを指定出来るようにしよう、という動きもあるらしい
Make uid & gid configurable for shared volumes #7198
systemdからsupervisorに乗り換えた
コンテナ内でsystemdでデーモン管理を行う場合、docker run時に以下の条件を満たす必要があります
--privilegedオプションをつける- 起動コマンドは
/sbin/initにする
公開環境を--privileged運用するのはちょっとアレなので、どんな方法があるのか探っていた結果、supervisorに乗り換える事にしました
Dockerfile上に直接、
CMD /usr/bin/supervisord -n
って書いても動くんですが、私はbootstrap.shというのを作って、
#!/bin/bash
/usr/bin/supervisord -n
と書くようにしました
理由としては、9zilla-nginx-pythonで書いたbootstrap.shとかがそうなんですが、supervisor実行までに実行したいコマンドもなんかしら書けるように、bootstrap.shで統一するようにしてます