IBM Cloud Open ToolchainテンプレートをカスタマイズしてGitOps的なToolchainを作ってみた！

# 背景
IBM CloudにはプロジェクトのDevOpsライフサイクルに合わせてIBMクラウドサービスとオープンソース・ツールやサードパーティのツールを組み合わせてDevOpsのためのToolchainの環境を簡単に構築するための仕組みがあります。
https://www.ibm.com/cloud/architecture/toolchains

今回の案件ではIBM Cloud Kubernetes service(IKS)を実行環境としたコンテナ・アプリケーション開発用のToolchainを構築することになり、手始めにToolchainのカタログで用意されている[Kubernetesアプリ開発のToolchain](https://www.ibm.com/cloud/architecture/toolchains/develop-kubernetes-app-toolchain)がそのまま適用可能かを実際にToolchainをセットアップして、今回の案件でそのまま使用することが可能かDelivery Pipelineの内容を精査した結果以下の点が要件に合わないことがわかりました。

これに伴い、当初はKubernetesアプリ開発のパイプラインを作成して手動でカスタマイズする想定で考えていたのですが、案件が進んでいくにつれてIKSで稼働するサービスが複数必要であることが判明し、毎回この作業を手動で実施するとなると無駄なコストがかかる上に作業ミスが必ず発生するのでToolchainのカスタマイズ自体を自動化することを考えました。

幸い、IBM Cloud ToolchainはカスタムToolchainのためのテンプレートを作成することが可能だと以下のチュートリアルからわかりました。
https://www.ibm.com/cloud/architecture/tutorials/create-a-template-for-a-custom-toolchain

そこで、このチュートリアルやチュートリアルで言及している[Open Toolchainテンプレートのマニュアル](https://github.com/open-toolchain/sdk/wiki#open-toolchain-templates-sdk)を参照しながら、前述した要件を満たすToolchainテンプレートを開発しました。

この記事では上記の流れで行った作業の詳細を記載するとともに、最終的に作成したToolchainテンプレートについて解説を行います。
なお、Toolchainテンプレートの作成方法についてはこの記事では割愛しますので、詳細な作成方法を知りたい方はぜひ以下の記事もご覧ください。
[IBM Cloud Open Toolchainテンプレートの作成方法まとめ](https://qiita.com/strada/items/96e0caec56d281a78abd)

# 今回作成したToolchainの要件
まず、はじめに今回作成したToolchainの前提となる要件を以下にまとめました。

- 前提条件
    - 対象となる環境は開発、ステージング、本番の3環境
- 機能要件
    - ソースコード管理
        - 管理対象
            - アプリのソースコードだけでなくIKSへアプリをデプロイする際に使用するk8sのマニフェストファイルもリポジトリでバージョン管理する
        - ブランチ戦略
            - 開発環境用のソースコードをmasterブランチで管理する
            - ステージングおよび本番環境用のソースコードをreleaseブランチで管理する
            - 開発環境でテストが完了したらmasterブランチからreleaseブランチへマージし、ステージングでテストを実施し、本番にリリース
            - 以下のイメージ
                -  ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/432627fc-cc26-0865-8ad7-750ff0f37979.png)
    - ビルド成果物管理
        - 管理対象
            - ソースコードを元にビルドされた以下二種類のコンテナ・イメージを管理する
                - 開発環境用のコンテナ・イメージ
                - ステージング環境および本番環境用のコンテナ・イメージ
                    - 本番環境はステージングでテスト済みのコンテナ・イメージをデプロイする

    - CI/CDパイプライン
        - 粒度
            - 開発、ステージング、本番の各環境で個別のパイプラインを作成する
        - 自動化の範囲
            - 開発
                - ビルドとデプロイを自動化
                - masterブランチへのPUSHをトリガーにビルドを開始
                - ビルドが完了すると自動的にデプロイを開始
            - ステージング
                - ビルドとデプロイを自動化
                - releaseブランチへのPUSHをトリガーにビルドを開始
                - **デプロイの開始はユーザーが明示的に行う**
            - 本番
                - **デプロイのみを自動化**
                - **デプロイの開始はユーザーが明示的に行う**
        - プロセス
            - ビルド自動化
                - ソース・コードからコンテナ・イメージをビルド
                - ビルドされたコンテナ・イメージをコンテナ・イメージ・レジストリに登録
            - デプロイ自動化
                - ソースコード管理のリポジトリに登録されているマニフェストファイルを元にコンテナ・イメージをk8sクラスターにデプロイ
- 非機能要件
    - セキュリティ
        - **ソースコードやk8sマニフェストファイルを所管する役割でファイルへのアクセス権限を分離するためにそれぞれを管理するリポジトリを分割する**
            - ソースコードは開発者しか更新できない
            - k8sマニフェストファイルは運用担当者しか更新できない
    - 拡張性
        - 今回の案件の複数サービスへの横展開だけではなく、他案件への横展開も想定

# 既存のToolchainが利用できるか精査
IBM CloudにはプロジェクトのDevOpsライフサイクルに合わせてIBMクラウドサービスとオープンソース・ツールやサードパーティのツールを組み合わせてDevOpsのためのToolchainの環境を簡単に構築するための仕組みがあります。
https://www.ibm.com/cloud/architecture/toolchains

今回の案件ではIBM Cloud Kubernetes service(IKS)を実行環境としたコンテナ・アプリケーション開発用のToolchainを構築することになり、手始めにToolchainのカタログで用意されている[Kubernetesアプリ開発のToolchain](https://www.ibm.com/cloud/architecture/toolchains/develop-kubernetes-app-toolchain)がそのまま適用可能かを確認しました。

Kubernatesアプリ開発のToolchainでは以下のツールがセットアップされます。

| ツールまたはサービス | 説明 |
|:-----------------|:-------------------|
| [GitリポジトリとIssue Tracking(GitLab)](https://www.ibm.com/garage/method/practices/code/tool_git_repos_and_issue_tracking)| コードを保存および管理し、不具合、拡張、タスクなどの作業を追跡します。 |
| [Eclipse Orion Web IDE](https://www.ibm.com/garage/method/practices/code/tool_eclipse_orion_web_ide) | コードを変更し、Webブラウザーからパイプラインを介してコードをデプロイします。 |
| [PIPELINE](https://www.ibm.com/garage/method/practices/deliver/tool_delivery_pipeline)| 自動的にビルドしてIBM Cloudにデプロイします。|
| [IBM Cloud Kubernetes Service （Kubernetesクラスター）](https://www.ibm.com/garage/method/practices/run/tool_ibm_container/) | IBM Cloud Kubernetes Service によって管理され、セキュリティを強化するための脆弱性アドバイザーを含むKubernetesクラスターにデプロイします。 |	 	

![alt](https://www.ibm.com/cloud/architecture/images/toolchain_icons/secure_kube_tc_diagram.svg)

Toolchainは以下のようにIBM CloudのToolchainのカタログから**Kubernetesアプリの開発**を選択して簡単にセットアップすることが出来ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/7a18234a-bd4c-88ba-1cf7-bfecb09d7b3b.png)

実際にToolchainをセットアップして、今回の案件でそのまま使用することが可能かDelivery Pipelineの内容を精査した結果[前述の要件](#%E4%BB%8A%E5%9B%9E%E4%BD%9C%E6%88%90%E3%81%97%E3%81%9Ftoolchain%E3%81%AE%E8%A6%81%E4%BB%B6)の太字箇所が要件に合わないことがわかりました。
要件に合わない点は以下の通りです。

1. ステージング環境および本番環境ではデプロイの開始はユーザーが明示的に行う
2. 本番環境ではデプロイのみのパイプラインで良い
3. ソースコードやk8sマニフェストファイルを所管する役割でファイルへのアクセス権限を分離するためにそれぞれを管理するリポジトリを分割する
4. Web IDEは使用しない（要件として必要としていない）

Web IDEに関しては利用しなければいいだけなのでまだ良かったのですが、それ以外の要件から[Kubernetesアプリ開発のToolchain](https://www.ibm.com/cloud/architecture/toolchains/develop-kubernetes-app-toolchain)をそのまま使用することが出来ないと判断しました。。

# カスタムするToolchainの概要
[前述の要件](#%E4%BB%8A%E5%9B%9E%E4%BD%9C%E6%88%90%E3%81%97%E3%81%9Ftoolchain%E3%81%AE%E8%A6%81%E4%BB%B6)を元にパイプラインの概要を以下のように整理しました。

## 開発環境
![2020-07-09 17_24_11-【ヘルスケアアプリ開発】アプリケーションの移行フロー_20200604.pptx - PowerPoint.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/92a0bd8c-781d-b032-1342-c3ab7ff8ef7a.jpeg)
Toolchainを利用した開発環境へのリリースフローをは以下のとおりです。

1. アプリ開発者が**アプリリポジトリ**の**feature**ブランチで開発した個別機能を**master**ブランチにマージする
2. **アプリリポジトリ**のmasterブランチへのコミットをトリガーにDelivery Pipeline（CI用）が起動する
    1. **アプリリポジトリ**の**master**ブランチのソースコードを取得し、ビルドおよび単体テストを実施する
    2. ソースコードを元にコンテナ・イメージのビルドを実施し、IBM Cloud Container Registryの開発環境用のNamespaceにPUSHする
    3. 運用リポジトリのマニフェストファイルを更新し、**master**ブランチへマージリクエスト経由でマージする。
        1. 運用リポジトリをCloneし**pipeline**という名前のブランチを作成する
        2. マニフェストファイルに記載されているDeploymentリソースで指定するコンテナ・イメージのタグを2でビルドしたイメージのタグに更新し、**pipeline**ブランチにPUSH
        3. **pipeline**ブランチから**master**ブランチへのマージリスクエストを作成する
        4. 作成したマージリクエストをマージする
3. 運用リポジトリの**master**ブランチへのマージリクエストの更新（※）をトリガーにDelivery Pipeline（CD用）が起動する
    1. **運用リポジトリ**の**master**ブランチの**開発環境用マニフェストファイル**を取得し、IKSの開発環境へコンテナ・イメージのデプロイを実施する

*※2020/07/10現在Delivery Pipelineのトリガーを「マージリクエストのクローズ」にしていると重複して2回実行されるという障害があるため、仕方なく「マージリクエストの更新」をトリガーにしています。*

## ステージング環境
![2020-07-09 17_30_07-【ヘルスケアアプリ開発】アプリケーションの移行フロー_20200604.pptx - PowerPoint.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/efa4e3c0-32ec-c169-c2a9-8da8b6f81b5d.jpeg)

Toolchainを利用したステージング環境へのリリースフローをは以下のとおりです。

1. アプリ開発者が**アプリリポジトリ**の**master**ブランチで結合テストまで完了したソースコードを**release**ブランチにマージする
2. **アプリリポジトリ**のreleaseブランチへのコミットをトリガーにDelivery Pipeline（CI用）が起動する
    1. **アプリリポジトリ**の**release**ブランチのソースコードを取得し、ビルドおよび単体テストを実施する
    2. ソースコードを元にコンテナ・イメージのビルドを実施し、IBM Cloud Container Registryのステージングおよび本番環境用のNamespaceにPUSHする
    3. 運用リポジトリのマニフェストファイルを更新し、**release**ブランチへ**マージリクエストを作成する**。
        1. 運用リポジトリをCloneする
        2. マニフェストファイルに記載されているDeploymentリソースで指定するコンテナ・イメージのタグを2でビルドしたイメージのタグに更新し、**master**ブランチにPUSH
        3. **master**ブランチから**release**ブランチへのマージリスクエストを作成する
3. 運用担当者は運用リポジトリのマージリクエストを承認し、マージする。
4. 運用担当者はDelivery Pipeline（CD用）を手動で起動する（※）
    1. **運用リポジトリ**の**release**ブランチの**ステージング環境用マニフェストファイル**を取得し、IKSのステージング環境へコンテナ・イメージのデプロイを実施する

*※2020/07/10現在Delivery Pipelineのトリガーを「マージリクエストのクローズ」にしていると重複して2回実行されるという障害があり、ここのトリガーを「マージリクエストの更新」にしてしまった場合Delivery Pipeline（CI用）でマージリクエストが作成された時点でDelivery Pipeline（CD用）が起動してしまうため仕方なく手動で実行にしています。*

**開発環境とのプロセス上の大きな違いはDelivery Pipeline（CI用）で更新されたマニフェストファイルのマージリクエストは作成されるだけで自動的にマージされないので、運用担当者がマージする必要がある点だけです**
このマージリクエストには本番環境用のマニフェストファイルの更新も含まれるため運用担当者のレビューを矯正するためにこのようなプロセスにしました

## 本番環境
![2020-07-10 16_13_02-【ヘルスケアアプリ開発】アプリケーションの移行フロー_20200604.pptx - PowerPoint.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/2a171606-c952-5c68-cd64-9a212bb4f3eb.jpeg)
Toolchainを利用した本番環境へのリリースフローをは以下のとおりです。

1. 運用担当者は運用リポジトリの**release**ブランチの**本番用のマニフェストファイル**の内容を確認する。
2. 運用担当者はDelivery Pipeline（CD用）を起動する
    1. **運用リポジトリ**の**release**ブランチの**本番環境用マニフェストファイル**を取得し、IKSのステージング環境へコンテナ・イメージのデプロイを実施する

**本番環境ではステージング環境でテスト済みのコンテナ・イメージをデプロイするのでDelivery Pipeline（CI用）は存在しません。**
**本番用のマニフェストファイルもステージング環境のリリースフローで更新済みなので、本番環境のリリースフローは更新済みのマニフェストファイルを確認してDelivery Pipeline（CD用）を起動するのみです**

# GitOps Toolchainテンプレートの作成
[カスタムするToolchainの概要](#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%81%99%E3%82%8Btoolchain%E3%81%AE%E6%A6%82%E8%A6%81)の内容を元に各環境用にテンプレートを作成しました。
テンプレートの作成方法は以下の記事にまとめてありますので必要に応じてご覧いただければと思います。

[IBM Cloud Open Toolchainテンプレートの作成方法まとめ]()

# 作成したGitOps Toolchainの解説
ここでは今回作成したGitOps Toolchainテンプレートについて、実際にテンプレートから作成されたToolchainの画面を見ながら解説します。

## 開発環境
開発環境のテンプレートからToolchainを作成するとToolchainの構成は以下のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/dd683a5a-a3a8-7838-efc9-a5124a70845c.png)


連携するツールは以下のとおりです。

|項目名|ツール|説明|
|:---|:---|:---|
|アプリリポジトリの問題管理|IBM Cloud Git（GitLab）|アプリのGitLabリポジトリへのリンク|
|アプリリポジトリのバージョン管理|IBM Cloud Git（GitLab）|アプリのGitLabリポジトリのIssuesページへのリンク|
|アプリのビルド用パイプライン|Delivery Pipeline|作成されたアプリのビルド用パイプライン|
|運用リポジトリの問題管理|IBM Cloud Git（GitLab）|運用のGitLabリポジトリへのリンク|
|運用リポジトリのバージョン管理|IBM Cloud Git（GitLab）|運用のGitLabリポジトリのIssuesページへのリンク|
|アプリのデプロイ用パイプライン|Delivery Pipeline|作成されたアプリのデプロイ用パイプライン|

パイプラインのタイルをクリックするとパイプラインの構成が見られるので実施に実装内容を確認していきましょう。

### アプリのビルド用パイプライン
アプリのビルド用パイプラインを開くと以下のようにパイプラインの構成を確認することが出来ます。
![screencapture-cloud-ibm-devops-pipelines-e144f22b-129d-41cc-919c-dbf57495ee25-2020-07-14-12_34_56.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/caa714b6-77ce-2742-d713-a7f187c87c6e.jpeg)


ビルド用パイプラインのステージは以下の2種類のステージで構成されています。

|ステージ|ステージの説明|実行トリガー|
|:------|:-----------|:----------|
|BUILD|アプリ用リポジトリのmasterブランチよりソースコードを取得し、単体テストを実施する|アプリ用リポジトリのmasterブランチへのコミットのプッシュ|
|CONTAINERIZE|BUILDステージで取得したソースコードを元にコンテナ・イメージをビルドし、IBM Cloud Container Registryに登録する|BUILDステージが完了したらジョブを実行|

ステージごとのジョブの内容は以下のとおりです。

|ステージ|ジョブ|ジョブの内容|
|:------|:----|:----------|
|BUILD|Fetch Code|ソースコードの取得する|
|BUILD|Unit Tests|単体テスト|
|CONTAINERIZE|Check dockerfile|アプリ用リポジトリに登録されたdockerfileの妥当性をチェックする|
|CONTAINERIZE|Check registry|IBM Cloud Container Registry(ICR)のNamespaceの存在を確認し、存在しなければ作成する|
|CONTAINERIZE|Build container image|ソースコードを元にコンテナ・イメージをビルドしICRへPUSHする|
|CONTAINERIZE|Check vulnerabilities|PUSHしたコンテナ・イメージの脆弱性チェックの結果を確認する|
|CONTAINERIZE|Create MR to update manifest file|運用リポジトリのマニフェストファイルをPipelineブランチで更新し、masterブランチへのマージ・リクエストを作成し、マージを実施する|

### アプリのデプロイ用パイプライン
アプリのデプロイ用パイプラインを開くと以下のようにパイプラインの構成を確認することが出来ます。
![screencapture-cloud-ibm-devops-pipelines-8bafc2d0-de4f-47bb-a003-9f39ef53cc78-2020-07-14-12_50_52.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/9c0abb70-15b9-b9f2-9765-a94b0ffadc29.jpeg)



デプロイ用パイプラインのステージはDEPLOYステージのみで構成されています。

|ステージ|ステージの説明|実行トリガー|
|:------|:-----------|:----------|
|DEPLOY|運用用リポジトリのmasterブランチよりマニフェストファイルを取得し、開発環境のIKSクラスターへマニフェストファイルを適用する|運用用リポジトリのmasterブランチへのマージ・リクエストのオープンまたは更新(※)|
（※）本来はマージ・リクエストのクローズをトリガーとしたいが、2020/07/14現在クローズをトリガーにすると二重でパイプラインが起動される問題が発生しているため一時的にオープンまたは更新に設定している。

ステージごとのジョブの内容は以下のとおりです。

|ステージ|ジョブ|ジョブの内容|
|:------|:----|:----------|
|DEPLOY|Deploy to Kubernetes|開発環境のIKSクラスターへのマニフェストファイルの適用|
|DEPLOY|Check health|Liveness probeおよびReadiness probeへのヘルスチェックの実施|



## ステージング環境
ステージング環境のテンプレートからToolchainを作成するとToolchainの構成は以下のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/4c506abb-e06f-193a-d607-e028bec0a1bb.png)

連携するツールは以下のとおりで、開発環境のパイプラインと同様の構成です。
開発環境とステージング環境のToolchainの違いは以下のとおりです。

- ビルド用パイプライン
    - 参照するアプリリポジトリのブランチが**release**
    - コンテナ・イメージの登録先のICRの登録先が本番用レジストリ
    - 作成されるマージ・リクエストは自動的にマージされない
        - デプロイ用パイプラインを実行するにはマージ・リクエストからマニフェストファイルの変更内容をレビューして手動でマージする必要がある。
- デプロイ用パイプライン
    - 参照する運用リポジトリのブランチが**release**
    - デプロイ先がステージング環境
    - デプロイに使用するマニフェストファイルがステージング環境用


## 本番環境
本番環境のテンプレートからToolchainを作成するとToolchainの構成は以下のようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/6d90c027-6b14-e304-d5fd-8e7fa5eba040.png)

本番用のToolchainはコンテナ・イメージのビルドが不要なので連携するツールは以下のようになります。

|項目名|ツール|説明|
|:---|:---|:---|
|運用リポジトリの問題管理|IBM Cloud Git（GitLab）|運用のGitLabリポジトリへのリンク|
|運用リポジトリのバージョン管理|IBM Cloud Git（GitLab）|運用のGitLabリポジトリのIssuesページへのリンク|
|アプリのデプロイ用パイプライン|Delivery Pipeline|作成されたアプリのデプロイ用パイプライン|

ステージング環境と本番環境のToolchainの違いは以下のとおりです。

- デプロイ用パイプライン
    - 実行トリガーが手動
    - デプロイ先が本番環境
    - デプロイに使用するマニフェストファイルが本番環境用

## パイプラインのジョブで使用するシェル・スクリプトの取得方法について
各ジョブで使用するシェル・スクリプトに関しては既存のToolchainの実装に倣い直接Githubのシェル・スクリプト保管先のリポジトリから取得するようにしています。

```
#!/bin/bash
# uncomment to debug the script
# set -x
source <(curl -sSL "https://raw.githubusercontent.com/strada501/kube-toolchain-gitops-commons/master/scripts/create_mr_to_update_manifest.sh")
```
この方法の場合は誰でもスクリプトを参照できてしまいますので、外部から参照されたくない場合にはIBM Cloud Gitのリポジトリにシェル・スクリプト保管先のリポジトリを作成するなどの考慮が必要です。
IBM Cloud GitはIBMがホストしている環境上のGitLab Community Editionで構築されており、リポジトリのコンテンツを静的Webページとして公開するための機能である[GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/)の機能を使用することが出来ないか検討したところ、GitLab Pagesの機能を使用するためには[GitLab Pages Daemon](https://docs.gitlab.com/ee/administration/pages/index.html)というHTTPサーバーを別途構築する必要があるため断念しました。
また、GitLab Pipelineを使用してWebサーバーに公開することも出来るようですが、CI/CDのメニューがIBM Cloud Gitだと表示されないのでこちらも断念しました。
したがって、IBM Cloud Gitの場合はGit Cloneでリポジトリごとダウンロードする必要があります。

# GitOps Toolchainの利用方法
## 事前準備
今回作成したGitOps Toolchainはアプリ用リポジトリも運用リポジトリもIBM Cloud Gitにリポジトリが作成されている前提なので事前にIBM Cloud Git上にリポジトリを作成する必要があります。

また、Delivery Pipeline（CI用）で運用リポジトリのマニフェストファイルを更新する際のリポジトリ認証としてPersonal Access Tokenを利用する想定なので、事前にPersonal Access Tokenの作成も必要です。

詳細な手順は以下のとおりです。

### アプリ用リポジトリおよび運用リポジトリの作成
1. [IBM Cloud Git](https://jp-tok.git.cloud.ibm.com/)にアクセスしてアプリ用のリポジトリを**New Project**ボタンから作成してください。

2. [こちら](https://github.com/strada501/kube-toolchain-gitops-sample-app)で公開しているサンプルアプリケーションのコンテンツをコピーして作成したアプリ用リポジトリに登録してください。

3. [こちら](https://github.com/strada501/kube-toolchain-gitops-sample-ops)で公開している運用リポジトリのコンテンツをコピーして作成した運用リポジトリリポジトリに登録してください。

※アプリ用リポジトリおよび運用リポジトリのURLは後で使用するのメモしてください。

### Persional Access Tokenの作成
1. IBM Cloud GitにPersonal Access Tokenを発行したいユーザーでログインする

2. ログイン後に以下のようにアカウントの**Settings**をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/9d5c943c-872c-b2fb-e61b-066050303608.png)

3. 左メニューの**User Settings**より**Access Tokens**を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/77df6020-0f13-0cf3-05ce-a804222ff920.png)

4. **Name**にAccess Tokensの名前を入力し、Scopesに**api**、**read_repository**、**write_repository**を設定し、**Create personal access token**をクリックする
![screencapture-jp-tok-git-cloud-ibm-profile-personal-access-tokens-2020-07-14-17_51_27.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/2d1b60c3-dabc-9237-ef5d-d76f8b33875e.jpeg)


## GitOps ToolchainテンプレートからToolchainを作成
### 開発環境
1. [こちら](https://cloud.ibm.com/devops/setup/deploy?repository=https%3A%2F%2Fgithub.com%2Fstrada501%2Fkube-toolchain-gitops-dev.git)から開発環境のGitOps Toolchainテンプレートセットアップページへアクセスする
2. 以下の赤枠の項目を入力し終わったら、「Delivery Pipeline(2)」のタブを選択し入力画面を移動する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/3d979c68-9446-fd0d-b695-295994a4f011.png)

3. 同様に以下の項目を入力し終わったら、「作成」ボタンをクリックし、ツールチェーンを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/d7ad405c-6876-4739-4ec3-de421d8fa111.png)

4. 作成が完了すると自動的にツールチェーンの画面が表示される
![screencapture-cloud-ibm-devops-toolchains-3de7e6df-f56c-42d5-a908-b4d606ea995a-2020-07-10-19_13_33.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/f4bb4dae-9cdc-764e-0069-0544f7ee2a43.jpeg)


### ステージング環境
1. [こちら](https://cloud.ibm.com/devops/setup/deploy?repository=https%3A%2F%2Fgithub.com%2Fstrada501%2Fkube-toolchain-gitops-stg.git)から開発環境のGitOps Toolchainテンプレートセットアップページへアクセスする
2. 以下の赤枠の項目を入力し終わったら、「Delivery Pipeline(2)」のタブを選択し入力画面を移動する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/b2033b60-d4fe-0626-a20f-64eedd23ecd3.png)

3. 同様に以下の項目を入力し終わったら、「作成」ボタンをクリックし、ツールチェーンを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/efa7c616-2830-462b-735f-4418204a7628.png)

4. 作成が完了すると自動的にツールチェーンの画面が表示される
![screencapture-cloud-ibm-devops-toolchains-1fb5db9a-fed1-4c38-80c4-49055ace56a9-2020-07-10-19_17_07.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/eb3db4c6-6005-c064-55f4-2f33acb349aa.jpeg)

### 本番環境
1. [こちら](https://cloud.ibm.com/devops/setup/deploy?repository=https%3A%2F%2Fgithub.com%2Fstrada501%2Fkube-toolchain-gitops-prod.git)から開発環境のGitOps Toolchainテンプレートセットアップページへアクセスする
2. 以下の赤枠の項目を入力し終わったら、「Delivery Pipeline(2)」のタブを選択し入力画面を移動する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/30e011bf-f823-dd24-d9f0-c4c44db58699.png)

3. 同様に以下の項目を入力し終わったら、「作成」ボタンをクリックし、ツールチェーンを作成する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/93749b08-6b02-f8c6-9cbf-92ed130eed9e.png)

4. 作成が完了すると自動的にツールチェーンの画面が表示される
![screencapture-cloud-ibm-devops-toolchains-bcb9a269-51f7-4486-bbf2-cd1a414f97b8-2020-07-10-19_19_10.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/fff4cf4b-2661-83ed-ebfc-10978a19199f.jpeg)


## GitOps Toolchainの稼働確認
### 開発環境
1. 以下のURLよりツールチェーンの一覧にアクセスし、開発環境用のツールチェーンを選択する
https://cloud.ibm.com/devops/toolchains?env_id=ibm:yp:jp-tok

2. 開発環境用ツールチェーンの画面でCode列からアプリリポジトリのバージョン管理を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/6b729e81-26f1-0faf-d385-dab21eb0dc6c.png)

3. アプリリポジトリにて変更対象のファイルを選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/24320dcc-47c9-fa0d-e6d4-176c08434344.png)

4. 何かしらの変更を行い「Commit changes」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/93d2228a-ac8a-7376-e391-4f649a0f9e51.png)

5. ツールチェーンの画面に戻るとアプリのビルド用パイプラインが起動されているので、クリックしてパイプラインを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/edbc3e58-6dc5-56ac-f9bd-3731ffcfa95b.png)

6. BUILDステージが開始され、すべての処理が完了するまでしばらく待機する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/b0b3c624-04db-cacd-a2f6-95bdc4bb6e99.png)

7. CONTAINERIZEステージが成功したら、アプリのビルド用パイプラインの処理は完了なので、再びツールチェーンの画面に戻る

8. アプリのビルド用パイプラインの処理が完了すると自動的にアプリのデプロイ用パイプラインが起動するのでクリックしてパイプラインを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/8e9bedad-f044-3cb8-7a6c-7231f84eb052.png)

9. CONTAINERIZEステージが成功したら、アプリのビルド用パイプラインの処理は完了なので、再びツールチェーンの画面に戻る
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/85a1627c-bc73-5d0f-d9ef-4509a5271d5f.png)

