DockerとJenkinsの構成をコードとしてJenkinsのセットアップを自動化する方法

提供：Dev Guides
移動先:案内、検索

著者は、ウィキメディア財団を選択して、 Write forDOnationsプログラムの一環として寄付を受け取りました。

序章

Jenkins は、最も人気のあるオープンソース自動化サーバーの1つであり、継続的インテグレーション（CI）や継続的展開（CD）ワークフローの調整によく使用されます。

Jenkinsの構成は通常、Webベースのセットアップウィザードを使用して手動で行われます。 これは、時間がかかり、エラーが発生しやすく、スケーラブルでないプロセスになる可能性があります。 ステップ4— Ubuntu18.04にJenkinsをインストールする方法ガイドのJenkinsをセットアップすることで関連するステップを確認できます。 さらに、構成は Git のようなバージョン管理システム（VCS）で追跡することも、コードレビュープロセスの監視下に置くこともできません。

このチュートリアルでは、DockerとJenkinsConfiguration as Code （JCasC）メソッドを使用して、Jenkinsのインストールと構成を自動化します。

Jenkinsは、プラグ可能なアーキテクチャを使用して、その機能のほとんどを提供します。 JCasCはConfigurationas Code プラグインを利用します。これにより、Jenkins構成の目的の状態を1つ以上の YAML ファイルとして定義できるため、セットアップが不要になります。ウィザード。 初期化時に、Configuration as Codeプラグインは、構成ファイルに従ってJenkinsを構成し、構成時間を大幅に短縮し、人的エラーを排除します。

Docker は、 container を作成および実行するための事実上の標準です。これは、仮想化テクノロジーであり、さまざまな[ X224X]オペレーティングシステム（OS）およびハードウェアアーキテクチャ。 Dockerを使用してJenkinsインスタンスを実行し、この一貫性とクロスプラットフォーム機能を利用します。

このチュートリアルは、JCasCの設定をガイドすることから始まります。 次に、JCasC構成ファイルに段階的に追加して、ユーザー、構成の認証と承認を設定し、最後にJenkinsインスタンスを保護します。 このチュートリアルを完了すると、起動時にConfiguration as Codeプラグインを使用して、Jenkinsインスタンスを自動的に構成および保護するように設定されたカスタムDockerイメージが作成されます。

前提条件

このチュートリアルを完了するには、次のものが必要です。

  • 2GB以上のRAMとDockerがインストールされているサーバーへのアクセス。 これは、ローカル開発マシン、Droplet、または任意の種類のサーバーにすることができます。 ステップ1— Dockerコレクションのインストールと使用方法のチュートリアルの1つからDockerをインストールしてDockerをセットアップします。

注：このチュートリアルはUbuntu18.04でテストされています。 ただし、Dockerイメージは自己完結型であるため、ここで概説する手順は、DockerがインストールされているすべてのOSで機能します。


手順1—セットアップウィザードを無効にする

JCasCを使用すると、セットアップウィザードを表示する必要がなくなります。 したがって、この最初のステップでは、セットアップウィザードが無効になっている公式の jenkins /jenkinsイメージの修正バージョンを作成します。 これを行うには、Dockerfileを作成し、そこからカスタムJenkinsイメージを作成します。

jenkins/jenkinsイメージでは、JAVA_OPTS環境変数を介してjenkins.install.runSetupWizardという名前のシステムプロパティを渡すことにより、セットアップウィザードを有効または無効にできます。 イメージのユーザーは、実行時に-envフラグを使用してJAVA_OPTS環境変数をdocker runに渡すことができます。 ただし、このアプローチでは、イメージのユーザーにセットアップウィザードを無効にする責任があります。 代わりに、ビルド時にセットアップウィザードを無効にして、セットアップウィザードがデフォルトで無効になるようにする必要があります。

これを実現するには、Dockerfileを作成し、ENV命令を使用してJAVA_OPTS環境変数を設定します。

まず、サーバー内に新しいディレクトリを作成して、このチュートリアルで作成するファイルを保存します。 

