インタビュアーさん、残ってください！ Dockerの原理についてお話ししましょう

[[376648]]

この記事はWeChatの公開アカウント「sowhat1412」から転載したもので、著者はsowhat1412です。この記事を転載する場合は、sowhat1412 公開アカウントにご連絡ください。

開発者は電子商取引プロジェクトを開発しました。 Jar プロジェクトには、Redis、MySQL、ES、Haddop などのいくつかのコンポーネントが含まれています。開発者がテストを行ってエラーが見つからなければ、テスト担当者に提出して実稼働前テストを行います。

テスト: 貴社のサービスで単体テストやデータ検証を実行すると、常に未知のバグに遭遇します。見てみませんか？

開発: どのようにテストしましたか?操作マニュアルをステップごとに実行しましたか?

テスト: ドキュメントどおりです!

開発: 再起動しましたか?キャッシュをクリアしましたか?コードは最新ですか? Chrome を使っていますか?何か変更しましたか?

テスト: これ…これ…これ…何もしてないよ！

この時点で、開発とテストの間の愛憎関係が正式に始まりました。

1 Dockerの紹介

1.1 Dockerの起源

Docker は Go 言語に基づいて開発されたコンテナ エンジンです。 Docker は、アプリケーションとシステム間の分離レイヤーです。通常、アプリケーションには、インストールされるシステム環境に対してさまざまな厳しい要件があります。展開するサーバーの数が多い場合、システム環境の構成は非常に面倒です。 Docker を使用すると、アプリケーションはホスト環境を気にする必要がなくなります。各アプリケーションは Docker イメージにインストールされ、Docker エンジンはアプリケーションをラップする Docker イメージの実行を担当します。

Docker の考え方は、開発者がアプリケーションと依存関係をコンテナにロードし、どこにでも簡単にデプロイできるようにすることです。 Dockerには以下の機能があります。

Docker コンテナは、システム リソースをあまり消費しない軽量の仮想化テクノロジです。

Docker コンテナを使用すると、さまざまなチーム (開発、テスト、運用など) 間のコラボレーションが容易になります。

Docker コンテナは、あらゆる物理マシンや仮想マシン、さらにはクラウド上のどこにでもデプロイできます。

Docker コンテナは非常に軽量なので、非常にスケーラブルです。

1.2 Dockerの基本コンポーネント

画像：

Docker イメージは、コンテナ サービスを作成するためのターゲットのようなものです。プログラミング言語のクラスとして簡単に理解できます。

容器：

Docker はコンテナ テクノロジを使用して、1 つのアプリケーションまたはアプリケーション グループを独立して実行します。コンテナはイメージを通じて作成されます。コンテナ内では、開始、停止、削除などの基本コマンドを実行できます。最終的に、サービスまたはプロジェクトはコンテナ内で実行され、コンテナはクラスのインスタンスとして理解できます。

リポジトリ:

倉庫は画像が保存される場所です。ウェアハウスは、Git と同様に、パブリック ウェアハウスとプライベート ウェアハウスに分かれています。一般的には高速化のために国産のDockerイメージを使用します。

1.3 VMとDocker

仮想マシン:

従来の仮想マシンでは、ハードウェアを含むマシン全体をシミュレートする必要があります。各仮想マシンには独自のオペレーティング システムが必要です。仮想マシンがオンになると、事前に割り当てられたすべてのリソースが使用されるようになります。各仮想マシンには、アプリケーション、必要なバイナリとライブラリ、完全なユーザー オペレーティング システムが含まれています。

ドッカー:

コンテナ テクノロジーは、ハードウェア リソースとオペレーティング システムをホスト マシンと共有して、動的なリソース割り当てを実現します。コンテナにはアプリケーションとそのすべての依存関係が含まれますが、カーネルは他のコンテナと共有されます。コンテナは、ホスト オペレーティング システム内のユーザー スペースで個別のプロセスとして実行されます。

1.4 DockerとDevOps

