Jenkins Configuration as Code：最初の一歩（ママ見て、すごいでしょ）

この記事は、6回にわたってお届けする予定の「Configuration as Code」シリーズの第1回です。

Jenkinsは非常に柔軟性があり、現在、継続的インテグレーションおよび継続的デリバリー（CI/CD）を実装するにあたってのデファクトスタンダードです。ほぼどのようなツールやユースケースの組み合わせにも対応できるプラグインを擁するアクティブなコミュニティがあります。しかし、柔軟性には代償もあります。Jenkinsのコアに加えて、多くのプラグインでは、システムレベルの設定が必要です。

場合によっては、Jenkins管理者はフルタイムの職務です。インフラストラクチャを維持し、何百ものインストール済みプラグインと何千ものホストされたジョブを持つ巨大なJenkinsマスターのご機嫌をとるのに、専任の担当者が必要になります。プラグインのバージョンを最新に保つことは大きな課題であり、フェールオーバーは悪夢です。

これでは何年も前、システム管理者がサービスごとに専用マシンを管理しなければならなかった時代と同じです。2018年の現代では、インフラストラクチャの自動化ツールと仮想化を使用してすべてがコードとして管理されます。アプリケーションのステージング環境として新しいアプリケーションサーバーが要る？それならDockerコンテナをデプロイするだけです。インフラストラクチャのリソースが足りない？それならTerraformのレシピを適用して、どこでも好きなクラウドで、もっと多くのリソースを割り当てればよいでしょう。

このようなコンテキストから考えると、 Jenkinsの管理者ロールはどうなるでしょうか？まだWeb UIで何時間も費やし、Webフォームのチェックボックスをクリックしなければならないのでしょうか？すでにいくらか自動化を進め、複雑怪奇なGroovyスクリプトや内製のXMLテンプレートを利用していたりするのではないでしょうか？

今年の初め、Jenkins Configuration as Code（JCasC）のアルファリリースが発表されました。JCasCは、YAML設定ファイルと自動モデル検索に基づく、Jenkins設定管理のまったく新しいアプローチです。JCasCはトップレベルのJenkinsプロジェクトに昇格し、対応するJenkins Enhancement Proposal（Jenkins Enhancement Proposal）が承認されました。

JCasCはJenkins管理者のために何をしてくれるのか?

JCasCを使用すると、Jenkinsマスターの起動時に、またはWeb UIから必要に応じて、YAMLファイルのセットをマスターに適用できます。これらの設定ファイルは、Jenkinsが実際に設定を保存するために使用する冗長なXMLファイルと比較して、非常に簡潔で人間にも読みやすい形式です。このファイルには、管理者がすべてのJenkinsコンポーネントを簡単に設定できるように、分かりやすい命名規則もあります。

設定ファイルのサンプル：

jenkins:
 systemMessage: "Jenkins managed by Configuration as Code"
 
 securityRealm:
   ldap:
     configurations:
       - server: ldap.acme.com
         rootDN: dc=acme,dc=fr
         managerPasswordSecret: ${LDAP_PASSWORD}
     cache:
       size: 100
       ttl: 10
     userIdStrategy: CaseInsensitive
     groupIdStrategy: CaseSensitive

ご覧のとおり、長々しい説明をしなくても、このYAMLファイルがどのようにJenkinsマスターをセットアップするかを理解できるでしょう。

利点

JCasCの最も直接的な利点は、再現性です。管理者は、簡単なセットアップを行うだけで、まったく同じ設定を持つ新しいJenkinsマスターをすぐに立ち上げられるようになりました。これにより、テスト用インスタンスを作成し、プラグインのアップグレードが及ぼす影響をサンドボックス環境でチェックできます。また、より自信を持ってフェールオーバーや障害回復のシナリオを実行できるようになります。

これに加えて、JenkinsのYAML設定ファイルをTerraformの設定と同様にソース管理システムで管理するれば、さらなるメリットが発生します。つまり、Jenkinsマスター設定の監査ができることと、設定を元に戻せるようになることです。テスト用Jenkinsインスタンスを実行し、設定が正常であることを確認してから変更を実稼働中のJenkinsマスターに適用するという、設定変更ワークフローを確立できます。

最後に、（しかし前記に劣らず）重要な点として、YAML設定ファイルを使用してJenkinsのマスターを素早くセットアップし、制御することで、管理者は各種プラグインによる柔軟性を持たせながら、チームごとのJenkinsインスタンスを提供できるようになります。Jenkinsfilesを使用してビルド定義を管理していれば、マスターは、恒久的なものというよりは、一時的な利用も可能なインフラストラクチャの部品になります。

Configuration as Codeを採用すると、ご機嫌をとらなければならないペットのようにJenkinsのマスターを扱う必要がなくなり、労力や悪影響なしに置き換え可能な家畜として管理できるようになります。「as Code」の世界へようこそ。

（それでもこの子たちはまだかわいいですよね）

では、この次は？

Jenkins Configuration for Codeプラグインの詳細については、プロジェクトのGitHubリポジトリをご覧ください。コミュニティやコントリビューターとチャットするには、私たちのgitterチャネルに参加してください。または、 DevOps World/Jenkins World 2018で直接JCasCプロジェクトとその未来についてお話しましょう。

また、「Configuration as Code」シリーズの次の記事もお見逃しなく。次回は、JCasCがパスワードやその他の認証情報などの機密データをどのように扱うかを取り上げます。

（この記事は、CloudBees社 Blog 「Jenkins Configuration as Code: Look Ma, No Hands」2018年8月27日 Nicolas De Loof 投稿の翻訳記事です。）