「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

GitLab CI + Kubernetes で、Spring Bootアプリ開発を最適化する | about.gitlab.com / Marco Lenzo

パイプラインという、継続的デリバリーを実現するシステムを整えて、Spring Boot appを作ります。GitLab CI、Kubernetesと、Kubernetesを導入したGoogle Cloud Container Engineの力を借りて、アプリケーションを作りますよ。

  継続的インテグレーション、継続的デプロイメント、継続的デリバリー、最近のこれらのワードがソフトウェア開発チームの間でだんだん話題になっています。

 具体的にいえば、コミットにビルド、テスト、デプロイする工程を、「パイプライン」という道具を使ってさまざまに自動化します。それでさらに質の高いコードを編集したり、もっと頻繁に試作を繰り返したりしよう、という考え方ですね。

 問題は、そのパイプラインをどうするかということです。機能を選ぶのが簡単で、操作がしやすく、インストールもしやすく、後から手直しができて、そしてメンテナンスしやすい必要がありますね。
 

  最近、私はGitLabというツールを見つけました。これがなかなか便利です。
 これだけ機能が豊富でエコシステムが完結していて、たった数分で設定が終わってしまうCIは、僕あんまり見たことがない。issue trackingなども操作でき、CI1つで管理できちゃいます。

  このページでは、Spring Bootアプリケーションを制作するとして、KubernetesクラスターとGitLab CIでビルド、テスト、デプロイをする方法を解説します。

 Spring Bootとは、Javaでマイクロサービスを展開するためのツールです。Spring Frameworkは大変に使いやすく、特別覚えることもありません。最低限の設定でも、よくある RESTful APIを使ったCRUDアプリケーションくらいなら作れてしまいます。

 KubernetesGoogle Borgで開発されたオープンソースのコンテナ管理ツールで、スケジュール、スケール、コンテナに入れたアプリケーションの管理ができます。

 

  まずはGitLabプロジェクトを作ろう

  今回の解説で一番大事な場面は「パイプラインの整備」なわけですけれど、それをするにはまず、GitLabプロジェクトを作成する必要がありますね。
 そこで今回、私は「actuator-sample」という名前のプロジェクトを作成することにしました。

 ですが、いちいち手作業でプロジェクトを作成するのも面倒です。皆さんは「git clone」で私のプロジェクトをコピーをして構いませんよ。プロジェクトのホームページから次のコマンドを入力してください。

======================
git clone git@gitlab.com:marcolenzo/actuator-sample.git
cd actuator-sample
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master
======================
 このあと、marcolenzoという筆者のGitLab ユーザ名を、あなたのユーザ名に変更してください。
 これにおいては、人様のコードをコピーして再利用する時のお約束です。

 

  次に、Spring Bootアプリケーション を作る

  次にSpring Bootアプリケーションをつくるのですが、これは Spring Initializrとういウェブページで必要事項を選択して「Geneate Project」を押すだけです。
  これから作るのは、「Maven Project」ですし、Spring Bootのバージョンもそのままのものを使います。最初のトグルで変更する部分はありません。

  Mavenというのは、依存関係や、ビルドのライフサイクルなどを定義する、プロジェクト管理ツールです。Javaプロジェクトでは比較的よく使われています。

 その下に、「Group」という欄がありますが、そこは「com.example」のまま飛ばします。
 「Artifact name」という欄には、今回のアプリの名前である、「actuator-sample」を入力します。

 「Dependencies」では2つの項目を選択しました。
 1つは「Web」。これはTomcatSpring MVCなどウェブ開発に必要なものがほとんど揃います。
 もう1つは「Actuator」で、これにはアプリケーションのモニターや管理や、Http requestのヘルスチェックをするような機能があるのです。
 

  そして、「Generate Project」ボタンを押すと、「actuator-sample.zip」というZipファイルがダウンロードされます。
 (写真1) Spring Initializr

 

  このファイルを解凍すると、すぐにアプリケーションが出てきます。Spring Initializrが開発に必要なものを万端に整えてくれるので便利ですね。

 次は開発用のマシンに Java JDK 1.7 以上を導入します。そしてJAVA_HOMEという変数をインストールしたものの通りに設定します。
 Linuxディストリビューションをお使いの場合は、 OpenJDKを使用することが望ましいでしょう。大抵のレポジトリにありますからね。
 そうでないのなら、 Oracle JDKを入れるという手段もありますよ。
 ですが、必ずや何らかのJava開発環境は用意してくださいね。