DevOps は、開発 (アプリケーション/ソフトウェア エンジニアリング)、技術運用、品質保証 (QA) 部門間のコミュニケーション、コラボレーション、統合を促進する一連のプロセス、方法、システムです。

DevOps は、Dev (開発) と Ops (運用) という 2 つの従来の役割を組み合わせたものです。 Dev は開発を担当し、Ops は展開とオンライン リリースを担当します。しかし、Ops は Dev が開発したアプリケーションを十分に理解しておらず、Dev がオンラインリリースの責任を負っています。多くのサービス ソフトウェアは、展開および実行の方法を知りません。両者の間には明らかなギャップがあり、DevOps はこのギャップを埋めるためのものです。 DevOps が行うことはより Ops 指向ですが、それを実行する人々はより Dev 指向です。率直に言えば、運用作業を行うには開発を理解している人が必要です。そして、Docker は DevOps に適しています。

1.5 Dockerとk8s

k8s の正式名称は kubernetes で、コンテナベースのクラスター管理プラットフォームであり、アプリケーションのライフサイクル全体を管理するためのツールです。アプリケーションの作成、アプリケーションのデプロイ、サービスの提供、アプリケーションのスケーリング、アプリケーションの更新など、非常に便利です。障害の自己修復も実現できます。たとえば、サーバーがハングアップした場合、手動による介入なしに、このサーバー上のサービスを別のホストで実行するように自動的にスケジュールできます。 Google 独自の強力な実用的なアプリケーションに依存している k8s は、現在、Docker 独自の Swarm を上回る市場シェアを誇っています。

起動、保守、監視する Docker コンテナが多数ある場合は、k8s を選択してください。

1.6 こんにちは世界

docker run hello-world の一般的なフローチャートは次のとおりです。

2 Docker の一般的なコマンド

公式ドキュメント:

https://docs.docker.com/engine/reference/commandline/build/

3 Dockerの動作原理

Docker は動作環境のみを提供します。 VMとは異なり、独立したOSを実行する必要はありません。コンテナ内のシステム カーネルは、ホスト マシンのカーネルと共有されます。 Docker コンテナは、本質的にはホスト マシン上のプロセスです。 Docker プロジェクトの場合、その基本原則は、実際には、ユーザー プロセスを作成するために次の操作を実行することです。

1. Linux 名前空間構成を有効にします。
2. 指定された Cgroups パラメータを設定します。
3. プロセスのルート ディレクトリを切り替えます (ルートの変更)。pivot_root システム コールを使用することをお勧めします。システムがサポートしていない場合は、chroot を使用します。

3.1 名前空間プロセス分離

Linux 名前空間メカニズムは、プロセス リソース分離ソリューションを提供します。 PID、IPC、ネットワークなどのシステム リソースはグローバルではなくなり、特定の名前空間に属します。各名前空間の下のリソースは透過的であり、他の名前空間の下のリソースに対しては見えません。システム内には、プロセス番号 0、1、2 の 2 つのプロセスが同時に存在できます。これらは異なる名前空間に属しているため、それらの間に競合は発生しません。

PS: Linux カーネルは、次の図に示すように、名前空間が分離された 6 つのシステム コールを提供します。

3.2 Cグループリソース割り当て

Docker は Cgroup を使用してコンテナが使用するリソース クォータを制御し、このクォータを超えると OOM が発行されます。クォータには主に CPU、メモリ、ディスクが含まれ、基本的には共通のリソース クォータと使用量の制御をカバーします。

Cgroup は Control Groups の略です。これは、プロセス グループが使用する物理リソース (CPU、メモリ、ディスク IO など) を制限、記録、分離できる、Linux カーネルによって提供されるメカニズムです。 LXC (Linux コンテナ) や Docker などの多くのプロジェクトでプロセス リソース制御を実装するために使用されています。 cgroup 自体は、プロセスをグループ化するための機能とインターフェースを提供するインフラストラクチャです。この機能を通じて、I/O やメモリ割り当て制御などの特定のリソース管理が実装されます。これらの特定のリソース管理機能は、Cgroup サブシステムと呼ばれます。