mkdir -p $HOME/playground/jcasc

次に、そのディレクトリ内を移動します。 

cd $HOME/playground/jcasc

次に、エディターを使用して、Dockerfileという名前の新しいファイルを作成します。 

nano $HOME/playground/jcasc/Dockerfile

次に、次のコンテンツをDockerfileにコピーします。

〜/ playground / jcasc / 

FROM jenkins/jenkins:latest
ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false

ここでは、 FROM 命令を使用してjenkins/jenkins:latestをベースイメージとして指定し、ENV命令を使用して[を設定しています。 X143X]環境変数。

ファイルを保存し、CTRL+Xを押してからYを押してエディターを終了します。

これらの変更を行ったら、新しいカスタムDockerイメージを作成し、それに一意のタグを割り当てます（ここではjcascを使用します）。 

docker build -t jenkins:jcasc .

次のような出力が表示されます。 

OutputSending build context to Docker daemon  2.048kB
Step 1/2 : FROM jenkins/jenkins:latest
 ---> 1f4b0aaa986e
Step 2/2 : ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
 ---> 7566b15547af
Successfully built 7566b15547af
Successfully tagged jenkins:jcasc

ビルドしたら、 dockerrunを実行してカスタムイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

--name jenkinsオプションを使用して、コンテナーに覚えやすい名前を付けました。 それ以外の場合は、代わりにランダムな16進IDが使用されます（例： f1d701324553）。 また、--rmフラグを指定して、コンテナープロセスを停止した後にコンテナーが自動的に削除されるようにしました。 最後に、-pフラグを使用して、サーバーホストのポート8080をコンテナーのポート8080にプロキシするように構成しました。 8080は、JenkinsWebUIが提供されるデフォルトのポートです。

ジェンキンスは開始するのに短い期間かかります。 Jenkinsの準備が整うと、出力に次の行が表示されます。 

Output... hudson.WebAppMain$3#run: Jenkins is fully up and running

次に、ブラウザを開いてserver_ip:8080にします。 セットアップウィザードなしでダッシュボードがすぐに表示されます。

セットアップウィザードが無効になっていることを確認しました。 クリーンアップするには、CTRL+Cを押してコンテナを停止します。 以前に--rmフラグを指定した場合、停止したコンテナーは自動的に削除されます。

このステップでは、セットアップウィザードが無効になっているカスタムJenkinsイメージを作成しました。 ただし、Webインターフェイスの右上に、セットアップに問題があることを示す赤い通知アイコンが表示されるようになりました。 アイコンをクリックすると詳細が表示されます。

最初の警告は、JenkinsURLを構成していないことを通知します。 2つ目は、認証と承認のスキームを構成しておらず、匿名ユーザーがJenkinsインスタンスですべてのアクションを実行するための完全な権限を持っていることを示しています。 以前は、セットアップウィザードがこれらの問題に対処するためのガイドを提供していました。 無効にしたので、JCasCを使用して同じ関数を複製する必要があります。 このチュートリアルの残りの部分では、問題がなくなるまで（つまり、赤い通知アイコンが消えるまで）、DockerfileとJCasCの構成を変更します。

次のステップでは、ConfigurationasCodeプラグインを含む選択したJenkinsプラグインをカスタムJenkinsイメージにプレインストールすることでそのプロセスを開始します。

ステップ2—Jenkinsプラグインをインストールする

JCasCを使用するには、ConfigurationasCodeプラグインをインストールする必要があります。 現在、プラグインはインストールされていません。 これは、http://server_ip:8080/pluginManager/installedに移動して確認できます。

このステップでは、Dockerfileを変更して、ConfigurationasCodeプラグインを含む選択したプラグインをプレインストールします。

プラグインのインストールプロセスを自動化するために、jenkins/jenkinsDockerイメージに付属のインストールスクリプトを利用できます。 コンテナ内の/usr/local/bin/install-plugins.shにあります。 これを使用するには、次のことを行う必要があります。

  • インストールするプラグインのリストを含むテキストファイルを作成します
  • Dockerイメージにコピーします
  • install-plugins.shスクリプトを実行して、プラグインをインストールします

