この章について

まず全体像を把握することから始めます。ここでの話は主に5,6章で効いてくるものですが、今自分が全体の中のどの部分に対して取り組んでいるのかを把握しておけるように、構成図等を示しておきます。

なお、ここではまだAWSに関する説明を行わず、構成図を元に、「全体像のどの部分をどの章で扱っていくか」を把握し、次章以降を迷いなく進めていけるようにするための章とします。

最終的に構築するインフラ構成

以下に構成図を示します。

構成図を全体像として、それぞれの章でどの部分を扱い、構築していくかを説明します。

この章ではDockerfileを作成し、イメージをビルドしてアプリケーションをローカルマシンで起動させることをゴールとします。

docker imageは、アプリケーションとその依存関係をひとまとめにした“実行可能なパッケージ”であり、これを元にコンテナが作成されます。そしてこれは配布可能なものになっています。

このハンズオンにおける「デプロイ」とは、ビルドした docker imageを実行環境（ローカル／AWS）に参照させ、アプリケーションとして動かすことだといえます。

構成図で言うと、以下の部分です。

Kubernetes（以降、k8s）という、コンテナ化されたアプリケーションを自動で配置・実行・管理するためのオーケストレーションプラットフォームがあります。

k8sではアプリケーションの状態や構成を manifest（マニフェスト）と呼ばれる YAML ファイルで定義します。このハンズオンでは、そのmanifestを効率的に整理・管理するためにhelmfileというツールを用います。

この章では、k8sの仕組みにも触れていきます。

構成図で言うと、以下の部分です（ここは微妙に表しにくいんですが、まあ大体で）。

3章で完成したmanifestをローカル環境で動作する軽量なk8sクラスタであるkind（Kubernetes in Docker）にデプロイしてみます。

kindを使えばお金もかからず、簡易的にローカルマシンでk8sの動作を確認できるため、まずはEKSにデプロイする前にお手軽ローカルで試してみましょうと言う章です。

ハンズオンのゴールからは若干それますが、構成図のEKS Clusterの部分をkindに置き換えて試してみると言う感じです。

雑ですが、構成図を改変して以下のようにあらわしてました（強引）。

3章で用意したk8s manifestを4章ではkindクラスターにデプロイしました。この章では、manifestをEKSクラスターにデプロイする準備として、インフラ構築をしていきます。

そこで、terraformというIaC(Infrastructure as Code)を用います。

AWS上にリソースを構築する手法として、マネコンをポチポチして作っていくのも１つです。しかし、企業だと「インフラリソースもコードで管理する」が主流と言っていいでしょう。

ここでは、terraformの構文にも触れながら進めつつ、主にはAWSリソースやネットワークについて取り上げます。EKS環境を用意すると言っても、「EKSだけ」用意するのではなく、必要最低限に周辺リソースも作っていきます。

5章を終えると、以下の構成図が完成します。

5章で用意した環境にデプロイしていきます。具体的には、構成図のECRにdocker imageをpushし、EKSクラスタにmanifestを適用させます。

概念的に表すと以下のようになります。

簡単のために、control plane（後述）にあるapi-serverをVPC内の「EKSクラスター」の中に書いています。実際はcontrol plane自体はAWS管理下にあり、このVPC内にはありません。その点も面白い部分でして、その辺の仕様に関しては、5章で改めて取り上げます。