👘 🧑🏻 🦆 1.0から1.7までのDocker Engineイノベーションの概要。 Docker Composeの概要 💘 🛡️ 🏾

前の記事で、 Dockerとは何か、Dockerfileを使用してコンテナー間で通信する方法については既に説明しました。

これらの記事はDocker 1.1.2によって作成されました。それ以来、多くの便利なことがDockerに登場しました。これについては、この記事で説明します。また、Docker Composeについても詳しく見ていきます。DockerComposeは、1つのファイルにすべての依存関係を持つマルチコンテナーアプリケーションを定義し、このアプリケーションを1つのコマンドで実行できるユーティリティです。例は、 InfoboxCloudのクラウドサーバーで実演されます。

InfoboxCloudにDockerとComposeをインストールする

DockerをInfoboxCloudにインストールするには、CentOS 7仮想マシンを作成することをお勧めします。本番環境でCoreOS / Fedora Atomic / Ubuntu Snappyを使用することは、依然としてリスクが高すぎます。 Dockerが機能するためには、まさに今必要な仮想マシンです。そのため、サーバーを作成するときは、「OSカーネル制御を許可する」ボックスを必ずチェックしてください。

InfoboxCloud for Dockerでサーバーを作成する方法

InfoboxCloudにまだアクセスできない場合は、注文してください。

クラウドを使用すると、月額料金がないため非常に便利です。登録時には、一度に少なくとも500ルーブルをアカウントに補充し（携帯電話会社からSIMカードを購入するのと同様）、必要に応じてクラウドを使用できます。ここで、 1か月あたりのクラウドサーバーのコストを簡単に計算できます（たとえば、2000ギガヘルツではなく、2ギガヘルツの周波数など、正しいサイズを指定します）。支払いは1時間ごとに行われ、アカウントで凍結されます。自動スケーリングを使用するか、使用可能なサーバーリソースの量を手動で変更すると、必要なリソースにのみ料金を支払うことができ、さらに必要に応じてリソースを節約し、より多くのリソースを取得できます。

登録後、電子メールでコントロールパネルにアクセスするためのデータを受け取ります。 https://panel.infobox.ruでコントロールパネルにログインします。

サブスクリプションの[クラウドインフラストラクチャ]セクションで、[新しいサーバー]をクリックします（必要に応じて、ドロップダウンメニューの右上隅にあるサブスクリプションが変更されます）。

必要なサーバーパラメータを設定します。下のスクリーンショットに示すように、サーバーに1つのパブリックIPアドレスを与え、 「OSカーネル制御を許可する」ボックスをチェックしてください。

使用可能なオペレーティングシステムのリストで、CentOS 7を選択し、サーバーの作成を完了します。

その後、サーバーにアクセスするためのデータが電子メールで送信されます。

CentOS 7でサーバーを作成した後、 SSHを介してサーバーに接続します。

このようなサーバーでDockerとDockerを操作するための便利なユーティリティをインストールできるスクリプトを準備しました。必要な設定は自動的に行われます。

コマンドを実行してDockerおよびComposeをインストールします。

bash <(curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/install.sh)

スクリプトは何をしますか

1. OSを更新します。

2.後置を停止し、自動開始を禁止します。 Postfixはポート25を占有しますが、Dockerのサービスにはこのポートが必要な場合があります。

3.公式のDockerリポジトリを追加し、docker-engineをインストールします。

5. EPELリポジトリを追加し、pipをインストールし、pipでDocker Composeをインストールします。

6. Dockerサービスを開始し、スタートアップに追加します。

InfoboxCloudでのDockerおよびComposeの更新

更新するには、スクリプトを実行します。

 bash <(curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/update.sh)

バージョン1.0のDockerの新機能

このセクションでは、バグの修正やドッカーアーキテクチャの改善については触れず、ユーザーの主な新機能についてのみ触れます。これは、Docker機能の知識を更新するのに役立ちます。

1.1

Dockerignoreのサポート

Dockerfileの横に.dockerignoreファイルを追加できます。Dockerは、ビルドコンテキストをdockerデーモンに送信するときに、ファイルで指定されたファイルとディレクトリを無視します。

