前回と同様に、ビデオに1時間以上費やす機会がある場合は、完全に視聴することをお勧めします（記事の最後を参照） 。 それ以外の場合は、テキスト形式で主要な本質を示します。
Dockerイメージには何が必要ですか？
CI / CDプロセス（継続的インテグレーション、継続的デリバリー、継続的デプロイメント）のコンテキストでの要件は次のとおりです。
- コンパクトなボリューム。 その理由は、CDのフレームワーク内では、非常に頻繁に大量に（各コミット）収集する必要があるため、すぐに巨大なストレージが必要になる可能性があるためです。 200 MB未満の画像レートを受け入れました（Ubuntuシステムの基本的な画像は130 MBかかります）。
- 10 KBのボリュームでコミットする場合、追加されたフルサイズのイメージではなく、イメージのサイズが同様に増加することを確認します。
- 画像の高速アセンブリ-10秒。
- 生成されたイメージをさまざまなサイトの最終製品として使用する機能（テストから実稼働まで）。
dockerfileの代わりにdapp
これらの要件を満たすには、標準のDockerメカニズムであるDockerfileでは不十分です。 Dockerの作成者にはこの理由が公式にあり、プロジェクトでは、一般的な（プライベートではなく）問題の解決と高レベルの移植性など、基本的かつ非常に論理的な原則として受け入れられています。
そのため、独自のユーティリティ-dapp （Rubyで、MITライセンスの下で配布）を作成しました。 この段階では、彼女は画像の組み立て方法を知っているだけであり、開発の計画にはCI / CDサイクル全体のサポートが含まれています。 dappの設計と実装では、使いやすさと速度/効率が優先されます。
2019年8月13日更新： dappプロジェクトの名前がwerfに変更され、そのコードが完全にGoに書き換えられ、ドキュメントが大幅に改善されました。
dappでコンパイルされたイメージの構成は、1つのリポジトリ→1つのプロジェクト→1つのDappfileの原則に関するDappfileで説明されています。 現在、このファイルの形式はRuby DSLですが、よりシンプルで使いやすいYAMLに切り替える予定です。
dappにはどのような機能がありますか？
1.ステージとキャッシュ
Dappは、Dockerイメージを構築するための4段階のパターンを実装します。
- before_install：OS設定など。これは（数十の異なるプロジェクトの分析結果による）コミットの1％未満を占めます。
- インストール：アプリケーションの依存関係-コミットの約5％。
- before_setup;
- セットアップ：構成-約2％。
これらの段階の結果はキャッシュされるため、画像の再構築速度が大幅に向上します。
2.外部コンテキスト
アセンブリ時のコンテナの場合、いわゆる「外部コンテキスト」が使用可能です。これらは、アセンブリ時に使用されるが最終イメージから除外されるマウントされたディレクトリです。 これらのディレクトリに情報を保存し、次のビルドに使用できます。
使用例は、ディレクトリ/ var / lib / aptです。apt-get更新後のコンテンツは、次のアセンブリにも必要ですが、イメージ自体（追加データ）には必要ありません。
3. Git
Gitからの変更のサポートも、最適化と柔軟性のアイデアに従って行われます。 イメージの最初のアセンブリでは、すべてのアプリケーションソースコード（gitアーカイブ）がイメージに追加され、後続のアセンブリではデルタのみ、つまり Gitパッチが適用されます。 パッチの内容は、パフォーマンスを向上させるためにキャッシュされます。
ファイル/ディレクトリを指定することができます。変更する場合は、インストール段階を実行する必要があります。
4.アーティファクト
場合によっては、プロジェクトをビルド（一部のコンポーネントを「コンパイル」）するために、最終アプリケーションで使用されない大規模なサードパーティツールが必要です（つまり、イメージに保存する必要はありません）。 これは、Cなどの言語でのソースのアセンブリだけでなく、たとえばNode.jsを使用したアセットの生成にも適用されます。 この問題は、いわゆる「アーティファクト」を使用して実装されます。 dapp buildコマンドが実行されると、アーティファクト（つまり、イメージのビルドに必要なサードパーティツール）を含む追加のDockerイメージが作成されます。 このアーティファクトのファイルは、外部コンテキストを使用して、追加から実際の（最終）イメージに追加されます。 アーティファクトについては、キャッシュもサポートされています。
5.シェフのサポート
画像の組み立てにおけるモジュール性は大きな利点をもたらしますが、シェル（Bash）のフレームワークでの実装は恩恵のない作業です。 しかし、構成管理システムで美しく作られています：Chef→Berkshelf、Puppet→Librarian ... Chefを使用しているため、dappにサポートを追加しました。 このサポートは、作成されたDockerイメージ内でレシピを実行する機能を意味します。
技術的には、ChefクックブックがGitリポジトリ内の特別なディレクトリ（.dapp_chef）に配置されるようにすべてが編成されます。 dapp buildコマンドが実行されると、必要なものはすべてDockerコンテナ内にマウントされたディレクトリに収集されます。 さらに、完全にインストールされたChef（chefdk）がコンテナにマウントされます。 次に、Chefが起動し、クックブックのコンテナーが構成されます。 結果のイメージはレシピに従って構成されますが、chefdkまたはcookbookは含まれません。
6.複数の画像
Dappfileで採用されている形式を使用すると、1つのファイルで多数の画像をすぐに記述できます。
オープンソースとしてのdapp
dappをほぼ2年間使用および開発してきましたが、CI / CDプロセスの構成と関連タスクの解決に役立つ、有用なオープンソースソリューションを作成したいと考えています。 ソースコードはGitHubで入手でき、 問題やプルリクエストも歓迎します 。 ドキュメントはこちらから入手できます 。
ところで、仕事があります！
dappの場合、テクノロジーエバンジェリストになることを夢見ているユニークな愛好家を探しています。 このようなツール、DevOpsの経験、プロジェクト管理、有能な技術テキストの作成に興味がある場合は、長々と説明せずに、info @ flant.ruまでご連絡ください。
ビデオとスライド
スピーチのビデオ（約1時間）がYouTubeで公開されました （リンクは13分から始まり、マイクに関する技術的な問題が停止し、導入部分でCIに関する一般的なレポートが繰り返されます ） 。
レポートのプレゼンテーション：
PS
ブログのトピックに関するその他のレポート：
- 「 WerfはKubernetesのCI / CDツールです（レビューおよびビデオレポート） 」 （Dmitry Stolyarov、2019年5月27日、DevOpsConf） 。
- “ データベースとKubernetes ” （Dmitry Stolyarov; 2018年11月8日HighLoad ++） ;
- 「 KubernetesとGitLabでのCI / CDのベストプラクティス 」 （Dmitry Stolyarov; 2017年11月7日HighLoad ++） ;
- 「 小規模プロジェクトでのKubernetesでの経験 」 （Dmitry Stolyarov、2017年6月6日、RootConfで） 。