Docker。 開始する

Dockerを使い始めたとき、同僚と私は同じ感情を感じました。 ほとんどの場合、これは基本的なメカニズムの理解不足に起因するため、その動作は予測不可能であるように思われました。 今、情熱は静まり、憎しみの発生はますます少なくなっています。 さらに、私たちは実際にそのメリットを徐々に評価し、好きになり始めます...一次拒否の度合いを減らし、使用の効果を最大化するには、Dockerのキッチンをよく見て、そこをよく見てください。

Dockerが必要なものから始めましょう：

1. コンテナ内のアプリケーションの単独起動
2. アプリケーションの開発、テスト、および展開の簡素化
3. 実行するために環境を構成する必要はありません-アプリケーションに付属しています-コンテナ内
4. コンテナオーケストレーションシステムにより、アプリケーションのスケーラビリティと管理を簡素化します。

先史時代

仮想マシンを使用して、同じホストで実行されているプロセスを分離し、異なるプラットフォーム用に設計されたアプリケーションを実行できます。 仮想マシンは、ホストの物理リソースを共有します。

• プロセッサ
• 記憶
• ディスクスペース
• ネットワークインターフェース。

各VMで、目的のOSをインストールし、アプリケーションを実行します。 このアプローチの欠点は、ホストのリソースの大部分がペイロード（アプリケーション作業）ではなく、いくつかのOSの動作に費やされることです。

コンテナ

アプリケーションを分離する別のアプローチは、コンテナです。 コンテナの概念は新しいものではなく、Linuxで長い間知られています。 1つのOS内の隔離された領域を分離し、その中でアプリケーションを実行するという考え方です。 この場合、OSレベルの仮想化について話します。 VMとは異なり、コンテナはOSスライスを単独で使用します。

• ファイルシステム
• プロセスツリー
• ネットワークインターフェース
• その他

T.O. コンテナで実行されているアプリケーションは、OS全体の1つであると見なします。 分離は、 名前空間やコントロールグループなどのLinuxメカニズムを使用して実現されます 。 簡単に言えば、名前空間はOS内での分離を提供し、制御グループはコンテナーのホストリソースの消費に制限を設定して、実行中のコンテナー間のリソースの分散を調整します。

T.O. コンテナ自体は新しいものではなく、Dockerプロジェクトだけが、第一に、名前空間、コントロールグループの複雑なメカニズムを隠し、第二に、ソフトウェア開発のすべての段階でコンテナを便利に使用できるエコシステムに囲まれています。

画像

最初の近似では、画像はファイルのセットと見なすことができます。 イメージには、ドッカーを備えたベアマシンでアプリケーションを実行および実行するために必要なすべてのものが含まれます：OS、ランタイム、および展開の準備ができたアプリケーション。

しかし、このような考慮事項では、同じホスト上で複数のイメージを使用する場合、ロードの観点とストレージの観点の両方から非合理的であるため、ほとんどのファイルが繰り返されるため、各イメージが作業に必要なすべてをドラッグします。異なる-起動されるアプリケーションと、場合によってはランタイムのみ。 イメージの構造により、ファイルの重複を避けることができます。

イメージはレイヤーで構成され、各レイヤーは不変のファイルシステムであり、ファイルとディレクトリの単純なセットです。 イメージ全体は、ファイルシステムレイヤーをマージした結果と見なすことができる統合ファイルシステム（ユニオンファイルシステム）です。 結合されたファイルシステムは、たとえば、同じ名前のファイルとディレクトリが異なるレイヤーに存在する場合、競合を処理できます。 次の各レイヤーは、前のレイヤーからいくつかのファイルを追加または削除します。 この文脈では、「削除」は「隠蔽」、つまり 下層のファイルは残りますが、結合されたファイルシステムでは表示されません。
Gitで類推できます。レイヤーは個別のコミットのようなものであり、画像全体はスカッシュ操作の結果です。 後で見るように、Gitとの類似点はこれで終わりではありません。 フェデレーションファイルシステムにはさまざまな実装があり、そのうちの1つがAUFSです。

たとえば、任意の.NETアプリケーションMyApplicationのイメージを考えます。最初のレイヤーはLinuxカーネルで、その後にOS、ランタイム、およびアプリケーション自体のレイヤーが続きます。



