GitOpsがDevOpsで顧客が抱える問題点を解決する方法

このブログでは、**GitOps**がクラウドネイティブで作業する際の全体的なCICDの効率化にどのように役立つのか、また**DevOps**で顧客が抱えている課題点を解決するためにどのような方法があるのかを紹介しています。

*本ブログは英語版からの翻訳です。オリジナルは[こちら](https://www.alibabacloud.com/blog/how-gitops-is-solving-customer-pain-points_595155)からご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。*

執筆者Liu Sheng

アップグレードサイクルが遅い、インフラが肥大化している、障害が見つかりにくいなど、クラウドに関わる従来のアプリケーションに共通する課題を解決するために、[クラウドネイティブ](https://www.infoworld.com/article/3281046/what-is-cloud-native-the-modern-way-to-develop-software.html?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)というコンセプトが生まれました。

クラウドネイティブ は、アプリケーション開発の効率を向上させ、企業の組織構造を変えるのに役立ち、企業の全体的な意思決定にも影響を与えることができます。クラウドネイティブアプリケーションは、今日のクラウド空間ではすでに動きの速い激流になりつつあります。例えば[コンテナの世界](https://www.docker.com/resources/what-container?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)では、[Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)は、アプリケーションサービスをデプロイメントやデバイスクラスなどの複数のリソースタイプに抽象化できるクラウドネイティブアプリケーションでも共有されているポータブルモデルを提供しているため、コンテナのオーケストレーションや管理運用のコミュニティ標準となっています。このような状況の中で、コミュニティ全体で新たに注目されているのは、従来からDevOpsが関与していた開発プロセスをCloud Nativeで効率化し、より高いパフォーマンスレベルを実現するにはどうすればよいのかという点です。多くの顧客にとっての答えは、Cloud NativeアプリケーションでGitOpsアーキテクチャを使用することです。

#DevOpsに共通する課題
より新しめの[GitOps](https://www.weave.works/blog/what-is-gitops-really?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)と比べると、[DevOps](https://devops.com/?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)には少し馴染みがあるかもしれません。当初、DevOpsは開発、テスト、運用の各部門間の障壁を取り除くことを目的としており、ヒューマンエラーを最小限に抑えつつ、アプリケーションのバージョンの反復効率を改善することを目指していました。これらの改善は、プログラムされたスクリプトと結合された自動化の拡大使用によって強化されました。今では、軽量で標準化された機能を持つコンテナ技術 - クラウドネイティブの時代に - DevOpsは、自動化によってより良い効率性を持ち帰るために、これまで以上に力を与えられています。テクノロジーがどのように更新され、反復されても、DevOpsの主な核心的な要求は変わりません。さて、GitOpsは単純にDevOpsの論理的な延長線上にあります。その中核には、アプリケーションをより効率的かつ安全にリリースするという目標があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/2548757b-46a1-68c1-d5b2-734254fcb41a.png)


他の話に進む前に、まずはDevOpsで働くユーザーの課題点をいくつか見てみましょう。

###課題点1：非差分アプリのリリースの難しさ
これらの課題点のうち、1つ目は、DevOpsを利用して環境スタック内のアプリケーションの非差分リリースを自動的に推進する方法にユーザーが苦慮していることでしょう。DevOpsでは、通常、テスト環境、本番環境、プレリリース環境の3つの環境があります。アプリケーションに対して、通常のシナリオは、対応する環境に異なるブランチをデプロイすることです。例えば、マスターブランチは通常オンライン環境にデプロイされ、最後のブランチはプレリリース環境にデプロイされ、他の開発ブランチはテスト環境にデプロイされます。現在のところ、異なるジョブを作成し、異なるソースコードブランチを引っ張ってきて異なる環境にデプロイしたり、同じジョブを使用し、異なるビルドパラメータを追加してビルドとリリースの方法を決定したりすることがほとんどのプラクティスとなっています。しかし、これらのプラクティスは管理が容易ではないため、初心者にとっても経験豊富なユーザーにとってもかなり大変なものです。次の図のような手順を見てみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/aaa3f2a8-b892-deb3-4521-88bf8dbaa490.png)

###課題点2：厳格なアクセスコントロール
多くのユーザーが抱える第二の問題点は、一般的に本番環境のリリース権限を厳密に管理する必要があり、通常はアプリケーション管理者かO&M管理者のみが本番リリース権限を持っていなければならないことです。いくつかの顧客とのやりとりの中で、私は、同じ CICD 環境に異なるジョブを作成し、ロールアクセス制御ポリシーに基づいてこれらのジョブを分離し、管理者権限を持つ担当者だけが本番リリースに使用されたジョブを見ることができるようにするという実装方法があることを知りました。しかし、より直接的で複雑ではない方法は、それほど厳密ではないアクセス制御に対応するために、本番用リリース専用のCICD環境を作成することです。しかし、この方法も完全ではありませんが、リソースを浪費し、アプリケーションの反復処理の頻度を減らすことができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/813f18aa-65cf-fcec-3aa7-1d5e3852794e.png)

###課題点3：反復回数が増えにくい
3つ目の課題点は、ユーザーがアプリケーションの反復回数を増やし、新規事業や革新的な事業の拡大に集中することが難しいと感じていることです。この困難さの理由の1つは、開発者が、実行中のアプリケーション間の同期とフィードバックプロセス、またはこれらのアプリケーションのテスト結果にギャップがあることを認識していることです。これに加えて、オンラインビジネスが問題に遭遇した場合、問題を迅速に発見し、再現し、ロールバックする方法を見つけ出す必要がありますが、このモデルではそう簡単ではありません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/cfd626d1-cc58-2279-67c8-c56f31c578b2.png)

###GitOps の仕組み
この3つの課題点はすべて、ユーザーとのコミュニケーションについて学んだものです。では、これらの課題点を再確認して、[GitOps](https://www.weave.works/technologies/gitops/?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)モデルがどのように設計され、開発プロセス全体をどのように改善することができるのかを見てみましょう。

ここでは、GitOpsリリースモデルを設計する際の核となる要求をいくつか挙げてみたいと思います。最初の要求はバージョン管理でした。私たちは、リリースされた各アプリケーションのバージョン番号を[GITコミットID](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)と関連付けられるようにしたいと考えていました。これには、各変更の履歴を追跡できるという利点があり、その結果としての不具合をより迅速かつ容易に発見し、修正することができます。2つ目の要求は、より良いベースライン管理システムです。ベースライン管理システムの2つのタイプについては、このブログの後半で詳しく説明します。3つ目の要求は、リリース許可管理とセキュリティ承認プロセスを含む、安全なリリースをより良く実装する方法です。最後の要求は、開発者が迅速にフィードバックを得られるようにする方法です。以下に、これらの要求を簡単にまとめてみました。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/f9907007-29d9-7037-2294-a263a8c46363.png)

###より簡単で集中的なバージョン管理
最初の点を論じると、GitOpsの核心的な考え方は、アプリケーションシステムの宣言的なインフラストラクチャとアプリケーションを[Gitリポジトリ](https://blog.axosoft.com/learning-git-repository/?spm=a2c65.11461447.0.0.7b5b2057UC3MuF)に格納することです。アプリケーションへの操作変更はすべてGitリポジトリの更新から来ており、これがGitOpsという名前の由来でもあります。これにより、全体の構造をシンプルにすることができます。実は、以前はDevOpsではこのようなことができませんでした。アプリケーションを構築してデプロイするためのスクリプトや設定ファイルを、アプリケーションのソースコードと同じリポジトリに保存することが出来ますが、これには 2 つの問題があります。開発者はデプロイスクリプトや設定ファイルを保守する必要があるため、製品開発に集中できない可能性があります。次に、デプロイメントスクリプトには環境の機密情報が含まれていることがあり、十分なセキュリティが確保されていないことです。そのため、管理のためにアプリケーションのソースコードリポジトリとビルドリポジトリを分離する必要がありました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/975523a7-f68a-52ee-6e64-96a77365bb62.png)

###柔軟でシンプルなベースライン管理
次に、ベースライン管理について説明します。ベースライン管理には、環境スタックベースラインと呼ばれるものがあります。図のように、本番環境ではマスターブランチのコードのみをデプロイし、プレリリース環境では最新ブランチのコードのみをデプロイし、プレビュー環境ではそれ以外の開発ブランチをデプロイするという設定です。これにより、ここでのプレビュー環境はテスト環境としても機能します。しかし、同時に、開発ブランチがテストと検証に合格し、最新ブランチにマージされた後は、その都度、テスト環境が動的に破壊されます。これなら、Kubernetesコンテナクラスタでも簡単に実装できます。

しかし、当然のことながら、特定のシナリオでは異なるポリシーを使用することができます。言い換えれば、ベースラインポリシーは非常に柔軟性に富んでいます。このベースラインは、小さなベースラインと呼ぶことができます。これは、プレビュー、プレリリース、および本番環境でのアプリケーションの進歩を管理するための中心的な方法として使用されます。大きなベースラインは、オンラインリリースのバージョンを管理するためのもので、オンラインで障害が発生したときに、前の安定バージョンに素早くロールバックできるようにしてくれます。これは本番リリースの管理では欠かせません。GitOpsでは、正確な "git commit "まで障害を素早く見つけ出すことができます。これらのベースラインをよりよく可視化するために、次の図を考えてみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/a33b4546-84db-cde4-bdcb-e058b98ab485.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/8704d355-5ebe-3005-6753-ebe970745aad.png)

###よりシンプルな権限管理システム
では、GitOpsに関わるアプリケーションリリースプロセスの権限管理とセキュリティ承認の仕組みを簡単に見ていきましょう。GitOpsにおける権限管理は、コードのマージプロセスを制御することで実装されているとまとめることができます。このモデルでは、開発者、つまり管理者ではない人は、JenkinsのようなCICD環境のための特別なアクセス権限を持つ必要はありません。開発者はログを閲覧するための権限が必要なだけで、これは非常に単純化されています。Git 側では、開発者はコードを開発ブランチにプッシュする権限を持つだけでなく、コードを最新のブランチにマージするために必要な権限、具体的には MR/PR を提出するための権限を適用することができます。開発者が新しいMR/PRを作成した後、ビルドがトリガーとなってアプリケーションをプレビュー環境にデプロイします。管理者は、新しいブランチのビルドとデプロイが一連のテストと検証に合格したかどうかを確認することで、このMR/PRを受け入れるかどうかを判断します。管理者がMR/PRの合否を受け入れた後に、最新のブランチコードを再構築し、プレリリース環境に再デプロイすることで、MR/PRの合否により、アプリケーションのリリースセキュリティ承認の目的を達成します。これがどのように機能するかの全体的な観点から、この図をチェックしてみてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/b35ee3aa-9a73-a336-dd3f-630c507dbfee.png)