10. DEPLOYステージが成功したら、アプリのデプロイ用パイプラインの処理は完了なので、テスト用のエンドポイントのURLを確認するため、ジョブから「Deploy to Kubernetes」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/5a1b819d-eb25-ad1c-9035-7f4db457e1c3.png)

11. ログの最下部にエンドポイントのURLが表示されているのでこのURLからアプリにアクセスする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/a9ea9d43-61ea-932e-065e-0f1f903fe5bc.png)

12. エンドポイントのURLにアクセスしアプリがデプロイされたことを確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/166cc15b-a83c-30b7-c63e-7d0d98c7e1eb.png)

### ステージング環境
1. 以下のURLよりツールチェーンの一覧にアクセスし、ステージング環境用のツールチェーンを選択する
https://cloud.ibm.com/devops/toolchains?env_id=ibm:yp:jp-tok
2. ステージング環境用ツールチェーンの画面でCode列から運用リポジトリのバージョン管理を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/eff1cd84-da66-423c-6495-2ea0a0e8d2d6.png)

3. 運用のGitリポジトリの左メニューより「Project Overview->Details->Branches」を選択する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/465b6ec1-ea18-beff-d47f-b88809e514d5.png)

4. 画面右上の「New branch」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/199a019f-f123-254b-304c-f9469fdb08c9.png)