3.3 chroot および pivot_root ファイル システム

chroot (ルート ファイル システムの変更) コマンドの機能は、プロセスのルート ディレクトリを指定された場所に変更することです。たとえば、現在 $HOME/test ディレクトリがあり、それを /bin/bash プロセスのルート ディレクトリとして使用したいとします。

まず、ディレクトリといくつかのフォルダを作成します HOME/test/{bin,lib64,lib}

bashコマンドをテストディレクトリに対応するbinパスにコピーします。cp -v /bin/{bash,ls} $HOME/test/bin

bashコマンドに必要なすべてのsoファイルを、テストディレクトリに対応するlibパスにコピーします。

chrootコマンドを実行して、オペレーティングシステムにHOME/test /bin/bashを使用することを伝えます。

chroot されたプロセスが ls / を実行すると、返されるのは $HOME/test ディレクトリの内容だけです。これは、Docker がコンテナのルート ディレクトリを実装する方法です。コンテナのルート ディレクトリをよりリアルに見せるために、通常、Ubuntu 16.04 の ISO など、完全なオペレーティング システム ファイル システムがコンテナのルート ディレクトリの下にマウントされます。このように、コンテナを起動した後、コンテナ内で ls / を実行すると、Ubuntu 16.04 のすべてのディレクトリとファイルが表示されます。

コンテナのルート ディレクトリにマウントされ、コンテナ プロセスに分離された実行環境を提供するために使用されるファイル システムは、コンテナ イメージと呼ばれます。より専門的な名前は、rootfs (ルート ファイル システム) です。したがって、最も一般的な rootfs には次のディレクトリとファイルが含まれます。

 $ ls /
 bin dev etc home lib lib64 mnt opt ​​proc root run sbin sys tmp usr var

chroot は現在のプロセスの / のみを変更しますが、 pivot_root は現在のマウント名前空間の / を変更します。 pivot_root は chroot の改良版と考えることができます。

3.4 一貫性

rootfs にはアプリケーションだけでなく、オペレーティング システム全体のファイルとディレクトリも含まれているため、アプリケーションとその動作に必要なすべての依存関係が一緒にカプセル化されていることになります。オペレーティング システムをコンテナー イメージにパッケージ化できるようになったことで、この最も基本的な依存関係環境が、ついにアプリケーション サンドボックスの一部になりました。これにより、コンテナーに一貫性と呼ばれるものが与えられます。

ローカル、クラウド、または任意のマシンのいずれであっても、ユーザーはパッケージ化されたコンテナ イメージを解凍するだけで、アプリケーションの実行に必要な完全な実行環境が再現されます。

3.5 ユニオンFS

rootfs を効率的かつ再利用可能にするにはどうすればよいでしょうか? Docker はイメージの設計にレイヤーの概念を導入しました。つまり、ユーザーのイメージ作成の各ステップで、増分 rootfs であるレイヤーが生成されます。階層化を紹介する前に、まず重要な知識ポイントである共同ファイルシステムについて説明します。

Union File System (UnionFS) は、階層型で軽量かつ高性能なファイル システムであり、ファイル システムの変更を単一のコミットとしてレイヤーごとに重ね合わせることができ、異なるディレクトリを同じ仮想ファイル システムにマウントできます。たとえば、現在、果物と野菜の 2 つのカテゴリがあります。果物にはリンゴやトマトが含まれ、野菜にはニンジンやトマトが含まれます。

 $ツリー
。
 ├── 果物
│ ├── リンゴ
│ └── トマト
└──野菜
  ├── ニンジン
  └── トマト

次に、ジョイント マウント メソッドを使用して、これら 2 つのディレクトリを共通ディレクトリ mnt にマウントします。

 $ mkdir mnt
 $ sudo マウント -t aufs -o dirs=./fruits:./vegetables none ./mnt

ここで、ディレクトリ mnt の内容を確認すると、ディレクトリ fruit と Vegetables の下のファイルが結合されていることがわかります。

 $ ツリー ./mnt
 ./分
