ラベル Jenkins の投稿を表示しています。すべての投稿を表示

2021年3月12日金曜日

k8s 上に Jenkins Server をデプロイして使ってみた

概要
環境
pv の作成
Jenkins のデプロイ
Pods の確認
upgrade する
動作確認
Tips: カスタマイズできる項目の取得 values
参考サイト

概要

kubeadm で構築した k8s 上に Jenkins をデプロイしてみました
helm を使ってデプロイしています

環境

Ubuntu 18.04
k8s v1.20.4
helm 3.5.2

pv の作成

Jenkins 用の PersistentVolume を作成しておきます
pvc に自動で結びつくように claimRef をしっかり定義しておきます

vim jenkins_pv.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  claimRef:
    namespace: default
    name: jenkins
  storageClassName: local-storage
  local:
    path: /mnt/jenkins
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node1

kubectl apply -f jenkins_pv.yml

Jenkins のデプロイ

helm repo add jenkins https://charts.jenkins.io
helm repo update
helm install jenkins jenkins/jenkins

とりあえずそのままデプロイしています
リポジトリを追加して install するだけです

Pods の確認

Pod が立ち上がっていれば成功です

kubectl get pod jenkins-0

NAME        READY   STATUS    RESTARTS   AGE
jenkins-0   2/2     Running   0          6m59s

Loadbalancer として使える Ingress がある場合はそのまま Ingress リソースを追加するだけで良いのですが NodePort を使ってノードの IP を使う場合はこのままだとアクセスできません
なので chart のパラメータを少しいじっして NodePort からアクセスできるようにしてみます

upgrade する

helm upgrade --set controller.serviceType=NodePort jenkins jenkins/jenkins

install 時でも良いのですが --set controller.serviceType=NodePort を付与することでノード側の IP でバインドしてくれます
service を確認してみます

kubectl get svc jenkins

NAME      TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
jenkins   NodePort   10.109.115.80   <none>        8080:31441/TCP   30m

動作確認

http://192.168.100.10:31441/ にアクセスすると Jenkins のログイン画面になります
admin ユーザのトークンは secret に格納されています

kubectl exec --namespace default -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo

ジョブを作成して実行してみると jenkins-agent がジョブ実行用の Pods を作成してそこでビルドが実行されているのが確認できると思います

Tips: カスタマイズできる項目の取得 values

helm show values jenkins/jenkins

これで values.yml が取得できます
chart 自体の構成を見たい場合は

helm show chart jenkins/jenkins

で取得できます

参考サイト

https://github.com/jenkinsci/helm-charts/tree/main/charts/jenkins

2020年3月12日木曜日

Jenkins のパラメータ付きビルドを Ruby の net/http を使ってコールしてみた

概要
環境
テキストのパラメータを付与してビルドする
ファイル付きのパラメータを付与してビルドする
最後に

概要

過去にライブラリを使って Jenkins のジョブを操作しました
今回は net/http だけを使ってジョブを操作してみました

環境

Ruby 2.5.5p157

テキストのパラメータを付与してビルドする

Jenkins のジョブは p1 というテキストのパラメータを受け取る想定です
post_form を使うと簡単です

require 'net/http'
require 'uri'
require 'json'

data_p1 = 0...1
data_p1.each { |d|
  build_parameter = {
    "parameter" => [
      {
        "name" => "p1",
        "value" => d
      }
    ]
  }
  query = {
      "json" => build_parameter.to_json
  }
  # ret = Net::HTTP.post_form(URI.parse('http://test:test@localhost:8080/job/test/build'), query)
  ret = Net::HTTP.post_form(URI.parse('http://test:test@localhost:8080/job/test/buildWithParameters'), query)
  puts ret.to_hash
}

/build と /buildWithParameters がありますが実行したビルド番号がほしい場合は buildWithParameters を使います (参考)

ファイル付きのパラメータを付与してビルドする

Jenkins のジョブは f1 というファイルと p1 というテキストのパラメータを受け取る想定です

post_form ではファイルを送れないようなので set_form + multipart/form-data を使います
クエリの作り方もハッシュではなく 2 次元配列になるようです (もしかするとハッシュでもいけるかも)

require 'net/http'
require 'uri'
require 'json'

filename = 'test.txt'
f = open("./#{filename}")
data_p1 = 0...1
data_p1.each { |d|
  build_parameter = {
    "parameter" => [
      {
        "name" => "p1",
        "value" => d
      },
      {
        "name" => "f1",
        "file" => filename
      }
    ]
  }
  query = [
    [ "json", build_parameter.to_json ],
    [ filename, f, { filename: filename } ]
  ]
  # url = URI.parse('http://localhost:8080/job/test/build')
  url = URI.parse('http://localhost:8080/job/test/buildWithParameters')
  http = Net::HTTP.new(url.host, url.port)
  req = Net::HTTP::Post.new(url.path)
  req.set_form(query, "multipart/form-data")
  req.basic_auth('test', 'test')
  ret = http.request(req)
  puts ret.to_hash
}

リクエスト情報はあとから作成するため認証情報もあとから basic_auth で設定しています

最後に

net/http だけを使って Jenkins のパラメータ付きビルドをコールしてみました
ビルドの結果なども使う想定であれば素直に jenkins_api_client を使うのが良いと思います
Jenkins の Remote API の仕組みや挙動を直接確認したい場合には良い方法かなと思います

2020年2月19日水曜日

概要

パラメータ付きビルドを API で試したい場合に docker を使ってサクっと確認、試せる方法を紹介します

環境

macOS 10.15.2
docker 19.03.5
Jenkins 2.60.3

Jenkins 起動

docker run -p 8080:8080 -p 50000:50000 jenkins

設定から CSRF を無効にしておきます

確認用ジョブ作成

面倒ですが UI をポチポチします

パラメータで渡した値とファイルの内容を表示するだけです

curl でパラメータ付きジョブを登録

GET でもできますが今回は POST を使います

普通のパラメータ

curl -X POST localhost:8080/job/test/build \
  --user root:xxxxxxxxxxxxxxxxx \
  --form json='{"parameter":[{"name":"p1","value":"hoge"}]}'

ファイル

