ここでコンテナとは Docker コンテナのことであり、主に開発・検証用途で使うコンテナのソースとイメージの管理方法について、今までの気づきを残しておきたいと思います。
Dockerfile や docker-compose の最新状況についてキャッチアップしていないところもあるので、ご了承ください。
コンテナといっても、使う用途はさまざまで、主にライフサイクルによって以下のようなレベルがあると思います。
これは管理不要でしょう。味見が終了して活用するため更に検証が必要となったら、次のレベルに上がります。
ここからは Git でソースや設定ファイルを管理し、万一環境が飛んだ時にも復旧できる様にしておいた方が良いでしょう。
この段階では何度でもビルドすればよいので、ビルドイメージの保存は不要です。
育成が終わり、いよいよ本番運用となった場合は、Git によるソース管理はもちろんのこと、すぐに再利用できる状態を作るためにビルドイメージの保存も重要です。
すでに頻繁にコンテナがビルドされないような枯れた環境でこそ、ビルドイメージのバックアップが大切になってきます。
それは、メンテの必要があり、久しぶりにコンテナをビルドしようとした場合、利用しているパッケージがセキュリティなどの理由により取得できなくなっている可能性があるためです。
イメージさえ取っておけば、ビルドができなくても元に戻すことはできます。
コンテナは小さいほうが良いということでスリム化を目指しますが、過度にスリム化目指すと必要なツール類が入っておらず実運用で苦労したり、何より試行錯誤を繰り返すため、開発に膨大な時間がかかります。コンテナサイズは過度に気にせず、動くことを最優先に構築するとよいと思います。
管理が面倒で１つのリポジトリで沢山のコンテナを管理したところ、欲張って育成中のコンテナを沢山発生させてしまい、いざ使おうと思ってもそのコンテナ部分のソースだけを抽出できず、、、
本来はビルド済みイメージだけを使うのでソースは関係ないと思いがちですが、docker-compose ファイルを参考にしたり、それをまた編集してコミットしたり、意外にソース側も使うことが多くあります。本来、本番環境はフォークしたリポジトリで運用することが前提ではありますが、リリースしたてのコンテナは運用中に成長することもあるため、オリジナルのリポジトリをそのまま使いたいということは、少なからずあると思います。
まだ、docker-compose が世に出る前、複数の Docker コンテナを使ったシステムを作りました。そのコンテナ間の連携に Python の fabric というパッケージを使って各種設定ファイルを変更したり、起動したりする運用スクリプトを作っていました。
そのこと自体悪いことではないのですが、Dockerfile を作る手間に加えて、運用スクリプトを作りメンテナンスする負担が大きくなりすぎ、自分を苦しめ始めました。
そもそもシステム構成が大げさすぎたのも一因です。ちょっとした Web アプリケーションに対し、GlusterFS によるファイル共有環境やMySQL レプリケーションと HAProxy による データベースのクラスター化など、やりすぎました。。。
運用を自動化し楽をするためにスクリプトを作ったハズですが、レアな運用ケースなどに対応できず、かえってスクリプトを運用することが負担になってきました。
特に運用が自分ひとりしかいない場合は、中途半端なスクリプトで自動化を目指すよりも、自分を苦しめているものは何かを明確にし、どうやったら運用負担が少なくなるかを試行錯誤した方が良いでしょう。
とはいえ、コンテナ運用ではないですが、自動化をして楽になったことも沢山あります。定期バックアップなどはその良い例です。
個人的には Rundeck による運用が気に入っていますが、それはまた別の機会にご紹介したいと思います。
また、上記は docker-compose がなかった頃に構築したシステムの話であり、今は何かしらコンテナ間連携が必要なものは Dockerfile と docker-compose 関連ファイルで完結すれば、余計なメンテナンスが不要になります。