まず、エディタを使用して、plugins.txtという名前の新しいファイルを作成します。 

nano $HOME/playground/jcasc/plugins.txt

次に、プラグインの名前とバージョンの次の改行区切りリストを追加します（<id>:<version>の形式を使用）。

〜/ playground / jcasc / plugins.txt 

ant:latest
antisamy-markup-formatter:latest
build-timeout:latest
cloudbees-folder:latest
configuration-as-code:latest
credentials-binding:latest
email-ext:latest
git:latest
github-branch-source:latest
gradle:latest
ldap:latest
mailer:latest
matrix-auth:latest
pam-auth:latest
pipeline-github-lib:latest
pipeline-stage-view:latest
ssh-slaves:latest
timestamper:latest
workflow-aggregator:latest
ws-cleanup:latest

ファイルを保存して、エディターを終了します。

このリストには、Configuration as Codeプラグインと、セットアップウィザードによって提案されたすべてのプラグインが含まれています（Jenkins v2.251以降で正しい）。 たとえば、 Git プラグインがあります。これにより、JenkinsはGitリポジトリを操作できます。 Pipeline プラグインもあります。これは、実際にはJenkinsジョブをコードとして定義できるプラグインのスイートです。

注：提案されたプラグインの最新リストは、ソースコードから推測できます。 plugins.jenkins.io で、コミュニティが提供する最も人気のあるプラグインのリストを見つけることもできます。 必要な他のプラグインをリストに自由に含めてください。


次に、Dockerfileファイルを開きます。 

nano $HOME/playground/jcasc/Dockerfile

その中に、COPY命令を追加して、plugins.txtファイルをイメージ内の/usr/share/jenkins/ref/ディレクトリにコピーします。 これは、Jenkinsが通常プラグインを探す場所です。 次に、install-plugins.shスクリプトを実行するための追加のRUN命令を含めます。

〜/ playground / jcasc / Dockerfile 

FROM jenkins/jenkins
ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt

ファイルを保存して、エディターを終了します。 次に、改訂されたDockerfileを使用して新しいイメージを作成します。 

docker build -t jenkins:jcasc .

この手順では、多くのプラグインをダウンロードしてイメージにインストールします。インターネット接続によっては、実行に時間がかかる場合があります。 プラグインのインストールが完了したら、新しいJenkinsイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

Jenkins is fully up and runningメッセージがstdoutに表示されたら、server_ip:8080/pluginManager/installedに移動して、インストールされているプラグインのリストを表示します。 plugins.txt内で指定したすべてのプラグインの横にあるチェックボックスと、それらのプラグインの依存関係であるプラグインの横にある色あせたチェックボックスが表示されます。

Configuration As Code プラグインがインストールされていることを確認したら、CTRL+Cを押してコンテナープロセスを終了します。

このステップでは、提案されたすべてのJenkinsプラグインとConfigurationasCodeプラグインをインストールしました。 これで、JCasCを使用して、通知ボックスにリストされている問題に取り組む準備が整いました。 次のステップでは、JenkinsルートURLが空であることを警告する最初の問題を修正します。

ステップ3—JenkinsURLを指定する

Jenkins URLは、Jenkinsインスタンスにアクセスする必要のあるデバイスからルーティング可能なJenkinsインスタンスのURLです。 たとえば、Jenkinsをプライベートネットワーク内のノードとしてデプロイしている場合、JenkinsのURLはプライベートIPアドレス、またはプライベートDNSサーバーを使用して解決可能なDNS名である可能性があります。 このチュートリアルでは、サーバーのIPアドレス（またはローカルホストの場合は127.0.0.1）を使用してJenkinsURLを形成するだけで十分です。