curl -X POST localhost:8080/job/test/build \
  --user root:xxxxxxxxxxxxxxxxx \
  --form "file1=@./test.txt" \
  --form json='{"parameter": [{"name":"p1","value":"hoge"}, {"name":"f1","file":"file1"}]}'

JSON ファイルを外だし

curl -X POST localhost:8080/job/test/build \
  --user root:xxxxxxxxxxxxxxxxx \
  --form "file1=@./test.txt" \
  --form json="@./data.json"

cat data.json

{
  "parameter": [{
    "name": "p1",
    "value": "hoge"
  }, {
    "name": "f1",
    "file": "file1"
  }]
}

最後に

パラメータがちゃんと送信できているか確認する際に使えると思います

2017年10月29日日曜日

jenkins_api_client で Pipeline Job を作成するときのコツ

概要
環境
とりあえずパイプラインジョブを作成するコード
XML をコードに落とすときのコツ
最後に

概要

前回 Ruby + jenkins_api_client を使って Jenkins を操作してみました
API からジョブを作成することはできますがジョブの作成には XML が必要です
今回はパイプラインジョブでその XML の情報を生成するコツを紹介します

環境

macOS X 10.12.6
Ruby 2.4.1p111
jenkins_api_client 1.5.3

とりあえずパイプラインジョブを作成するコード

こんな感じでパイプラインジョブを作成することができます

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'pass'
)

def create_job_xml
  builder = Nokogiri::XML::Builder.new(:encoding => 'UTF-8') { |xml|
    xml.send("flow-definition", :plugin => "workflow-job@2.12.2") {
      xml.description
      xml.keepDependencies "false"
      xml.properties {
        xml.send("org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty") {
          xml.triggers
        }
      }
      xml.definition(:class => "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition", :plugin => "workflow-cps@2.41") {
        xml.script "node {\n   echo 'Hello World'\n}"
        xml.sandbox "true"
      }
      xml.triggers
      xml.disabled "false"
    }
  }
  builder.to_xml
end

# puts create_job_xml
puts client.job.create('job_name', create_job_xml)

このコード内で生成している XML の情報は以下の通りです
puts のコメントアウトすれば XML の情報を確認することができます


<?xml version="1.0" encoding="UTF-8"?>
<flow-definition plugin="workflow-job@2.12.2">
   <description />
   <keepDependencies>false</keepDependencies>
   <properties>
      <org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty>
         <triggers />
      </org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty>
   </properties>
   <definition class="org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition" plugin="workflow-cps@2.41">
      <script>node {
   echo &amp;apos;Hello World&amp;apos;
}</script>
      <sandbox>true</sandbox>
   </definition>
   <triggers />
   <disabled>false</disabled>
</flow-definition>

XML をコードに落とすときのコツ

自分のおすすめとしては

まず手動でパイプラインジョブを作成する
jenkins_home にある jobs/job_name/config.xml で XML の内容を確認する
XML をコードに落とし込む

という流れが一番簡単で良いと思います

サンプルコードの場合 XML のマーシャライザは nokogiri を使っています
なので少し nokogiri の使い方も知っておく必要があります
まずタグ情報の定義は xml.hoge という感じで定義します
XML 内に値がある場合はスペースを 1 つ開けて文字列で値を定義します

ex)

xml.disabled "false"

XML のタグ情報にハイフンやドットが含まれる場合は xml.send メソッドを使います
第一引数で要素名を指定して第二引数で要素の属性情報を定義します

xml.send("org.jenkinsci.plugins.workflow.job.properties.PipelineTriggersJobProperty")

また XML が入れ子になっている場合はブロックにすれば OK です

xml.definition(:class => "org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition", :plugin => "workflow-cps@2.41") {
  xml.script "node {\n   echo 'Hello World'\n}"
  xml.sandbox "true"
}

改行は \n で置換してあげましょう
それ以外もメタ文字に関してはちゃんと置換してあげてください

たぶん気をつけるべきはそれくらいだと思います
実際にリクエストを送信する前に XML の情報を出力してみて、手動で作成したジョブの XML と合っているか確認すると良いと思います

最後に

jenkins_api_client でジョブを作成するときのコツを紹介しました
基本は素の XML を頑張って Ruby のコードに落とし込む作業をやる感じになります
なれれば簡単にコードに落とし込むことができます
今回はジョブの設定がほとんどないジョブをコード化したので短いですがジョブの設定が多くなればそれだけコード側も多くなります

jenkins_api_client を使う場合はおそらくこれが一番簡単だと思いますが、結局 XML の文字列情報を client.job.create に渡せれば良いだけなのでファイルから文字列情報を生成しても良いかと思います

2017年10月23日月曜日

概要

前回 Jenkins の API を curl で試してみました
今回は Ruby から実行してみました
専用の SDK があるようなのでそれを使ってみます

環境

macOS X 10.12.6
Jenkins 2.60.3
Ruby 2.4.1p111

ライブラリインストール

bundle init
vim Gemfile

gem "jenkins_api_client"

bundle install

サンプルコード集

いろいろと試してみます

ジョブの一覧の取得

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'ab4eda0916f1a599e8132bc2bf8a3cec'
)
jobs = client.job.list_all
puts jobs.class # -> Array
jobs.each { |job|
  puts job
}

jobs = client.job.list("^hoge")
jobs.each { |job|
  puts job
}

list メソッドを使うことで正規表現でジョブを絞込することができます

ジョブをビルド

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'ab4eda0916f1a599e8132bc2bf8a3cec'
)
jobs = client.job.list_all
jobs.each { |job|
  code = client.job.build(job)
  # build_id = client.job.build(job, params = {}, opts = {"build_start_timeout" => 100})
}

client.job.build でジョブ名を文字列で指定するだけです
上記サンプルは全ジョブを実行しているので必要なジョブだけ絞り込んで実行したほうが良いでしょう

また build_start_timeout を指定してビルドを実行するとレスコンスコードではなくビルドの番号が返ってきます
なのでビルド番号がほしい場合は下の方法で呼ぶ必要があります

コンソール情報を取得する

ビルド番号からコンソールの情報を取得します
text or html が選択できます

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'ab4eda0916f1a599e8132bc2bf8a3cec'
)