├── リンゴ
├── ニンジン
└── トマト

mnt ディレクトリには、apple、carrots、tomato の 3 つのファイルがあることがわかります。果物と野菜のディレクトリは、mnt ディレクトリに統合されます。

 $ echo mnt > ./mnt/apple
 $ cat ./mnt/apple
 メートル
 $ 猫 ./果物/リンゴ
 メートル

./mnt/apple の内容が変更され、./fruits/apple の内容も変更されていることがわかります。

 $ echo mnt_carrots > ./mnt/carrots
 $ 猫 ./野菜/ニンジン
古い
$ 猫 ./果物/ニンジン
mnt_にんじん

./vegetables/carrotsは変更されていません。代わりに、./fruits/carrots ディレクトリに carrots ファイルが表示され、その内容は ./mnt/carrots にあったものと同じです。

結論は：

mount aufs コマンドが発行されると、野菜と果物に対する権限は設定されません。デフォルトでは、コマンド ラインの最初のディレクトリは読み取りおよび書き込み可能で、後続のディレクトリはすべて読み取り専用です。ファイル名が重複している場合は、マウント コマンド ラインで先にリストされているファイル名が優先されます。

3.6 レイヤー

ユニオン ファイル システムについて説明した後、Docker での階層化について説明します。画像はレイヤー化によって継承できます。ベースイメージ（親イメージなし）に基づいて、ユーザーはさまざまな特定のアプリケーションイメージを作成できます。異なる Docker コンテナは、いくつかの基本的なファイル システム レイヤーを共有しながら、独自の変更レイヤーを追加できるため、ストレージ効率が大幅に向上します。

Docker は AUFS (AnotherUnionFS) と呼ばれるユニオン ファイル システムを使用します。 AUFS は、各メンバー ディレクトリに対して異なる読み取りおよび書き込み権限の設定をサポートします。

1. rw は読み取り書き込みを意味します。
2. ro は読み取り専用を意味します。権限を指定しない場合は、最初のものを除いて ro がデフォルト値になります。 ro ブランチの場合、書き込み操作やホワイトアウト検索操作は受信されません。
3. rr は real-read-only の略です。読み取り専用とは異なり、rr は本質的に読み取り専用のブランチをマークします。この方法により、AUFS はファイル変更通知をチェックするために inotify を設定する必要がなくなるなど、パフォーマンスを向上させることができます。

ro レイヤー内のファイルを変更する場合はどうすればよいでしょうか? ro は変更できないためです。 Docker では、ro レイヤーには通常 wh 機能があります。この ro ディレクトリ内のファイルをホワイトアウトする必要があります。 AUFS ホワイトアウトの実装は、上位レベルの書き込み可能なディレクトリに対応するホワイトアウト隠しファイルを作成することによって実現されます。たとえば、次の 3 つのディレクトリとファイルがあります。

 $ツリー
。
 ├── 果物
│ ├── リンゴ
│ └── トマト
├── test #ディレクトリは空です
└──野菜
    ├── ニンジン
    └── トマト

次のように実行します。

 $ mkdir mnt
 $ マウント -t aufs -o dirs=./test=rw:./fruits=ro:./vegetables=ro none ./mnt
 $ ls ./mnt/
リンゴ ニンジン トマト

rw 権限を持つテスト ディレクトリにホワイトアウト隠しファイル .wh.apple を作成すると、ファイル ./mnt/apple が消えることがわかります。これは、rm ./mnt/apple を実行した場合と同じです。

 $ ./test/.wh.apple をタッチします
 $ ls ./mnt
 ニンジン トマト

AUFS の場合、イメージの複数のベース レイヤーが /var/lib/docker/aufs/diff ディレクトリに配置され、一緒にマウントされた各レイヤーの情報は /sys/fs/aufs を照会することで表示されます。最終的に、複数のベース レイヤーが /var/lib/docker/aufs/mnt にまとめてマウントされ、完成した製品がそこに保存されます。

