本番でDockerを使うときに決めておくこと

レン

手元でdocker composeで動いたから、そのままVPSに持っていけばいいよね？

プロクラ

動くとは思うよ。ただ、手元と本番では前提が違うところがいくつかある。持ち込む前に決めておくと、後で慌てずに済む。

1. イメージをどう用意するか

• 本番のサーバー上でビルドする（手軽だが、資源を使う）
• 別の場所でビルドして、置き場所から取得する（本番の負荷が小さい）
• 小さいプランでは、ビルド中のメモリ不足に注意する
• 版を固定する（毎回最新を取る設定にすると、意図せず変わる）

プロクラ

4つめが重要だよ。最新版を自動で取る設定にしていると、再起動しただけで中身が変わることがある。動いていたものが動かなくなる原因になる。

2. 再起動したときの扱い

• サーバーが再起動したとき、コンテナが自動で上がる設定にする
• 落ちたときに再起動する設定も入れる
• ただし、無限に再起動を繰り返さないよう上限を設ける
• 実際に一度、サーバーを再起動して確かめる

プロクラ

4つめを済ませておくと、更新のための再起動が怖くなくなるよ。本番で初めて試すことにならないようにしよう。

3. ログとバックアップ

プロクラ

コンテナのログは既定では上限が無く、放っておくと膨らむ。バックアップの対象も、コンテナの中ではなくボリュームや共有ディレクトリになる点に注意が必要だよ。

• ログの最大サイズと保存数を、全体の既定として設定する
• バックアップの対象は、ボリュームと共有ディレクトリ
• データベースは、中身を書き出す形で取るほうが確実
• 設定ファイル一式も、バージョン管理に入れておく

4. 守りの設定

• コンテナ内でrootとして動かさない
• 外に出す必要が無いポートは、公開しないか範囲を限定する
• イメージに認証情報を焼き込まない
• ベースイメージを定期的に更新する（中のOSにも弱点が見つかる）

プロクラ

4つめは忘れられやすいところだよ。ホストのOSは自動更新していても、コンテナの中身は自分で作り直さないと古いまま。更新の対象として、両方を意識しよう。

レン

版を固定する、再起動を試す、ログの上限を決める。持ち込む前にやっておく。

5. 資源の上限を決める

プロクラ

既定では、コンテナはホストのメモリを使えるだけ使う。1つのコンテナが暴走すると、他も巻き込んで落ちることになる。

• コンテナごとに、使えるメモリの上限を指定する
• 合計が、サーバーの容量に収まるようにする
• 上限に達したコンテナだけが止まるので、被害が限定される
• 本番と検証を同居させるなら、特に効く

プロクラ

小さいプランほど、この設定の価値が高いよ。1つの不具合で全部が落ちる構成にしないための、安い保険だと考えて。