コミット時にコンテナが一時停止する

以前は、コンテナを実行するためのコミットは推奨されませんでした。同時操作とコミット中の整合性に違反する可能性があります（たとえば、コミット中に記録が行われた場合）。これで、コミット時にコンテナが一時停止します。

この機能を無効にする必要がある場合は、次のコマンドを使用します。

 docker commit --pause=false <container_id>

ログの最終行を出力する

これで、コンテナログの最後の行を表示できます。

以前は、ログ全体を表示するコマンドを使用してログを表示していました。

 docker logs <container_id>

次のコマンドを使用して、たとえばログの最後の10行を表示できます。

 docker logs --tail 10 <container_id>

また、ログ全体を読み取らずに、ログに追加されている内容を監視することもできます。

 docker logs --tail 0 -f <container_id>

Dockerコンテナを構築するときにコンテキストとしてtarファイルをサポート

これで、コンテキストとしてtarアーカイブをdockerビルドプロセスに渡すことができます。

アーカイブを使用して、Dockerテンプレートのアセンブリを自動化できます。次に例を示します。

 cat context.tar | docker build -

または

 docker run builder_image | docker build -

ホストファイルシステム全体をコンテナにマウントする機能

これで、 -volumesにホスト/ファイルシステムのルートを渡すことができます。

例：

 docker run -v /:/host ubuntu:ro ls /my_host

ただし、ホストファイルシステムをコンテナ/ファイルシステムのルートにマウントすることは禁止されており、コンテナ内の一部のフォルダでのみ可能です。

1.2

コンテナ再起動ポリシー

以前は、コンテナごとに、システムの起動時に実行する独自のスクリプトを作成する必要がありました。これで、Dockerサービスを使用してコンテナーを再起動できます。

--restartフラグは、次のポリシーを使用してdocker run コマンドに追加されます。

no-コンテナがクラッシュした場合、コンテナを再起動しません（デフォルト）。
on – failure-コンテナがゼロ以外のコードで終了した場合（つまり、異常な場合）、コンテナを再起動します。再起動の試行回数のオプションを指定することもできます（失敗時：5）
always-終了コードに関係なく、常にコンテナを再起動します。

dockerデーモンの--restartフラグは、新しいオプションのために非推奨になりました。

たとえば、Redisを含むコンテナは、存在する限り無限に上昇しようとします。

 docker run --restart=always redis

別の例：コンテナが正常に終了せずに落下した場合、5回上昇しようとします。

 docker run --restart=on-failure:5 redis

--cap-add --cap-drop

バージョン1.2より前では、Dockerはホワイトリストからすべての特権または特権のみを受け取り、他のすべてを禁止できました。 --privilegedフラグを使用すると、ホワイトリストに関係なく、コンテナにすべての権限が付与されます。これは本番環境では推奨されておらず、本当に安全ではありません。ホストで直接作業しているようです。

バージョン1.2では、 docker runで使用する2つの新しいフラグ--cap-addと--cap-dropが導入されました。これらのフラグを使用すると、コンテナの許可内容をより正確に制御できます。

たとえば、コンテナインターフェイスのステータスを変更するには：

 docker run --cap-add=NET_ADMIN ubuntu sh -c "ip link eth0 down"

コンテナでchownを無効にするには：

 docker run --cap-drop=CHOWN ...

mknod以外のすべてを解決するには：

 docker run --cap-add=ALL --cap–drop=MKNOD ...

-デバイス

以前は、 -privilegedコンテナで-vを使用してデバイスをマウントすることにより、コンテナ内でデバイスを使用できました。 docker runで--deviceフラグを使用できるようになりました 。これにより、-- privilegedフラグなしでデバイスを使用できます。

たとえば、コンテナ内でデバイスを使用する場合：

 docker run --device=/dev/snd:/dev/snd ...

書き込み可能な/etc/hosts、/etc/hostname、/etc/resolv.conf

これで、実行中のコンテナで/etc/hosts、/etc/hostname、/etc/resolve.confを編集できます。これは、これらのファイルを上書きできるバインドまたはその他のサービスをインストールする必要がある場合に便利です。