5. 「Create branch」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/92f8ca1a-a059-c031-f650-481ceb440516.png)

6. ステージング環境用ツールチェーンの画面に戻り、Code列からアプリリポジトリのバージョン管理を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/7b718e33-b037-fb6d-f81c-5679184e88b0.png)

7. アプリのGitリポジトリの左メニューより「Project Overview->Details->Branches」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/d0d21e0d-8e47-9e91-c0f7-13ebbba6e969.png)

8. 画面右上の「New branch」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/21d0e65c-2087-265e-45e6-a14d3ebfb1e7.png)

9. 「Create branch」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/9a73618a-d1af-d5ef-f44a-28a02b9c5ec2.png)

10. アプリのGitリポジトリの左メニューより「Merge Requst」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/627937b3-b4e5-4cc0-eed1-b246bfab2951.png)

11. Merge Requstの画面右上の「New merge request」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/686b4b00-14ed-ca71-91ea-7862dc4fa94c.png)

12. Source branchに「master」を選択し、Target branchに「release」を選択した上で、「Compare branches and coninue」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/59628cbb-c326-69cc-b0be-b9bfb8d728f2.png)

13. 任意で各項目を入力した上で「Submit merge request」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/c15e4143-be1a-9437-dea1-3f40a79851dd.png)

