Dockerの使用を開始して以来、かなりの数の問題に直面しています。 その1つは、アプリケーションのアセンブリを整理し、コンテナにパッケージ化することです。 アセンブリコンテナの概念を導入することで、この問題を解決しました。 それが何であるのか、なぜそれが必要なのか、どのようにしてこのポイントに到達したのかについては、この投稿で説明します。
ビルダーコンテナとは何ですか？
アセンブリコンテナは特別にアセンブルされたドッカーイメージであり、そのタスクは、プログラムのソースに対して何らかの作業を行うことです。たとえば、インストールの依存関係、ソースのコンパイル、静的コード分析などです。 定義は非常に長いので、例を見てみましょう。
あるプロジェクトがあります。 ビルドして実行するには、次のものが必要です。
- 必要なすべてのnpmパッケージをインストールする
- bowerを使用して、すべてのクライアント依存関係をインストールします
- それから私たちにこのすべてをもたらすようにうなり声を実行します
このためにnpm-builderを使用します-nodejs、npm、g ++、およびmakeを含むアセンブリコンテナー。わかりやすくするために、すべての手順を個別に実行します。
$ docker run --rm -v `pwd`:/data -w /data leanlabs/npm-builder npm install $ docker run --rm -v `pwd`:/data -w /data leanlabs/npm-builder bower install --allow-root $ docker run --rm -v `pwd`:/data -w /data leanlabs/npm-builder grunt build
そのため、いくつかのチームで組み立てられたプロジェクトを取得しました。
何が起こっているのか見てみましょう。 docker container npm-builderをプロジェクトのルートディレクトリで実行し、現在のディレクトリ（すべてのソースを含むプロジェクトのルートディレクトリ）を/ dataにマウントします。コンテナのすべてのコマンドが実行されるように/ dataをコンテナの作業ディレクトリとして指定します。
最初のコマンドnpm installは、bowerを含むpackage.jsonにリストされているすべてのnodejsモジュールをnode_modulesディレクトリにインストールします。
次のコマンドbower install --allow-rootを使用して、bower.jsonにリストされているすべての依存関係をbower_componentsディレクトリーにインストールします。
そして最後のコマンドで、私たちはうなり声でプロジェクトの構築を開始します。 また、コンテナを起動するときに、-rmオプションを指定して、停止後にコンテナが削除されるようにします。
phpプロジェクトの例を使用すると、 composerアセンブリコンテナーを使用して依存関係をインストールできます。
$ docker run --rm -v `pwd`:/data imega/composer:1.1.0 install --no-dev
なんでこんなこと？
プロジェクトへのエントリーのしきい値。 アセンブリコンテナを使用すると、開発者のマシンにさまざまなソフトウェアをインストールする必要がなくなります。 プロジェクトで作業を開始するために必要なのは、プロジェクトリポジトリのクローンを作成し、dockerをインストールし、docker-composeを実行して「docker-compose up -d」を実行することです。プロジェクトの構築と開始に必要なすべてのコンテナは、Dockerハブからプルアップされます。 開発者のマシンに、アセンブリと起動に必要な多様なソフトウェアをインストールする必要がなくなりました。
ビルド時間。 アセンブリのすべての指示がDockerfileで指定されている場合、コンテナのアセンブリ時間は、アセンブリ手順の数に比例して増加し始めます。
均一なランタイム。 アプリケーションの構築と起動は独立しており、コンテナへのパッキングは、アセンブルされたアプリケーションの単なるコピーです。 これは、環境に関係なく、アプリケーションが常に実行されるコンテナは同じであることを意味します。たとえば、phpのアプリケーションはすべて、phpを含むコンテナで実行されます。 そのため、何かが突然壊れた場合、どこでも同じように壊れます。
アセンブリ手順の再利用。 アセンブリがDockerfileに記述されている場合、すべてのアセンブリステップを毎回記述し、ONBUILD命令を使用して解決する必要がありますが、この場合、一定のレベルの柔軟性が失われますアセンブリでは、アセンブリ中に何が起こるかを理解するために、親コンテナのソースを調べる必要があります。
アセンブリの予測可能性。 Dockerの使用を開始したとき、最初に、ホストマシンでプロジェクトをビルドするいくつかの手順を実行しました。 これをしないでください;）
アセンブリプロセスの均一性 。Dockerfileの詳細を処理する必要がないため、Dockerは主に構成管理ツールとしてではなく、アプリケーションのパッケージ化、配信、起動の手段として機能します。 ビルドプロセスをDockerfileから分離することで、ほとんどのDockerfileが次のようになることを実現できました。
FROM leanlabs/nginx:1.0.1 COPY . /var/www/client/ COPY ./build/sites-enabled/client.conf /etc/nginx/sites-enabled/client.conf CMD ["nginx", "-g", "daemon off;"]
既存のツールを使用します。 Dockerエコシステムには、すでに多くのツールがあり、十分かつ有用であり、あまりよくありませんが、車輪を再発明したくありませんでした。 たとえば、docker-compose、アセンブリコンテナもここで機能します。
アセンブリコンテナーの使用に関する規則
アセンブリコンテナのアイデアを適用する過程で、私たちは自分自身のためのいくつかの開発および使用契約を特定しました。
一般的な「インターフェース」 。 一般から、volume'yを割り当てました。 アセンブリコンテナには、アプリケーションのソースコードとキャッシュをマウントするためのボリューム/データがあります。たとえば、アセンブリコンテナのキャッシュでディレクトリをマウントするために、サードパーティの依存関係（composer、npm、bowerキャッシュ）があります。 アセンブリコンテナーの場合、インターフェイスとして機能する1つの基本イメージを使用します。
アセンブリコンテナは、アプリケーションへの外部依存関係です。 たとえば、phpunitはコンポーザーを介して接続され、バージョンとその存在はアプリケーション自体によって直接決定されるため、phpunitで個別のアセンブリコンテナーを使用しません。
起動方法。 起動方法に従って、コンテナを次のように分割します。
- ワンショットコンテナー、1回実行、コマンドを実行し、作業を完了します。 依存関係のインストール、 ソースコードの複製 、apiのドキュメントの生成に使用すると便利です。
- 長時間実行されるコンテナ、長寿命のコンテナ、ソースの変更を追跡してプロジェクトを再構築します-スタイルが変更されたときにSCSSを再構築し、JSをビルドし、ソースが変更されたときにテストを実行し、静的アナライザーを実行します。
コンテナの命名。 npm-builder、erlnag-builderなど、アセンブリコンテナの名前に接尾辞「-builder」を追加します。
docker-composeで使用する
たとえば、ソースコードを変更するときにアクションを実行する必要がある場合、開発者の環境でdocker-composeと組み合わせてアセンブリコンテナを使用すると便利です。
docker-composeでは、すべてが簡単ですが、微妙な違いがあります。 ワンショットコンテナーは、docker-compose upが「-d」オプションで実行される場合にのみ使用できます。そうでない場合、そのようなコンテナーの操作が完了すると、composeは他のすべてのコンテナーを停止します。
これは、composerを使用してphpアプリケーションの依存関係をインストールする方法です。
phpbuilder: image: imega/composer:1.1.0 volumes: - "./:/data" - "$HOME/.composer:/cache" command: ["update"]
長時間実行されるコンテナは問題なく動作します。 これは、nodejsのインストールの開始、依存関係のうねり、およびgruntの開始の様子です。
clientbuilder: image: leanlabs/npm-builder volumes: - "./:/data" - "$HOME/.node_cache:/cache" command: ["/bin/sh", "-c", "npm install && bower install --allow-root && grunt"]
makeで使用する
Dockerおよびアセンブリコンテナと組み合わせてMakeを使用して、リリースをビルドします。代わりに、docker-composeを使用します。
アセンブリコンテナアプローチを使用したメイクファイルの例を次に示します。
IMAGE = leanlabs/client TAG = 1.1.9 build: @docker run --rm -v $(CURDIR):/data -v $$HOME/node_cache:/cache leanlabs/npm-builder npm install @docker run --rm -v $(CURDIR):/data -v $$HOME/node_cache:/cache leanlabs/npm-builder bower install --allow-root @docker run --rm -v $(CURDIR):/data -v $$HOME/node_cache:/cache leanlabs/npm-builder grunt build release: @docker build -t $(IMAGE) . @docker tag $(IMAGE):latest $(IMAGE):$(TAG) @docker push $(IMAGE):latest @docker push $(IMAGE):$(TAG) .PHONY: build release
まとめ
その結果、Dockerがインストールされているすべての環境で再現された、かなり軽量なプロセス、既存のツールで使用できるアプリケーションをコンテナにビルドおよびパックするプロセスが得られました。 高品質のアセンブリコンテナの作成に時間を費やしたので、責任範囲に適したタスクで再利用できます。
以上です。 ご清聴ありがとうございました。
この記事の執筆を手伝ってくれた同僚cnam812に感謝します。