現在 Docker でサポートされているユニオン ファイル システムには、OverlayFS、AUFS、Btrfs、VFS、ZFS、Device Mapper などがあります。 overlay2 ストレージ ドライバーを使用することをお勧めします。 Overlay2 は現在、Docker のデフォルトのストレージ ドライバーです。以前はAUFSでした。

3.6.1 読み取り専用レイヤー

Ubuntu を例にとると、docker image inspect ubuntu:latest を実行すると、コンテナの rootfs の下部 4 層が ubuntu:latest イメージの 4 層に対応していることがわかります。これらはすべて読み取り専用 (ro+wh) でマウントされ、それぞれに Ubuntu オペレーティング システムの一部が増分形式で含まれています。 4 つの層が組み合わされて完成品が形成されます。

3.6.2 読み取りおよび書き込み可能なレイヤー

rootfs の最上位の操作権限は rw です。ファイルが書き込まれる前は、このディレクトリは空です。コンテナ内で書き込み操作が実行されると、変更によって生成されたコンテンツがこのレイヤーに増分的に表示されます。読み取り専用レイヤー内のファイルを削除したい場合はどうすればよいでしょうか?この問題は上記で説明しました。

最上位の読み取り/書き込み層は、特に rootfs を変更した後に生成された増分を保存するために使用されます。追加、削除、変更など、すべてここで行われます。変更したコンテナの使用が完了したら、docker commit コマンドと push コマンドを使用して、変更した読み取りおよび書き込み可能なレイヤーを保存し、他のユーザーが使用できるように Docker Hub にアップロードできます。また、元の読み取り専用レイヤーの内容はまったく変更されません。これが増分 rootfs の利点です。

3.6.3 初期化レイヤー

これは -init で終わるレイヤーであり、読み取り専用レイヤーと読み取り/書き込みレイヤーの間に挟まれます。 Init レイヤーは、Docker プロジェクトによって別途生成される内部レイヤーであり、/etc/hosts などの情報を保存するために使用されます。

このようなレイヤーが必要な理由は、これらのファイルは元々読み取り専用の Ubuntu イメージの一部ですが、ユーザーはコンテナを起動するときにホスト名などの特定の値を書き込む必要があることが多いため、読み取り/書き込みレイヤーで変更する必要があるためです。ただし、これらの変更は現在のコンテナに対してのみ有効であることが多く、docker commit を実行するときに、読み取りおよび書き込み可能なレイヤーと一緒に init レイヤー情報をコミットすることは望ましくありません。

最終的に、これら 6 つのレイヤーが組み合わされて、コンテナー用の完全な Ubuntu オペレーティング システムが形成されます。

4 Dockerネットワーク

上記の Docker の原則から、Docker は、プロセスを分離するための PID 名前空間、ファイルシステムを分離するためのマウント名前空間、ネットワークを分離するためのネットワーク名前空間など、Linux の名前空間テクノロジを使用してリソースを分離していることがわかります。ネットワーク名前空間は、他のネットワーク名前空間から分離された独立したネットワーク環境 (ネットワーク カード、ルーティング、Iptable ルールを含む) を提供します。 Docker コンテナには通常、独立したネットワーク名前空間が割り当てられます。

Docker をインストールすると、docker network ls を実行すると 3 つのネットワークが自動的に作成されることがわかります。

 [root@server1 ~]$ docker ネットワーク ls
ネットワーク ID名前ドライバー スコープ
0147b8d16c64 ブリッジ ブリッジローカル 
 2da931af3f0b ホスト ホストローカル 
 63d31338bcd9 なしヌル                地元 

docker run を使用して Docker コンテナを作成するときに、--net オプションを使用してコンテナのネットワーク モードを指定できます。 Docker には次の 4 つのネットワーク モードがあります。

4.1 ホストモード

VMware のブリッジ モードと同等で、コンテナーがホスト モードで起動されると、コンテナーは独自のネットワーク カードを仮想化したり、独自の IP を構成したりせず、ホストの IP とポートを使用します。ただし、ファイル システムやプロセス リストなど、コンテナーの他の側面は、ホスト マシンから分離されたままです。

