この記事では、CI / CDプロセスの構築と保守に毎日使用するオープンソースユーティリティであるdappを使用して、構成の開発とデバッグを容易にするツールキットを紹介します（短いビデオで示します）。
2019年8月13日更新： dappプロジェクトの名前がwerfに変更され、そのコードがGoに書き換えられ、ドキュメントが大幅に改善されました。
注 ：最近、dappでのYAML構文のサポートが発表されました。その機能はこの出版物に記載されています。 デフォルトでは、以下で説明するすべてのツールは、彼とRuby DSLの構成（dappの以前のバージョンで使用）の両方に対して有効であり、そうでない場合は個別に示されます。
ステージ内観
最初の手順で構成を記述することは、命令を実行するときにアセンブリコンテナに含まれる内容が理解できないため複雑です。
アプリケーションとアーティファクトの構築は、関連する一連のステージで構成されます。 各ステージは、前のステージのイメージ（ fromステージの場合はベースイメージ）に基づくアセンブリコンテナーにアセンブルされ、Dockerイメージ（アプリケーションキャッシュ）に保存されます。 すべてのステージは特定の機能を実行し、構成内の対応するディレクティブに関連付けられています。 ステージの性質、機能、機能、および可能な状態についての詳細は、 ドキュメントをご覧ください。
アセンブリプロセス中に、 イントロスペクションオプションを使用して特定のステージにアクセスでき ます 。 イントロスペクション中、アセンブリコンテナである環境には、保守ツールと環境変数が含まれます。 ツールキットは、一連のユーティリティの形式で提供されます。これは、アセンブリ時に必要です。 これは、 dappdepsディストリビューションのサービスコンテナーからディレクトリをマウントすることで追加されます（アセンブリコンテナーでは、 /.dapp/deps 。 /.dapp/depsパスで利用可能です）。 これらの分布の概念、それらのアセンブリおよび構成のプロセスに関する詳細は、 dappdepsに関する記事に記載されています 。
開発中に、イントロスペクションを使用すると、アセンブリコンテナで目的の結果に到達し、すべてのステップ、指示を対応するステージの構成に転送できます。 このアプローチは、タスクが明確な場合に役立ちますが、それを解決する手順は明らかではなく、実験が必要です。
イントロスペクションモードで設定を記述するプロセス（ symfony-demoアプリケーションの例を使用）は、このビデオで説明されています：
デバッグ時に、イントロスペクションを使用すると、アセンブリが失敗し、結果が予想を満たしていない理由を確認でき、依存ファイル、システムステータスを確認できます。
最後に、 Ansible-collectorでイントロスペクションを使用する場合（dappでのAnsibleサポートの詳細については、 この記事を参照してください ） 、アセンブリコンテナーでAnsibleプレイブックをデバッグしてから、Ansible-tasksを適切な構成ステージに転送できます：
アセンブリ中、次のイントロスペクションオプションがサポートされます 。
開発モードでローカルGitリポジトリを操作する
標準ビルドモードで構成を開発する場合、dappがアセンブリ中にファイルの変更を考慮するように、正式なコミットが必要です。 Dockerfile構築するときに作業ディレクトリをマウントするのと同様に、ローカルリポジトリの現在の状態を操作したいDockerfile思います 。
この概念は、アセンブリの開発モードで実装されます。アセンブリは、構成に対応するローカルGitリポジトリへのコミットされていない変更を考慮します。 正確には、次のgitサブディレクトリからのパスが考慮されます： add 、 includePaths 、 excludePaths 、 stageDependencies 。
git-submodulesとネストされたGitリポジトリを追加すると、すべてのレベルで.gitignoreファイルが考慮されます。
dapp dimg build --dev
asLayersディレクティブを使用した代替キャッシングスキーム
ステージbefore_install 、 install 、 before_setup 、 setupは、構成内の対応する指示に依存します。 命令を変更すると、対応するステージがすべての命令で再アセンブリされます。 したがって、重い、時間のかかる命令では、開発が遅れる可能性があります。
このすべてに加えて、コマンドを実行するときに、アセンブリが最終段階の命令のいずれかに該当する場合に追加します。 アセンブリを新たに実行する必要があるという事実に加えて、倒れた指示の前に環境の状態を取得し、以前の指示の正確性を確認する方法はありません。
開発とデバッグを容易にするために、 asLayersディレクティブが導入されました。これは、構成内の特定のアプリケーションまたはそのアーティファクト（ dappfile.yaml ）に対して指定されます。 アセンブリ中、 命令は個別にキャッシュされ 、順序が変更された場合にのみ再アセンブリが実行されます。
asLayersディレクティブがない場合（またはasLayers: false場合）、デフォルトのキャッシュが使用されます。 ステージのすべての命令に対して1つのDockerイメージasLayers: trueを指定すると、新しいキャッシュモードが有効になります-シェルのコマンドごとに1つのDockerイメージまたはAnsibleの1つのタスク。
ビルドモード間の切り替えは、 asLayersディレクティブによってのみ規制されます。残りの構成指示は変更されません。 アセンブリ命令をデバッグした後、 asLayersオフにする必要があります。 asLayersでasLayersを使用するビデオデモ：
asLayersディレクティブを使用すると、命令を個別にキャッシュできます。 イントロスペクションオプション--introspect-errorおよび--introspect-before-error使用すること--introspect-before-errorユーザーは問題ステートメントの実行前または実行後に環境を取得できます。
重要な注意事項：
- 新しいdapp機能はYAML設定でのみ実装されているため、
asLayers Ruby DSLのバージョンではサポートされなくなりました。 - この命令は、イメージの定期的なアセンブリに使用しないことが重要です。このモードは、過剰な数のDockerイメージを生成し、インクリメンタルアセンブリ用に設計されていません（レイテンシとアセンブリキャッシュのサイズが増加するため）。
要約する
dappは、DevOpsエンジニアの日常業務の主要ツールの1つであるため、本当に便利で、すべてのニーズを満たそうとする意欲があります。 同時に、これはオープンソースプロジェクトであり、サードパーティのユーザーからの問題も喜んでいます。そのシナリオは私たちの経験とは異なる場合があります。 また、この記事へのコメントでdappの使用に関するご質問にお答えする準備ができています-ようこそ！
PS
ブログもご覧ください。