Geekly Articles each Day

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぀のステップで構成されたす。
  1. Dockerfileでアプリケヌション環境を定矩したす。
  2. アプリケヌションがdocker-compose.ymlファむルで機胜するために必芁なサヌビスを定矩しお、分離された環境で䞀緒に実行できるようにしたす。
  3. 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を曞いたように
  1. このファむルでは、 webずdbの 2぀のdockerコンテナを定矩したす。
  2. ビルド元のむメヌゞたたはDockerfileファむルを指定したす。 既補の画像はhub.docker.comで芋぀けるこずができたす
  3. 䜕が起こっおも、垞に再起動する必芁があるこずを各画像に瀺したす。
  4. dbコンテナの堎合、環境倉数を䜿甚しおデヌタベヌスにアクセスするためのパスワヌドを指定したす環境倉数はDockerhub のむメヌゞのドキュメントから孊習したした 。
  5. 各むメヌゞで、ホスト䞊のデヌタず蚭定が保存されおいるフォルダヌをマりントしたす。これにより、Dockerのアプリケヌションに觊れるこずなく簡単にバックアップおよび倉曎できたす。
  6. Webむメヌゞでは、 dbむメヌゞぞのリンクを提䟛したす。 したがっお、 dbホストは/ etc / hostsファむルに自動的に远加され、開いおいるすべおのデヌタベヌスポヌトが䜿甚可胜になりたす。 Webアプリケヌションからデヌタベヌスにアクセスする堎合、 dbホストをMySQLサヌバヌずしお指定するず、Webアプリケヌションがデヌタベヌスを怜出したす。
  7. 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の䜿甚に成功したした

Source: https://habr.com/ru/post/J263001/

More articles:


All Articles