これはなに
JenkinsをKubernetes上で動かして、CDパイプライン内でSkaffoldを使う手順を記します。
パイプラインの一連の処理は、Kubernetes上にコンテナとして展開されるJenkinsエージェントで実行します。Skaffoldはこのエージェントから、パイプラインの1ステップとして実行されます。
また、Skaffoldにより、コンテナのビルド、プッシュ、デプロイが行われますが、この時のデプロイ先として、Jenkins自身が動いているものと同じKubernetsクラスターを使います。
(Skaffoldって何?という方はこちらを参照ください)
動作確認済みの環境
- Ubuntu 16.04 LTS
- Kuberentes クラスター
- minikube v0.25.2
- Kubernetes v1.9.4
- kubectl v1.10
- helm v2.8.2
- JenkinsのHelm Chart
- このコミット時点のチャートを利用(Helm Chartはタグやリリースで管理されていないため)
手順
それではやって見ます。全体の流れは、以下のような感じです。
-
JenkinsをKubernetesにデプロイする
-
ビルドパイプラインを作成する
-
JenkinsをKubernetes上にデプロイする
まずはKubernetes上でJenkinsを動かします。ラクをしたいので、公式のHelm Chartを利用します。
1.1 Helm Chartのパラメータの修正
基本はHelmを使ってJenkinsをデプロイしますが、あらかじめいくつか設定を変更しておきます。
まず、values.yaml(Helm Chartに与える設定情報を記述したファイル)をダウンロードします。
wget https://raw.githubusercontent.com/kubernetes/charts/78ee4ba1546c0428756af2684d3c0eac82a3c04d/stable/jenkins/values.yaml
以降、values.yaml内のパラメータを変更していきます。
クラスター外からのアクセス方法の変更
ローカルのクラスターを使うので、クラスター外からのアクセスの方法としてServiceのNodePortタイプを使うように変更します。
ServicePort: 8080
# For minikube, set this to NodePort, elsewhere use LoadBalancer
# Use ClusterIP if your setup includes ingress controller
- ServiceType: LoadBalancer
+ ServiceType: NodePort
# Master Service annotations
ServiceAnnotations: {}
# service.beta.kubernetes.io/aws-load-balancer-backend-protocol: https
Jenkinsにインストールしておくプラグインの変更
既にいくつかのプラグインが書かれていますが、バージョンを更新したり、追加のプラグインを加える必要があります。
# JMXPort: 4000
# List of plugins to be install during Jenkins master start
InstallPlugins:
- - kubernetes:1.1
+ - kubernetes:1.5.2
- workflow-aggregator:2.5
- - workflow-job:2.15
- - credentials-binding:1.13
- - git:3.6.4
+ - workflow-job:2.21
+ - credentials-binding:1.16
+ - git:3.8.0
+ - ghprb:1.40.0
+ - blueocean:1.4.2
# Used to approve a list of groovy functions in pipelines used the script-security plugin. Can be viewed under /scriptApproval
# ScriptApproval:
# - "method groovy.json.JsonSlurperClassic parseText java.lang.String"
永続化オプションの変更
ローカルのクラスターで簡単に動かすために、VolumeとしてEmplyDirを使うようにします。データ永続化は保証されない、本番では絶対利用できない方法なので、ご注意ください。
# jenkins-agent: v1
Persistence:
- Enabled: true
+ Enabled: false
## A manually managed Persistent Volume and Claim
## Requires Persistence.Enabled: true
## If defined, PVC must be created manually before volume will be bound
1.2 HelmでJenkinsをデプロイする
対象のクラスターでHelmを使ったことがなければ、helm init
しておきます。
helm init
以下のコマンドで、修正済みのvalues.yamlを適用してJenkinsをデプロイします。併せて、jenkinsというNamespaceを作って、そこにデプロイしています。
helm install -f values.yaml --name jenkins --namespace=jenkins stable/jenkins
kubectlのデフォルトのNamespaceをjenkinsに変更しておきます。
kubectl config set-context $(kubectl config current-context) --namespace=jenkins
Jenkinsが起動するまで少し時間が必要です。数分待ってから、Deployment、Service、Podの状態を確認してください。
kubectl get deployment,pod,service
Jenkinsの起動処理まで進めば、以下のような結果が返ってきます。
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
jenkins 1 1 1 1 7h
NAME READY STATUS RESTARTS AGE
jenkins-5c89487645-s6mxv 1/1 Running 1 7h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
jenkins NodePort 10.96.215.81 <none> 8080:31590/TCP 7h
jenkins-agent ClusterIP 10.110.217.211 <none> 50000/TCP 7h
Jenkinsのサーバーが立ち上がるまでには更に時間が必要です。上の状態になってからも、数分程度時間を置いてください。
1.3 JenkinsのGUIにアクセスする
管理者ユーザーのパスワードは、デプロイ時に自動生成された値がKubernetesのSecretオブジェクトに格納されています。以下のコマンドでそれを確認することができます。
printf $(kubectl get secret --namespace jenkins jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo
JenkinsサーバーのIPアドレス、ポート番号は以下のコマンドで確認することができます。
printf $(kubectl get pod -o 'jsonpath={.items[0].status.hostIP}'):$(kubectl get service jenkins -o 'jsonpath={.spec.ports[0].nodePort}');echo
Webブラウザで、__http://[上で確認したIP]:[上で確認したポート番号]/__にアクセスすると、Jnekinsのログイン画面が表示されます。ユーザー名、パスワードには、以下の値を入力します。
- ユーザー名: admin
- パスワード: (上記コマンドで確認した文字列)
ログインに成功するとJenkinsのトップ画面が表示されます。
以上で、JenkinsをKubernetes上にデプロイする作業は完了です。
- ビルドパイプラインを作成する
ここからは、あらかじめ作成しておいたサンプルアプリケーションとJenkinsfile(パイプラインの定義ファイル)を利用して、ビルドパイプラインを作成していきます。ここで利用するJenkinsfileでは、パイプライン中の1ステップの中でSkaffoldを実行します。Skaffoldによって、コンテナのビルド、プッシュ、デプロイを自動実行します。
2.1 サンプルアプリケーションの準備
まずは、Github上にサンプルアプリケーションのコードとJenkinsfileを準備していきます。
サンプルアプリケーションをForkする
サンプルアプリケーションのコード(Jenkinsfileを含む)は、GitHubリポジトリに置いてあります。これをご自身のアカウントにForkしておいてください。
このアプリケーションは、cowsayというジョークアプリをWeb API化したものです。このアプリを起動して所定のURLにアクセスすると、cowsayと同様のアスキーアートが返ってきます。
パイプライン内でgit clone
するリポジトリを修正する
Forkしてできたリポジトリに含まれるJenkinsfileは、Fork元のリポジトリをgit clone
するように記述されています。これを、Fork後のリポジトリをcloneするように修正します。
Fork後のリポジトリをブラウザで表示し、Jenkinsfileの該当箇所(画像参照)を修正してください。
接続先のコンテナレジストリを変更する
Skaffoldが呼び出されると、その内部処理でdocker build
やdocker push
が実行され、コンテナのビルド、プッシュを行います。このときのコンテナイメージのプッシュ先を、ご自身がプッシュ可能なコンテナレジストリに修正しておきます。
Fork後のリポジトリをブラウザで表示し、skaffold.yamlの該当箇所(画像参照)を修正してください。
2.2. ビルドパイプラインを作成する
次に、JenkinsのUIからビルドパイプラインを作成します。
コンテナレジストリの認証情報をJenkinsに登録する
Skaffoldの内部処理で実行されるdocker push
において、コンテナレジストリへのアクセスのための認証情報が必要となります。ここで、あらかじめJnekinsに認証情報を設定しておきます。
Jenkinsのトップ画面から、認証情報 > (global) > 認証情報を追加 の順にクリックします。
以下のように、イメージのプッシュ先のコンテナレジストリの認証情報を入力します。認証情報のID(Jenkins上で管理するための識別名となる値)は、docker_idとしてください。
- 種類: ユーザー名とパスワード
- ユーザー名:(コンテナレジストリのアカウント名)
- パスワード:(コンテナレジストリのパスワード)
- ID: docker_id
2.2 パイプラインを作る
ビルドパイプラインはJenkinsのBlue Cceanプラグインで作成します。Jenkinsのトップ画面から__Open Blue Ocan__をクリックします。
Blue Oceanの画面で、__Create a new Pipeline__をクリックします。
Pipelineの作成画面に遷移します。以降この画面の流れに従ってPipelineを作成していきます。
まずは、ソースコードをホストしているサービスを選択します。この手順ではGitHubを利用しているので__GitHub__をクリックします。
次に、JenkinsからGitHubのAPIを呼び出すためのアクセストークンを設定します。__Create an access key here.__をクリックすると、GitHubの画面が新たなタブで開きます。
GitHubのパスワード入力が求められたら、自身のアカウントのパスワードを入力します。
新たなアクセストークンを発行する画面に遷移したら、__Token description__にトークンの用途の説明を入力します。ここではjenkinsと入力しておきます。
他の設定はデフォルトのままにして、画面下の__Generate token__をクリックします。
作成されたアクセストークンが表示されたら、トークンの文字列の右横にあるアイコンをクリックして、クリップボードにトークンをコピーします。
JenkinsのPipeline作成画面に戻って、コピーしたトークンを入力欄にペーストし、__Connect__をクリックします。
GitHubで複数のorganizationに対するアクセス権を持っている場合、Fork後のリポジトリがあるorganizationをここで指定する必要があります。
最後に、Choose a repositoryでサンプルアプリケーションをForkしたリポジトリを選択します(デフォルトのままであれば、リポジトリの名称はcowwebとなっています)。
ここまでの手順を完了すると、Jenkinsfileが自動的に読み込まれ、それを基にJenkinsにパイプラインが作成されます。さらに自動的にパイプラインが起動され、以下のような画面となります。
上の画像でハイライトした部分をクリックすると、パイプラインの実行状況の詳細を表示する画面に遷移します。
画面下方にあるテーブルの行をクリックすると、パイプラインの実行中のコンソール出力が表示されます。__Task skaffold__の__Shell Script__をクリックして展開すると、skaffold run
コマンドが実行され、その後続の処理でコンテナのビルド、プッシュ等がおこなわれていることが確認できます。
パイプラインが無事に終了すると、以下のような画面となります。
2.3 デプロイされたアプリケーションの動作確認をおこなう
すでにSkaffoldによって、ビルドされたアプリケーションがKubernetesにデプロイされています。以下のコマンドでPod、Serviceが作成されていることを確認してください。
kubectl get -n cowweb pod,service
以下のようにアプリケーション本体のPodと、NodePortタイプのServiceが作成されているはずです。
NAME READY STATUS RESTARTS AGE
cowweb 1/1 Running 0 1m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cowweb NodePort 10.100.135.47 <none> 8080:32370/TCP 1m
アプリケーションにアクセスするには、以下のコマンドを実行してアプリケーションにアクセスするためのIPアドレス、ポート番号を取得します。
export COWWEB_HOST=$(kubectl get pod -n cowweb -o 'jsonpath={.items[0].status.hostIP}'):$(kubectl get service cowweb -n cowweb -o 'jsonpath={.spec.ports[0].nodePort}')
続いて、アプリケーションにリクエストを投げてみます。
curl "http://$COWWEB_HOST/cowsay/say/?message=Hello_Jenkins"
正しく動作していれば、以下のようなcowsayアプリケーションのアスキーアートが返却されます(呼び出しの度にランダムに異なるアスキーアートが表示されます)。
_______________
< Hello_Jenkins >
---------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
以上で、JenkinsのパイプラインからSkaffoldを実行し、コンテナのビルド、プッシュ、デプロイをすることができました。またデプロイ先として、Jenkins自身が動いているものと同じKubernetsクラスターを使い、実際にアプリケーションの動作を確認しました。
- 補足: Jenkinsfileの内容の解説
ここでは、このエントリで利用したサンプルアプリケーションのJenkinsfile(パイプラインの定義ファイル)の内容について、簡単に解説します。
Jenkinsfileの全体は以下のようになっています。
podTemplate(
label: 'skaffold',
containers: [
containerTemplate(name: 'skaffold-insider', image: 'hhayakaw/skaffold-insider:v1.0.0', ttyEnabled: true, command: 'cat')
],
volumes: [
hostPathVolume(hostPath: '/var/run/docker.sock', mountPath: '/var/run/docker.sock')
]
) {
node('skaffold') {
withCredentials([
usernamePassword(credentialsId: 'docker_id', usernameVariable: 'DOCKER_ID_USR', passwordVariable: 'DOCKER_ID_PSW')
]) {
stage('Info') {
container('skaffold-insider') {
sh """
uname -a
whoami
pwd
ls -al
"""
}
}
stage('Test skaffold') {
git 'https://github.com/hhiroshell/cowweb.git'
container('skaffold-insider') {
sh """
docker login --username=$DOCKER_ID_USR --password=$DOCKER_ID_PSW
skaffold run -p release
"""
}
}
}
}
}
冒頭のpodTemplate配下には、パイプラインの処理を実行する際に利用する、Podの定義を記述します。
podTemplate(
label: 'skaffold',
containers: [
containerTemplate(name: 'skaffold-insider', image: 'hhayakaw/skaffold-insider:v1.0.0', ttyEnabled: true, command: 'cat')
],
volumes: [
hostPathVolume(hostPath: '/var/run/docker.sock', mountPath: '/var/run/docker.sock')
]
) {
containersには、Podに含めるコンテナを記述します。このパイプラインでは、hhayakaw/skaffold-insider:v1.0.0という、Skaffoldがインストールされたコンテナを利用しています。このコンテナは、あらかじめ作成してDocker Hubにプッシュしてあります。
volumesには、コンテナにマウントするボリュームを記述します。Skaffoldは、内部でDockerコマンドを利用するため、Dockerコンテナ内でDockerコマンドを実行する、Docker in Docker(DinD)構成となります。このため、/var/run/docker.sockをマウントしています(DinDの詳細についてはWeb上に色々な記事がありますので、それらを参照下さい。このエントリの最後にリンクをまとめて記します)。
node配下には、パイプラインのステップの処理内容を定義します。
node('skaffold') {
withCredentials([
usernamePassword(credentialsId: 'docker_id', usernameVariable: 'DOCKER_ID_USR', passwordVariable: 'DOCKER_ID_PSW')
]) {
node配下のwithCredentialsには、ステップ内で利用するクレデンシャル情報を記述します。上記の記述により、JenkinsのGUIで設定した、docker_idという名前の認証情報が利用可能になります。また、後続のステップの定義おいて、環境変数DOCKER_ID_USRによってユーザー名が、DOCKER_ID_PSWによってパスワードが参照できます。
さらに後続のstageの記述により、パイプラインのステップで実行される実際の処理を定義します。
stage('Info') {
container('skaffold-insider') {
sh """
uname -a
whoami
pwd
ls -al
"""
}
}
stage('Test skaffold') {
git 'https://github.com/hhiroshell/cowweb.git'
container('skaffold-insider') {
sh """
docker login --username=$DOCKER_ID_USR --password=$DOCKER_ID_PSW
skaffold run -p release
"""
}
}
この記述では、Info、Test skaffoldという名前の2つのstage(ステップ)を定義しています。また、どちらもskaffold-insiderコンテナを使って処理を実行しています。
ステップInfoでは、uname
等のコマンドを実行して、コンテナの基本的な情報をコンソールに出力しています(具体的なビルドの処理は行っていません)。
ステップTest skaffoldでは、アプリケーションのコードのチェックアウト、プッシュ先のDockerレジストリへのログインの後、Skaffoldを実行しています。-p
オプションでは、Skaffoldのプロファイル名を指定しています。プロファイルは、ビルド、プッシュ、デプロイの設定のセットで、今回はJenkins内で実行するための設定情報を、releaseという名前で記述してあります。
- 参考リンク一覧
- Skaffold関連
- Docker in Docker関連
- Jenkins on Kubernetesでパイプラインを使う他の例