Edited at

Dockerを本番環境で運用する際に気をつけていることはこれ


TL;DR

Dockerはとても便利なので使っている方も多いと思います。


しかし、Dockerやdocker-composeを本番環境で使うことは


  • スケール

  • ネットワーク

  • 管理

等の問題があるため


コンテナオーケストレーションサービス(GKEやEKS,ECS等)を使うことになるかと思います。

本番環境でコンテナオーケストレーションツールを使う際に、


Docker周りについて、個人的に気をつけていること


をまとめてみました。


〜気をつけていること〜


Summary


  • イメージのサイズを小さくする

  • 認証情報をイメージに含めない

  • ステートレス

  • タグをつける

  • Dockerfileを簡潔に書く


イメージのサイズを小さくする

イメージを小さくすることには、メリットが多くあります。


イメージのpullにかかる時間が少なくなる

オーケストレーションサービスはコンテナを起動するたびに都度イメージをpullしています。


ザイズを小さくすることで、コンテナの起動にかかる時間を短縮することができます。


コスト削減

オーケストレーションサービスでDockerイメージを使用するために

DockerHubやECR,GCRを使うことになると思います。

ECR,GCRはイメージサイズに応じた課金+転送量での課金です

オーケストレーションサービスでも、ネットワークのトラフィック量に応じて課金が発生するので

小さければ小さいほど料金は安くなります。

イメージ手っ取り早く小さくするにはalpinescratchを使うとよいです。

バイナリ化できるアプリケーションの場合は、multi stage build でイメージ作ると便利です。

Alpine Linux で Docker イメージを劇的に小さくする

 

FROM scratchから始める軽量Docker image for Go


認証情報をイメージに含めない

アプリケーションで、GCPのサービスアカウントAWSのIAMのキーDBアクセス情報等の外部に公開してはいけない認証情報が必要になることは多いと思います。


これらの情報はDockerイメージには含めずに、コンテナ起動時に渡す(ファイルをマウントする、環境変数で渡す等)ようにしています。 

こうすることで、イメージが流出してしまったとしても(ほとんどないと思います)問題ないし

認証情報だけ変えることで本番環境、ステージング環境で同じイメージを使用することができます。


ステートレス

これはアプリケーション寄りでDockerには直接関係は少ないかもしれません。


本番環境でDockerを使用する場合、同じコンテナを複数起動することがほとんどです。


その際に各コンテナ(アプリケーション)がステータスを持っていると、まずいことになります。

※今回は記載しませんが、DBの場合は別です。


タグをつける

僕も開発時はタグをつけずにlatestでつくってしまうことが多いんですが、

タグをつけると便利なのでちゃんとつけましょう。


バージョンだけでなく、[version]-devとかしておくとわかりやすくて⭕️


Dockerfileを簡潔にわかりやすく書く

後々メンテするときにも、簡潔にわかりやすく書いてある方がメンテしやすいです。

複雑な処理を書く場合はコメントを必ず記載するようにしています。


おしまい

※書き忘れもあると思うので随時追加します。


質問・フィードバックはTwitter or コメントでお願いします。


これもあるよ、ここは違うよ etc... 教えてもらえたら嬉しいです😃


それでは、よいDockerライフを〜