server_ip:8080/configureに移動し、 JenkinsLocation見出しの下のJenkinsURL フィールドに値を入力することで、WebインターフェイスでJenkinsURLを設定できます。 ConfigurationasCodeプラグインを使用して同じことを実現する方法は次のとおりです。

  1. 宣言型構成ファイル（casc.yamlと呼びます）内でJenkinsインスタンスの目的の構成を定義します。
  2. 構成ファイルをDockerイメージにコピーします（plugins.txtファイルの場合と同じように）。
  3. CASC_JENKINS_CONFIG環境変数を構成ファイルのパスに設定して、ConfigurationasCodeプラグインにそれを読み取るように指示します。

まず、casc.yamlという名前の新しいファイルを作成します。 

nano $HOME/playground/jcasc/casc.yaml

次に、次の行を追加します。

〜/ playground / jcasc / casc.yaml 

unclassified:
  location:
    url: http://server_ip:8080/

unclassified.location.urlは、JenkinsURLを設定するためのパスです。 これは、JCasCで設定できる無数のプロパティの1つにすぎません。 有効なプロパティは、インストールされているプラグインによって決まります。 たとえば、jenkins.authorizationStrategy.globalMatrix.permissionsプロパティは、 Matrix AuthorizationStrategyプラグインがインストールされている場合にのみ有効です。 使用可能なプロパティを確認するには、server_ip:8080/configuration-as-code/referenceに移動すると、特定のJenkinsインストールに合わせてカスタマイズされたドキュメントのページが見つかります。

casc.yamlファイルを保存し、エディターを終了して、Dockerfileファイルを開きます。 

nano $HOME/playground/jcasc/Dockerfile

Dockerfileの最後にCOPY命令を追加して、casc.yamlファイルを/var/jenkins_home/casc.yamlのイメージにコピーします。 /var/jenkins_home/を選択したのは、これがJenkinsがすべてのデータを保存するデフォルトのディレクトリだからです。

〜/ playground / jcasc / Dockerfile 

FROM jenkins/jenkins:latest
ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt
COPY casc.yaml /var/jenkins_home/casc.yaml

次に、CASC_JENKINS_CONFIG環境変数を設定するENV命令をさらに追加します。

〜/ playground / jcasc / Dockerfile 

FROM jenkins/jenkins:latest
ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
ENV CASC_JENKINS_CONFIG /var/jenkins_home/casc.yaml
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt
COPY casc.yaml /var/jenkins_home/casc.yaml

注： ENV命令は、変更される可能性が低いため、上部に配置しました。 COPYおよびRUN命令の前に配置することで、casc.yamlまたはplugins.txtを更新する場合に、キャッシュされたレイヤーの無効化を回避できます。


ファイルを保存して、エディターを終了します。 次に、イメージを作成します。 

docker build -t jenkins:jcasc .

そして、更新されたJenkinsイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 jenkins:jcasc

Jenkins is fully up and runningログ行が表示されたら、server_ip:8080に移動してダッシュボードを表示します。 今回は、通知数が1つ減り、JenkinsURLに関する警告が消えたことにお気づきかもしれません。

次に、server_ip:8080/configureに移動し、 JenkinsURLフィールドまでスクロールダウンします。 JenkinsのURLがcasc.yamlファイルで指定されているのと同じ値に設定されていることを確認します。

最後に、CTRL+Cを押してコンテナプロセスを停止します。

このステップでは、ConfigurationasCodeプラグインを使用してJenkinsURLを設定しました。 次のステップでは、通知リストの2番目の問題に取り組みます（ Jenkinsは現在セキュリティで保護されていないメッセージです）。

ステップ4—ユーザーの作成

これまでのところ、セットアップには認証および承認メカニズムは実装されていません。 このステップでは、基本的なパスワードベースの認証スキームを設定し、adminという名前の新しいユーザーを作成します。

casc.yamlファイルを開くことから始めます。 

nano $HOME/playground/jcasc/casc.yaml

次に、強調表示されたスニペットを追加します。

〜/ playground / jcasc / casc.yaml 