レイヤーは読み取り専用であり、ドットネットレイヤーにあるファイルをMyApplicationレイヤーで変更する必要がある場合、ファイルは最初に目的のレイヤーにコピーされ、次に変更され、元の形式で元のレイヤーに残ります。



レイヤーの不変性により、ホスト上のすべてのイメージでレイヤーを使用できます。 MyApplicationは、データベースを使用し、NodeJSサーバーとも対話するWebアプリケーションであるとします。



画像をダウンロードする際にも共有は明らかです。 マニフェストを最初にロードします。これには、イメージに含まれるレイヤーが記述されます。 次に、マニフェストからまだローカルにないレイヤーのみがダウンロードされます。 T.O. MyApplicationで既にカーネルとOSをダウンロードしている場合、PostgreSQLおよびNode.jsではこれらのレイヤーは読み込まれません。

要約すると：

• イメージは、Dockerがインストールされたベアマシンでアプリケーションを実行するために必要なファイルのセットです。
• イメージは不変のレイヤーで構成され、各レイヤーは前のレイヤーのファイルを追加/削除/変更します。
• レイヤーの不変性により、レイヤーを異なるイメージで一緒に使用できます。

Dockerコンテナー

Dockerコンテナは、イメージに基づいて構築されます。 画像をコンテナに変換する本質は、記録を許可する最上位レイヤーを追加することです。 アプリケーションの結果（ファイル）はこのレイヤーに書き込まれます。



たとえば、PostgreSQLサーバーでイメージに基づいてコンテナを作成し、起動しました。 データベースを作成すると、対応するファイルがコンテナの最上層、つまり記録層に表示されます。



コンテナからイメージを作成するために、逆の操作を実行できます。 コンテナの最上層は、書き込み許可のみが他の層と異なります。それ以外は、通常の層（ファイルとディレクトリのセット）です。 最上層を読み取り専用にして、コンテナを画像に変換します。



これで、イメージを別のマシンに転送して実行できます。 同時に、前の手順で作成したデータベースをPostgreSQLサーバーで確認できます。 コンテナの操作中に変更が行われると、データベースファイルは不変データレイヤーから記録レイヤーにコピーされ、そこで既に変更されています。

Docker

ローカルマシンにドッカーをインストールすると、クライアント（CLI）と、デーモンとして機能するhttpサーバーが取得されます。 サーバーはREST APIを提供し、コンソールは入力されたコマンドを単純にhttpリクエストに変換します。

登録

レジストリは画像のリポジトリです。 最も有名なのはDockerHubです。 GitHubに似ており、ソースコードではなく画像のみが含まれています。 DockerHubには、パブリックおよびプライベートのリポジトリもあり、画像をダウンロード（プル）、画像の変更をアップロード（プッシュ）できます。 一度ダウンロードされた画像とコンテナは、手動で削除されるまでローカルに保存されます。



独自のイメージストレージを作成する可能性があり、必要に応じて、Dockerはまだローカルに存在しないイメージを探します。 Dockerを使用する場合、イメージストレージはCI / CDの最も重要なリンクになります。開発者はリポジトリにコミットし、テストが実行されます。 テストが成功した場合、コミットに基づいて、既存のイメージが更新されるか、新しいイメージが後続の展開でアセンブルされます。 また、レジストリでは、画像全体ではなく、必要なレイヤーのみが更新されます。



アプリケーションが単に宛先に配信されて起動されるような一種のボックスとしてのイメージの認識を制限しないことが重要です。 また、アプリケーションをイメージ内でアセンブルすることもできます（コンテナー内と言う方が正確ですが、それについては後で詳しく説明します）。 上の図では、イメージを構築するサーバーにインストールできるのはDockerのみであり、アプリケーションのさまざまなコンポーネントを構築するために必要なさまざまな環境、プラットフォーム、およびアプリケーションはインストールできません。

Dockerfile

Dockerfileは、新しいイメージを作成するための一連の命令です。 各命令は、イメージに新しいレイヤーを追加します。 例として、以前に考慮されていた.NETアプリケーションMyApplicationのイメージを作成できるDockerfileを考えます。

FROM microsoft/aspnetcore WORKDIR /app COPY bin/Debug/publish . ENTRYPOINT["dotnet", "MyApplication.dll"] 

各命令を個別に検討してみましょう。