###フィードバックの高速化システム
最後に、GitOpsを使ってチームメンバー間の相互作用を実現し、フィードバックを素早く得る方法についてお話しましょう。これには2つの部分があり、1つはソースコードをプッシュした後、開発者がメールやDingTalk、Slackのようなものを通じてリアルタイムでビルド結果を得ることで、自分のアプリケーションをより効果的かつ迅速に開発・テストすることができるというものです。もう一つは、開発者が自動テストのフィードバック、アプリケーションのプレビューリンク、他のチームメンバーからのコメントをMR/PRページで見ることができるという点です。以下は、このプロセスを可視化したものです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/3e908796-457b-0bba-3365-2de39314e8ca.png)

###GitOps: 全体的なアーキテクチャ
ここから先の図は、GitOpsを利用して異なるKubernetesクラスタへのアプリケーションのリリースを管理するための全体的なアーキテクチャと時系列の図です。まず、アプリケーションのソースコードとビルドのソースコードが分離されています。上部に点線が見えるようになっています。点線の上の部分は一般的な開発者から見える部分で、この部分で操作する権限を持っています。残りの部分は管理者が操作する権限を持っています。緑の部分はJenkinsのパイプラインタスクです。開発者はJenkins環境でジョブを作成したり、ジョブをビルドしたりする権限はなく、ジョブをビルドするためのログを見る権限しかありません。この一般的なアプリケーションはGitリポジトリにあります。