4.2 コンテナモード

コンテナ モードでは、新しく作成されたコンテナがネットワーク名前空間をホストと共有するのではなく、既存のコンテナと共有することを指定します。新しく作成されたコンテナは、独自のネットワーク カードを作成したり、独自の IP を構成したりするのではなく、指定されたコンテナと IP、ポート範囲などを共有します。同様に、ネットワークを除いて、ファイル システムやプロセス リストなど、2 つのコンテナーの他の側面は分離されたままです。 2 つのコンテナのプロセスは、lo ネットワーク カード デバイスを介して通信できます。

4.3 なしモード

なしモードでは、コンテナは構成なしで独自のネットワーク スタックに配置されます。実際、このモードではコンテナのネットワーク機能がオフになります。このモードでは、コンテナーはネットワークを必要としません (たとえば、ディスク ボリュームの書き込みのみが必要なバッチ タスクなど)。

4.4 ブリッジモード

ブリッジ モードは Docker のデフォルトのネットワーク設定です。このモードでは、ネットワーク名前空間を割り当て、各コンテナに IP アドレスを設定します。 Docker Server が起動すると、ホスト上に docker0 という仮想ブリッジが作成され、このホスト上で起動された Docker コンテナがこの仮想ブリッジに接続されます。仮想ブリッジの動作モードは、物理スイッチの動作モードと似ています。ホスト上のすべてのコンテナは、スイッチを介してレイヤー 2 ネットワークに接続されます。

Docker は RFC1918 で定義されているプラ​​イベート IP セグメントからホストマシンとは異なる IP アドレスとサブネットを選択し、docker0 に割り当てます。 docker0 に接続されたコンテナは、サブネットから未使用の IP を選択して使用します。通常、Docker はネットワーク セグメント 172.17.0.0/16 を使用し、172.17.0.1/16 を docker0 ブリッジに割り当てます (docker0 は、ホスト上の ifconfig コマンドを使用して表示できます。これはブリッジの管理インターフェイスと見なすことができ、ホスト上の仮想ネットワーク カードとして使用できます)。

ネットワーク構成プロセスは、おおよそ 3 つのステップで構成されます。

ホスト上に仮想ネットワーク カード veth ペア デバイスのペアを作成します。 Veth デバイスは常にペアで表示されます。それらはデータ チャネルを形成します。データは 1 つのデバイスから入力され、別のデバイスから出力されます。したがって、2 つのネットワーク デバイスを接続するために、veth デバイスがよく使用されます。

1. Docker は、veth ペア デバイスの一方の端を新しく作成されたコンテナーに配置し、eth0 という名前を付けます。もう一方の端はホスト内に配置され、veth65f9 のような名前が付けられ、このネットワーク デバイスは docker0 ブリッジに追加され、brctl show コマンドで表示できます。
2. docker0 サブネットからコンテナに IP を割り当て、docker0 IP アドレスをコンテナのデフォルト ゲートウェイとして設定します。
3. ブリッジモードでのコンテナ通信

外部へのコンテナアクセス

ホスト ネットワーク カードが eth0、IP アドレスが 10.10.101.105/24、ゲートウェイが 10.10.101.254 であると仮定します。 IP 172.17.0.1/16 のホスト上のコンテナから Baidu (180.76.3.151) に ping を実行します。まず、IP パケットがコンテナからデフォルト ゲートウェイ docker0 に送信されます。パケットが docker0 に到達すると、ホストのルーティング テーブルを照会し、パケットをホストの eth0 からホストのゲートウェイ 10.10.105.254/24 に送信する必要があることを検出します。その後、パケットは eth0 に転送され、eth0 から送信されます。この時点で、Iptable ルールが有効になり、送信元アドレスが eth0 のアドレスに変更されます。このように、外部から見ると、このパケットは 10.10.101.105 から送信されており、Docker コンテナは外部からは見えません。

コンテナへの外部アクセス