14. 続いて画面中の「Merge」をクリックする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/0df63e4d-3f94-14ae-9506-c11e25188f4a.png)

15. Merge Requstのステータスが「Merged」になりマージが完了したことを確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/3efc8d3b-8ff1-c8b1-4e03-83a14e1595a8.png)

16. ツールチェーンの画面に戻るとアプリのビルド用パイプラインが起動されているので、クリックしてパイプラインを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/5506eaf6-ef06-ce01-3e23-7af1df22e23e.png)

17. BUILDステージが開始され、すべての処理が完了するまでしばらく待機する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/60f870a8-d212-fcc2-840e-03ef73f22f71.png)

18. CONTAINERIZEステージが成功したら、アプリのビルド用パイプラインの処理は完了なので、再びツールチェーンの画面に戻る
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/daffa174-9df9-db1f-fa20-9f258acafe17.png)

19. ステージング環境用ツールチェーンの画面でCode列から運用用リポジトリのバージョン管理を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/5dc0de9c-4d57-3c9e-1e41-1768a36b3e38.png)

20. 運用用のGitリポジトリの左メニューより「Merge Requst」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/eab80174-4c43-d42d-d26b-6471fcaf5fbe.png)

21. releaseブランチ宛のマージリクエストを選択し開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/9194203b-b4dd-8be5-9102-a5c4de0507e2.png)

