7月6日に開催された第5回とことんDevOpsのレポートです。
今回は日本仮想化技術の遠山から「GitOps超入門 -インフラからアプリまで全てのコードをGitで管理しよう-」と題してお話しさせていただきました。最近、時々聞くようになったGitOpsという言葉。開始時のアンケートでもGitOpsに関しては勉強中という方がほとんどでした。GitOpsという概念がどんなもののなのか、DevOpsとの違いは、CI/CDとの違いはなど、GitOpsの位置付けを確認しながら、実際にGitOpsの例を見ながらどんなことができるのかを説明させていただきました。
また、Q&Aコーナーでも、GitOpsの概念を洗い出していくような質問が多かったように思います。Q&Aを通して、GitOpとはなんなのかをより理解いただけたのではないでしょうか。
振り返りも兼ねて当日の配信の様子をYoutubeでアーカイブしていますので、是非ご覧ください。当日参加できなかった方も、これを機会にとことんDevOps勉強会に興味を持っていただければと思います。また、当日いただいたQ&Aに関してもこちらのブログでまとめていますので、ご覧ください。
セミナー動画 - Youtube Libe アーカイブ
発表資料 - Speaker Deck
Q&Aまとめ
Q: GitOpsはKubernetesのシステム以外でも使えるのでしょうか？
ほとんどのGitOpsツールはKubernetes上で動いているため、結果的にKuberbetesが前提となっています。唯一、PipeCDはKubernetes以外もサポートしているので、そちらを試してみるのも良いかと思います。ただし、現時点ではほとんどのツールがKubernetesを前提としているのが現状です。
Q: ArgoCDはGitからコミットされた際の挙動をGUIツールで作っていく感じですか？
ArgoCDはアプリケーションのマニフェストなどをGitで管理して、そのコードに変更があった場合、そのコードに基づいて環境をデプロイするものです。なので、CIツールのように挙動をGitOpsツールで設定することはありません。
Q: CIツールやCIOpsとの位置付けの違いはなんでしょう？棲み分けすべきものか、共存できるのか。
CIOpsとGitOpsは、場合によって使い分けるというイメージです。GitOpsの最大の利点はCIとCDを分離できるという点です。アプリケーションソースコードのチェックやコンtげないめー字のチェック、イメージビルドまでをCIツールで従来通り行い、アプリケーションをデプロイするところはGitOpsツールを使って行うという棲み分けをする感じです。具体的には、開発会社と運用会社が違う場合などは、CIを開発会社が面倒を見て、CDをGitOpsで運用会社が面倒を見ると言った運用すると言った形態が一番GitOpsを活用できるのではないでしょうか。
登壇者注:
昨日の説明がわかりにくかったと思いますので、追記します。CIOpsとGitOpsはどちらも「コードベースでアプリケーションのコード解析、セキュリティチェックなどを行い、テストに合格したアプリケーションをデプロイして実行する」という面では同じです。違いはCIOpsはCIツールを使って1から10までを処理するという面です。GitOpsはGitOpsツールを通じて、Gitソースを元としてデプロイだけを専属してやるものです。前準備部分はCIツールを行うなどして対応します。「CIOpsはGitOpsよりフローがシンプルなのでわかりやすいし、目的も達成しているから良い」と思う反面、デプロイにCIツールを使うということは、CIツールにKubernetesのアクセス情報（kubeconfig）を提供する必要がある点、Kubernetes APIへのアクセスを許可する必要がある点にセキュリティ上のリスクがあるという懸念があります。デプロイしたアプリに問題があってロールバックしたいと言った場合、CIOpsのやり方では簡単に元に戻すことはできません。
セキュリティのことを考えると、デプロイ先がKubernetesならばCIOpsよりもGitOpsを技術として採用した方が良いと思います。一方で、デプロイ先がKubernetesではない場合は従来のやり方でCI/CDを行うと良いと思います。
CircleCIとArgoCDを組み合わせて使う方法をCircleCIのエンジニアの方がブログで紹介していたりします。CIツールについては好きなものを使うにして、理想はこれだと私は考えます。
Q: ArgoCDでテストする際は、コミット後にKubernetes上でコンテナ立ててする感じですか？
ArgoCDではアプリケーションをデプロイするためのものなので、テストに関しては従来の手法でArgoCDの外で行っていく形になります。CIの方でアプリケーションのテストやコンテナのビルドを行い、その変更を元にデプロイを行うのがArgoCDの役割になります。
ArgoCDは複数のクラスターを作ることができるので、End-to-EndのテストをするときなどはArgoCDでテスト用の環境を作って、そこでテストを実施することも可能です。
Q: デプロイ先やデプロイ方法の変更はどのように行うのでしょうか?
ArgoCDの場合、デプロイ先はあらかじめArgoCDにデプロイ先のクラスターを複数登録しておくことができます。アプリケーションを設定する際にデプロイ先を指定することで、任意のクラスターにデプロイすることができます。他のGitOpsツールの場合は、yamlファイルに記述しておくことで、デプロイ先を指定できるものもあります。
デプロイ方法の変更は想定していないGitOpsツールもあるので、基本的には新しいアプリケーションとして作り直す方が良いです。
Q: 表示いただいていたGitOpsのフローについて、ArgoCDがクラスタ内のPodを最新化するトリガーはコンテナレジストリに対するイメージのプッシュという理解でよろしいでしょうか?また、特定のリポジトリに特定のタグがついたコンテナイメージだけを対象にする、などの利用方法は可能なのでしょうか?
Argo CDというかGitOpsツールは、Git上のIaCの変更に従ってアプリケーションコンテナーをデプロイ（上書き）します。すでにクラスターで動いているものをアップデートするのではなく、上書きします。イメージのプッシュの仕方についてはCIツールの設定でいかようにもできるかと思います。
Q: GitOpsはどういった素性の開発プロジェクトで活かせるでしょうか？さきほどCIとCDを分離した体制～のようなお話もありましたが、その他にも見解があればお聞かせください。「こういうプロジェクトはDevOpsのほうが良い」みたいのもあれば知りたいです。
Kubernetes上でアプリケーションを稼働させるのであれば、現段階ではGitOpsが最善だと思います。特に、セキュリティ面でクレデンシャルの管理などはGitOpsの方が優れていると思います。逆に、デプロイ先がKubernetes以外の場合は、従来通りのCIツール主体のDevOpsの方が良いと思います。
Q: セキュリティという観点で、コンテナの静的解析などはGitOpsとして考えるべきでしょうか？
GitOpsではあくまでデプロイするだけなので、コンテナイメージの解析（セキュリティ脆弱性とバグの洗い出しや動作確認）などは、事前にCIのパイプラインの中で実行しておく必要があります。クラスターですでに動いているアプリケーションについても、CIツールなどを通じてセキュリティチェックを定期的に行い、コンテナイメージに脆弱性が見つかった場合は新しいアプリケーションイメージを作成し、動作確認した上で新しいアプリケーションとしてデプロイするようにします。
Q: GitOpsを学習するのに適した教材はなんでしょうか？
Kubernetesの勉強会やセミナーなどで、GitOps関連のネタがたくさん提供されていますので、そちらを一通り見てみると良いと思います。その上で、さまざまなGitOpsツールを比べてみると良いと思います。
Q: 保守開発エンジニアからSREを目指して転職・学習中なのですが、おすすめの学習ロードマップなどありますでしょうか？学習例としては、ECS+Github Actions+Terraform -> EKS+Terraform+Github Actions(現在学習中)
公式のドキュメントを見ていって、その上でわからない事があれば書籍を見るような流れが良いかと思います。最近では公式ドキュメントや公式の学習サイトが充実してきているので、まずはそちらを活用することをお勧めします。