コンテナを作成し、コンテナのポート 80 をホストのポート 80 にマップします。ホスト eth0 が受信した宛先ポート 80 にアクセスすると、Iptable ルールは DNAT 変換を実行し、トラフィックを上記で作成した Docker コンテナである 172.17.0.2:80 に送信します。したがって、外部からコンテナ内のサービスにアクセスするには、10.10.101.105:80 にアクセスするだけで済みます。

4.5 --リンク

コンテナが作成されたら、その名前で ping を実行します。このとき、次のように --link を使用する必要があります。

 docker run -d -P --name linux03 --link linux02 linux  
 docker exec -it linux03 ping linux02 は正常に ping できます。
 docker exec -it linux02 ping linux03 には ping できません。

ソースを遡って linux03 の /etc/hosts を見ると、基本的には単なるホスト マッピングであることがわかります。

 172.17.0.3 linux03 12ft4tesa # Windows ホストファイルと同じですが、アドレスバインディングがあります

4.6 自作の橋

直前に開始したコマンド (デフォルトでは --net bridge を使用しますが、省略可能) では、このブリッジが docker0 になります。次の 2 つは同等です。

 docker run -d -P --name linux01 LinuxSelf  
 docker run -d -P --name linux01 --net bridge LinuxSelf  

Docker0 はデフォルトではドメイン名アクセスをサポートしておらず、--link を使用してのみ接続できます。カスタム ネットワークを使用する場合、基盤となる Docker がすでに対応する関係を維持しているため、ドメイン名へのアクセスが可能になります。

 # --driver bridge ネットワークモードは次のように定義されます: bridge  
 # --subnet 192.168.0.0/16 はサブネットを定義します。範囲は 192.168.0.2 ~ 192.168.255.255 です。  
 # --gateway 192.168.0.1 サブネットゲートウェイを 192.168.0.1 に設定します 
 docker ネットワーク作成  --ドライバー ブリッジ --サブネット 192.168.0.0/16 --ゲートウェイ 192.168.0.1 mynet  

次のステップ

docker run -d -P --name linux-net-01 --net mynet LinuxSelf  
 docker run -d -P --name linux-net-02 --net mynet LinuxSelf  
 docker exec -it linux-net-01 ping linux-net-02 の IP # 結果 OK
 docker exec -it linux-net-01 ping linux-net-02 # 結果OK

5 視覚化インターフェース

5.1 ポーター

Portainer は Docker 用のグラフィカル管理ツールであり、ステータス表示パネル、アプリケーション テンプレートの迅速な展開、コンテナ イメージ ネットワーク データ ボリュームの基本操作 (イメージのアップロードとダウンロード、コンテナの作成など)、イベント ログの表示、コンテナ コンソールの操作、Swarm クラスターとサービスの集中管理と操作、ログイン ユーザーの管理と制御などを提供します。機能は非常に包括的で、基本的に中小規模のユニットのコンテナ管理のニーズをすべて満たすことができます。

5.2 DockerUI

DockerUI は Docker API をベースとしており、Docker コマンドラインと同等の機能をほとんど提供し、コンテナ管理やイメージ管理をサポートします。しかし、DockerUI の致命的な欠陥は、複数のホストをサポートしていないことです。

5.3 造船所

Shipyard は、Docker コンテナ、イメージ、レジストリを管理するためのシステムです。複数のホストにわたる Docker コンテナ クラスターの管理を簡素化します。 Web ユーザー インターフェースを通じて、コンテナーが使用しているプロセッサとメモリ リソースの量、実行中のコンテナーなどの関連情報の概要を取得できるほか、すべてのクラスターのイベント ログを確認することもできます。

6 Docker学習ガイド

もともとは共通手順、Dockerfile、Docker Compose、Docker Swarm について書こうと思っていたのですが、諦めようと思います。公式ドキュメントは不十分です!いくつかの学習ガイドをお勧めします。

公式ドキュメント: https://docs.docker.com/engine/reference/commandline/build/

入門から実践まで: https://github.com/yeasy/docker_practice

オンラインチュートリアル: https://vuepress.mirror.docker-practice.com