Kubernetesを使ったアプリケーション開発の進め方
では日々の開発はどのように行うのか簡単に説明します。
KubernetesはKubernetes自身も含めて基本的に全てコンテナで運用されています。そのためアプリケーションサーバーを立ち上げたい時、必ずコンテナを起動する必要があります。docker build、docker pushまではDockerを使っていて馴染みのある操作だと思いますが、docker runをKubernetesクラスタで実行するイメージですね。
本番運用する場合は良いのですが、ローカルで動作確認したい場合毎回docker pushするのは面倒ですよね。ローカルのKubernetesクラスタのツール次第ではありますが、例えばkindだとkind load docker-image sample-image:latestのようにローカルのDockerイメージを利用することができます。
docker pushされたイメージはKubernetesのリソース作成時にIMAGE:VERSIONを指定することでコンテナを起動できます。例えばPodのマニフェストにspec.image: nginx: 1.14と書き、そのマニフェストをkubectl applyすることでNGINXのコンテナを起動できます。具体的な操作については連載第3回を読むと手を動かしながら理解を進めることができますので、まだ読んでいない方はぜひお読みください。
リソース作成時、毎回kubectl applyを実行するのか？
これまで、Pod作成時に毎回kubectl applyを実行するという説明をしてきましたが、これにはいくつか問題があります。
マニフェストを作成することで設定のバージョン管理やレビューが簡単になりましたが、このマニフェストの適用を手動で行うと、適用のバージョン管理やレビューが難しくなってしまいます。
そこでCIOpsやGitOpsという考え方に基づき、マニフェストを適用することが一般的です（OpsはOperationsの略です）。
CIOpsは、CIツールを利用してマニフェストの適用を行う方法です。例えば、GitHubで管理しているマニフェストのコンテナイメージバージョンを変更したとします。プルリクエストをmainブランチにマージするタイミングでGitHub Actionsを動かし、Kubernetesクラスタに対してkubectl apply -fを実行させます。GitHub ActionsというCIツールを利用してクラスタへの適用作業を行っているため、この方法はCIOpsと呼ばれます。
GitOpsは、デプロイツールがマニフェストの変更を監視し、変更があった場合に自動適用を行う方法です。
デプロイツールには以下がよく使われます。
Argo CD
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.
Argo CDはGitOps用のOSSです。元々はIntuit社（正確にはIntuit社が買収したApplatix社）が自社で開発していたソフトウェアです。
Argo CDではApplicationという名前のCustom Resourceを利用し、「どのリポジトリの」「どのマニフェストの」「どのバージョン（ex.ブランチ）の」マニフェストを「どの環境に」適用するかを指定します。Argo CD自身もKubernetes上に構築します。
Spinnaker
Spinnaker is an open-source, multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence.
元々はNetflix社が開発していたツールです。Argo CDが「Kubernetes向け」と謳っているのに対し、Spinnakerはあらゆるユースケースで利用できると言っています。そのためArgo CDはKubernetesクラスタへのデプロイのみを扱いますが、SpinnakerではDocker ImageのビルドなどCIパイプラインを構築することもできるようです。
FluxCD
Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible.
こちらもKubernetes向けのツールとなっています。GitOpsを提唱したWeaveWorks社が元々開発をしていました。現在Fluxバージョン2であるFlux v2を開発しているようです。Argo CDとかなり近いですが、Flux v2になってマルチテナンシーが可能になったことが違いの1つです。第2回で紹介したOktetoではGitOpsのチュートリアルとしてFluxが使えるので、GitOpsを体験してみたい方はこちらを参考に触ってみると良いでしょう。
CIOpsとGitOpsの違いは？
CIOpsとGitOpsについて紹介してきましたが、最も大きな違いはなんでしょうか？ Gitを使っているか否かが違いではありません！ push型かpull型かが大きな違いとなっています。2つの特徴をまとめると以下のとおりです。
- CIOps：push型。即時適用作業が実施される。kubectl applyでやっていることを自動化するイメージなのでわかりやすく直感的。
- GitOps：pull型。宣言的であるため、管理されているマニフェストが常に正しい設定となる。
GitOpsはなかなか想像しづらいと思いますが、GitリポジトリをSingle Source Of Truth（唯一正しいとされるソース）として常にリポジトリの内容がクラスタに適用されています。
どちらが正解ということはなく、メリットデメリットがあります。それぞれ所属する組織やクラスタの運用方法によってどの方法を選択するのが良いかは変わってきます。ここではこういったデプロイの手法がKubernetesを利用する上では一般的になっているということを覚えておいていただけたらと思います。
ここまでの解説で、Kubernetesにあまり馴染みのない方でも、アプリケーション開発フローのイメージが少しは沸いたでしょうか？ Kubernetes利用の有無に関わらず、CI/CDの導入は少しハードルが高いかもしれません。この連載を機に少しでも理解が深まれば幸いです。では次回最終回でお会いしましょう！
