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', # phpapp 'groupadd -g 242 phpapp', 'useradd -m -d /home/phpapp -g 242 -u 242 phpapp' end install do run 'apt-get install -y php7.0-sqlite3 php7.0-xml php7.0-zip', # composer 'curl -LsS https://getcomposer.org/download/1.4.1/composer.phar -o /usr/local/bin/composer', 'chmod a+x /usr/local/bin/composer' end before_setup do # composer install run 'chown phpapp:phpapp -R /demo && cd /demo', "su -c 'composer install' phpapp" end setup do # run 'echo `date` > /demo/version.txt', 'chown phpapp:phpapp /demo/version.txt' end end # , start.sh docker.expose 8000 end
また、
start.sh
を追加して実行可能にする必要があります（
chmod +x start.sh
）：
#!/bin/sh cd /demo su -c 'php bin/console server:run 0.0.0.0:8000' phpapp
アプリケーションイメージをビルドするには、次のコマンドを使用します。
$ 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
ブログのトピックに関するその他のレポート：
- 「 WerfはKubernetesのCI / CDツールです（レビューおよびビデオレポート） 」 （Dmitry Stolyarov、2019年5月27日、DevOpsConf） 。
- “ dappで練習します。 パート2. Helmを使用したKubernetesでのDockerイメージの展開 ";
- 「 dappを使用してプロジェクトを構築します。 パート1：Java ";
- 「 dappを使用してプロジェクトを構築します。 パート2：JavaScript（フロントエンド） ";
- 「 dappとGitLab CIを使用してKubernetesでアプリケーションをビルドおよびインストールします 。」