この記事は、オープンソース
dappユーティリティを使用してアプリケーションのDockerイメージを構築するための入門ガイドです
（詳細については、 アナウンスメントを参照してください 。例として2つの単純なアプリケーション（1つのイメージ）結果が得られます。
2019年8月13日更新： dappプロジェクトの名前がwerfに変更され、そのコードがGoに書き換えられ、ドキュメントが大幅に改善されました。
すぐに、dappがローカルアプリケーション開発を簡素化するユーティリティとして考えられていなかったことを予約します。 しかし、最近、私たちは普通の開発者の生活をどのように促進できるかというビジョンを開発しました。これについては別の記事が必ず出てきます。 そして今-CI / CDプロセスの簡素化について。
ビルドアプリケーション
アセンブリはCI / CDプロセスでどの部分を使用しますか？
distol peer レポートの図をもう一度見てみましょう：
アセンブリは、プログラムのソースコードをGitリポジトリ
（ gitステージ）からDockerイメージに変換し、さまざまな環境
（ ビルドステージ）で実行できる状態にします。 問題は、既に
Dockerfileと
Dockerfileを持っている場合、単純化するために何がありますか？ 実際、さまざまな言語のアプリケーション用にDockerイメージを作成することに関する多くの記事があります。 しかし基本的に、これらはソーススライスからのアプリケーションの構築と起動に関する記事です。
数十のアプリケーションがある場合、どのような問題に遭遇しますか？ ビルドプロセスに
多くの共通部分があり、
Dockerfile一部をコピーする必要があることが判明した場合 いつ
アセンブリの速度を上げたいですか（結局、アプリケーションで変更されたファイルは2つだけです）？ これらの質問は、実際に会うまで事前に予測することはできません。 このような質問に対する回答とそれらを解決した経験は、dappユーティリティに組み込まれています。
dappとDappfileを使用してビルドする
dappが提供するものの実例を見てみましょう。 最初のテストとして、シンプルなPHPアプリケーション
symfony-demoを使用します。
GitHubで最も
Dappfileする人のために、
Dappfileが既に追加され、
Vagrantfileれ
Vagrantfileので、
Vagrantfile vagrant up実行するだけで、Dockerとdappをシステムにインストールせずにアプリケーションをビルドできます。
お急ぎで「まっすぐに突っ込みたい」場合は、dappをインストールし
（ werfインストールドキュメントを参照 ）、アプリケーションリポジトリを複製する必要があります。
$ git clone https://github.com/symfony/symfony-demo.git $ cd symfony-demo $ vi Dappfile
アセンブリを記述する
Dappfileは、RubyのDSL構文のファイルです（
Vagrantfileに似てい
Vagrantfileが、古い形式のサポートを維持しながらYAMLに切り替える予定です）。 その内容：
dimg 'symfony-demo-app' do docker.from 'ubuntu:16.04' git do add '/' do to '/demo' end end shell do before_install do run 'apt-get update', 'apt-get install -y curl php7.0',
また、
start.shを追加して実行可能にする必要があります（
chmod +x start.sh ）：
アプリケーションイメージをビルドするには、次のコマンドを使用します。
$ dapp dimg build
そして、次のように実行します：
$ dapp dimg run -d -p 8000:8000 -- /demo/start.sh
機能：キャッシュ、gitパッチ、ビルドステージ
アセンブリは、実行されたすべてのアクションを含む長いログを生成します。 リストは非常に大きいため、その一部は
GitHubに個別にアップロードされ
ます 。
dapp dimg build再度実行すると、これらのアクションは再び実行されません。 彼らの仕事の結果はキャッシュされます。 再起動ログは
ここで見ることができ
ます 。 彼の断片：
ステージ名と結果
[USING CACHE]行が表示されます-これは、dappが説明されたアクションを実行せず、新しいイメージレイヤーを作成したが、既存のレイヤーを使用したことを意味します。
開発者になりすまして変更を加えましょう。たとえば、
app/Resources/views/base.html.twigのページヘッダーのリンクテキストを変更します。 コミットし、アプリケーションのビルドを試みます。
git patchのみが重ね
られている
ことが git patch ます 。 キャッシュされたレイヤーに基づいて新しい画像が作成され、プロジェクトファイルに変更が追加されました。
... Setup [USING CACHE] signature: dimgstage-symfony-demo:3705edf770dd88ac714a7001fd24f395c87b2110005025eff48019d5973846ce date: 2017-08-16 04:16:46 +0000 difference: 0.0 MB Git artifacts dependencies [USING CACHE] signature: dimgstage-symfony-demo:f3f1c3e1ce5f0f5b880b1ec693b194d7e6a841a4166b29982d11b4e4c4cbe360 date: 2017-08-16 04:16:49 +0000 difference: 0.0 MB Git artifacts: apply patches (after setup) [USING CACHE] signature: dimgstage-symfony-demo:15e56865dd8b2a1cc55d5381a4e6f2cbcdc3a718509de29b15df02e8279b42c3 date: 2017-08-16 04:16:52 +0000 difference: 0.0 MB Git artifacts: latest patch ... [OK] 3.22 sec signature: dimgstage-symfony-demo:a9c21d0e36218563c8fd34b51969ed2f3b6662ca7775acae49488c5ebbbf25e1 Docker instructions ... [OK] 3.16 sec signature: dimgstage-symfony-demo:2eae4537c4210aaf4a153c7b8d3036343abf98b4ac4a3b99a2eb1967bea61378 instructions: EXPOSE 8000
このビルドアクセラレーションは、特別な処理を必要としないファイルに適しています。 たとえば、
composer.jsonが変更され、アセンブリ中に
composer installを呼び出す必要がある場合はどうしますか？
この場合、dappは4つのカスタムビルドステージをサポートします
（詳細はドキュメントで説明されています ） 。 最初の段階は
before_install 、その間ソースコードは利用できません。 通常、これはめったに変更されないパッケージとOS設定のインストールです。 次の3段階：
install 、
before_setupおよび
before_setupすでにソースコードにアクセスできます。
git patchオーバーレイを管理する方法
ファイルの変更が特定のステージからアセンブリを再起動することを示すために、
gitディレクティブで
stage_dependenciesディレクティブを指定する必要があります。 このアプリケーションの場合、
composer.jsonまたは
composer.lockファイルを変更すると、
composer installが開始される
before_setupステージから再構築が行われます。 したがって、
gitディレクティブは次のようになります。
git do add '/' do to '/demo' stage_dependencies.before_setup 'composer.json', 'composer.lock' end end
ビルドログは
こちらです。
installステージの後に
git path適用され、
before_setupステージからイメージが再構築されたことが
before_setupます。
... Install [USING CACHE] signature: dimgstage-symfony-demo:a112d1abf364602c3595990c3f043d88e041a2a6f3cbcf13b6fc77a9fb3fd190 date: 2017-08-16 04:14:19 +0000 difference: 5.0 MB Git artifacts dependencies ... [OK] 2.75 sec signature: dimgstage-symfony-demo:9f0600ab6fb99356110c50454fc31e5fdc6ac3028e4ba8f200e789d140514bf9 Git artifacts: apply patches (after install) ... [OK] 2.18 sec signature: dimgstage-symfony-demo:f139188f9b0662d8177d41689b57c700e2276d997139673c3384731f6851d72e Before setup [BUILDING] ...
リポジトリ内のファイル変更とステージ間のこのような関係により、全体のビルド時間を短縮できます。 ほとんどの場合、アプリケーションの依存関係はほとんど追加または変更されません。 たとえば、開発者が新しい機能を実装するため、
composer.json依存関係を追加する必要がありました。 新しい依存関係がある最初のコミット、イメージは
before_setupステージから再構築されます-これには時間がかかります。 ただし、
composer.json変更されなくなる後続のコミットは、迅速に実行されます。 これにより、CI / CD構成で、開発者とDevOpsエンジニアのブランチで各コミットのビルドを自動的に実行できます
（「 継続的な統合と実稼働への配信のためのGitLab CI。パート1：パイプライン 」を参照） 。
機能：マルチステージまたはアーティファクト画像？
少し前まで 、
Dockerfile 、他のイメージ（マルチステージビルド）を使用して最終イメージの一部を組み立てることが可能になりました。 これは、golang、webpack、gcc、またはその他のツールを最終イメージにドラッグしないために行われます。これらのツールは、アセンブリにのみ必要であり、アプリケーションの実行中は絶対に必要ありません。 Dappは、
artifactセクションを使用してこのアセンブリをネイティブにサポートします。
次の例の
golang Webアプリケーションを
ご覧ください。 最初のアプリケーションと同様に、GitHubから
Dappfileおよび
Vagrantfileを
Dappfile実験準備のできたリポジトリを
Vagrantfileできます（
2019年8月13日更新： werfを使用してビルド
例を使用）。
手順：
$ git clone https://github.com/revel/examples revel-examples $ cd revel-examples/booking $ vi Dappfile
Dappfileは次のようになります。
dimg_group do artifact do docker.from 'golang:1.8' git do add '/' do to '/go/src/github.com/revel/examples' end end shell.before_install do run 'apt-get update', 'apt-get install -y sqlite3 libsqlite3-dev tree' end shell.install do run 'go get -v github.com/revel/revel', 'go get -v github.com/revel/cmd/revel' end shell.build_artifact do run '(go get -v github.com/revel/examples/booking/... ; true)' run 'revel build github.com/revel/examples/booking /app' end export '/app' do to '/app' after 'install' end end dimg 'booking-app' do docker.from 'ubuntu:16.04' end end
同じコマンドをすべてビルドして実行できます。
$ dapp dimg build $ dapp dimg run -p 9000:9000 --rm -d -- /app/run.sh
docker imagesの出力の間で迷子にならないように、最終画像をテストします。
$ dapp dimg tag booking-app:v1.0
これで、golangビルドツールを使用して、最終画像のサイズが画像のサイズに依存しないことがわかります。
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE booking-app v1.0 57d564633ecb 4 minutes ago 136MB ubuntu 16.04 ccc7a11d65b1 7 days ago 120MB golang 1.8 6ce094895555 3 weeks ago 699MB
次に、
artifact使用して
Dappfileをより詳細に説明します（意図的に
Dappfileアプリケーションのアセンブリ機能を省略します-興味がある場合は、コメントで議論できます）。 一般的に、構造は次のようになります。
dimg_group artifact do docker.from git export end dimg 'dimg_name' do docker.from end end
artifactセクションは、アプリケーションの一部を別のイメージにアセンブルする必要があることを示し、 artifact内のgitディレクティブは、ソースコードを配置する場所を示すことができます。exportは、 build_artifactステージbuild_artifact実行した後、別のイメージから最終イメージにコピーするものを示しbuild_artifact 。exportでは、最終段階の画像がアーチファクトの結果を必要とする段階を指定することもできます。 私たちの場合、それはafter 'install' 、つまり installステージコマンドの後、アーティファクトイメージの/appディレクトリが最終イメージにコピーされます。
一見、これはすべてマルチステージ
Dockerfileに似ていますが、アーティファクトの利点は、Gitの変更に対するキャッシングとステージの依存関係（これらの依存関係は
gitセクションで説明できます）を使用することです。
まとめ
説明されているdappの機能：ステージへの分割、Gitリポジトリ内のファイルの変更へのステージの依存、アーティファクトイメージの使用により、CI / CDプロセスとローカル開発の両方で、ほぼすべてのアプリケーションのアセンブリを簡素化および高速化できます。
しかし、これはほんの始まりに過ぎません。
Dappfile複数の画像を一度に記述でき、
dapp dimg buildはそれらを収集し、
dapp dimg push --tagタグ
dapp dimg push --tag配置し、レジストリにキャッシュ画像と最終画像をプッシュします。 これらの機能については、次の記事で詳しく説明します-最近、dappに登場したKubernetesでの展開のサポートの説明と併せて。
PS
ブログのトピックに関するその他のレポート：