jenkins:
  securityRealm:
    local:
      allowsSignup: false
      users:
       - id: ${JENKINS_ADMIN_ID}
         password: ${JENKINS_ADMIN_PASSWORD}
unclassified:
  ...

Jenkinsのコンテキストでは、セキュリティレルムは単なる認証メカニズムです。 ローカルセキュリティレルムは、ユーザーがID/ユーザー名とパスワードを指定する必要がある基本認証を使用することを意味します。 他のセキュリティレルムが存在し、プラグインによって提供されます。 たとえば、 LDAP プラグインを使用すると、既存のLDAPディレクトリサービスを認証メカニズムとして使用できます。 GitHub認証プラグインを使用すると、GitHubクレデンシャルを使用してOAuth経由で認証できます。

allowsSignup: falseも指定していることに注意してください。これにより、匿名ユーザーがWebインターフェイスを介してアカウントを作成できなくなります。

最後に、ユーザーIDとパスワードをハードコーディングする代わりに、実行時に値を入力できる変数を使用しています。 JCasCを使用する利点の1つは、casc.yamlファイルをソース管理にコミットできることであるため、これは重要です。 ユーザーのパスワードを構成ファイル内にプレーンテキストで保存すると、資格情報が事実上侵害されてしまいます。 代わりに、変数は${VARIABLE_NAME}構文を使用して定義され、その値は、同じ名前の環境変数、または/run/secrets/ディレクトリ内に配置された同じ名前のファイルを使用して入力できます。コンテナイメージ。

次に、casc.yamlファイルに加えられた変更を組み込むために、新しいイメージを作成します。 

docker build -t jenkins:jcasc .

次に、-env オプションを介してJENKINS_ADMIN_IDおよびJENKINS_ADMIN_PASSWORD環境変数を渡しながら、更新されたJenkinsイメージを実行します（<password>をパスワードに置き換えますあなたの選択）： 

docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

これで、server_ip:8080/loginに移動し、指定した資格情報を使用してログインできます。

正常にログインすると、ダッシュボードにリダイレクトされます。

CTRL+Cを押してコンテナを停止し、この手順を終了します。

このステップでは、JCasCを使用して、adminという名前の新しいユーザーを作成しました。 また、VCSによって追跡されるファイルからパスワードなどの機密データを排除する方法も学びました。 ただし、これまでのところ、ユーザー認証のみを構成しました。 承認メカニズムを実装していません。 次のステップでは、JCasCを使用して、adminユーザーに管理者権限を付与します。

ステップ5—認証の設定

セキュリティレルムを設定した後、承認戦略を構成する必要があります。 このステップでは、 Matrix Authorization Strategy プラグインを使用して、adminユーザーの権限を構成します。

デフォルトでは、Jenkinsコアインストールは3つの認証戦略を提供します。

  • unsecured：匿名ユーザーを含むすべてのユーザーは、すべてを実行するための完全な権限を持っています
  • legacy：レガシーJenkins（v1.164より前）をエミュレートします。この場合、adminの役割を持つすべてのユーザーに完全なアクセス許可が与えられ、匿名ユーザーを含む他のユーザーには読み取りアクセス権が与えられます。

注：Jenkinsのrole は、ユーザー（たとえば、daniel）またはグループ（たとえば、developers）にすることができます。


  • loggedInUsersCanDoAnything：匿名ユーザーにはアクセス権がないか読み取り専用アクセス権が与えられます。 認証されたユーザーには、すべてを実行するための完全な権限があります。 認証されたユーザーに対してのみアクションを許可することにより、どのユーザーがどのアクションを実行したかを監査することができます。

注： ドキュメントで、他の承認戦略とそれに関連するプラグインを調べることができます。 これらには、認証と承認の両方を処理するプラグインが含まれます。