これらのファイルへの変更は、コンテナのアセンブリ中に保存されず、結果の画像には表示されないことに注意してください。変更は、実行中のコンテナにのみ表示されます。

1.3

docker execによる追加プロセスの開始

以前は、sshd（だけでなく）がコンテナで機能するためには、実行中のアプリケーションでsshdプロセスを開始する必要があり、追加のリスクとオーバーヘッドが発生しました。デバッグには、コンテナへのアクセスが非常に重要です。したがって、新しいdocker execコマンドが追加されました。これにより、ユーザーはdocker apiおよびCLIを使用してコンテナー内のプロセスを開始できます。

たとえば、コンテナ内にbashセッションを作成するコマンドは次のようになります。

 docker exec -it ubuntu_bash bash

主な推奨アプローチである「コンテナごとに1つのアプリケーション」は変更されていませんが、開発者は、アプリケーションのオフィスプロセスを必要とするユーザーに会いに行きました。

Docker Createによるコンテナーライフサイクル管理の改善

docker run image_nameコマンドは、コンテナーを作成し、その中でプロセスを開始します。多くのユーザーは、コンテナのライフサイクルをより正確に制御するために、これらのタスクを分離することを求めています。 docker createコマンドはこれを可能にします。

例：

 docker create -t -i fedora bash

、コンテナレイヤを作成し、コンテナIDを表示しますが、開始しません。

開始するには、次を実行します。

 docker start -a -i <container_id>

したがって、 docker createコマンドは、ライフサイクルを管理するためにdocker startおよびdocker stopコマンドを使用する柔軟性をユーザーおよび/またはプロセスに与えます。

セキュリティオプション--security-opt

このリリースでは、新しいフラグ--security-optが追加され、ユーザーがカスタムラベルとSELinuxおよびAppArmorプロファイルをカスタマイズできるようになりました。

たとえば、コンテナプロセスがApacheポートでのみリッスンできるようにする次のポリシーが表示されます。

 docker run --security-opt label:type:svirt_apache -i -t centos bash

この機能の利点の1つは、SELinuxおよびAppArmorをサポートするカーネルで特権モードを使用せずに、ユーザーがdockerコンテナーでdockerコンテナーを実行できるようになったことです。コンテナに特権を与えないことにより、潜在的な脅威の攻撃対象領域を大幅に削減できます。

1.4

このリリースでは、セキュリティが大幅に改善されています。

1.5

IPv6サポート

コンテナごとに、新しいフラグ--ipv6を使用してipv6アドレスを割り当てることができます。コンテナー内で、ipv6アドレスを解決できます。

読み取り専用コンテナ

--read-onlyフラグを使用することにより、コンテナファイルシステムを読み取り専用にすることができます。これにより、アプリケーションがファイルを書き込むことができるコンテナ内の場所を制限できます。この機能をボリュームと組み合わせて使用すると、コンテナが管理する既知の場所にのみデータを記録するようにできます。

統計用のAPI

コンテナのCPU、メモリ、ネットワークIO、ディスクIOに関するデータを提供する統計用のAPIがあります。したがって、コンテナを監視できるようになりました。

アセンブリに使用するDockerfileを指定する機能

最も要求の多い機能の1つが実装されました-デフォルトでファイルだけでなく、 Dockerビルドを使用する機能。 docker build -fを使用すると、イメージをビルドするファイルを指定できます。たとえば、テスト用と本番用に別々のDockerfileを使用できるようになりました。

画像のオープン仕様

これで、画像の仕様が公開されました。これは、画像内に何がどのように含まれているかを理解するのに役立ちます。

1.6

これで、一連のdockerユーティリティが最終的に別個のDocker Engine、Registry、Compose、Swarm、およびMachineに形成されます。作成については、記事の次のセクションで説明します。その他のユーティリティについては、次の記事で説明します。

コンテナと画像のラベル

ラベルを使用すると、ユーティリティで使用できるコンテナと画像にユーザー定義のメタデータを追加できます。

ロギングドライバー

3つのオプションを含む新しいオプション--log-driverが登場しました 。

json-file（デフォルト）
syslog
なし

また、サードパーティのロガーに接続できるロギングAPIが登場しました。