job = 'hoge'
build_id = client.job.build(job, params = {}, opts = {"build_start_timeout" => 100})
ret = client.job.get_console_output(job, build_num = build_id, start = 0, mode = 'text')
puts ret['output']
puts ret['size']
puts ret['more']

client.job.get_console_output を使います
ビルド番号が必須なので、ジョブを実行した際にビルド番号を取得するようにします
(ビルド番号がない場合は最新のビルドから取得しても良いような気がしますが)

ジョブを連結する

いわゆる「他のプロジェクトのビルド」を設定することができます

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'ab4eda0916f1a599e8132bc2bf8a3cec'
)
jobs = client.job.list_all
target_jobs = client.job.chain(jobs, 'success', ["all"]) # 安定している場合のみ起動にチェックが入る
# target_jobs = client.job.chain(jobs, 'failure', ["all"]) # 失敗した場合でも起動にチェックが入る
# target_jobs = client.job.chain(jobs, 'unstable', ["all"]) # 不安定でも起動にチェックが入る

client.job.build(target_jobs[0])

第二引数を変更することで次のビルドに進む条件を変更できます
第三引数は chain する対象のジョブを絞り込むことができます
例えば failure を指定すると失敗したジョブだけを chain することができます
これを使えば失敗したジョブだけをつないでビルドすることができるようになります
ちなみに chain コール後はジョブが連結されているので each で回してビルドするのではなく先頭だけ実行すればすべてのジョブが実行されます

ジョブを作成する

XMl の生成が必要です
Helper クラスが合ったのそれを使います

require 'jenkins_api_client'

client = JenkinsApi::Client.new(
  :server_ip => 'localhost',
  :username => 'root',
  :password => 'ab4eda0916f1a599e8132bc2bf8a3cec'
)

def create_job_xml
  builder = Nokogiri::XML::Builder.new(:encoding => 'UTF-8') { |xml|
    xml.project {
      xml.actions
      xml.description
      xml.keepDependencies "false"
      xml.properties
      xml.scm(:class => "hudson.scm.NullSCM")
      xml.canRoam "true"
      xml.disabled "false"
      xml.blockBuildWhenDownstreamBuilding "false"
      xml.blockBuildWhenUpstreamBuilding "false"
      xml.triggers.vector
      xml.concurrentBuild "false"
      xml.builders {
        xml.send("hudson.tasks.Shell") {
          xml.command "\necho 'going to take a nice nap'\nsleep 15\necho 'took a nice nap'"
        }
      }
      xml.publishers
      xml.buildWrappers
    }
  }
  builder.to_xml
end

puts client.job.create('job_name', create_job_xml)

create_job_xml の内容を変更すればジョブの内容を変更することができます
curl でファイルを操作してジョブを作成するよりかはプログラム内で XML を扱ったほうが若干ジョブの作成しやすさは上かなと思います

最後に

Ruby から Jenkins の API をコールしてみました

ビルドの実行からジョブの作成まで基本的なことはすべてできると思います
また、今回は触れませんでしたがプラグイン関連の処理もできるので Jenkins 自体の設定もコードから操作することができるかもしれません (未確認)

あとは Sinatra や Rails などの Web フレームワークと組み合わせれば独自 UI なども簡単にできると思います

参考サイト

2017年10月19日木曜日

Jenkins の API を curl でサラッと試してみた

概要
環境
事前作業
CSRF の無効化
API トークンの取得
ジョブの作成
いろいろコールしてみる
Tips
最後に

概要

久しぶりに Jenkins のリモート API に触れたので使い方などをまとめておきます

環境

macOS X 10.12.6
Jenkins 2.60.3

事前作業

今回は docker 上で動かしました
Jenkins を動かすのはどこでも問題ないです
一番初めのテンポラリーパスワードによる認証とプラグインのインストール、ユーザの作成までは済ませておいてください

今回は root という名前のユーザを作成した体で勧めます

CSRF の無効化

Jenkins -> Jenkins の管理 -> グローバルセキュリティ設定 -> CSRF対策

のチェックをオフにして Apply

API トークンの取得

root -> 設定 -> API トークン -> API トークンの表示

ジョブの作成

適当に作成してください
API でも良いですが面倒なので手動で作成しました
ちなみに API で作成した場合は謎の XML ファイルを作成して FORM として POST すれば作成できます -> 参考

いろいろコールしてみる

つらつらと curl でコールしてみました
ちなみに全部 POST で送っていますが GET でも OK です

ジョブの一覧の取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/api/json?tree=jobs'

ちなみに件数を指定して取得することもできます

curl --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/api/json?tree=jobs%5Bname%5D%7B0%2C1%7D'

URL にするとこんなフォーマットです
curl でコールするときは URL エンコードする必要があるので上記のようになっています

http://localhost:8080/api/json?tree=jobs[name]{0,1}

ジョブのビルド

curl -v -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/build'

ここでポイントですがレスポンスの Location ヘッダにキューの情報が付与されています
ここに番号が振られておりそれがビルドの番号にもなるので、実行したビルドの結果を追いたい場合には Location ヘッダの情報を使用してください

Location: http://localhost:8080/queue/item/3/

最後に成功したビルドの結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/lastSuccessfulBuild/api/json?pretty=true'

最後に成功したビルドのコンソール結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/lastSuccessfulBuild/logText/progressiveText?start=0'

ビルド番号を指定してビルドの結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/api/json?pretty=true'

ビルド番号を指定してビルドのコンソール結果を取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/logText/progressiveText?start=0'

ビルド番号を指定してビルドのコンソール結果を HTML で取得

curl -X POST --user 'root:bcc000720152bfd435e5c5128705908a' \
'http://localhost:8080/job/test/3/logText/progressiveHtml?start=0'

Tips

トークンを使わないでも API をコールすることができます
トークンの箇所に作成したユーザのパスワードを入力しても API をコールすることができます

また、良くないですがそもそも認証情報付与するの面倒くさいという場合はグローバルセキュリティ設定から「セキュリティを有効化」のチェックをオフにすればトークンもパスワードもなしで API をコールできます

最後に

Jenkins のリモート API を試してみました
基本は UI で操作していて、その操作を API として使いたいときに URL の最後に /api を付け加えてやるとその操作の API リファレンスがいろいろと表示されるのでそこでやり方を確認するといいと思います