============================================
### DebianやUbuntuなどのシステムに OpenJDK 8をインストールするには

sudo apt-get install openjdk-8-jre

###  Fedora、Oracle Linux、Red Hat Enteprise、CentOSなどのシステムにOpenJDK 8をインストールするには

su -c "yum install java-1.8.0-openjdk"

### 環境変数 JAVA_HOME を設定する

export JAVA_HOME=/path/to/your/java/home #  /usr/lib/jvm/java-8-openjdk-amd64/ のように、適切な場所を設定する

### ダウンロードしてきたアプリケーションを解凍し、起動する

~/git/actuator-sample$ unzip ~/Downloads/actuator-sample.zip -d ../
~/git/actuator-sample$ ./mvnw spring-boot:run

[...]

2016-12-02 22:41:14.376 INFO 10882 --- [    main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)
2016-12-02 22:41:14.420 INFO 10882 --- [   main] com.example.ActuatorSampleApplication : Started ActuatorSampleApplication in 17.924 seconds (JVM running for 87.495)
============================================

 これらのコマンドで、まだコードが全く書かれていないアプリケーションが起動します。
 Spring Boot はデフォルトできちんと変数などを自動で設定してくれますからね。
 クラスパスをざっと確認すれば、この先のコンフィグに困ることはありません。

 今回は、すぐに開発に取り掛かれそうなことが確認できました。

===========================
~$ curl http://localhost:8080/health
 {"status":"UP","diskSpace":{"status":"UP","total":981190307840,"free":744776503296,"threshold":10485760}}
===========================
  Spring Boot のアプリジェネレーター機能についてもっと知りたい方は、 reference documentationguidesをご覧ください。
 

  この空白のアプリを、originにプッシュしましょう。
 この操作については、masterブランチのディレクトリにプッシュする機能を使います。
 ここでgitやブランチをどう扱うかとか、コラボレーションはどうするかなどについては、ここでは説明しません。

 あとからGitLab Flowに掲載されている environment branches機能を使って、デプロイ先の環境を指定したりします。
 その操作がピンとこない方は、about.gitlab.comのGitLab Flowのページをぜひともご確認くださいね。

===========================
git add --all
git commit -m "Creates actuator-example application"
git push origin master
===========================


 GitLab CIで、どのような継続的デリバリー用パイプラインを作成する?

  コードの編集はGitLabの中で行うとして…
 次はデプロイやビルドを自動化する準備、GitLab CIの編集に取り掛かります。

 ここで設定するのは、テスト項目、発覚した問題の早期報告、ビルドが成功したらデプロイする環境の設定、などの項目です。

 (これがもう2,3年前のCIserverときたら、 Jenkins のようなサービスを自前のサーバーにインストールして、全ての項目をバッシュスクリプトで設定していたのですが、

 最近のCIはなかなか進化しておりまして、クラウドホスティングでも利用できるようになったりと、使用形態にだって選びようが出てきました。なんとまあ、楽なこと!)
 

  しまった!話がそれました。
 GitLab ではCIとCDパイプラインを作成し、ビルド、テスト、デプロイなど、様々な作業を自動化できます。

 

  今回のデプロイ先は、クラスター管理に
