Docker の初心者村から始めますか?必要なのは次の11のルールです

多くの人は最終的に、問題を解決するために Docker を使用することを決定します。 Docker には次のような多くの利点があります。

• 統合 - オペレーティング システム、ライブラリ バージョン、構成ファイル、アプリケーションなどをコンテナーにパッケージ化します。これにより、QA によってテストされたイメージが実稼働環境に同じ動作をもたらすことが保証されます。
• 軽量 - メモリをほとんど消費せず、メインプロセスにのみメモリを割り当てます。
• 高速読み取り - 一般的な Linux プロセスを開始するのと同じくらい高速なワンクリック起動。

それにもかかわらず、多くのユーザーは依然としてコンテナを一般的な仮想マシンとしてのみ扱い、コンテナの重要な機能を忘れています。

使い捨て

この機能のため、一部のユーザーはコンテナの概念を変更する必要があります。 Docker コンテナをより有効に活用し、その価値を最大限に高めるために、絶対にしてはいけないことがいくつかあります。

1. コンテナにデータを保存しないでください。コンテナは中断、置換、または破壊される可能性があります。コンテナ内で実行されているアプリケーションのバージョン 1.0 は、データに影響を与えたりデータ損失を引き起こしたりすることなく、バージョン 1.1 に簡単に置き換えることができます。したがって、データを保存する必要がある場合は、ボリュームに保存します。この場合、2 つのコンテナが同じボリュームにデータを書き込むと破損が発生する可能性があるため、注意が必要です。アプリケーションが共有データ ストアへの書き込みに適していることを確認してください。

2. アプリケーションを 2 つの部分に分けて出荷しないでください。コンテナーを仮想マシンと考える人もいるため、ほとんどの人は、アプリケーションを既存の実行中のコンテナーにデプロイする必要があると考えます。これは、継続的にデプロイとデバッグを行う必要がある開発フェーズでは当てはまるかもしれませんが、QA と本番の継続的デリバリー (CD) パイプラインでは、アプリケーションはイメージの一部である必要があります。覚えておいてください: コンテナは一時的なものです。

3. 大きな画像を作成しない 大きな画像は配布しにくくなります。アプリケーションを実行するには、必要なファイルとライブラリのみを使用するようにしてください。不要なパッケージをインストールしないでください。また、新しいイメージ レイヤーに大きなファイルをダウンロードする「update」(yum update) を実行しないでください。

4. シングルレイヤーイメージは使用しないでください。マルチレイヤーファイルシステムを効果的に使用するには、必ずオペレーティングシステム用の独自のベースイメージレイヤーを作成し、次にユーザー名定義用のレイヤー、ランタイムインストール用のレイヤー、構成用のレイヤー、最後にアプリケーション用のレイヤーを作成します。これにより、イメージの再作成、管理、配布が容易になります。

5. 実行中のコンテナからイメージを作成しないでください。つまり、イメージを作成するために「docker commit」コマンドを使用しないでください。この画像作成方法は再現不可能なので、完全に避けるべきです。ソース管理リポジトリ (GIT) に保存されている場合に Dockerfile への変更を追跡できるように、常に Dockerfile またはその他の完全に再現可能な S21 (ソースからイメージ) アプローチを使用します。

6. 「latest」タグだけを使用しないでください。latest タグは、Maven ユーザーにとって「SNAPSHOT」のようなものです。コンテナは多層ファイルシステムという基本的な特性を持っているため、タグの使用を推奨します。数か月かけてイメージをビルドした後、親レイヤー (つまり、Dockerfile の FROM) が新しいバージョンに置き換えられたために (新しいバージョンに下位互換性がないか、ビルド キャッシュから取得した「最新」バージョンが間違っているため)、アプリケーションを実行できないことが判明するのは誰も望んでいないと思います。また、コンテナを本番環境にデプロイするときは、「最新」タグの使用を避ける必要があります。これは、現在実行されているイメージのバージョンを追跡することが不可能だからです。

7. 1 つのコンテナで複数のプロセスを実行しないでください。コンテナは 1 つのプロセス (HTTP デーモン、アプリケーション サーバー、データベース) のみを実行する場合に最も効果的に機能しますが、複数のプロセスを実行すると、ログの管理と取得、およびプロセスを個別に更新するときに多くの問題が発生します。

8. 証明書をイメージに保存したり、環境変数を使用したりしないでください。画像内にユーザー名やパスワードをハードコードしないでください。環境変数を使用して、コンテナ外部から情報を取得します。 Postgres ミラーリングはこの原則の素晴らしい例です。

9. ルート権限でプロセスを実行しない 「デフォルトでは、Docker コンテナはルート ユーザー権限で実行されます。(…) Docker テクノロジが成熟するにつれて、より安全なデフォルトが利用可能になります。現在、ルートを要求することは他のユーザーにとって危険であり、すべての環境でルートにアクセスできるわけではありません。イメージでは、USER ディレクティブを使用して、コンテナを実行するための非ルート ユーザーを指定する必要があります。」 (Docker イメージ作成者向けガイダンスより)

10. IP アドレスに依存しない 各コンテナには独自の内部 IP アドレスがあり、コンテナを起動して停止すると変更される可能性があります。アプリケーションまたはマイクロサービスが別のコンテナと通信する必要がある場合は、環境変数を使用してコンテナ間で適切なホスト名とポートを渡します。

11. コンテナの監視 Docker 監視は開発者からますます重視されるようになっています。 Docker のリアルタイム監視には、Cloudinsight が推奨されます。自分で作成したスクリプトを必要とする一部の監視方法とは異なり、無料の SaaS サービスである Cloudinsight では、ワンクリックで Docker を監視でき、優れたビジュアル インターフェイスを備えています。さらに、Cloudinsight は複数のオペレーティングシステムやデータベースなどの監視もサポートしており、監視対象のすべてのシステムインフラストラクチャコンポーネントのパフォーマンスデータを統合的に表示できます。