コンソールの結果が平文 or HTML じゃなくてそれっぽい JSON とかに置き換えできれば Jenkins を使って簡単な API サーバが作れそうな気がしました
プラグインとか探せばあるのかな、、、

2017年4月19日水曜日

はじめての Jenkinsfile (git 連携)

概要
環境
Jenkinsfile 作成
Pipeline ジョブを作成する
Jenkinsfile を書き換えてみる
最後に
参考サイト

概要

Jenkinsfile を改めて試してみました
Github 上で Jenkinsfile を管理してそれを取得してビルドを実行します

環境

CentOS 7.3
Jenkins 2.46.1

Jenkinsfile 作成

あらかじめ Github 上にリポジトリを作成しておきましょう

git clone https://github.com/hawksnowlog/test-jenkins-file
cd test-jenkins-file
vim Jenkinsfile

node {
  echo 'My first Jenkinsfile'
}

git add .
git commit -m “first”
git push -u origin master

でとりあえず OK です

Pipeline ジョブを作成する

Jenkins 上で Pipeline ジョブを作成します
Pipeline ジョブでないと Jenkinsfile が使えないのでご注意ください

ジョブを作成したら Pipeline の設定箇所で「Pipeline script from SCM」を選択します
SCM を git に変更し先程 push した Github リポジトリの URL を記載します

これでビルドするとビルド結果に echo の結果が表示されると思います

Jenkinsfile を書き換えてみる

vim Jenkinsfile

node {
  stage('Echo') {
    echo 'My first Jenkinsfile'
  }
}

git add .
git commit -m “second”
git push -u origin master

書き換えて再 push 後ジョブをビルドし直すとビルド結果が変わっていることがわかると思います
ステージを追加することでステージごとにビルド結果が表示されるので結果も見やすくなります

最後に

Jenkinsfile を Github で管理して Jenkins でビルドしてみました
Webhook などでジョブをキックできるようにすると更に便利かもしれません

Pipeline ジョブにすればジョブの内容をコードに落とせるので便利です

参考サイト

https://jenkins.io/doc/book/pipeline/getting-started/

2017年4月9日日曜日

touch: cannot touch '/var/jenkins_home/copy_reference_file.log': Permission denied

概要
環境
エラー詳細
解決策
参考サイト

概要

docker 上で Jenkins のイメージを動作させる時に発生したので解決策を紹介します

環境

CentOS 7.3
Jenkins 2.46.1
docker 17.03

エラー詳細

実行コマンドは以下の通り

docker pull jenkins
docker run -p 8080:8080 -p 50000:50000 -v $(pwd):/var/jenkins_home jenkins

で以下のエラーが発生

touch: cannot touch ‘/var/jenkins_home/copy_reference_file.log’Permission denied
Can not write to /var/jenkins_home/copy_reference_file.log. Wrong volume permissions?

解決策

chown -R 1000 $(pwd)

$(pwd) の部分は run する時にマウントするパスを指定してください
今回はカレントをマウントしているので上記の用になっています

参考サイト

https://github.com/jenkinsci/docker/issues/177

2017年4月8日土曜日

Jenkins のビルド結果を Slack に通知する方法

概要
環境
Slack にアプリ追加
Jenkins のプラグインの追加
ビルドの設定
動作確認
最後に

概要

Jenkins の結果を Slack に通知してみました

環境

CentOS 7.3
Jenkins 2.46.1

Slack にアプリ追加

Jenkins アプリを追加しましょう
追加したら通知するチャネルを入力します

追加が完了すると次の画面で Jenkins 側の設定も詳細に教えてくれます
ここでは Step3 の「Team Domain」「Integration Token」をメモしておきます

Jenkins のプラグインの追加

プラグインの追加から Slack Notification Plugin を追加します

インストール後は再起動なしで OK です

ビルドの設定

「ビルド後の処理」で「Slack Notifications」を追加します

どのイベントを通知するか設定することができます
基本は全部チェックで OK だと思います

カスタムの設定画面を開きます
先程取得した「Team Domain」「Integration Token」を「Team Subdomain」「Integration Token」にそれぞれ入力します
Project Channel に通知するチャネルを入力します
シャープからちゃんと入力するようにしてください

Include Custom Message にチェックを入れてメッセージを入力すると一緒に Slack に通知することができます

動作確認

ビルドを実行してみましょう
成功するビルドだと以下のように表示されれば OK です

最後に

Jenkins のビルド結果を Slack に通知する方法を紹介しました
ドキュメントがだいぶ揃っているのでかなり簡単に追加できました

今回はビルドごとにトークンやドメインを設定しましたが、Jenkins の設定で共通の設定を行うことができるので、常に同じチーム、チャネルに通知する場合はそっちで設定したほうが良いと思います

2017年3月12日日曜日

SSH2 Easy でビルドのパラメータを渡す方法

概要
環境
その前に
SSH するホストの設定
ジョブの設定
動作確認
最後に

概要

SSH したホストでコマンドを実行するというジョブは Jenkins ではよくあるケースだと思います
SSH2 Easy もそんなことができるプラグインの 1 つです
今回は SSH2 Easy を使ってビルドのパラメータを SSH したホストに渡す方法を紹介します

環境

Mac OS X 10.12.3
Jenkins 2.32.3
SSH2 Easy 1.4

その前に

今回は Mac 上で Jenkins を動作させ、動作させている Mac に SSH するので Mac の SSH をオンにします
環境設定 -> 共有 -> リモートログインを ON にします

SSH するホストの設定

Jenkins の管理 -> システムの設定 -> Server Groups Center で SSH するホストを設定します
SSH2 Easy ではグループが設定できます
グループに認証情報を設定し、そのグループの認証情報を使ってログインできるホストをグループにぶら下げることができます

ジョブの設定

まずはパラメータを渡せるようにします
これは何でも OK です

次にリモートホストでコマンドを実行するビルドを追加します
「Remote Command」を選択しビルドの設定をします
そのときにパラメータとして設定した値をダラーで参照すればパラメータの値をリモートホストで参照することができます

動作確認

ジョブを実行してみましょう
するとパラメータに渡した値がリモートホスト上でも展開されて結果に表示されると思います

最後に

SSH2 Easy でビルドパラメータを渡す方法を紹介しました
他の SSH 系のプラグインは試してないですが、同じようにできるかもしれません

