Jenkinsを使用したマルチ環境展開のベストプラクティス

私には3つの環境があり、それぞれ独自の構成を持つ独自の仮想ネットワーク上にあります。各環境で継続的デプロイメントを行う場合、Jenkinsの3つの個別のインスタンスが必要ですか？マルチ環境アーキテクチャーへの展開をグレードアップするいくつかのベストプラクティスは何ですか？

これは、ci/cdツールを環境に結合するための一般的なアンチパターンであるため、非常に良い質問です。

Jenkinsはビルドファクトリです。このように、それは環境の概念や配信さえも完全に認識していないはずです。

最善の方法は、何らかのステージングプロセスやインターフェイスを用意することです（余裕がある場合は、専用の配信ソフトウェア）。

ステージングプロセス

環境ごとにある種のステージングジョブを作成して、環境の構成を定義し、最終的なパッケージを環境にバンドルする必要があります。

次に、各環境の配信ジョブがあります。

配信ツール

ステージングと配信雇用を創出行うためには、あなたのような、非常に基本的なスクリプトツールを使用することshellが、より適したスクリプトツールがある、のようなAnsible、puppet、chef...

費用が余裕がある場合は、展開ソフトウェアへの投資を検討することもできます（コメントセクションで、私が扱ったいくつかについて触れます）。

これらのソフトウェアは、何らかの環境のステージングプロセスを管理することに注意してください。

言うまでもなく、デプロイソフトウェアとスクリプトを組み合わせると、多くのメリットがあります。

分離ツールと環境を超えて

あなたはベストプラクティスを求めたので、SCMツールと配信プロセスの結合という、よく見られる別のアンチパターンについて言及する価値があるように思えます。

（もちろんパスワードや機密情報ではなく）環境構成を保存し、SCMツール（またはなど）でライブスクリプトを実行することは非常に良い習慣です。ただし、稼働中に環境設定をチェックアウトして稼働スクリプトを実行することは非常に悪い習慣です。必要なときに使用できない場合があります。svngit

このチェックアウトフェーズは、前述のステージングプロセスの一部である必要があります。

Idem Potence

別のベストプラクティスは、スクリプトをidem-potent次のようにすることです。これは、ステージングと配信を実行するためにスクリプトを1回再生できる必要があることを意味します。そうすれば、それらを何度も再生できるはずです。また、構成に何らかの変更が加えられない限り、システムの状態は変更されません。

スケーリング

最後のベストプラクティスとして、私が直接の経験から共有するのは、ジェンキンスを呼び出すことです。異なるチームは異なるジェンキンスのニーズと用途を持っています。あまりにも多くのチームが共通のJenkinsを共有している場合、リソースに問題がある可能性があります。最悪のケースは、チームがJenkinsマスターを再起動する必要がある一方で、別のチームが配信する必要がある場合です。

理想は、同じ目標と配信計画を共有するチームごとまたはチームのグループごとに1つのJenkinsを持つことです。

私は、Jenkinsのフリースタイルジョブを使用することから、Jenkinsパイプライン（宣言構文）を使用するように環境ごとに別々のジョブを作成することから移行しました。

Jenkinsパイプラインには単一のファイル（Jenkinsfile）があり、異なる環境（Dev / Staging / Prod）に異なるステージを定義し、それらのステージでは環境ごとに異なる動作を定義します。たとえば、「デプロイ」ステージでは、開発環境かステージング環境かによって、異なるkubernetes名前空間/クラスターにデプロイします。

すべてのブランチに存在するプロジェクトごとにJenkinsfileが1つしかないため、このアプローチが好きです。

あなたの質問への短い答えはノーです。Jenkinsは本番環境と対話する必要はありませんが、必要に応じて対話できます。言い換えれば、ジェンキンスがこれらの環境に到達できる場合、それはおそらくそれらと相互作用することができます。

ベストプラクティスアプローチから、通常は、デプロイを可能な限りシンプルで再現性の高いものにするソフトウェア（たとえば、make、Ansible、Terraform、Cloud Formation、またはKubernetes）を使用することをお勧めします。

パイプラインは並列ターゲットを処理できるため、必要に応じて3つの環境すべてを同時に構築してデプロイできます。

より多くのフィードバックを得るために、質問をより正確または詳細にすることができます。

さまざまな環境で単一のJenkinsfileを使用できます。しかし、この環境を区別するために何かが必要です。環境変数や、各環境で何をする必要があるかを制御するためのパラメーター化されたジョブのパラメーターなどです。1つの環境でビルド、テスト、e2eの実行、イメージのリポジトリへのプッシュを実行したい場合があります。次に、同じイメージを使用して、次のステージング（ステージング、可能性があります）で展開し、煙のテストを実行します。次に、同じイメージを使用して本番環境にデプロイします。