システム開発や運用保守等の部分おいて、ピンポイントでエンジニアに業務依頼ができるSES。 しかしSES企業は多く、どこを利用するか迷っている方も多いのではないでしょうか。 この記事では、おすす […]
Kubernetes 時代の CI/CD「Jenkins X」とは? 〜後編その1〜
中編 で予告した通り、本記事ではサンプルとして用意されている quickstart プロジェクトを作成して、Jenkins X がどのように CI/CD を実施するのかを見ていきたいと思います。
目次
Jenkins X の URL 確認
自分がインストールした Jenkins X の URL は jx コマンドを利用し、以下のように確認できます。
$ jx get urls
Name URL
jenkins http://jenkins.jx.XXX.XXX.XXX.XXX.nip.io
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
jenkins-x-chartmuseum http://chartmuseum.jx.XXX.XXX.XXX.XXX.nip.io
jenkins-x-docker-registry http://docker-registry.jx.XXX.XXX.XXX.XXX.nip.io
jenkins-x-monocular-api http://monocular.jx.XXX.XXX.XXX.XXX.nip.io
jenkins-x-monocular-ui http://monocular.jx.XXX.XXX.XXX.XXX.nip.io
nexus http://nexus.jx.XXX.XXX.XXX.XXX.nip.io
また、前回もご紹介しましたが、Jenkins のログイン情報は以下で確認できます。
$ grep -A2 '^jenkins' ~/.jx/adminSecrets.yaml
jenkins:
Master:
AdminPassword: XXXXXXXX
^^^^^^^^
[adinserter block="1"]
インストール直後の Jenkins 内のジョブ構成
インストール直後の Jenkins には、以下のようなジョブが既に設定され、初回ビルドが実行されている状態になっているはずです。
XXXXXX (GitHub のユーザ名)
`+-- environment-XXXXX-production
+-- environment-XXXXX-staging
(XXXXX はいずれも Jenkins インストール時に自動で決定される適当な英単語が入る)
しかし、初期設定状態では、インストール時に GitHub の access token を入力したにもかかわらず、Jenkins 上にはそのアカウント情報が登録されておらず、以下のメッセージが延々と出てビルドが進まなくなっているでしょう。
(GitHub への API アクセスの rate limit に引っかかっている)
05:39:18 Connecting to https://api.github.com with no credentials, anonymous access
05:39:18 GitHub API Usage: Current quota has 40 remaining (9 over budget). Next quota of 60 in 53 min. Sleeping for 17 min.
05:42:18 GitHub API Usage: Still sleeping, now only 14 min remaining.
上記の問題を解決するために、Jenkins がリポジトリにアクセスする際の GitHub のアカウントを登録します。
GitHub の設定
- New personal access token のページに行きます
public_repo
だけにチェックを入れ、Generate token
ボタンを押します- ここで表示される token をコピーしておきます
- 初期に追加されている staging, production ジョブの設定画面を開きます
Branch Sources
設定項目にあるGitHub
>Credentials
の横にある追加
ボタンを押し、Jenkins
を選びますユーザ名
に GitHub アカウント名、パスワード
に 2. で発行した token を入力します- ID/説明については任意で設定してください
追加
ボタンを押し、Credentials
のドロップダウンで追加した認証名を選択します- ジョブを保存します
- ブランチ一覧中の master の行にあるビルド実行ボタンを押します
- GitHub の rate limit に引っかかっている既存のビルドについては中止しても問題ありません
この設定をすることによって、GitHub API の rate limit に引っかからずにジョブが実行されるようになります。
残念ながら、現在のバージョンの Jenkins X では、プロジェクトを作成し、ジョブを追加するごとにこの作業を実施しないといけないようです…
(追加されたジョブにも credential の設定が入っていないため、rate liit に引っかかる)
[adinserter block="1"]
動かしてみよう
それでは、実際に quickstart プロジェクトを作成し、どのように CI/CD が実施されるのかを見ていきましょう。
quickstart プロジェクトの作成
まず、以下のコマンドを実行します。
プロジェクト作成時に、作成したプロジェクトのリポジトリがこのコマンドの実行時ディレクトリ配下に作成されます。後のコード修正で利用するため、実行ディレクトリを控えておきましょう。(いつも思い出せる作業ディレクトリとかがいいでしょう)
$ jx create quickstart
すると、以下の様にサンプルプロジェクトの構成を選択するプロンプトが表示されます。
? select the quickstart you wish to create [Use arrows to move, type to filter]
❯ android-quickstart
angular-io-quickstart
aspnet-app
dlang-http
golang-http
node-http
node-http-watch-pipeline-activity
今回は、簡単な Java アプリを作成しますので spring-boot-http-gradle
を選択します。
次に、プロジェクト名を聞かれるので、自分がわかりやすい名前を入力します。(例では、quickstart-spring-boot
を設定)
? Project name quickstart-spring-boot
次に、Git ユーザ名として、GitHub で登録しているユーザ名を利用するか聞かれるので Y を押し、Enter キーを押します。
? Do you wish to use XXXXXX as the git user name: (Y/n)
次に、すぐに git リポジトリを作成するか聞かれるので Y を押し、初回コミットメッセージを入力します。
? Would you like to initialise git now? Yes
? Commit message: Initial import
Git repository created
selected pack: /home/XXXXXX/.jx/draft/packs/github.com/jenkins-x/draft-packs/packs/gradle
No git server found!
replacing placeholders in directory /home/XXXXXX/work/quickstart-spring-boot
app name: quickstart-spring-boot, git server: github.com, org: XXXXXX
skipping directory "/home/XXXXXX/work/quickstart-spring-boot/.git"
Using git provider GitHub at https://github.com
GitHub のユーザで、複数の Organization に所属している場合は、どの Organization にリポジトリを作成するかの選択肢が表示されますので、適宜選択してください。
そうすると、作成するリポジトリ名を聞かれるので Enter キーを押して最初にプロジェクト名と同一のリポジトリを作成します。
? Which organisation do you want to use? XXXXXX
? Enter the new repository name: quickstart-spring-boot
Creating repository XXXXXX/quickstart-spring-boot
Pushed git repository to https://github.com/XXXXXX/quickstart-spring-boot
No git server found!
Created Jenkins Project: http://jenkins.jx.XXX.XXX.XXX.XXX.nip.io/job/XXXXXX/job/quickstart-spring-boot/
Watch pipeline activity via: jx get activity -f quickstart-spring-boot -w
Browse the pipeline log via: jx get build logs XXXXXX/quickstart-spring-boot/master
Open the Jenkins console via jx console
You can list the pipelines via: jx get pipelines
When the pipeline is complete: jx get applications
For more help on available commands see: https://jenkins-x.io/developing/browsing/
Note that your first pipeline may take a few minutes to start while the necessary images get downloaded!
Creating github webhook for XXXXXX/quickstart-spring-boot for url http://jenkins.jx.XXX.XXX.XXX.XXX.nip.io/github-webhook/
ここまでで、quickstart プロジェクトの作成は完了です。
jx コマンドからの出力にも記載されていますが、作成が完了した時点で以下の作業が自動的に行われます。
- Jenkins X 上へのプロジェクト登録・Jenkins へのジョブ登録
- GitHub 上に作成したリポジトリの webhook 設定
- 最初のアプリケーションバージョン
0.0.1
として各種ファイルのバージョン定義を更新、Git リポジトリ上でタグ付けを行う - リポジトリの初期コミットの内容で、以下を実施する
- Docker イメージの作成
jenkins-x-docker-registry
への Docker イメージの pushjenkins-x-chartmuseum
への Helm chart のアップロード- Docker registry と Chartmuseum は、Jenkins X インストール時に一緒にインストールされたものが使われます
- staging 環境の構成情報を保持しているリポジトリへの PR 追加、マージ
- 冒頭でご紹介した
environment-XXXXX-staging
リポジトリを指しています - マージされると、Jenkins 上で CD が実行され、4. で作成された Docker イメージ/Helm chart を利用して staging 環境の構築が行われます
- 冒頭でご紹介した
上記のように、初回コミットによるデプロイが Jenkins 上で行われ、Kubernetes 上の jx-staging namespace に作成したアプリケーションが公開されます。今回作成したアプリケーションは HTTP での接続を待ち受けますので、そのままインターネット経由で公開されたアプリケーションにアクセス可能です。
デプロイされたアプリケーションにアクセスしてみる
デプロイされたアプリケーションの URL は、以下のコマンドで知ることができます。
$ jx get applications
APPLICATION STAGING PODS URL PRODUCTION PODS URL
quickstart-spring-boot 0.0.1 1/1 http://quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io
また、Kubernetes 上で Web サービスを公開する際に利用する Ingress リソースを確認しても、アクセス先の URL を見ることが可能です。
$ kubectl get ing --all-namespaces
NAMESPACE NAME HOSTS ADDRESS PORTS AGE
jx-staging quickstart-spring-boot quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 22h
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
jx chartmuseum chartmuseum.jx.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 15d
jx docker-registry docker-registry.jx.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 15d
jx jenkins jenkins.jx.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 15d
jx monocular monocular.jx.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 15d
jx nexus nexus.jx.XXX.XXX.XXX.XXX.nip.io XXX.XXX.XXX.XXX 80 15d
では、実際に動いているかどうか、以下の URL にアクセスしてみましょう。
http://quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io/greeting
すると、以下の様なレスポンスが返ってくることが確認できるはずです。
{"id":1,"content":"Hello there, World!"}
さらに、元になっているソースを見ると name
パラメータをリクエスト時に付加すると、content
の内容が変わるように書かれているので試してみましょう。
http://quickstart-spring-boot.jx-staging.XXX.XXX.XXX.XXX.nip.io/greeting?name=Hoge
すると、以下の様にレスポンスが変わり、ちゃんと想定通り動作していることが確認できますね。
{"id":2,"content":"Hello there, Hoge!"}
ちなみに、Jenkins X で作成できる quickstart プロジェクトは、以下の GitHub organization を見ると元のソースを確認することができます。
https://github.com/jenkins-x-quickstarts/
[adinserter block="1"]
まとめ
本記事では、Jenkins X をインストールした状態から、予め用意されている quickstart プロジェクトを作成し、Jenkins X が CI/CD をどのように動くかをご紹介しました。
次回、後編その2(最終回)では、作成したアプリケーションを修正し、production 環境へのリリース作業を実施し、筆者が Jenkins X に持った印象を述べる予定です。
>Kubernetes 時代の CI/CD「Jenkins X」とは? 〜前編〜
>Kubernetes 時代の CI/CD「Jenkins X」とは? 〜中編 〜