helpdelete

インフラ屋にJenkinsってどうなん？〜言うてるオレもわからんわ〜

コレ自体は「当日の資料」＆「カンペ」です。

ブラウザでご覧の方は、右上の Presentation を右クリックし「新しいタブで開く」でご覧ください。

注意+前提

  • 個人的見解ですので「実際に使う際」には他を参考ください
  • 自身は「中の人ではない」「そんなにJenkinsに詳しくない」「実績は(ガチ勢から見りゃ)微々たるもの」なので、信憑性・真義については「自分で使ってみて検証」してください
  • 質問は Q. の接頭辞付けてくれたら拾います

この勉強会をやる理由

いつも「Jenkinsを立てて、提供するだけ」のインフラエンジニアの人に 「Jenkins、使わないですか？」 って言うたら 「なんでこんな便利なものを、教えてくれなかったんですか！」 って言われたから。

Jenkinsとは

  • Jenkins (ジェンキンス) とは、Javaで書かれたオープンソースの継続的インテグレーションツールである。
  • ソフトウェアのビルド、検証、サーバへのインストール等の一連作業を自動化する事が出来る。

…は、Wikipedia から抜粋。

特徴

  • 様々なシチュエーションに応じた「トリガー」
  • いくつかの「ジョブ種」でつくる「ジョブ」
  • わかりやすい「見える化」と「履歴蓄積」
  • 豊富なプラグイン
  • お手軽かつ閉鎖空間にもOKな「Jenkinsエージェント(ノード)」
  • 「え、こんなことにも？」で使われてる汎用性

本来は…

  • 本来
    • ソースのテスト・ビルドに関する自動化に使う(ことが主目的)
  • 現状
    • 「タイマー実行」「バッチ処理」絡みの、ありとあらゆることに使われている

例:データのメトリクス集計、定期メール発信、etc...

他人に説明するときの「てきとーな文句」

「Jenkins？ ああ、 visual cron みたいなもんっすよーw」

みたいな雑さでも「わかっていただける」かも。

デモ「各種インスコ」

だいたい https://jenkins.io/doc/book/installing/  に書いてあります。

  • CentOS
  • Ubuntu Server
  • Dockerコンテナとして
  • Docker on Jenkins on Docker

CentOS

rootで実行。

yum install -y java-1.8.0-openjdk
curl http://pkg.jenkins-ci.org/redhat/jenkins.repo > /etc/yum.repos.d/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
yum install jenkins
chkconfig jenkins on
service jenkins start

こっからは「動いてから」のこもごも。

firewall-cmd --add-port=8080/tcp --permanent
systemctl restart firewalld
cat /var/lib/jenkins/secrets/initialAdminPassword

UbuntuServer

おそらく、Debianも一緒。

wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

こっからは「動いてから」のこもごも。

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Docker上

docker run --name jenkins-container -u root -d -p 8080:8080 jenkins
docker logs jenkins-container

Docker上で普通に上げるだけじゃ…（さっきの)

dockerondocker.png

Docker on Jenkins on Docker

コレも 公式インストール資料  に載ってるんですけどね。

docker run --name jenkins-container -u root -d -p 8080:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkinsci/blueocean
docker logs jenkins-container

※blueocean同梱版はdockerコマンド一式入っているためこっちを採用

デモ「使い方の触り」

  • 「フリースタイル・プロジェクトのビルド」ジョブ
  • フォルダ
  • パイプライン
    • Slack仕込
  • その他のジョブ種
  • JenkinsAgentで、他のマシンをワーカーに

その他のジョブ種

pipline-types.png 

(手前味噌ですが)こちらをご覧ください…。

インフラの方々にとっての重要度

  1. Jenkins を「他者が使う」ための「ただインストール・運用する」という知見
  2. Jenkins を「インフラ(自分たち用)の自動化・メンテナンス用」として使う

「インフラの自動化・メンテナンス用」の例

  • AWSで「最新のOSイメージ」出るたびに、自動でプロビジョニングしてAMIビルドする
  • 本来の使い方として「インフラで使うツールのソースをCI(継続的インテグレーション)してテスト回す
  • インフラのツール等の「CD(継続的デリバリ/デプロイ)」

取り扱い注意

「餅は餅屋」は、色々な局面で”居る”ので…

  • 「自動化」「タスク(ジョブ)スケジューラ」
    • 業務（business） : JP1、Tivoli
    • インフラ運用自動化 : Rundeck
    • 監視系 :Mackerel, Zabbix, nagios, etc...

