誰もが Kubernetes を愛していますが、Docker はもう人気がないのでしょうか?

1. はじめに

Docker に関して言えば、多くの人の第一印象は仮想化コンテナであるというものであり、そのため誰もが誤解に陥りやすく、つまり、Docker は OS 上で VMWare を実行するのと同じように、Linux オペレーティングシステムの上にある単なる別のレイヤーであると考えてしまいます。 Docker は遅くて複雑になる傾向があります。ネイティブにインストールされたサービスほど快適ではありません。

[[441440]]

実はこれは誤解です。 Docker によって管理されるさまざまなサービスはすべて、仮想化製品ではなく、オペレーティング システムのネイティブ プロセスです。正しい定義は、アプリケーション コンテナ エンジンです。

では、このアプリケーション コンテナ エンジンをどのように理解すればよいのでしょうか? Docker のコア原則について説明します。その主なメカニズムの 1 つは、Linux 名前空間メカニズムを通じてリソースの分離を実現することです。このリソース分離には以下が含まれます。

1. UTS、ホスト名とドメイン名の分離
2. IPC、セマフォ、メッセージキュー、共有メモリの分離
3. PID、プロセス番号の分離
4. ネットワーク、ネットワークデバイス、ネットワークプロトコルスタック、ネットワークポートの分離
5. マウント、マウントポイントの分離（ファイルシステム）
6. ユーザー、ユーザーおよびユーザー グループの分離。

これらの分離メカニズムはすべて Linux カーネルの名前空間メカニズムによって実装されており、Docker コンテナ設計の本質でもあります。

まるで、300平方メートルの家に1つの家族が住んでいて、寝室、キッチン、バスルームが家族専用になっているかのようでした。しかし、その家はとても大きいので、3家族が住むことができ、費用を分担できるだけでなく、ホストファミリーに追加収入をもたらすことになります。次に、3 つの家族のニーズを満たし、いくつかの生活システムを確立できるように、この大きな家を再計画して設計する必要があります。一部のリソースは共有できますが、プライバシーを保護するために重要なリソースは分離する必要があります。実際、みんなが平等に大きな家に住んでいます。

この比喩は、Docker を、家の中の複数の家族のために計画し手配する大家と考えることができるということを実際に皆に伝えています。 Docker は多くのコンテナ サービスを管理し、コンテナ サービスはホスト マシン上で実行されます。たとえば、MySQL、Nginx、マイクロサービスなどはすべてコンテナ サービスです。誰もが同じ OS 上で平等に動作しますが、自分の部屋に入ると、他の人の部屋の状況については何もわかりません。これにより、サービス間のリソース競合を防ぐだけでなく、事前にインストールされたプロトコルに従って CPU、メモリ、ディスク容量が割り当てられます。こうすることで、誰もが明確に共存でき、誰も他の人を利用することはできません。もちろん、外部ネットワーク ポートは各企業によって異なる方法で割り当てる必要があります。

このスキルを使用すると、限られたクラウド リソース上で多くのサービスを実行できます。私の会社のウェブサイトは Alibaba Cloud の ECS CentOS7 上で実行されており、Nginx、MySQL、Wordpress の 3 つの Docker コンテナを実行しています。割り当てたメモリは 512M のみで、少ないですが、問題なく動作します。物理メモリが小さすぎるだけです。サービスを再起動すると、OS からメモリ リソースが不足していると報告され、Docker を再起動してメモリをクリアする必要がある場合があります。

私は以前の勤務先の 2 つのインターネット プラットフォーム製品に、優れたパフォーマンス、4 つのコア、16G のメモリを備えた 3 台の ECS サーバーを使用していました。彼らは 50 を超えるマイクロサービスとその他の基本サービスを実行していたため、すべてのリソースが圧迫されていました。キーには、サービス ログの分離、環境変数の分離、グローバル構成の分離なども含まれます。メリットは非常に多くあります。重要なのは、インターネット アーキテクチャ上で当社製品の DevOps に優れた基本サポートを提供することです。仮想マシン上で 2 セットのマイクロサービスを実行できます。1 つは本番用、もう 1 つはテスト用です。テストされたマイクロサービスはバージョン番号をアップグレードして新しい本番マイクロサービスになり、古いマイクロサービスは移行および置き換え期間に入ります。

II.質問

1. Docker にはインターネット接続が必要ですか?

インターネット接続は必要ありません。 Docker レジストリ サービスは内部的に構築できます。以前、Alibaba Cloud の複数のマシンの 1 つにレジストリ サービスをインストールし、他のマシンがイントラネットのポート 5000 経由でアクセスできるようにしました。各サーバーの Docker サービスが SSL を使用しないように構成することを忘れないでください。

開発クライアントが Nginx の HTTP SSL ポートにアクセスし、リモート公開を通じてレジストリ リポジトリにリバース プロキシすることのみを許可できます。この場合、パブリック ネットワークでは可能な限り HTTPS を使用する必要があるため、サーバーに Docker バージョンの nginx をインストールする必要があります。次の図に示すように:

イントラネットに Docker をインストールする方法については、まずインターネットにアクセスできるマシンを見つけ、Docker ハブを通じて独自の Docker イメージを作成する必要があります。スクリプト技術であるドックファイルの作成方法を知っておくのが最善です。主に、ローカリゼーションとパラメータの最適化のために Docker イメージをさらに作成する必要があり、その後 Docker はそれをイントラネット上のプライベート レジスタ サービス リポジトリにプッシュします。他のイントラネット マシンでは、Docker pull コマンドを使用するだけで、作成した Docker イメージを使用できます。

