第22章. アプリケーションを整理する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
本書を通して、Kubernetes上に構築されたアプリケーションの様々なコンポーネントについて説明してきた。 プログラミングをコンテナとしてラップし、それらのコンテナをPodに配置し、ReplicaSetsでそれらのPodを複製し、デプロイでそれらを展開する方法を説明してきた。さらに、これらのオブジェクトを1つの分散システムに集めたステートフルで実世界のアプリケーションをデプロイする方法まで説明した。しかし、実際にそのようなアプリケーションを実用的に扱う方法については説明していない。アプリケーションを構成する様々なコンフィギュレーションを、どのようにレイアウトし、共有し、管理し、更新できるのか?それがこの章のテーマである。
私たちを導く原則
アプリケーションをどのように構成するかの具体的な詳細を掘り下げる前に、この構成を推進する目標について考えてみる価値がある。 Kubernetesでクラウドネイティブ・アプリケーションを開発する一般的な目標が信頼性とAgileであることは明らかだが、これはアプリケーションのメンテナンスとデプロイをどのように設計するかにどう関係するのだろうか?以下のセクションでは、これらの目標に最も適した構造を設計する際の指針となる3つの原則について説明する。その原則とは以下の通りだ:
-
ファイルシステムを信頼できる情報源として扱う
-
変更の品質を保証するためにコードレビューを実施する。
-
機能フラグを使ってロールアウトとロールバックを行う
信頼できる情報源としてのファイルシステム
本書の冒頭で行ったように、Kubernetesを初めて探求し始めると、一般的にKubernetesと必須的に対話することになる。 kubectl run やkubectl edit のようなコマンドを実行して、クラスタ内で動作しているPodやその他のオブジェクトを作成したり変更したりする。YAMLファイルの書き方と使い方を検討し始めたときでさえ、ファイルそれ自体がクラスタの状態を修正するための道の駅であるかのように、アドホックな方法で説明された。現実には、真のプロダクション化されたアプリケーションではその逆であるべきだ。
クラスタの状態(etcdのデータ)を信頼できる情報源とみなすのではなく、YAMLオブジェクトのファイルシステムをアプリケーションの信頼できる情報源とみなすのが最適だ。 KubernetesクラスタにデプロイされたAPIオブジェクトは、ファイルシステムに格納された真実を反映したものだ。
これが正しい視点である理由は数多くある。まず第一に、クラスターをあたかも不変性のインフラであるかのように扱うことができる。クラウド・ネイティブ・アーキテクチャに移行するにつれ、アプリケーションとそのコンテナは不変性インフラであるという考え方にますます馴染んできたが、クラスタをそのように扱うことはあまり一般的ではない。しかし、アプリケーションを不変性インフラに移行する理由は、クラスタにも当てはまる。もしあなたのクラスタが、インターネットからダウンロードしたランダムなYAMLファイルをアドホックに適用して作ったSnowflakeだとしたら、それは命令的なbashスクリプトから作られた仮想マシンと同じくらい危険だ。
さらに、ファイルシステムを介してクラスタの状態を管理することで、複数のチームメンバーとの共同作業が非常に容易になる。 ...