取り扱い注意(続き)

  • Jenkinsを JP1 などの「業務用ジョブスケジューラ」に使うかは、慎重に考えたい
    • 業務 視点とは「別コンテキスト」で使うほうが良さそう
    • 「ジョブネット」とか組むものではないし、「リラン」も組めないことはないけど…
  • 「監視」に使うのも、方針決めてから
    • 「ちっちゃく保ちたい」「集約したい」「今は簡易にこれ＋シェルスクリプトにしとくか」などの判断があればOK

インフラ視点で使う場合の「ベネフィット(ご利益)」は…

まあ「自動化」という言葉におしなべられて「そんなんJenkins以外でもできるわ」とDisられそうですが…。

ベネフィット(ご利益)

  • インフラの仕事に「いろんな人を巻き込める」可能性のある可視性
    • コンソール/Cronではなく「Web画面で」というところ
      • これは「Jenkinsに限った利点」ではないけれど
    • 複数のロールの方が「レビュー」できるDSL（PipelineScript）
      • コレに関してはちょっと限定的

ベネフィット(続き)

  • 「不定期だが人間の判断で定型文を打つ必要」の１クリック化
    • 「自分じゃなくても良く」なって、仕事が減る？可能性
      • ただし権限の設計はきちんとね
  • 本気でDevOpsするなら「Container/クラウドのAsCodeされたサーバ構成のCI」
    • DockerfileやAnsibleのymlとかのビルドやServerSpecテストをCIしてみたり

その他

「可視性/見える化」と「人を巻き込める」「目が多くなる」という考え方

  • 出力を見やすくする・残す
    • AsCodeが前提ですが…
    • サーバオペレーションのログなんざ、手打ちなら「コンソールソフトのログ」くらいしか残ってないじゃん？

と、言うのに、一役買ってくれます。

困りごと

  • 容量わりかし要る問題
    • バックアップどうしょう？履歴どこまで残そう？
  • Jenkins自体のSPOF化と冗長化コスト
  • 「いろんなUpdate」で「事故死」問題
    • Java、その他鯖プロダクト、Jenkins自体、Plugin…どれが上がっても「突然死」する可能性は避けられない

Infrastracture as codeの潮流から…

少し「インフラ」側から身近なものに？

IaCとCI

  • 「クラウドの意義」(の一つ)
    • インフラ(という物理前提の世界)のソフトウェア化…だと俺は思ってます
  • 転じて「"環境"は"コードからビルドするもの"」という概念になる
    • コードは「ビルド」し「テストし続け」る対象に

IaCとCI（続き）

  • 「リソース」と「コード」を使って「成果物」をビルド
    • ディストリイメージは「リソース」、これを使って「コード」がビルド
  • 構成物の「何かが変化」したら「ビルド」して「テストする必要が在る
    • 例えば「ディストリイメージ」「ソース」のどちらが変化してもビルドテストする必要
  • つまり「環境作成のCI」が当然になる

何言ってっか解らんす

environment-ci.png

参考

ご視聴ありがとうございました

アンケート にお答えいただければ、小躍りします。

「やってみて」から「再演してみて」からの意見/FB

アンケート結果 

  • 「CIとはなんぞ」を説明しといたほうがよい
    • CIは概念だ
    • 「手順書だってCIできる(ただし全手動)」だったりね
  • 「なんでビルドなんて行為が要るのですか？」という疑問
    • そしてそれを「なんで何回も回す必要があるのですか？」という疑問
    • それを「インフラ」に置き換えたらどうなんの？「ネットワーク」やったり「実機」やで？…からの像が繋がらない
      • 「Cloud(AWS)とか」だとできるんかも…
      • 三浦的には違う、実機でやってた
  • 「使い方が思いつかない…」という感想
    • 「これCISCOで使う」つったら、どうなんねんやろなぁ、という漠然としたもの
    • 「使う必要が無いなら使わない」は原則だと思うので…
  • 「(インフラ勉強会のイベントを経て)見る人のパイは増えている」ので、もしかすると「ニーズはある」かもしれないが…
    • (セッション自体の)必要性は読めない
  • ただ「開発の人がこういうことを考えながらやってるんだ」ということを知れるのが良かった
  • じゃあ「序盤に出てくる"インフラの人が便利やって言うてた"」ってどんなユースケース？
    • 各種サーバのcronとかに分散したくない
    • AWS Lambda & スケジュール実行に敷居を感じていた
      • 自分は「bash & aws cliでしこたま書いてる」のに…
    • どこからでも行ける「オーケストレーション出来る何か」がほしかった
      • それを「自分がコントロールできる」近所でカジュアルなものが欲しかった
  • CIを言葉で説明するの難しい…
    • CIは文脈で意味が違うから、なんの略か言ってから話してほしいと思うし
    • 自分の界隈ではこの意味であると暗黙の了解で略語を使うのは危険