異なるブランチを持ち、一定のセット関係を持っています。各ビルド(preview-pipelineやprod-pipelineなど)は別のGitリポジトリから行われ、そこには何らかの情報が保存されています。その情報を見ることができるのはアプリケーション管理者だけで、一般的な開発者はその情報を見る権限を持っていません。続いて、アプリケーションのリリース環境スタックを設定する必要があります。この例では、プレビュー環境、プレリリース環境、本番環境を設定しています。プレリリース環境と本番環境でのアプリケーションのリリースには、管理者のセキュリティ承認が必要です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/62b3e29f-6bf1-4e54-1039-f285f6e3f04d.png)

最後に、時系列図です。開発者が新しい機能を投稿し、最新のブランチを指すMRを作成します。そして、MRを作成するというアクションがpreview-pipelineのビルドのトリガーとなり、ビルドはpreview-pipelineのビルドリポジトリを引っ張ってきます。ビルドリポジトリには、ビルドスクリプトとデプロイする環境の情報が格納されています。

その後、自動ビルドプロセスが実行されます。まず、ビルド、静的コードテスト、単体テストのためにアプリケーションソースコードリポジトリからアプリケーションソースコードを引っ張り出し、テスト結果をMRにフィードバックします。次に、コンテナイメージをパッケージ化し、イメージリポジトリにプッシュします。最後に、ファイルを介してアプリケーションをKubernetesクラスタにデプロイし、機能テストを行います。テスト結果もMRにフィードバックされます。デプロイ後、関連するアプリケーション情報を収集し、DingTalkを介して開発グループに送信します。DingTalkの通知を受け取った後、開発者はリンクをクリックしてアプリケーションの状態を見ることができます。問題が存在する場合は、アプリケーションを再開発して再提出し、前のプロセスを繰り返すことができます。問題がない場合は、管理者にコードを承認して最新のブランチにマージするよう依頼できます。最新のブランチとマスターブランチが更新されると、前回のビルドプロセスと同様のプロセスが起動し、アプリケーションをプレリリース環境と本番環境にプッシュします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/647921/8ee67056-ce59-86d1-0cf0-c308119127f0.png)

*アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
[アリババクラウドジャパン公式ページ](https://www.alibabacloud.com/ja)*