Kubernetesを使った、 Google Cloud Container Engineというサービスです。

 Kubernetesはほとんどのクラウドプロバイダで使うことができるほか、Linuxサーバーにもすぐに入れることができるくらい、ありふれたソフトです。

 よって、今回の紹介するセッティングは、一部を状況に応じて変更すれば、他のKubernetes環境でも流用可能なはずですよ。

 

  さて、パイプラインを構築する前に、アプリのレポジトリに2つのファイルを追加する必要があります。
 1つ目はDockerコンテナの設定ファイル、
 2つ目はデプロイ対象であるKubernetesの設定ファイルです。


 

  Spring Bootアプリケーション をDockerコンテナにパッケージングする

  まずは、プロジェクトのrootディレクトリに「Dockerfile」を作ります。
 そこに次のような設定をしてください。

===========================
FROM  openjdk:8u111-jdk-alpine
VOLUME  /tmp
ADD  /target/actuator-sample-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT  ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
===========================
 一番上の「FROM」という項目には、Dockerイメージを指定します。
 今回我々は、Alpine Linuxという超軽量LinuxディストロにOpenJDKをインストールしたモデルを使うことにしました。

 2番目の「VOLUME」には、外部ストレージやコンテナをマウントしたときにどこを一時的なマウントポイントにするかを指定します。ここでは「/tmp」ファイルですね。

 3番目の「ADD」には、ビルドの最中に生成された実行可能なJARファイルを、コンテナのrootディレクトリのどこにコピーして保管するかを指定します。

 4番目の「ENTRYPOINT」には、コンテナを開始したときに、まず最初に実行するコマンドを指定します。
 ここでは、単純に「java -jar app.jar」を実行することにしています。

 途中に「-D」フラグで挿入されている「java.security.edg=file:/dev/./urandom」は、アプリがスタートアップする時点でフリーズを起こさないようにするための、SecureRandomクラスです。
 デフォルトでは「/dev/random」と設定されていますが、これではハードウェア乱数生成器に空白がおこるたびに、アプリの動きを止めてしまいます。

 

  この変更をコミットしましょう。

===========================
git add Dockerfile
git commit -m "Adds Dockerfile"
git push origin master
===========================


  Kubernetes(デプロイ環境)の設定

  プロジェクトのrootディレクトリに「deployment.yml」というファイルを作成して、次のように設定します。

============================================
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: actuator-sample
spec:
  replicas: 2
  template:
   metadata:
    labels:
     app: actuator-sample
   spec:
    containers:
    - name: actuator-sample
     image: registry.gitlab.com/marcolenzo/actuator-sample
     imagePullPolicy: Always
    ports:
     - containerPort: 8080
    imagePullSecrets:
     - name: registry.gitlab.com
============================================

 Kubernetesの Deploymentは、アプリと同じ「actuator-sample」という名前になりました。
 「replicas」には、使用するPodsの数を記入します。ここでは「2」です。

 Kubernetes はアプリケーションを自動的にビンパッキングし、デプロイしているコンピューターのリソースに応じてシステムを自己変更してくれます。

 Podの中には、複数のコンテナを管理することもできますが、今回は「actuator-sample」という名前のプライベート GitLab Container Registryしか入れていません。
 最後のほうにある「imagePullSecrets」にGitLab Container Registryを入れるためです。 

   Kubernetesのリソースの処理方法などで、さらに詳しい情報を得たい方は、公式ドキュメントをご覧ください。

  このファイルの変更もきちんとコミットしましょう。

===========================
git add deployment.yml
git commit -m "Adds Kubernetes Deployment definition"
git push origin master
===========================



  GitLab CI で pipeline を構築する

  さて、ようやく GitLab CIの設定に参ります。
 rootディレクトリに「.gitlab-ci.yml」設定ファイルを作成してください。
 このファイルに書かれた内容は、GitLab Runners が読み取って、ビルドやデプロイが実行されていきます。
 ここに設定するjobの個数は無制限です。ビルドのライフサイクルに有益なものなら、どんどん追加しましょう。
 

============================================
image: docker:latest
services:
  - docker:dind

variables:
  DOCKER_DRIVER: overlay
  SPRING_PROFILES_ACTIVE: gitlab-ci

stages:
  - build
 
- package
  - deploy