1. 基本的なイメージを決定し、それに基づいて独自のイメージを構築します。 この場合、Microsoftの公式イメージであるmicrosoft / aspnetcoreを使用します。これはDockerHubにあります
2. 画像内に作業ディレクトリを設定します
3. 事前共有MyApplicationアプリケーションをイメージ内の作業ディレクトリにコピーします。 最初に、ソースディレクトリが書き込まれますdocker buildで指定されたコンテキストへの相対パス、および2番目の引数はイメージ内のターゲットディレクトリです。この場合、ドットは作業ディレクトリを示します
4. コンテナを実行可能ファイルとして設定します。この場合、 dotnet MyApplication.dllコマンドが実行されてコンテナが起動します

Dockerfileを使用してディレクトリでdocker docker buildを実行すると、microsoft / aspnetcoreに基づいたイメージが取得され、さらに3つのレイヤーが追加されます。



軽量イメージ用の優れたDocker機能を示す別のDockerfileを検討してください。 コンテナをサポートするプロジェクト用に同様のファイルがVisualStudio 2017によって生成され、アプリケーションのソースコードから画像を収集できます。

 FROM microsoft/aspnetcore-build:2.0 AS publish WORKDIR /src COPY . . RUN dotnet restore RUN dotnet publish -o /publish FROM microsoft/aspnetcore:2.0 WORKDIR /app COPY --from=publish /publish . ENTRYPOINT ["dotnet", "MyApplication.dll"] 

ファイル内の指示は、2つのセクションに分かれています。

1. アプリケーションをビルドするためのイメージの定義：microsoft / aspnetcore-build。 このイメージは、.NETアプリケーションをビルド、公開、および実行するように設計されており、タグが2.0のDockerHubによると、サイズは699 MBです。 次に、アプリケーションのソースファイルがイメージにコピーされ、その内部でdotnet restoreおよびdotnet buildコマンドがdotnet restoreれ、結果がイメージ内の/ publishディレクトリに配置されます。
2. ベースイメージは決定されます。この場合はmicrosoft / aspnetcoreで、ランタイムのみが含まれ、 DockerHubの2.0タグによると、サイズは141 MBのみです 。 次に、作業ディレクトリが決定され、前のステージの結果がそこにコピーされます（名前は--from引数で指定されます）。コンテナを起動するコマンドが決定され、 --fromイメージが準備できました。

その結果、最初にアプリケーションのソースコードを取得し、SDKを使用して重いイメージに基づいてアプリケーションを複製し、ランタイムのみを含む明るいイメージの上に結果を配置しました。

結論として、Dockerfileでの作業を考慮して、簡単にするために、イメージの概念を意図的に操作したことに注意してください。 実際、各命令によって行われた変更は、もちろん、イメージではなく（結局、不変のレイヤーのみを持ちます）、コンテナーで発生します。 メカニズムは次のとおりです：コンテナがベースイメージから作成され（記録用のレイヤーが追加されます）、このレイヤーの命令が実行され（ファイルを記録レイヤーに追加できます： COPYまたはENTRYPOINT ）、 ENTRYPOINT docker commitコマンドが呼び出され、イメージが取得されます。 コンテナを作成してイメージにコミットするプロセスは、ファイル内の各命令に対して繰り返されます。 その結果、最終イメージを形成するプロセスで、ファイル内の指示と同じ数の中間イメージとコンテナーが作成されます。 それらはすべて、最終イメージのアセンブリ後に自動的に削除されます。

おわりに

もちろん、Dockerは万能薬ではありません。その使用は、多くの人が話している現代のテクノロジーを使用したいという欲求だけでなく、正当化され、動機付けられるべきです。 同時に、有能で場所に適用されたDockerは、ソフトウェア開発のすべての段階で多くの利点をもたらし、プロセスのすべての参加者の生活を楽にすることができると確信しています。

この問題をさらに研究することの基本的なポイントと関心を明らかにできることを願っています。 もちろん、Dockerをマスターするには、この記事だけでは十分ではありませんが、Dockerを実行しているコンテナの世界で何が起こっているのかについての全体像を理解するためのパズルの要素の1つになることを願っています

参照資料

1. Docker ドキュメント
2. 名前空間メカニズム
3. 制御グループのメカニズム
4. Dockerの記事