これらの承認戦略はすべて非常に大雑把であり、さまざまなユーザーに権限を設定する方法をきめ細かく制御することはできません。 代わりに、plugins.txtリストにすでに含まれているMatrixAuthorizationStrategyプラグインを使用できます。 このプラグインは、よりきめ細かい認証戦略を提供し、プロジェクト/ジョブごとだけでなく、グローバルにユーザー権限を設定できるようにします。

Matrix Authorization Strategyプラグインを使用すると、jenkins.authorizationStrategy.globalMatrix.permissionsJCasCプロパティを使用してグローバル権限を設定できます。 これを使用するには、casc.yamlファイルを開きます。 

nano $HOME/playground/jcasc/casc.yaml

そして、強調表示されたスニペットを追加します。

〜/ playground / jcasc / casc.yaml 

...
       - id: ${JENKINS_ADMIN_ID}
         password: ${JENKINS_ADMIN_PASSWORD}
  authorizationStrategy:
    globalMatrix:
      permissions:
        - "Overall/Administer:admin"
        - "Overall/Read:authenticated"
unclassified:
...

globalMatrixプロパティは、（プロジェクトごとのアクセス許可ではなく）グローバルアクセス許可を設定します。 permissionsプロパティは、<permission-group>/<permission-name>:<role>の形式の文字列のリストです。 ここでは、adminユーザーにOverall/Administer権限を付与しています。 また、Overall/Read権限をauthenticatedに付与します。これは、認証されたすべてのユーザーを表す特別な役割です。 anonymousと呼ばれる別の特別な役割があり、認証されていないすべてのユーザーをグループ化します。 ただし、アクセス許可はデフォルトで拒否されるため、匿名ユーザーにアクセス許可を付与したくない場合は、そのエントリを明示的に含める必要はありません。

casc.yamlファイルを保存し、エディターを終了して、新しいイメージを作成します。 

docker build -t jenkins:jcasc .

次に、更新されたJenkinsイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

Jenkins is fully up and runningログ行を待ってから、server_ip:8080に移動します。 ログインページにリダイレクトされます。 クレデンシャルを入力すると、メインダッシュボードにリダイレクトされます。

この手順では、adminユーザーのグローバル権限を設定しました。 ただし、承認の問題を解決すると、通知メニューに表示されるようになった追加の問題が明らかになりました。

したがって、次のステップでは、Dockerイメージを変更し続け、問題がなくなるまで各問題を1つずつ解決します。

続行する前に、CTRL+Cを押してコンテナを停止します。

ステップ6—ビルド認証の設定

通知リストの最初の問題は、ビルド認証に関連しています。 デフォルトでは、すべてのジョブは多くのシステム権限を持つシステムユーザーとして実行されます。 したがって、Jenkinsユーザーは、悪意のあるジョブまたはパイプラインを定義して実行するだけで、特権昇格を実行できます。 これは安全ではありません。

代わりに、ジョブを構成またはトリガーしたのと同じJenkinsユーザーを使用してジョブを実行する必要があります。 これを実現するには、 AuthorizeProjectプラグインと呼ばれる追加のプラグインをインストールする必要があります。

plugins.txtを開きます： 

nano $HOME/playground/jcasc/plugins.txt

そして、強調表示された行を追加します。

〜/ playground / jcasc / plugins.txt 

ant:latest
antisamy-markup-formatter:latest
authorize-project:latest
build-timeout:latest
...

プラグインは、JCasC構成で指定する必要がある新しいビルド認証戦略を提供します。 plugins.txtファイルを終了し、casc.yamlファイルを開きます。 

nano $HOME/playground/jcasc/casc.yaml

強調表示されたブロックをcasc.yamlファイルに追加します。

〜/ playground / jcasc / casc.yaml 

...
        - "Overall/Administer:admin"
        - "Overall/Read:authenticated"
security:
  queueItemAuthenticator:
    authenticators:
    - global:
        strategy: triggeringUsersAuthorizationStrategy
unclassified:
...

ファイルを保存して、エディターを終了します。 次に、変更したplugins.txtファイルとcasc.yamlファイルを使用して新しいイメージを作成します。 