2017年3月8日水曜日

Jenkins2.0 ちょっと触ったのでメモ

概要
環境
所感とか
最後に
参考サイト

概要

Jenkins2.0 (執筆時点では既に 2.1) がリリースされたのでアップグレードして軽く触ってみたので所感とかをメモしておきます
事細かに追っているわけではないので間違い等がある可能性がありますのでご了承ください

環境

Windows Server 2008 R2
Jenkins 1.617 -> 2.1

所感とか

アップグレード方法

Jenkins の管理からアップグレード
1.617 から2.1 にアップグレードした
アップグレード後プロセスを再起動
本体アップグレード後にプラグインをアップグレードし再起動
- ざっと確認した感じだと動作していないプラグインはなさそう
- デザイン崩れは多少あったがロジックの下位互換はちゃんと保たれていそう

UI

トップ画面、管理画面での UI に大きな変化はなし
ジョブの作成画面とジョブの編集画面の見た目が大きく変わっていた
ジョブの編集画面で「保存」と「Apply」がスクロールに追従するようになった、常にブラウザの下側にいるようになった
- なぜ「Save」「Apply」じゃないのかはわからない
Build Pipeline Plugin のビューのスタイルがうまく適用されていなかった
- Build Pipeline Plugin は今後使うなということか
/safeRestart は問題なく使えた
今回からかどうかわからないけど、Windows + Jenkins の場合 Jenkins のワークスペースがあるドライブの容量が限界に近いと以下のような警告をしてくれる
- 「Jenkinsのデータディレクトリ “C:\Program Files (x86)\Jenkins” (JENKINS_HOME)の容量がほぼいっぱいになっています。容量オーバーになる前に対処してください。」
サーバベースのダウンロードに変更してくださいという警告が出た
- You currently are using browser-based download to retrieve metadata for Jenkins plugins and tools. This has reliability issues and is not considered fully secure. Consider switching to server-based download.
- こんな警告アップグレード前は出ていただろうか

Pipeline as Code

Pipeline as Code がデフォルトでインストールされている
- https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md
- Pipeline as Code 自体は 1.6 自体からもプラグインとしてインストールすることはできていた
- おそらく 2.0 系の目玉機能
- ビルドの内容を Groovy と呼ばれる言語で記述することが可能
ビルドの内容を git や SVM などのバージョン管理システムで管理することができる
- ビルドの内容を git clone して実行できる、ビルドの内容の変更が管理できるようになる
- 自分の場合、これまではビルドの内容を如何に少なくしてデプロイスクリプト側に寄せるかを考えていた
- デプロイスクリプトを git で管理し、ビルドの内容を書き換えないことで、擬似的にビルドの内容をバージョン管理していた
- 今後はそれをしなくて済むようになる (と思う)
- とは言えデプロイスクリプトをいきなりすべて Groovy にするのは厳しいはず
- また、ジョブ全体の内容を管理した場合はこれまで通り XML を管理するしかなさそう
Stage という概念がありこれがいわゆるジョブの単位とイコールっぽい
- 複数の Pipeline ジョブは作らないで一つの Pipeline ジョブの中に複数の Stage を記載する感じか
- 確かにジョブを細分化しまくると管理が大変なことになるケースが多かった気がする
- とは言え Stage を記載しまくっているビルドコードも見づらくなると思うのでこの辺の作り方にセンスが影響する感じか
Groovy の 2.4 に対応している

最後に

超ざっとですが Jenkins 2.0 をレビューしてみました
詳細は参考サイトにある Changelog にある issue を見るのが一番いいと思います

Pipeline as Code がどこまで普及するかがポイントかなと思います
Groovy 自体そこまで難しい言語ではないので導入自体は難しくないと思います
あとは既存のジョブを如何に Pipeline ジョブへ移行できるかもポイントかなと思います
普通のジョブと Pipeline ジョブが混ざっいても問題ないですが、それもそれでなんか気持ち悪い感じもするので

参考サイト

Jenkins の Pipeline を使ってシェルの実行結果をメールで送信してみた

概要
環境
SMTP サーバの設定
使用する Ruby のコード
Pipeline ジョブを作成する
ビルドコードを作成する
動作確認する
最後に

概要

最近 Jenkins 2.x を触っていて、少しづつ Pipeline as Code にも慣れていこうとしています
導入ってわけではないですが、少しやりたいことがあって Pipelien ジョブを作成してみたので紹介します
やったことは簡単で、実行したシェルの結果 (Ruby の結果) をメールの本文として送信してみました

環境

CentOS 6.7 64bit Final
Jenkins 2.3
Ruby 2.3

SMTP サーバの設定

今回は SMTP サーバに Gmail を使いました
設定方法はこのあたりを参考にしてください
Google の 2 段階認証を設定している場合はアプリパスワードの発行が別途必要になります
発行したパスワードを Jenkins に設定するようにしてください

使用する Ruby のコード

内容は何でも OK です
メール本文に記載したい文章は puts するようにしています

mkdir /var/lib/jenkins/work/
vim /var/lib/jenkins/work/test.rb

puts "hoge"

Pipeline ジョブを作成する

Pipeline ジョブを作成していきます
新規ジョブ作成から作成します
ジョブの種類は Pipeline を選択してください

ビルドコードを作成する

ジョブの設定で Pipeline の項目を設定しましょう
Definition は「Pipeline script」にします
で、Script は以下の通りです

node {
    stage 'Execution'
    sh 'rm -f result.txt && touch result.txt'
    sh '/usr/local/rvm/rubies/ruby-head/bin/ruby /var/lib/jenkins/work/test.rb >> result.txt'

    stage 'Reading Result'
    def result = readFile('result.txt')

    stage 'Sending email'
    mail (to: 'your.account@gmail.com',
        from: 'your.account@gmail.com',
        subject: "Job '${env.JOB_NAME}' (${env.BUILD_NUMBER})",
        body: "${result}");
}

ruby への PATH は各自の環境に合わせて適宜変更してください
流れを簡単に説明すると

結果を保存するファイルを作成
ruby を実行して出力結果をファイルに保存
readFile でファイルを開き内容を変数に保存
mail で SMTP サーバを使ってメール送信