連想画像識別子：ダイジェスト

イメージをダウンロード、ビルド、または実行するときに、 名前空間/リポジトリ：タグまたは単なるリポジトリの形式でそれらを指定できます。「ダイジェスト」と呼ばれる新しい識別子を使用して、 名前空間/リポジトリ@ダイジェストという構文のコンテナをダウンロード、ビルド、および起動できるようになりました。ダイジェスト-画像内のコンテンツへの不変のリンク。

ダイジェストを使用するための優れたユーザーケース-パッチと更新。セキュリティ更新プログラムをリリースする場合は、セキュリティ更新プログラムと共にイメージのダイジェストを指定して、更新プログラムがサーバーにインストールされていることを確認できます。

--cgroup-parent

コンテナは、名前空間、機能、およびcgroupの組み合わせで構成されます。 Dockerは、任意の名前空間と機能をサポートするために使用されていました。フラグ--cgroup-parentを使用してcgroupのサポートを追加しました。特定のcgroupをコンテナに渡すことができます。これにより、コンテナでcgroupを作成および管理できます。 cgroupのリソースを定義し、共通の親グループにコンテナを配置できます。

ウリム

これまでのところ、コンテナはdockerデーモンからulimit設定を継承しています。 ulimitを使用すると、プロセスの使用を制限できます。生産負荷では制限が非常に高くなる場合がありますが、コンテナには理想的ではありません。新しいオプションを使用すると、dockerデーモンを構成するときにすべてのコンテナーのulimit設定を指定できます。次に例を示します。

 docker -d --default-ulimit nproc=1024:2048

このコマンドは、すべてのコンテナに対して1024のソフト制限と2048の子プロセスのハード制限を設定します。異なるパラメーターに対してオプションを複数回使用できます。

 --default-ulimit nproc=1024:2048 --default-ulimit nofile=100:200

これらの設定は、コンテナを作成するときにオーバーロードできます。

 docker run -d -ulimit nproc=2048:4096 httpd

コミットおよびインポート時にdockerfileステートメントを使用できるようになりました

これで、画像全体を再構築することなく、その場で画像を変更できます。これはcommit-exchangeおよびimport --change関数によって可能になり、新しいイメージに適用する変更を指定できます。適用できるサポートされているコミットおよびインポートの手順を以下に示します。

1.7

このリリースには、書き換えられたネットワークおよびボリュームサブシステム、安定性の向上、ZFSドライバーが含まれています。

Docker作成

分散アプリケーションは通常、連携して動作するいくつかの小さなサービスで構成されています。 Dockerはこれらのアプリケーションを個別のコンテナーに変換し、一緒にバインドします。 Docker Composeでは、各コンテナを構築、起動、管理する代わりに、1つのファイルにすべての依存関係を持つマルチコンテナアプリケーションを定義し、単一のupコマンドでこのアプリケーションを起動できます。アプリケーションの構造と構成をまとめておくと、どこでも簡単に繰り返し実行できます。

Composeの使用は、通常3つのステップで構成されます。

Dockerfileでアプリケーション環境を定義します。
アプリケーションがdocker-compose.ymlファイルで機能するために必要なサービスを定義して、分離された環境で一緒に実行できるようにします。
docker-compose upコマンドを実行します。 Docker Composeはアプリケーションを起動します。

Composeを使用すると、アプリケーションのライフサイクルを管理できます。

サービスの開始、停止、および再構築
実行中のサービスのステータスを表示する
実行中のサービスのログをブロードキャストします
サービスで必要なコマンドを実行します。

docker-compose.yml

docker-compose.ymlファイルには、アプリケーションをdockerにデプロイするためのルールが含まれています。

dockerの各サービス– compose.ymlには、少なくとも1つのイメージ（ image ）またはビルドするスクリプト（ build ）が含まれている必要があります。他のすべてのパラメーターは、 docker runコマンドのパラメーターと同様にオプションです。

docker runと同様に、Dockerfileで指定されたオプション（CMD、EXPOSE、VOLUME、ENVなど）はデフォルトで実行されます。docker-compose.ymlでそれらを繰り返す必要はありません。