docker build -t jenkins:jcasc .

次に、更新されたJenkinsイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

Jenkins is fully up and runningログ行を待ってから、server_ip:8080/loginに移動し、資格情報を入力して、メインダッシュボードに到達します。 通知メニューを開くと、ビルド認証に関連する問題が表示されなくなります。

続行する前に、CTRL+Cを実行してコンテナを停止します。

このステップでは、システムユーザーではなく、ビルドをトリガーしたユーザーを使用してビルドを実行するようにJenkinsを構成しました。 これにより、通知リストの問題の1つが解消されます。 次のステップでは、AgenttoControllerセキュリティサブシステムに関連する次の問題に取り組みます。

ステップ7—エージェントからコントローラへのアクセス制御を有効にする

このチュートリアルでは、すべてのビルドを実行するJenkinsのインスタンスを1つだけデプロイしました。 ただし、Jenkinsは、エージェント/コントローラー構成を使用した分散ビルドをサポートしています。 コントローラは、Web UIの提供、クライアントがリクエストを送信するためのAPIの公開、およびビルドの調整を担当します。 エージェントは、ジョブを実行するインスタンスです。

この構成の利点は、よりスケーラブルでフォールトトレラントであるということです。 Jenkinsを実行しているサーバーの1つがダウンした場合、他のインスタンスが余分な負荷をかける可能性があります。

ただし、コントローラがエージェントを信頼できない場合があります。 たとえば、OPSチームがJenkinsコントローラーを管理し、外部の請負業者が独自にカスタム構成されたJenkinsエージェントを管理する場合があります。 エージェントからコントローラーへのセキュリティサブシステムがない場合、エージェントはコントローラーに、要求するアクションを実行するように指示できますが、これは望ましくない場合があります。 Agent to Controller Access Controlを有効にすることで、エージェントがアクセスできるコマンドとファイルを制御できます。

Agent to Controller Access Controlを有効にするには、casc.yamlファイルを開きます。 

nano $HOME/playground/jcasc/casc.yaml

次に、次の強調表示された行を追加します。

〜/ playground / jcasc / casc.yaml 

...
        - "Overall/Administer:admin"
        - "Overall/Read:authenticated"
  remotingSecurity:
    enabled: true
security:
  queueItemAuthenticator:
...

ファイルを保存して、新しいイメージを作成します。 

docker build -t jenkins:jcasc .

更新されたJenkinsイメージを実行します。 

docker run --name jenkins --rm -p 8080:8080 --env JENKINS_ADMIN_ID=admin --env JENKINS_ADMIN_PASSWORD=password jenkins:jcasc

server_ip:8080/loginに移動し、前と同じように認証します。 メインダッシュボードにアクセスすると、通知メニューにそれ以上の問題は表示されなくなります。

結論

これで、JCasCを使用して単純なJenkinsサーバーを正常に構成できました。 Pipelineプラグインを使用すると、開発者はJenkinsfile内でジョブを定義できますが、Configuration as Codeプラグインを使用すると、管理者はYAMLファイル内でJenkins構成を定義できます。 これらのプラグインはどちらも、Jenkinsを Everything as Code （EaC）パラダイムに近づけます。

ただし、JCasC構文を正しく取得することは困難な場合があり、ドキュメントを解読するのは困難な場合があります。 行き詰まっていて助けが必要な場合は、プラグインのGitterチャットで見つけることができます。

JCasCを使用してJenkinsの基本設定を構成しましたが、新しいインスタンスにはプロジェクトやジョブが含まれていません。 これをさらに進めるには、 Job DSL プラグインを調べてください。これにより、プロジェクトとジョブをコードとして定義できます。 さらに、JCasC構成ファイル内にジョブDSLコードを含め、構成プロセスの一部としてプロジェクトとジョブを作成することができます。

「https://www.finddevguides.com/index.php?title=DockerとJenkinsの構成をコードとしてJenkinsのセットアップを自動化する方法&oldid=106165」から取得
Powered by MediaWiki