という感じになります
コード内ではわかりやすいように stage を使って処理をわけています
stage を使ってわけることでビルド結果が見やすくなります

動作確認する

では、実際に実行してみましょう
以下のように各 stage ごとに処理時間とエラーだったかどうかが表示されると思います

最後までいけばメールもちゃんと届いていると思います
メールの送信部分でエラーになる場合は SMTP の設定を見なおしてください
ビルドは成功したのにメールが届かない場合はフィルタに引っかかっていないか確認してみてください

最後に

Pipeline を使ってメールの送信をしてみました
本当はプライベートリポジトリで管理している Ruby のスクリプトを clone して実行したかったんですが、Pipeline で ID/PW を使った git clone のやり方がわからず諦めました

とりあえず Groovy が使えるようになったほうがいいのと、Jenkins が用意している sh とか mail とか stage とか git とかが使えるようにならないとダメかなと思います
その辺のリファレンス的なのってどっかにあるのかな
あると思うんだけど見つけられない、、、

2017年3月7日火曜日

Jenkins を使って Dockerfile を CI/CD する方法

概要
環境
設定
動作確認
Tips
最後に

概要

Jenkins の Docker Plugin を使って Jenkins から Dockerfile をビルドしてみました
基本的には前回の設定をそのまま使って行います

環境

Docker
- CentOS 7.3.1611
- Docker 1.12.6
Jenkins
- CentOS 6.7 64bit
- Jenkins 2.10
- Docker Plugin 0.16.2

設定

ジョブを新規で作成して Github から取得した Dockerfile をビルドします

ソースコード管理 -> git

で Github の URL を入力します
もちろん Dockerfile が存在するリポジトリを選択してください

ビルド -> ビルド手順 -> Build / Publish Docker Containers

を選択します
以下の内容を入力します

Directory for Dockerfile･･･./
Cloud･･･test-docker-server
Image･･･hawksnowlog/request-dumper

Cloud の部分は前回設定した「システムの設定」->「クラウド」に追加した Docker 情報の Name になります

設定はこれで完了でジョブを実行してみましょう

動作確認

まずジョブが問題なく完了することを確認してください
コンソール出力には docker build の結果がデバッグログが表示されていると思います

また、docker ホストにログインしてイメージの一覧を確認するとジョブによって作成されたイメージが存在することが確認できると思います

docker images | grep hawksnowlog

hawksnowlog/request-dumper               latest              e3923949379a        6 minutes ago       735.9 MB

Tips

ちょっと Plugin の挙動の補足をしておきます

--no-cache=false で動作しているようです、これはジョブの設定からは変更することができなようです
なのでリソースが変更されていない状態だとすべてキャッシュを使ってイメージを作成するため超速です
試しに 2 回ジョブを実行してみると 2 回目はすぐに終了すると思います

タグ名に動的な値を入れることができない
今回だと hawksnowlog/request-dumper というタグにしています
キャッシュを使わず再ビルドが走ると新しいイメージに設定したタグが振られ古いイメージは <none> になってしまいます
一応 Jenkins 側のログに作成したイメージの ID が残るのでどのリソースから作成されたイメージから追うことはできますが <none> イメージが増えてしまうのはあまりうれしくはないと思います
なので、動的にタグ名が触れるといいのですがジョブの設定でビルド番号の変数などが使えなさそうだったので、どうするのだろうかなと思った次第です

最後に

Jenkins の Docker Plugin を使って Dockerfile 自体のビルドを行ってみました
これでリポジトリに push があった場合に、Dockerfile のビルドも自動で行うことができるようになると思います

あとは新規で作成したイメージから再度コンテナを作成すれば OK です
その辺の自動化も検証できたら紹介したいと思います

2017年3月6日月曜日

Jenkins の Docker Plugin を使って Docker と Jenkins を連携してみた

概要
環境
Docker サーバの設定変更
Jenkins スレーブ用のイメージの取得
- おまけ: Java がインストールされたコンテナの用意
- そのコンテナを Jenkins のスレーブ用のイメージとして保存しておく
Jenkins 側の設定
- スレーブ用のイメージを指定する
テスト用のジョブの作成
最後の
参考サイト

概要

Jenkins の Docker Plugin を使って Jenkins から Docker コンテナを操作できるようにしてみました
設定方法から簡単なサンプルジョブを作成してみます
Jenkins と Docker サーバの準備は事前に行っておいてください

環境

Docker
- CentOS 7.3.1611
- Docker 1.12.6
Jenkins
- CentOS 6.7 64bit
- Jenkins 2.10
- Docker Plugin 0.16.2

Docker サーバの設定変更

Jenkins サーバから tcp で Docker サーバにアクセスできる必要があります
ポートは好きなポートを指定することができます

mkdir /etc/systemd/system/docker.service.d/
vim /etc/systemd/system/docker.service.d/docker.conf

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock

systemctl reload-daemon
systemctl restart docker

で tcp ポートでのアクセスを有効にできます
2376 は好きなポートを指定してください
docker.sock のソケットファイルの指定も必要になるので注意してください
また、reload-daemon -> restart の流れが必要になるので、どちらか一方だけだと有効にならないので注意してください

失敗した方法としては DOCKER_OPTS に設定する方法です
環境変数に export したあとで restart しても全く反映されなかったので設定ファイルを作成しました

netstat -an | grep 2376

tcp6       0      0 :::2376                 :::*                    LISTEN

ps aux | grep dockerd

root     31530  0.2  1.9 563920 40756 ?        Ssl  10:00   0:00 /usr/bin/dockerd -H tcp://0.0.0.0:2376

こんな感じになっていれば OK です

Jenkins スレーブ用のイメージの取得

設定を有効にしたら Jenkins 用のスレーブイメージを pull します

docker pull evarga/jenkins-slave

完了すれば OK です
中身は Ubuntu 14.04 で Java は OpenJDK7 がインストールされていました
SSH が有効になっており jenkins/jenkins でログインできます

docker run -d evarga/jenkins-slave
docker inspect --format="{{ .NetworkSettings.IPAddress }}" 3e7e77225972

で IP が確認できるので SSH できるか確認してみると良いと思います

おまけ: Java がインストールされたコンテナの用意

