コンテナ
「コンテナ」というものが世間に広まってから、もう10年くらい経つだろうか。
かなり初期の頃から知ってはいたのだが、なかなか使う機会がなかった。VMでいいじゃん。ということでVM一辺倒であった。
数年前から業務で使い始めた。よくある使われ方で、開発環境の構築である。誰かのPCでは走るけど、俺のPCでは動かねえ、とかを防ぐために、環境を統一させる、という使い方である。ITの人たちには釈迦に説法である。
開発環境で一通り使い倒してみて、大変便利なものであることはわかったので、では、プロダクトでも使ってみよう、、、ということで、私が経営しているキャンプ場の予約システムをコンテナ化してみた。
- 動作環境
- python
- django + uwsgi + nginxリバプロ
- DBはsqlite3(ローカルファイル)
- その他pipライブラリ
- トラフィック
- セッション数としてせいぜい10/分。
この程度の環境である。
流行っているから、ということでkubernetesを使おうか、とも思ったが、さすがにオーバースペックであろう、ということで、普通にpodman運用にすることにした。素直にdockerにすればいいのに、とは思う。この辺り、素直じゃないところで私の性格を推測っていただけるかと思う。
さて、実際に予約システムをコンテナ化するのはそれほど苦労はしなかった。そりゃあ、元々動いている環境をコンテナの中に作るだけだから、それほど難しくはない。
難しかった、、、というか、納得ができるように運用する方法については、少し苦労をした。
まず、開発向きのコンテナの管理と、運用向きのコンテナ管理をどうするか、である。
元々同じディレクトリの中にDockerfileを入れて、develもprodも同じDockerfileを使うつもりでいた。どうせ同じコンテナイメージを作るだけだから、二重管理しないように同じものを使おう、という考えからである。
だが、pythonのソースコードをどこに置くか、で困った。どうやら世間的にはprodの場合は資材はコンテナの中に閉じ込めるのがベストプラクティスなようなので、そのようにした。develの場合は-vでbindマウントする。
そのため、Dockerfileは二つに分けた。develとprodのディレクトリで分けてしまう感じである。
これが最善かどうかわからないが、散々迷った挙句、自分の中ではこの運用にすることに決めた。
改めてdevelとprodで分ける運用にすると、今度はdjangoに外部からパラメータを渡す必要が出てきた。prodの場合はdebug=falseで、develの場合はdebug=trueで動かしたい、とか、dbの接続先(予約システムの場合はdevel用とprod用のsqlite3ファイルの場所)を切り替えたい、、、とか、パラメータとは少し違うが、cronのジョブをコンテナ内で動かすのか、ホストOSで動かすのか、、、等々。
これらはENVIRONMENTSファイルを用意し、devel用とprod用で定義するようにした。当然、djangoプロジェクトの方も、環境変数を読んで接続先等を切り替える必要がある。これが案外面倒であった。
これらに対応し、めでたくコンテナ化できた。2日前にユーザーに送るリマインドメールのジョブも動くし、キャンプ場に設置してある各種Switchbotセンサーから環境情報を収集するAPIも動く。めでたしめでたし。
最初からコンテナありきで作っていたらもっと簡単にできたのだろうが、運用周りも含めて楽しく学習ができた。
次は無駄にk8s化してみるとするか。