22. 「Changes」タブを選択し、変更内容を確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/e256bc6b-3a7b-050e-bda0-3780b544ba70.png)

23. ビルド用パイプラインによりビルドされたコンテナ・イメージのタグが運用用リポジトリのステージングと本番のマニフェスト・ファイルに反映されているはずなので、内容が正しいことを確認する。問題がなければ「Overview」タブを選択して戻る
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/f2d56e57-819b-d101-7203-664ce363169c.png)

24. 「Merge」をクリックしマージを実行する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/3d97d1e8-19b5-1499-5e1a-21188d875abd.png)

25. Merge Requstのステータスが「Merged」になりマージが完了したことを確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/d91f736a-9d6b-120e-f858-814381386b63.png)

26. ツールチェーンの画面に戻り、アプリのデプロイ用パイプラインをクリックしてパイプラインを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/87c66bfa-0de0-9840-29b4-7f5dfe9ec3af.png)

27. DEPLOYステージの実行アイコンをクリックし、パイプラインを起動する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/186aec3a-dd4c-fce7-55d9-aa72aac683d2.png)

28. DEPLOYステージが開始され、すべての処理が完了するまでしばらく待機する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/7c088bb1-e118-2b58-9f87-4dd0f74ddead.png)

29. DEPLOYステージが成功したら、アプリのデプロイ用パイプラインの処理は完了なので、テスト用のエンドポイントのURLを確認するため、ジョブから「Deploy to Kubernetes」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/e8caa639-b664-4850-41bb-cf63c36afbe1.png)

