Helmを使ったCD JenkinsパイプラインのHarnessへの移行

JenkinsパイプラインからHarness CDへの切り替えは簡単でした！以下は、Coreyの体験談です。

私たちのチームはHarnessに参入することになりましたが、これまでの製品開発には、継続的インテグレーション／継続的デプロイメント（CI/CD）パイプラインをJenkinsで構築していました。Harness CDへの移行について、私たちの経験を共有したいと思います。ネタバレ注意：簡単にできました！

Harnessを使用する前のデプロイメントソリューションを振り返ると、基本的なCD機能を実行するためにCIツールを使用することに固執していました。そこから抜け出した今だから言えますが、私たちはストックホルム症候群のような状態に陥っていたことが明らかになりました。 その違いを明らかにすべく、CI/CDツールの機能比較は以前にも取り上げたことがあります。

Jenkinsパイプラインの基本的な概要を見てみましょう。このパイプラインは、毎晩のビルドを開発環境やQA環境にデプロイし、非本番で使用するものです。

JenkinsのCDパイプラインでは、CIからパブリッシュされたコンテナや、gitからHelmのチャート／値を利用しています。この例では、パイプラインは複数のサービスと、k8sの名前空間内の全てをスモークテストするクライアントアプリをデプロイしています。ここまではごく普通のことですが、Jenkinsパイプラインのスニペットを見てみましょう。

stage('Deploy to Nightly K8S') {
            when {
                expression { params.DEPLOY_TO_NIGHTLY == true }
            }
            steps {
                script {

                dir('runtime/serviceA') {
                    script{
                      sh ( script:"/usr/local/bin/helm upgrade --install --atomic --timeout 10m -n ${nightly_namespace}  -f ./helm/serviceA/nightly/nightly-values.yaml --set image.tag=${tagName} --set service.deploymentName=${tagName} ${backend_release} helm-repo/helm-chart")
                    }

Jenkinsパイプライン内のいくつかのステージは、動的変数を使用するHelmのラッパーとなりました。JenkinsにリッチなCD機能がない代わりに、デプロイされたバージョンとロールバックを管理するためにHelmに依存することになりました。JenkinsをCDのために使うのは、古いハードウェアで最新のPCゲームをプレイするようなものです。可能だけど、かっこ悪い。

Harness移行、スクリプトはもう組まない！

幸いなことに、私たちはいくつかのベストプラクティスに基づいてHarnessに迅速に移行できる立場にありました。

• CIは既にさまざまな環境で実行可能なコンテナイメージを公開していました。
• CDパイプライン内のロジックを削減する、成熟したHelmチャートがありました。
• 環境の仕様は、プライベートなgitリポジトリーにHelmの値として保存されていました。

では、Collectorというサービス例で、Harnessのパイプラインを実行してみましょう。

Harnessはこのようなデプロイメントを想定して設計されています。そのため、パイプラインの再作成は、コードを書かずに基本的な設定を行うだけで良いのです！コネクターを使用することで、Harnessは同じコンポーネント（コンテナ、Helmチャート、Helm値など）を定義し、アクセスすることができました。上のハイライトは、HelmチャートとHelm値の両方を含むManifestセクションと、その場所を示しています。Artifactセクションには、必要なコンテナイメージの構成が全て含まれています。さらに、インフラストラクチャーも同じように処理されます。Kubernetesコネクターをセットアップし、名前空間を選択します！

そして最後に、パイプラインそのものについてです。

終わり！このサービスは１ステージ、１ステップだけです！このパイプラインは、新しいコンテナイメージが公開されるたびにトリガーされます。 ロールアウトのデプロイは一例に過ぎません。その他、カナリアやブルーグリーンなどの複雑なデプロイメントも、Jenkinsパイプラインなどでロジックを再作成することなく利用することが可能です。

また、HarnessにはContinuous Verificationなどの機能があり、デプロイが健全であることを確認し、ロールバックを推奨することも可能です。デプロイ時に基本的なk8sプローブに頼ることが多いHelmと比較すると、Harnessはデプロイを意識してロールバックの判断ができるようになっているのです。

おまけアドバイス：Helm値を使ったHarnessテンプレーティング

Harnessはテンプレートエンジンも持っています。Helmをご存知の方なら、Harnessのテンプレートも似たような仕組みで動きます。一般的な使用例としては、動的なパイプラインの値をHelmチャートに渡すことが挙げられ、コマンドライン構文が設定されることが多いようです。しかし、これは必ずしも必要ではありません。下記のvalues.yamlファイルの例では、パイプラインの実行中に置き換えられるHarnessの変数が使用されています。

config:
  installationKey: "<+serviceConfig.serviceDefinition.spec.variables.INSTALL_KEY>"
  backendURL: <+serviceConfig.serviceDefinition.spec.variables.BACKEND_URL>
 
image:
  repository: harness/serviceB
  tag: <+artifact.tag>

基本的なケースは、トリガーされたアーティファクトタグを使用することです。しかし、他の例としては、ユーザー入力や環境固有の値もあり得ます。テンプレートがもう１つあっても困りません。より多くの例については、Harnessの組み込み変数のリファレンスを参照してください。

結論

もし私たちが過去にしていたデプロイと同じようなものを抱えているなら、クラウドネイティブなデプロイのために原始的なCIツールでやりくりすることに苦労している可能性が高いでしょう。Harnessに移行すれば、私たちと同じアハ体験ができるはずです。

CDのためにゼロから設計された製品でデプロイする場合、Continuous Verificationやカナリアデプロイメントといったことが可能なだけでなく、Harnessが提供するソリューションに統合されているのです。パイプラインが次のレベルに到達するのに十分な経験値を獲得した今、古いPCをアップグレードして、節約した時間を次世代ゲームに費やす時が来たのです！

今後数週間のうちに、CI JenkinsパイプラインをHarnessに移行した経験を共有する予定です。その際にはこの記事を更新し、リンクを貼る予定です。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。