今回はすでにできあがっている Jenkins スレーブ用のイメージを作成しました
手動で作成することもできるのでその方法を紹介しておきます
基本は JDK が動作するコンテナを用意できれば OK です
今回は ubuntu のイメージから JDK がインストールされたコンテナを準備します

docker pull ubuntu
docker run -i -t ubuntu /bin/bash

でコンテナに入って、コンテナ内で以下のコマンドを順次実行していきます

apt-get update
apt-get install openssh-server
mkdir /var/run/sshd
apt-get install openjdk-8-jdk
adduser jenkins
/usr/sbin/sshd
exit

openjdk-6-jdk がないので 8 をインストールしています
jenkins ユーザのパスワード「jenkins」と設定しました

以下のようなコンテナが作成されれば OK です

docker ps -a

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS               NAMES
65ab636fe103        ubuntu              "/bin/bash"         3 minutes ago       Exited (0) 3 seconds ago                       gigantic_hawking

そのコンテナを Jenkins のスレーブ用のイメージとして保存しておく

コンテナのままだと消しちゃったときに面倒なのもあるので、コンテナをイメージ化しておきます
docker commit コマンドを使って作成します
CONTAINER ID は作成されたイメージのものを利用してください

docker commit 65ab636fe103 jenkins-1

念のためイメージがあるか確認すると良いと思います

docker images | grep jenkins-1

jenkins-1                                latest              7e5771f93803        22 seconds ago      225.1 MB

このイメージを Jenkins のスレーブ用のイメージとして代わりに使うこともできます

Jenkins 側の設定

ここからは Jenkins 側の設定になります
Docker サーバを Jenkins から操作するために Docker サーバの登録を行います

Jenkins -> Jenkins の管理 -> システムの設定 -> クラウド -> 追加 -> Docker

で Docker サーバを登録できます
一番下にポツンとあるので気づきにくいかもしれません

Name･･･好きな名前を設定してください
Docker URL･･･http://xxx.xxx.xxx.xxx:2376
Docker API Version･･･1.24
Connection Timeout･･･5
Read Timeout･･･15
Container Cap･･･100

という感じで入力します
Docker URL の部分は先程 tcp を有効にした Docker サーバの IP アドレスを入力してください

スレーブ用のイメージを指定する

Jenkins のスレーブを管理するためのスレーブプロセスを動作させるイメージを選択します
事前に pull しておいたイメージを指定します

Add Docker Template -> Docker Template

Docker Image･･･evarga/jenkins-slave
Instance Capacity･･･1
Remote Filing System Root･･･/home/jenkins
Lables･･･slave1 (あとでこのラベルを指定することで、このイメージを使えるようにします)
用途･･･このスレーブをできるだけ利用する
Launch method･･･Docker SSH computer launcher
- 認証情報･･･jenkins ユーザのログイン情報 (ない場合は新規で作成)
Remote FS Root Mapping･･･/var/lib/jenkins
Pull strategy･･･Pull once and update latest

特に気にするところはないですが、Labels は必ず指定するようにしてください

テスト用のジョブの作成

ではテスト用のジョブを作成します
Pipeline ジョブを作成してください

General -> Docker Container にチェックをします

そして Pipeline に以下のように定義します

node('slave1') {
  stage 'Stage 1'
  echo 'Hello World 1'
  stage 'Stage 2'
  sh 'hostname'
  stage 'State 3'
  sh 'java -version'
}

ここで先程 Labels に設定した値を使用します
こうすることで指定のイメージからコンテナを作成してビルドすることができます

コンソールの結果を見ると以下のようになっている思います

最後の

Jenkins Docker Plugin で Docker 連携を試してみました
ドキュメントが若干少なかったのが困った点でしょうか

今回は Pipeline ジョブとして作成しましたが、普通のジョブでもできるのか気になりました
スレーブはコンテナとして動作するので、それをノードとして登録できればノードを指定してジョブを実行するだけなのでできると思いますが、面倒そうなのでやめました

あとはスレーブ用のイメージに ruby や golang などの公式のイメージを使う方法も知りたいなと思いました
単純にイメージを追加で登録すればできるとは思うのですが

Jenkins のスレーブは謎の jar を動作させる必要があったと記憶しているので結局 Java のインストールされていないとダメなのだろうか
そうなると、今回使ったイメージに ruby や go やらをインストールしたイメージを作成してそれを使う感じになっぽいな、、、

この辺りも追加で検証してみたいと思っています

参考サイト

2017年2月8日水曜日

Jenkins の thinBackup を使ってみたのでメモ

概要
環境
thinBackup プラグインのインストール
バックアップ
リストア
リストア後にやること
最後に

概要

Jenkins のバックアップについて考えている最中 thinBackup という手軽に使えるバックアッププラグインに出会ったので軽くメモしておきます
やったことは thinBackup を使ってバックアップしたファイルを他の Jenkins サーバにリストアするところまでやってみました

環境

CentOS 6.7 64bit
Jenkins 2.10 (バックアップ側)
Jenkins 2.11 (リストア側)

thinBackup プラグインのインストール

Jenkins の管理 -> プラグインの管理からインストールすれば OK です
Jenkins の再起動は不要でした

バックアップ

Jenkins の管理 -> thinBackup という項目が増えます
選択すると以下のような画面になります

まず Settings -> Backup directory を必ず指定しなければいけません
今回は「/var/tmp/jenkins」を指定しました
ディレクトリがない場合は自動で作成してくれるので何でも OK です

で「Backup Now」を選択するとバックアップがはじまります
選択しても何も画面変化が起きないのですが、成功していると設定したディレクトリ配下にバックアップが作成されています (わかりづらい)

# ls -l /var/tmp/jenkins/
合計 8
drwxr-xr-x 4 jenkins jenkins 4096  6月 30 18:48 2016 FULL-2016-06-30_18-48
drwxr-xr-x 4 jenkins jenkins 4096  6月 30 19:35 2016 FULL-2016-06-30_19-35

2 回バックすると 2 世代分、上記のように作成してくれます

今度はこれを別の Jenkins サーバにリストアしてみます
リストするための tar.gz に圧縮しておきます

# cd /var/tmp/jenkins/
# tar cvzf backup.tar.gz FULL-2016-06-30_18-48/*

リストア