30. ログの最下部にエンドポイントのURLが表示されているのでこのURLからアプリにアクセスする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/9baf1365-abad-c924-abda-aed27e1150be.png)

31. エンドポイントのURLにアクセスしアプリがデプロイされたことを確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/84875734-5f3c-0cf4-d214-3b31dbc5b2f9.png)

### 本番環境
1. 以下のURLよりツールチェーンの一覧にアクセスし、本番環境用のツールチェーンを選択する
https://cloud.ibm.com/devops/toolchains?env_id=ibm:yp:jp-tok
2. 本番環境用ツールチェーンの画面でCode列からアプリリポジトリのバージョン管理を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/5394ba63-6651-a659-a82e-82ac632923f8.png)

3. 運用のGitリポジトリのブランチ選択より「release」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/b8b6bc9f-d73f-5d8c-eeb6-1211703a4cc9.png)

4. ファイル一覧から「manifests/prod/deployment.yml」を開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/fa254333-d800-a7ea-65fd-0e0ae555db3e.png)

5. マニフェストファイルのコンテナ・イメージのURI（Deploymentのspec.template.spec.containers[0].image）の値が今回デプロイされるものとして妥当か確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/d599bf54-6dc0-41ca-9b2e-8c24760227ca.png)

6. ツールチェーンの画面に戻りアプリのデプロイ用パイプラインをクリックしてパイプラインを開く
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/16763112-ea1b-5446-fff6-53327b3a2e9f.png)

7. DEPLOYステージの実行アイコンをクリックし、パイプラインを起動する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/42b0bbbe-8564-076e-83cd-ae2acdace8c7.png)

8. DEPLOYステージが開始され、すべての処理が完了するまでしばらく待機する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/7aea5f89-eaed-598d-a7a6-c2c7ffffe4af.png)

9. DEPLOYステージが成功したら、アプリのデプロイ用パイプラインの処理は完了なので、テスト用のエンドポイントのURLを確認するため、ジョブから「Deploy to Kubernetes」を選択する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/5729dafe-e565-56d8-fb95-c157e22d3310.png)

10. ログの最下部にエンドポイントのURLが表示されているのでこのURLからアプリにアクセスする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/46673c47-1ddc-7a8e-df4d-f77d2387bca9.png)

11. エンドポイントのURLにアクセスしアプリがデプロイされたことを確認する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/5259/7ebaa98b-9723-ef2a-489b-415675efff63.png)