（僕にとって）はじめてのSpring Cloud Pipelines

Spring界隈以外の人にはおそらく馴染みの薄い（失礼）、Spring Cloud Pipilinesについてざっくり紹介する。

なあに？

• CI/CDパイプラインを作るためのフレームワークのようなもの
  • CI/CDツールそのものでないので、それらは別途用意する必要がある
• デプロイ先としてKubernetes（K8S）、CloudFoundry（CF）に対応
• CI/CDツールとしてJenkins、Concourseに対応

公式サイト

• ドキュメント
• GitHub

前提知識

• わりと必須
  • CI/CDツール（Jenkins等）の基本的な仕組み
    • 無いと、Spring Cloud Pipelinesの機能なのかCI/CDツールの機能なのか判断しづらい
  • bashの文法
    • わりとシェル芸が激しいので、知らないと何が起きてるのか良く分からない
  • K8SやCFのコマンド
    • kubectlとか
• あるとうれしい
  • groovyの文法
    • サンプルを眺めてるうちになんとかなりそう
  • Dockerの基本的な知識
    • Jenkinsのイメージ起動はstart.shで行うので直接的には不要
    • イメージのカスタマイズ時にDockerfileやdocker-compose.ymlの編集をするときに必要

用語定義

• パイプラインジョブ
  • アプリケーションのCI/CDを実行するジョブ
• シードジョブ
  • ジョブを作るジョブ。ここではパイプラインジョブを作るジョブとする
• Jenkinsfile
  • CI/CDのパイプライン定義をgroovy形式で記述するファイル。CI/CDのコア部分

スクリプトファイルの種類

処理はgroovyファイル、Jenkinsfile、bashファイルに記載する。
以下は、Jenkins＋CF環境の例（①、②はどの環境でも共通）
（）内は、ファイルのあるディレクトリ

• ①init.groovy（jenkins/seed）
  • Jenkins初期化に呼び出される
• ②jenkins_pipeline.groovy（jenkins/seed）
  • シードジョブ定義を記載する
  • シードジョブ実行時にパイプラインジョブを複数作る場合、ビルドパラメータにgitのurlをカンマ区切りで指定する
• ③jenkins_pipeline_jenkinsfile_sample.groovy（jenkins/jobs）
  • パイプラインジョブ定義を記載する
  • Jenkinsfileを指定する
• ④Jenkinsfile-sample（jenkins/declarative-pipeline）
  • パイプラインジョブ定義を記載する
  • ビルドやデプロイを行うシェルスクリプトをここから呼び出す
• ⑤pipeline.sh（common/src/main/bash）
  • 環境に応じたビルドやデプロイコマンドを記載する

処理の流れ

• パイプラインジョブの作成
  • Jenkins起動時にシードジョブを生成する（①→②を呼び出し）
  • JenkinsのWeb画面でシードジョブを実行する
  • ③と④の定義が参照され、パイプラインジョブが生成される
  • JenkinsのWeb画面でパイプラインジョブを実行する
  • ④に定義されたシェルスクリプトが呼び出され、ビルドやデプロイ、テストが実行される

いけてるところ

• Jenkinsの構築が楽
  • 設定済みのDockerfileとdocker-compose.ymlが提供されてる
• パイプラインジョブが一発で作れる
  • 画面でポチポチしなくていいのは楽
• Jenkinsおじさん化の抑止
  • まがりなりにもテンプレ化・構造化されてるので、方言ができづらい
  • とはいえ、Jenkinsおじさんが完全に駆逐されるとも思えないが...

いけてないところ

• K8S、CF以外の環境にデプロイしようとするととたんに難易度が上がる
  • できなくはないが、修正ポイントが増えてしまう
    • groovyファイル、Jenkinsfile、bashファイルそれぞれに手が入ることになる
  • そこまでするとフレームワークとしてのSpring Cloud Pipelinesの利点が減る
  • そもそもデプロイはSpinnakerあたりにまかせたほうがいいのでは
    • 連携できそうな雰囲気はするが、怪しい...
• カスタマイズの具体的な方法が提示されていない
  • そもそもK8S、CF以外向けにカスタマイズする想定はなさそう
• シェル芸が激しくてつらい
  • 実際の処理（ビルドとかデプロイ）を実行しているbashの中身がごちゃごちゃで可読性が低い
  • 結局、bashに渡す変数の取り回しのために、groovyファイルの記述も煩雑になってしまっている
• 日本語情報が少ない
  • ググっても出てこない（皆無？）

おわりに

• 調査・検証時にK8SやCFをつかわずEC2にDockerコンテナで無理やりデプロイしたので、真価をまだ見極められてない
  • ほんとうはEKSが使えたら使いたかった
• しかし、「Spring Cloud ほにゃらら」シリーズは何でもあるな（追いきれません）