別インスタンスを立てて Jenkins のインストールと初期設定まで済ませてください
( 2.10 だと初回アクセス時にアクティベーション作業があるのでちょっと面倒ですが、、、)

アクティベーションが完了してリストア先の Jenkins にログインできたらバックアップ時同様にプラグインの管理から「thinBackup」をインストールします
更に Settings -> Backup directory でこちらも同様に「/var/tmp/jenkins」を設定します

そしたら先ほど圧縮した backup.tar.gz をリストア先の上記ディレクトリに転送し解凍します
要するにバックアップサーバで作成したものをリストア先のサーバに同じように配置すれば OK です

# pwd
/var/tmp/jenkins
# ls -ltr
合計 4
drwxr-xr-x 4 root root 4096  6月 30 19:23 2016 FULL-2016-06-30_18-48

この状態で「Restore」を選択すると以下のようになります

ちゃんと展開できているとプルダウンでリストア先の設定を選択することができます
オプションでビルド番号もリストアするかとプラグインの情報もリストアするか選択できます
とりあえず自分は「Restore plugins」は ON にして Restore してみました

リストアが完了するとこれまた何事もなく元の画面に戻ってきます

リストア後にやること

まずリストアした情報を反映させるために Jenkins を再起動しましょう

http://localhost:8080/safeRestart にアクセスして再起動

してください

Jenkins の再起動が完了するとジョブの情報がリストアできていることが確認できると思います

で、この後真っ先にやったほうがいいこととして

すべてのジョブを無効化する

という作業はやったほうがいいと思います
ジョブによっては定期的に実行するジョブがあると思います
リストア後のジョブの状態はバックアップしたときの状態でそのままあがってくるため、ジョブが有効だとジョブによっては勝手に実行されてしまいます
それでも問題ないということであれば全然大丈夫ですが、まだバックアップ元のサーバが残っている場合などは二重で実行される恐れがあります

あとやったほうがいいこととしては Jenkins の管理で「リバースプロキシーの設定がおかしいようです。」というエラーが出ていることがあるので

システムの設定 -> Jenkinsの位置 -> Jenkins URL

の設定を見なおして見直しましょう
おそらくバックアップ元の Jenkins サーバの情報になっているのでここをリストアサーバの情報に書き換えれば OK です

基本はこれだけやればバックアップ元と同じ状態に持っていくことができました
全部見きれたわけじゃないので、もしかしたらまだ設定が足りないところがあるかもしれませんが、少なくとも警告やエラーのたぐいは出なくなりました

最後に

Jenkins のバックアップとリストアについて thinBackup というプラグインを使った方法を紹介しました
自分は小規模な環境なのでこれで問題ない気がします

心配なのはリストア先の Jenkins のバージョンがもっとバージョンアップした場合 (例えばバージョン 3 とかになった場合) にちゃんとリストアできるのかという点です

もしバージョンの互換がないと結局で手動でリストアすることになってしまいそうです

2017年1月18日水曜日

サクッと Jenkins Blue Ocean を試す方法

概要
環境
イメージのダウンロード
コンテナの起動
アクセスしてみる
触ってみた感想
最後に
参考サイト

概要

「Jenkins の Blue Ocean が登場したので触ってみたい」と思ってインストールしようとしてみたが、Maven が必要で、Maven をインストールしてみたが、ダウンロードがひたすら長いし、途中でエラーになってインストールできない、、、
なんて場合にサクッと UI を触れる方法を紹介します
Docker を使うので Docker よくわからんという人は「サクッ」にはならないかもしれません、、、　

環境

Mac OS X 10.11.6
Docker for Mac 1.12.0-beta21
Jenkins 2.6
Blue Ocean (Built at 27th May 2016 06:35 PM master 24c104c)

イメージのダウンロード

docker pull jenkinsci/blueocean

blueocean のイメージがかなり大きいのでダウンロードに時間がかかります
自分が試した環境だと 1 時間くらいかかりました

コンテナの起動

docker run -p 8080:8080 jenkinsci/blueocean
docker ps -a

CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                               NAMES
70e39a00dc24        jenkinsci/blueocean   "/bin/tini -- /usr/lo"   43 minutes ago      Up 24 minutes       0.0.0.0:8080->8080/tcp, 50000/tcp   pedantic_morse

ここはサクッと起動します
起動したコンテナ ID は「70e39a00dc24」とします

アクセスしてみる

http://localhost:8080/ にアクセスします
とりあえず Jenkins のセットアップをする必要があります

まずテンポラリパスワードを取得します
先ほどとは別のターミナルで以下を実行してテンポラリパスワードを取得します

docker exec -it 70e39a00dc24 bash
cat /var/jenkins_home/secrets/initialAdminPassword

入力できたらあとは「Install suggedsted plugins」を設定して「Create First Admin User」を適当に設定すれば OK です

そのままログインできたら、とりあえず 1 つジョブを作成してください
そしてジョブができたら http://localhost:8080/blue にアクセスします

すると Blue Ocean の UI を確認することができます

あとは触ってみるだけです

触ってみた感想

箇条書きですが残しておきます
うまく動かなかった点などは自分の触ったバージョンが古いという可能性もあります

ビルドログのダウンロードができる
ビルドの編集はできない、あくまでも見るだけ
New Pipeline をクリックするといつもの Jenkins の作成画面に飛ばされる
Jenkins のトップ画面から blueocean へのリンクがほしい、逆に blueocean から普通の Jenkins へのリンクがほしい
All のビューを表示しているだけか
ユーザを新しく作成しても、そのユーザが作成したジョブだけを確認することができない、あくまでも All のビューにあるジョブを表示してくれるだけ
Pipeline ジョブを作成するとジョブを確認したときに stage ごとにわかりやすく表示してくれる
基本的には Pipeline ジョブを見やすくしてくれるプラグインっぽい

最後に

とりあえず Blue Ocean を触る方法を紹介しました
Maven を使って自分のサーバなどに頑張ってインストールしようとしているができない方におすすめです

また、絶賛開発中のサブプロジェクトなのでこれからいろいろと変更があるかもしれません

それでも Pipeline ジョブに特化したものにはなりそうなので、今からでも既存のジョブを Pipeline ジョブに変更しておくとかはやっておいたほうがいいかもしれません

参考サイト

登録: 投稿 (Atom)