コードとしてのポリシー

第11章. PaCとコードとしてのインフラ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

最後の数章では、KubernetesでPaCがどのように使われているかを探った。第1章で紹介したPaCの選択基準に照らして、いくつかのソリューションを調査した。Kubernetesの章における私のゴールは、あなたが評価できるソリューションを提示し、その中からあなたのニーズに最適なものを選択できるようにすることだった。どのソリューションにも長所と短所があり、個人的には、他のソリューションよりも優れている、より成熟していて機能的なソリューションもあると思う。しかし、決断を下すのはあなた自身であり、私はあなたが決断を下すための出発点を示したのだ。

この章では、Kubernetesを越えて他のPaCユースケースに目を向け始め、PaCがコードとしてのインフラ（IaC）のプラクティスをどのように改善するかから始める。この章では主にAWSにおけるIaCに焦点を当てる。

Kubernetesを完全に放棄する前に、Kubernetes PaCソリューションの最も重要な部分、 APIサーバのリクエストフローを覚えておいてもらいたい。

第4章で紹介し、図11-1に示したKubernetes APIサーバのリクエストフローは、Kubernetesクラスタに予防的コントロールを適用するネイティブな手段を提供するため、Kubernetes PaCソリューションの最も強力な側面である。

図11-1. Kubernetes APIサーバのリクエストフロー

変異と検証を行うウェブフックをPaCソリューションに統合することで、Kubernetes APIサーバのリクエストフローは、データが永続化される前に、データ入力の変換と検証というよく知られたパターンを適用する。 これらのパターンは、少なくとも1980年代のオリジナルのクライアント、サーバモデルと同じくらい古いものであり、さらに私は1990年代から2000年代初頭にかけてLotus Notes、Dominoアプリケーションを構築したときに使っていた。

入力変換と検証の点をあまり強調したくはないが、この機能と、（検知的あるいは反応的とは対照的に）予防的コントロールを構築する上でいかに重要であるかについて、あえて強調しておきたい。この予防的なスタンスは、プラットフォームやシステムを問わず、比較的ユニークなものである。IaCと、PaCがIaCにどのように適用されるかを探求するために進むにつれて、予防的、検知的、反応的コントロールと、Kubernetesとは異なり、IaCにおける予防的コントロールが、リソースがIaCによって適用される場所から上流で、非ネイティブ実装によってほとんど達成される方法について議論する。

PaCをIaCでどのように使うことができるのかに飛び込む前に、コードとしてのインフラを定義し、探求し、なぜそれが現代のインフラのデプロイと管理にとって重要なのかを理解しよう。

コードとしてのインフラ

第1章では、EaC（Everything as code）という概念を紹介し、この概念によって、リソースやポリシーをマシン読み取り可能なコード成果物として定義し、適用する方法がどのように変わったかを説明した。 ...