DevOps関連のコードと構成をコードリポジトリに構築する方法は？

私たちは会社として成長しており、製品が拡大し、DevOps関連の活動と取り組みも成長しています-展開パイプラインやその他のプラグインを使用して、Bambooからより柔軟で構成可能なJenkinsに切り替えました。Ansibleに切り替え、Dockerを社内のあちこちで使い始めました。

これらすべてのものには、ある程度のコーディングまたは構成が必要です-Ansibleスクリプトと構成、Jenkinsグルーヴィーなスクリプト、Dockerfiles、YAML構成。

今のところ、我々はのためのハイレベルのディレクトリに別の「OPS」リポジトリを作成したjenkins、ansible、docker及びother（ひどい名前であるが、現在はすべて「その他」DevOpsチームのためのオートメーションのものがあります）。

私たちのアプローチは正しく感じられず、拡張できない場合がありますが、DevOps関連のコードをコードリポジトリに保持するためのベストプラクティスと推奨事項は何ですか？

説明するコードと構成の現在の構成は、関連する技術的ソリューションによって構成されています。これは悪い設計で、メンテナンスアクティビティに多くのオーバーヘッドが追加され、多くのトラップが追加されます。代わりに、その組織は、展開しているアーティファクトを中心に構築する必要があります。

この理由は、アーティファクト（例： Dockerイメージまたはソフトウェアパッケージ）を以下の動詞のオブジェクトと見なしたいためです。

• 建てる
• テスト
• 展開する

実行したい自動化されたタスクの最小限のセットを検討します。テスト動詞の実装方法について何かを変更したい場合は、適切なリポジトリー内のアーティファクトに対応するフォルダーにアクセスして、更新が必要なjenkins固有の自動化項目を見つけるのは簡単です。代わりに、自動化レシピが技術的ソリューションを中心に構成されている場合、ジェンキンスがテスト手順に関与していることをすぐに理解し、アーティファクト関連の自動化アイテムを見つける必要があります。複雑な状況では、技術的なソリューションを中心とした組織が更新を非常に困難にします。これは、サービスに関連するすべての技術的なソリューションをアプリオリに知って、それに応じて更新する必要があるためです。

たとえば、ウェブサイトのコードとマイクロサービス「a」を含むリポジトリには、操作専用の次のサブディレクトリを含めることができます。

./ops/website
./ops/micro-service-a

それぞれにとと呼ばれる3つのスクリプトbuildがtestありdeployます。自動化アイテムの構成がなんとかして明確になったので、構成に注目しましょう。

構成編成に関する主な条件と要件deployは、サービスのようなアーティファクトに適用されるときに動詞によって設定されます。deploy動詞は、次のパラメータを持っている必要があります。

• デプロイするアーティファクトのバージョン、
• アーティファクトのデプロイメントターゲット。デプロイされたアーティファクトが実行される具体的な環境を示します（例：クラスターと通信するエンドポイント）
• それは他のエンドポイントへの接続に使用する資格情報（たとえば、データベース）
• のランタイム構成（キャッシュエントリの存続期間など）

運用の観点から見ると、このパラメータ化の内訳は、ランタイム構成にバンドルできる資格情報は別として、展開の問題の自然な自由度と一致しますが、不用意に広がらないように分離することをお勧めします。

私はbock dockerに答えることができます。dockerを使用するためのベストプラクティスの1つは、プロジェクトの同じリポジトリにdockerファイルと構成ファイルを保持することです。そのため、プロジェクトのクローンを作成するときはいつでも、dockerイメージをビルドできます。たとえば、複数のバージョンのdocker composeファイル（prod、staging、dev）を保持して、イメージをビルドし、各環境の特定のオプションを使用してコンテナーを実行できます。たとえば、開発マシンでは、特定のネットワークを使用して、より多くの依存関係コンテナーを実行できます。

各ツールのコードは、独自のリポジトリに配置されます。例えば

1. JenkinsリポジトリへのJenkins Groovyテンプレート
2. 独自のリポジトリ内のAnsible YAMLプレイブック（役割、タスク、インベントリサブディレクトリを含む）
3. 独自のリポジトリ内のCloudformation / Terrformテンプレート
4. 独自のDockerファイル5.など

これにより、プロセスのオーケストレーションと各環境のさまざまなブランチの維持に関して、より適切にスケーリングできます。

これにより、よりきめ細かい制御が可能になり、バージョン管理のオーバーヘッドをすべてバージョン管理システムにオフロードできます。また、環境ごとに個別のブランチを作成し、すべての製品リリースのコードにタグを付けます（アプリケーションコードベースの場合と同様）。インフラを考え、コードの観点から処理します。（プロセスの変更はすべてコード化し、QA、SIT、UAT、次にPRODに送信する必要があります）アプリケーションと同様。

たとえば、本番環境（マスターブランチ）で実行されているAnsibleのV2.1が、製品（マスターブランチ）で実行されているV2.0のDockerコンテナーがあるとします。

同様に、DBスクリプト/ bashスクリプトを独自のリポジトリに保存します。追跡および自動化の目的で、デプロイされた各URLのすべてのツール/パーツのバージョンを表示するように構成されたヘルスチェックファイル（JSON / YAML）を持つことができます。（WebフックがURLを読み取ってデプロイメントを自動化するため）

Ops、Dev、DevOpsを区別することで、分離が促進され、「壁を越えて投げる」という考え方が適用されます。チーム間の連携を強化するには、プロジェクトのビルドとデプロイに必要なすべてをリポジトリに配置する必要があります。

そうは言っても、質問への答え：

DevOps関連のコードと構成をコードリポジトリに構築する方法は？

プロジェクトの実行にconfigが必要な場合は、同じディレクトリに配置する必要があります。