Windows システムで開発している場合は、Docker デスクトップ for Windows をダウンロードしてインストールし、Mac バージョンと同じように使用します。

2. Docker でプログラムのホットアップデートを実装するにはどうすればよいですか?

Dockerfile を使用してイメージを構築し、プログラムを実行するためのコンテナを生成しました。プログラムコードが変更されました。ホットアップデートを実装するにはどうすればよいですか?

Docker を更新する一般的な方法は、新しいイメージをプルダウンしてからコンテナを再起動することです。もちろん、賢い方法もいくつかあります。 Docker 内のリリース プログラム ディレクトリをローカル ディレクトリにミラーリングすることで、プログラム パッケージのみが毎回アップロードされ、サーバーのローカル ディレクトリが更新された後に Docker が再起動されます。この方法により、Docker が大きすぎてアップロードに時間がかかるという問題を回避できます。

ただし、これらはすべてコンテナの再起動を必要とするため、真のホット アップデートとは言えません。オンライン ビジネス システムで許可されるジッター期間は、多くの場合非常に厳格です。 Docker イメージがテスト環境でテストされ、問題がない場合でも、検証せずに本番サーバーに直接置き換えることはできません。 Web システムの場合は、API ゲートウェイ + Docker-compose + マルチバージョン操作を使用してホット アップデートを実現することをお勧めします。これにより、アップグレード ジッターの影響も最小限に抑えられます。次の図に示すように、T はテスト、P は本番、v1 と v2 は Docker-compose のマルチバージョンリリースを表します。 API ゲートウェイは、アップグレードのジッターを最小限に抑えるために、マイクロサービスの新しいバージョンへのジャンプをリダイレクトします。

具体的な意味を簡単に説明しましょう。 Docker-compose をアプリケーション リリース全体として使用すると、マイクロサービスでもモノリシック アプリケーションでも、すべてが 1 つのユニットとしてデプロイおよび管理されます。

そして、更新が必要なプログラムの新しいバージョンに対して、Docker-compose の新しいバージョンがリリースされます。 QA 検証後、API ゲートウェイは動的切り替えを実装します。これがDockerホットアップデートの一般的な考え方です。

3. Docker がデータ ボリュームをマウントすると、マッピング ファイルが同期されなくなりますか?

Docker を学習しているときに、redis.conf をマッピングするとこのような状況が発生することがわかりました。 yml を実行する前にコンテナからコピーをコピーする必要がありますか?

Docker が構成ファイルをマップする場合、まずこのファイルが必要です。覚えておいてください、このファイルが内部に作成されるまで待たないでください。そうしないと、ディレクトリのみが作成されます。

したがって、Docker マッピング ファイルが存在しない場合は、マッピング ディレクトリが使用されます。

最初の方法は、構成ファイルがすでに存在する場合です。つまり、それをサーバーのカスタム構成ディレクトリにアップロードし、Docker がそれを直接マッピングします。この時点では、ファイルのマッピングまたはディレクトリのマッピングは同じです。

2 番目の方法: 構成ディレクトリをカスタム ディレクトリにマップし、コンテナー操作プロセス中にスクリプトが自動的に書き込まれます。この場合、コンテナの初期化プロセス中に、スクリプトによって構成ディレクトリ内のさまざまなファイルをイメージ内のパッケージ化された構成ファイルに書き込む必要があります。

実際、私は最初の方法を使用する、Redis に最適化された本番レベルの Docker を作成しました。設定は自分でアップロードする必要があります。私の gitee ソースコード リポジトリをご覧いただけます。 gitee リポジトリには、Redis のローカライズとパフォーマンス チューニング用の Dockerfile と構成ファイルも含まれています。 gitee で「read bytes」を検索します。私が作成した優れたスタンドアロンの Redis Dockerfile ファイルがあり、これはパフォーマンスが最適化されており、学習に使用できます。

3. 結論

つまり、Kubernetes全盛の今の時代、冷静に考えなければいけない時もあるということです。そんなに複雑にする必要が本当にあるのでしょうか？ Dockerだけでは不十分ですか? Portainer のような無料のオンライン Docker 管理ツールを使用すると、クラウド サービス グループを適切に管理できます。

ただし、1 つだけ限界があります。それは、Docker を操作するときは、スクリプト スキルを含む Linux スキルを常に磨く必要があるということです。これは、一部の Docker イメージでは実際の環境に応じた使用ニーズを満たすことができないため、独自の Dockerfile を構築する必要があるためです。以前のプロジェクトでは、Maven を使用して独自の Dockerfile と Shell スクリプトを作成し、パッケージ化からリリースまでのマイクロサービスを一度に完了し、更新するマイクロサービスを柔軟に選択することができました。これには Linux に関する深い理解が本当に必要です。

実際、より複雑な K8s に直面すると、Linux に精通しているという問題は依然として避けられません。したがって、それは依然として重要なステップです。コンテナ時代において、コンテナ エンジンをうまく使うには、まずシンプルな Docker から始め、プログラムを完成させるだけでなく Linux スキルを練習することで、技術がより速く向上します。