maven-build:
  image: maven:3-jdk-8
  stage: build
  script: "mvn package -B"
  artifacts:
   paths:
   - target/*.jar

docker-build:
  stage: package
  script:
  - docker build -t registry.gitlab.com/marcolenzo/actuator-sample .
 
- docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
  - docker push registry.gitlab.com/marcolenzo/actuator-sample


k8s-deploy:
  image: google/cloud-sdk
  stage: deploy
  script:
  - echo "$GOOGLE_KEY" > key.json
  - gcloud auth activate-service-account --key-file key.json
  - gcloud config set compute/zone europe-west1-c
  - gcloud config set project actuator-sample
  - gcloud config set container/use_client_certificate True
  - gcloud container clusters get-credentials actuator-sample
  - kubectl delete secret registry.gitlab.com
  - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
  - kubectl apply -f deployment.yml
============================================

 長いですね。慌てず、意味を1つ1つ見てまいりましょう。
 

  Dockerイメージとサービスの設定
===========================
image: docker:latest
services:
  - docker:dind
===========================
  GitLab ランナー の機能の1つに、パイプラインにDockerイメージを使わせるというものがあります。

 image」には、これから使うDockerイメージの名前を入れることができます。ここに指定するものは、ローカル環境のDockerエンジンでも、Docker Hubなどにアップされているものでも構いません。

 「services」には「主にどのコンテナにリンクを張って、開発に使っていくか」という項目を定義します。
 ここで、「どうしてこれから使用するDockerは『image』で定義したはずなのに、さらに同じような設定をしているのだろう」と思ったあなた、よい質問です。
 今回筆者が設定した「services」のコンテナ自体は、一見ごく普通のDockerですが、実はこれ「Dockerの中に仕掛けたDocker」なんです。そういうコンテナを指定する機能もあるのです。

 

  Variables
===========================
variables:
  DOCKER_DRIVER: overlay
  SPRING_PROFILES_ACTIVE: gitlab-ci
===========================
 ビルド環境を細かく設定するために、変数が使われることがあります。

 「DOCKER_DRIVER」とは、Dockerエンジンにどのストレージドライバーを使わせるかを定義する変数です。
 この部分はきちんと定めておいたのは、パフォーマンスを上げるためですね。

 その下に「SPRING_PROFILES_ACTIVE」という変数がありますが、これはSpring Boot を制作する時には特に便利です。
 ここには、Springプロジェクトに何らかの動きを取らせてもよいサービスを定義します。ここでは「gitlab-ci」です。

 この変数を定義しておくと、(利用できるサービスが増えた結果ですが、)
 アプリに複数の設定を与えることができるようになります。

 これを応用すると、状況に応じてアプリケーションの環境を変更する操作ができるのです。
 たとえば、「開発マシンでアプリを起動したときには、ローカルホストのデータベースを使う」
「GitLab CIでアプリを起動したときには、(GitLab CIの設定に従って)mongoデータベースを使う」など、
 大体そのぐらい大雑把な規模で設定を使い分けることが可能になります。


 

  Stages
===========================
stages:
  - build
  - package
  - deploy
===========================
 「stages」では、ビルドのライフサイクルを定義します。
 複数のjobを同じステージにまとめ上げることもできるので、jobのグループ分けができます。

  同じステージを設定されたjobは、全て同時進行で動きだします。次のステージに設定されたjobが開始するのは、前のステージにあるjobが全て終了してからです。
   

 

  maven-build job
===========================
maven-build:
  image: maven:3-jdk-8
  stage: build
  script: "mvn package -B"
  artifacts:
   paths:
    - target/*.jar
===========================
 これはわざわざ、オリジナルで作り出したjobです。ジョブ定義というやつ。
 jobって、よほど変数やキーワードと被っていなければ、どんな名前を付けることもできるんです。だから、名前をつけるときには、他のキーワードに同じものがないかをお確かめください。
 
 

  このjobの主な役割は、「 Mavenのビルド」です。
 とはいえ、その下に「image」とある通り、これはDockerイメージを定義しているんですね。
 「maven:3-jdk-8」と設定されています。Java JDK 8 がプリインストールされたMaven 3 環境のことです。
 

  そして、このjobは「build」ステージで実行されるように設定されています。

  「script」には、GitLabランナーに実行させるシェルコマンドを指定します。
 このjobの場合、「mvn package -B」というものが設定されていますが、これは何でしょう。
 じつは、Mavenのビルド・ライフサイクルには、いくつかのモードがあります。

 詳しい情報は公式ドキュメントをご覧いただきたいのですが、その中の「-B」モードには、プロジェクトを検査したり、コンパイルしたうえでユニットテストを実施したりと、今回のアプリにぴったりな機能がついています。

 テストの内容は、Spring Initializr が「src/test/java」フォルダに作成したものが使われます。そこにさらにほかのユニットテストを追加することも可能です。

 テストに合格したアプリは、実行可能なJARファイルとしてパッケージに変換されます。

 

  実行可能なJARファイルに、複数のjobを適用させたいのなら、jobアーティファクツの保存先をきちんと決定しておく必要があります。また、保存先を決めておくことで、ビルドが成功したあとに、UIのPipelines画面からアプリをダウンロードできるようになります。
 (写真2)Pipelines画面とダウンロードボタン

 なお、これは余談ですが、開発の手法によっては、異なるバージョンのJava JDK も使って、アプリケーションをコンパイルしたい場合があります。「クロスコンパイル」というものです。

 そこで、上の「.gitlab-ci.yml」にはありませんが、もう1つイメージに「maven:3-jdk-7」を使ったjobを用意しておくと便利かもしれません。
 名前は、あくまで試験的なコンパイルであることから、「maven-test-jdk-7」とします。
 ===========================
maven-test-jdk-7:
  image: maven:3-jdk-7
  stage: build
  script: "mvn package -B"
  artifacts:
   paths:
    - target/*.jar
===========================
 実行するステージを「maven-build」jobと同じく「build」に設定しています。
 なので、Java JDK 8版と、Java JDK 7版の2つのアプリが同時に作成されるかんじです。
 なお、この程度の設定を追加したくらいでは、パイプラインの実行時間が長引くことはありません。


 

  docker-build job
===========================
docker-build:
  stage: package
  script:
  - docker build -t registry.gitlab.com/marcolenzo/actuator-sample .
  - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN registry.gitlab.com
  - docker push registry.gitlab.com/marcolenzo/actuator-sample
===========================

  「docker-build」は、前の「maven-build」jobで「実行可能なJARファイル」として変換されたアプリケーションを、Dockerコンテナにパッケージ化するjobです。

  当然、このjobの「script」は「docker」コマンドでできています。
 大まかにいうと、アプリを「build」して、プライベート・レジストリに「login」、そしてGitLab Container Registryにイメージを「push」するコマンドです。
 

  「$CI_BUILD_TOKEN」は、定義済み変数です。
 GitLab Container Registryにログインするために使われています。
 

  定義済み変数についてもっと知りたい方は、こちらの 変数説明書をご覧ください。


 

   k8s-deploy job

 このjobには、制作したアプリケーションを Google Container Engineにデプロイするために色々な設定をしました。今回のjobでは一番長めです。

 なぜ、 Google Cloud SDK (gcloud) を利用することにしたかというと、Google Container Engineクラスターとその他Google Cloudエコシステムを管理する機能があるなど、開発に役立つプログラムが充実しているからですね。

 今回、Google Container Engineクラスターには、gcloudのGUIから簡単に作成したものを使いました。
 

  GUIに入力する項目ですが、Nameのところにプロジェクト名と同じ「actuator-sample」と入れましたが、これは分かりやすいのでそうしただけのことです。場合によってはプロジェクト名と異なる名前をつけることもあります。
 マシンタイプはこれ以外にも選択することもできますし、ノードの個数もいくらでも構いません。
 あとそれから、「zone」の選択を忘れずに。
 (写真3)gcloudのGUI

  さて、この設定の中で大切なのは、ここからです。
 gcloudとノン・インタラクティブ・ログインを果たすためには、サービスアカウントを設置しなくてはなりません。
 「API Manager > Credentials > Create Credentials」に移動して、「Compute Engine default service account」というJSONキーを作成します。
 

  ここでもう1度「k8s-deploy」jobを見直してみましょう。

============================================
k8s-deploy:
  image: google/cloud-sdk
  stage: deploy
  script:
  - echo "$GOOGLE_KEY" > key.json  # この変数はサービスアカウントキーのこと。
  - gcloud auth activate-service-account --key-file key.json
  - gcloud config set compute/zone europe-west1-c
  - gcloud config set project actuator-sample
  - gcloud config set container/use_client_certificate True
  - gcloud container clusters get-credentials actuator-sample
  - kubectl delete secret registry.gitlab.com
  - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
  - kubectl apply -f deployment.yml
============================================
 「image」には、「google/cloud-sdk」を指定していますが、このイメージはgcloudからプレロードすることでまかないます。このとき依存関係やアルファ/ベータコンポーネントなども同時にロードされます。

 「stage」は「deploy」と設定されており、「package」ステージの後に実行されることになっています。
 なのでこのjobが実行される頃には、「docker-build」jobで実行されたGitLab Container Registryへのプッシュなどは、すでに終了しているということです。


 それでは、「script」の説明に参ります。
 

   まず1行目に、「- echo "$GOOGLE_KEY" > key.json  # この変数はサービスアカウントキーのこと。
 とある通り、この「$GOOGLE_KEY」という変数をきちんと定義しておかなくてはなりません。
 先ほどもらってきた、サービスアカウントキーをこれに代入します。
 外部サービスと連携するために使われる安全変数は、ユーザー定義変数という扱いですから、GitLab UIの「Project > Variables > Add Variable」に移動して変数を認証させます。
 (写真4)Add Variable画面

 

 「script」のほとんどを占めているのが「gcloud」です。今回、 Google Cloud SDK (gcloud)使用する関係上使うことになったコマンドです。
 「gcloud auth activate-service-account --key-file key.json」は、「ノン・インタラクティブ・ログインをする」という命令を下しています。
gcloud config set 」というコマンドが3行にわたって続いています。上からそれぞれzone、プロジェクト、クラスターが指定されていますが、これらはいずれもスクリプトの適用ターゲットを示しています。
gcloud container clusters get-credentials actuator-sample」は、gcloud container クラスターに「actuator-sample」へ証明書を発行させて、kubectl設定ファイルをダウンロードできるようにします。

(Kubernetesを他のプロバイダで使用しているか、独自のサーバーにインストールしている場合、gcloudの設定は必要ありません。kubectl ファイルは「~/.kube/config 」というディレクトリに保管されるはずです。)

 

  次に、「kubectl」コマンドの内容を説明します。
 2つめのkubectlコマンドに、「kubectl create secret docker-registry」というものがありますが、このスクリプトは先ほど設定した「deployment.yml」ファイルの内容に従って、imagePullSecretを作成させます。
 「deployment.yml」は、私たちのプライベートGitLab Container Registryに置かれています。それで、そこに行きつくまでの認証コードなどが後からずらずらと書かれていて、非常に難しい印象を与えているのです。
 要は、プライベート・レジストリにログインして、指定のコンテナをダウンロードしてこいという話です。

 そして、一番上の「kubectl delete secret registry.gitlab.com」は、この新たにダウンロードしてくるDockerコンテナのために、古い「docker-registry」を削除しておく必要があるから設定されました。
 実は Kubernetes APIには、オペレーション対象を「上書き」する機能がないみたいなんです。

 プライベートDockerレジストリといっても、パスワードさえ与えておけば、外部のCIと連携可能なわけです。
 実践的な話をするなら、Kubernetes secrets にいくつものパイプラインを適用させて、様々な管理方法を取りたいものです。
 管理のしかたはパイプラインごとに分類することもできますが、コンフィグ管理ツール( AnsibleSaltPuppetChefなど)ごとに振り分けても便利な気がするんですよね。

 というのも、やっぱりセキュリティの関係上、プライベートレジストリを使った方が安全ですし、
 管理ツールもときどき他のものを回すようにしないと、セキュリティ強度にだんだん偏りが出てきます。
 こういう対策は、どのプロジェクトでも取った方が良いと思うんですよね。

 ただ、そこで「kubectl delete」コマンドが、他のパイプラインの継続を妨げてしまうというリスクがあるのが残念です。

 あと、「$REGISTRY_PASSWD」はユーザー定義変数です。
 GitLab UIの「Project > Variables > Add Variable」から、きちんと設定しましょう。
 

  さて、ここで設定したクラスターがきちんと動いているかどうかを確認してみましょう。

===========================
$ kubectl get deployments
NAME     DESIRED    CURRENT   UP-TO-DATE   AVAILABLE   AGE
actuator-sample    2     2       2         2       2m
$ kubectl get pods
NAME               READY STATUS RESTARTS AGE
actuator-sample-3641958612-3e5xy   1/1   Running  0       2m
actuator-sample-5542343546-fr4gh  1/1  Running  0      2m
===========================

   (写真5)ようやくデプロイだぜ!

 

  GitLab Environments

 ごめん。まだ話終わってないのさ。デプロイしたのに。
 ここで、 GitLab Environmentsという、環境とデプロイとを追跡調査するための機能について教えるから。

  それじゃあ、まず「.gitlab-ci.yml」を開いて、「k8s-deploy」jobを分割する。
 片一方を「staging」、もう片方を「production」として使うように変更する。
 以下の設定を参考にして。

============================================
k8s-deploy-staging:
  image: google/cloud-sdk
  stage: deploy
  script:
  - echo "$GOOGLE_KEY" > key.json
  - gcloud auth activate-service-account --key-file key.json
  - gcloud config set compute/zone europe-west1-c
  - gcloud config set project actuator-sample
  - gcloud config set container/use_client_certificate True
  - gcloud container clusters get-credentials actuator-example
  - kubectl delete secret registry.gitlab.com
  - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
  - kubectl apply -f deployment.yml --namespace=staging
  environment:
   name: staging
   url: https://example.staging.com
  only:
  - master

k8s-deploy-production:
  image: google/cloud-sdk
  stage: deploy
  script:
  - echo "$GOOGLE_KEY" > key.json
  - gcloud auth activate-service-account --key-file key.json
  - gcloud config set compute/zone europe-west1-c
  - gcloud config set project actuator-sample
  - gcloud config set container/use_client_certificate True
  - gcloud container clusters get-credentials actuator-example
  - kubectl delete secret registry.gitlab.com
  - kubectl create secret docker-registry registry.gitlab.com --docker-server=https://registry.gitlab.com --docker-username=marcolenzo --docker-password=$REGISTRY_PASSWD --docker-email=lenzo.marco@gmail.com
  - kubectl apply -f deployment.yml --namespace=production
  environment:
   name: production
   url: https://example.production.com
  when: manual
  only:
  - production
============================================

 2つのjobは、名前とデプロイ先が微妙に違うことを除いては、「k8s-deploy」とほとんど同じです。
 ですが、ここで「environment」という要素が追加されましたね。その下には、「url」でGitLab Environmentsページへのハイパーリンクが張られています。(あとで「Pipelines > Environments」で探してね)
 そして、「only」でどのブランチでjobを作動させるかを指定しています。
 「when: manual」は本来自動で行われるはずのjobを手動で実行されるように変更するコマンドです。
  このjobが果たしている役割は、継続的デリバリーといういうより、「継続的デプロイメント」と呼んだ方が正しいのかもしれません。

 デプロイ先の環境を、「namespace」で分類できるあたりは、Kubernetes独特の癖です。

 

  ここでは、詳しく述べませんが、「master」「production」のようにパイプラインを環境によって使い分けることができなかった頃は、ソフトウェアのコラボレーションどころではありませんでした。
 つまり、アプリのレビューとともにマージリクエストを出したり、ブランチごとに異なるコードを作成することがかなりやりづらかったのです。
 マージリクエストは、ターゲットとなるブランチをマージしてしまう前に、アプリをレビューすることでその変更が適切かどうかについて議論することもできるようになる機能です。
 レビューがないと、今の人きっと困りますよ~。
 マージリクエストに動的環境が備わることで、デプロイしたアプリケーションにチームでアクセスすることができるようになりました。
 いちいちブランチをチェックして、デプロイの宛先などを手動で変える必要もありません。

 それから、アプリのレビュー自体はクローンやインストールをしなくても可能ですから、技術者ではない人に試してもらって、試作品の意見をもらうこともできます。
 

===========================
git commit -am "Showcasing Pipelines"
git push origin master
git checkout -b production
git push origin production
===========================

 (写真6)「Pipelines > Pipelines

 ダウンロードボタンを押したところ、「K8s-deploy-production」というボタンが出現しています。
 

  「Pipelines」画面では、どのようなパイプラインが実行されたかが表示されています。
 ここで、ブランチがそれぞれのステージでどのような結果を出したかを一挙に見ることができます。

 今回の場合、「 k8s-deploy-production」はGUIからビルド・アーティファクツをダウンロードするときになって初めて実行されるようになります。
 

  (写真7)それでは「Pipeline>Environments」に移動してみましょう

  さらに、タブを「Environments」に切り替えると、そこには最も新しいバージョンの「redeploy」環境が支度されています。
 その下には、少し古いバージョンのブランチが表示されていますが、それには「roll back」ボタンがついていて、それぞれのバージョンの環境を記述したページにアクセスするようになっています。
 (写真8)少し古いバージョンのブランチと「roll back」ボタン

 

  結び

  このチュートリアルでは、継続的デリバリーGitLabで実現できるようにかなり細かいところまで説明しました。
 また、今回アプリケーションのひな型を作成するために使用した Spring Bootというサービスも、自動で応用コンテキストを設定してくれていたりと、思いの他、高品質なサービスを提供してくれました。
 Kubernetesは処理リソースに応じてコンテナの編成を最適化してくれます。
 パイプラインはGitLab CIがコアエンジンとして機能します。内容は「.gitlab-ci.yml」ファイルで定義し、その結果などはGUIで確認できるということです。

  この基本的な要素を組み合わせることで、開発チームやカンパニーに、問題の調査、コードの評定、CI,そしてCDなどの様々な機能を与えることができるのです。
 

  ゲスト著述家

  Marco Lenzo
 いつでも何かに挑戦してみることを心に決めて働くソフトウェア設計者。
 専門分野は、トランザクション処理とplatform as a service (PaaS)。
 Java、Spring、Go、そしてKubernetesをよく扱っている。彼にとってそれらはお茶の子と朝飯前なのだ。

  
PDF
更新日:2017-11-12 17:43:34 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/ Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

僕がHugo静的サイト・ジェネレータをGitLabで使うときにしたCI設定 | from Leow Kah Man - Tech Blog

 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポジトリにNodeJS Dockerイメージを構…2017-11-18 13:00:02

【GitLab 公式 を訳してみた】Dockerイメージを使う

GitLab Documentation > GitLab Continuous Integration (GitLab CI) > Docker integration >Dockerイメージを使う  GitLab CIは、GitLab ランナーと連携して、Dockerエンジンを様…2017-11-18 00:10:16

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン があることに気がつきました。  原…2017-11-17 23:50:27

【GitLab 公式 を訳してみた】GitLab CI/CDで使える変数

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CDで使えるAPI変数  GitLab ランナーは、CIから送られてきたjobをもとに、ビルド環境を整えます。…2017-11-17 23:50:02