利用可能なdocker – compose.ymlオプションのリストは、公式ドキュメントに記載されています。

理論から実践に移り、PHPとMySQLでApacheのdocker-composeを作成しましょう。

 web: image: trukhinyuri/apache-php ports: - "80:80" - "443:443" volumes: - ./apache/www/:/var/www/ # - ./apache/conf/sites-enabled/:/etc/apache2/sites-enabled/ links: - db restart: always db: image: centurylink/mysql:latest volumes: - ./mysql/conf/:/etc/mysql/conf.d/ - ./mysql/data/:/var/lib/mysql/ environment: MYSQL_ROOT_PASSWORD: ********** # MYSQL_DATABASE: wordpress restart: always

LAMPをデプロイするためのdocker-compose.xmlを書いたように

このファイルでは、 webとdbの 2つのdockerコンテナを定義します。
ビルド元のイメージまたはDockerfileファイルを指定します。（既製の画像はhub.docker.comで見つけることができます）
何が起こっても、常に再起動する必要があることを各画像に示します。
dbコンテナの場合、環境変数を使用してデータベースにアクセスするためのパスワードを指定します（環境変数はDockerhub のイメージのドキュメントから学習しました ）。
各イメージで、ホスト上のデータと設定が保存されているフォルダーをマウントします。これにより、Dockerのアプリケーションに触れることなく簡単にバックアップおよび変更できます。
Webイメージでは、 dbイメージへのリンクを提供します。したがって、 dbホストは/ etc / hostsファイルに自動的に追加され、開いているすべてのデータベースポートが使用可能になります。 Webアプリケーションからデータベースにアクセスする場合、 dbホストをMySQLサーバーとして指定すると、Webアプリケーションがデータベースを検出します。
Webコンテナでは、外部ポート80および443を転送して、ネットワーク経由でサイトにアクセスできるようにします。

マウントされたフォルダーに、サイトファイル、Apache構成、サイトデータベースを配置します。サイトが新しい場合は、データベースの名前を使用して環境変数のコメントを解除できます。コンテナの起動時に作成されます。これで、サーバーに非常に迅速に展開できるポータブルWebサイトができました。

InfoboxCloudでサーバーを作成し、 Dockerをインストールし、記事の冒頭で指定した単一のコマンドを使用して構成するとします。 dockerでランプフォルダーをコピーするだけです– compose.xml、サイトおよびデータベースフォルダー、コマンドを実行します

 docker-compose up -d

LAMPスタックが上昇し、私たちのサイトは既に動作します。とても簡単！サイトを別のサーバーに移動するか、10台のサーバーに展開しますか？ LAMPフォルダーを別のサーバーにコピーしてdockerを実行するだけで、もう一度作成します。

したがって、 dockerおよびcomposeを使用すると、アプリケーションおよびシステム全体を準備済みの環境にパックし、それらのデプロイメントの構成を規定できます。この場合、展開は1つのチームで行われ、準備が整っていないユーザーでも実行できます。 InfoboxCloud（および一般的にはIaaSクラウド）での複雑なシステムの展開もPaaSのシンプルさで行われますが、インフラストラクチャのすべての側面を制御します。これは、 OnlyOfficeが使用する展開方法です。

composeを使用して再デプロイするときに重複バインドマウントエラーが発生した場合

この場合、作成されるコンテナを確認してください。これを行うには、次のコマンドを使用します。

 docker ps -a

docker-compose.ymlで説明されているコンテナのほかに、奇妙な名前のコンテナが表示されます。この場合、名前は「335698fa2d_lamp_db_1」です。

次のコマンドで削除します：

 docker rm 335698fa2d_lamp_db_1

335698fa2d_lamp_db_1は、奇妙な名前のコンテナの名前に置き換えます。

その後、composeは正常に再デプロイされます。

おわりに

次の記事では、Dockerの他の便利なユーティリティについて検討します。記事に間違いを見つけた場合、または質問がある場合は、PMまたはメールでご連絡ください。 Habréにコメントを残せない場合は、コミュニティに書き込みます。

Dockerの使用に成功しました！

1.0から1.7までのDocker Engineイノベーションの概要。 Docker Composeの概要