こんにちは。
ALH 開発エンジニアのREIYAです。
今回は、仮想環境構築ソフトウェア『Docker』を簡単に解説します！

結局何してるの?

時代の変化です。もっとこうしたらええやんがDockerの時代を呼びました。
おそらく様々な現場で、以下が当たり前でした。

これは1つの大きなシステムに対して1つのVMリソースをまるごとあてがっています。まぁいいんですけど、、
昨今、マイクロサービスが流行っており、AWSでもマイクロサービスを推奨している感じです。

そこで、複数の小さめなサービスを組み合わせて運用したいというときに
1つのVMをマンションとし、部屋割りをしてアプリを複数運用したらいいじゃんという、まぁVPSみたいな発想を構築済み環境を丸ごとお届けが目的だったDockerコンテナで部屋割りしてやろう
という使われ方で実現してる感じです。

元来のDocker

VMと違い、ホストOSのカーネルをコンテナ間で共有するので、ここにあるように軽量ながらも、OSに依存しないコンポーネント化、カプセル化、オブジェクト指向、、、etcが実現できるという素敵アイテムです。
もろこのコンテナのイメージを持てばよい。

増えまくった結果

コンテナ自体めっちゃいいじゃん！！！じゃあいっぱい組み合わせて使おうぜ！！
ってなるでしょ
そうなると、コンテナ間で通信したりすることになる。例えば
コンテナ1がJavaアプリ、コンテナ2がCアプリで、互いにlocalhostで起動したとして、ホスト上のポートを使って通信する。

2個だからまだいいが、これがいっぱいあるとポートがぐっちゃぐちゃになる。
じゃあ接続情報であったり、コンテナの依存関係たちを綺麗にまとめちゃおう！
ということで、
Pythonがインデント最強！括弧なんていらねぇ！で流行ったように
同じような書き方のymlまたはyamlファイルで定義する発案がなされる
こんなかんじ

DockerCompose

DockerComposeという、Docker強くしてやるぜヤツを使うとymlで複数コンテナを一括定義できて、

こんな感じに、より簡単にまとめられるようになる
ただ、コンテナ1つはやっぱりパソコンなのである
いくらマイクロサービスといってもアプリによって、サイズが違うから
全部のコンテナが同じサイズでは、無駄があったり、サイズ不足があったりする

それに冗長化構成したければ、これ複数枚書くの。。。？
ただ複数コンテナを一括定義できるだけじゃたりない！！もっと便利にしたい！！わーわー！！

オーケストレーション

はい。人類はわがまま。Dockerを極めようぜという猛者たちのおかげで
コンテナオーケストレーションツールが台頭しました。
これはコンテナのスケーリングやクラスタ構成などを自動(設定できるが)でガツガツやってくれる便利ツール。
代表的なのがKubernetesです。当初Googleが作って、いまは別の会社が開発してます。
みんな大好きGoogleが作ったんだから両手あげて飛び込みましょう。Googleは世界征服してます。
ここまで具体的なことを一切書きませんでしたが、一連の歴史を理解したうえでkubernetesを使いこなせればよいですね。

Kubernetes、なんてよむんだ

私の周りではくばねてぃすって言ってる人多いです。
開発者が言うにはにはクーべネティスで、略してk8sという表記も多く使われています。
色んな理由で、あんまりこの言葉をいうことは少なかったりします。

これはなに?

前半では、Docker便利じゃん→複数コンテナだる...→kubernetesええやん！まで紹介しました。
その続きです。

弱点

Kubernetes自体、導入してyml書いてコマンドぽちーしたら、いい感じにコンテナ達をクラスタとかで立ち上げてくれるんですが
じゃあ自分のサーバに入れてみよう！となった際、結構いろんな制約があります。
わたしはCentOS7でこれとかを試しましたが、契約してるサーバのメモリが1GBで足りずだめでした。4GBだっけかが必要らしく、公式によるKubernetes稼働要件はこう。

まぁとにかくめんどくさいんです。複雑だし。
ではどうする？

そもそもクラウドの時代

どうせみんなAWS、Azure、GCPとかを使ってる。
これらは、AWSなら、AWS側からAWS用のMySQLサービスを提供してたり、AWS用のPostgreSQLを提供してたり、AWS用のNAS (S3)を提供してたり、と
もとからお得パックがはいってますよね。

マンションの部屋借りたら元からお風呂ついてるみたいなこと。
アプリ開発に必要なインフラは、お風呂にシャンプー置くラックを用意したり、シャワーヘッドが不満だからもうちょい優しいヘッドに変えたり、というかんじ。

そんなかんじで、AWSがkubernetesをもともと用意しています。ほらこれ

EKSを使う

そも、Kubernetesはコンテナをオーケストレート、というかいい感じに調整するために
Kubernetes自体が大量のIPアドレス(デフォで111個とか)を占有し
Kubernetesの確保したリソースの内部にクラスタを構成、中にコンテナを内包し、持ってるIPをDHCP的に割り当てます。
なんていうか、JavaのVMがメモリを確保して、その中でEdenやOldに分けてGCしてるのと同じ。

Nodeも複数持てます。
Kubernetesでの用語はこちらなどにまとまってるので見てみてね。

AWSやAzureとかにて、EKSとかAKSを作成ぽちーすると、まずはリソースを作成します。
作成されたリソースのアドレス範囲は、例えば192.168.100.0/24とかでマスクしてください。
最低必要なサブネットマスクはたぶん25。

あとはkubernetesの設定用のymlを作成して、
kubectl apply的なコマンドぽちーしたら、OK。
コンテナのIPは自動で割り当てられちゃうので、DNSを貼って、コンテナ名でアクセスするなり、Nginxでうまいことリバプロする必要があります。
そう、Nginxでうまいことリバプロする必要があります。
大事なことなので2回書きました。

そうなんです、Nginxでうまいことリバプロする必要があるんです（3回目）。
だからKubernetesはもともとIngressというヤツをもってるんです。正体はただのNginx。

この記事では以下の図で説明していますが
最終的にパソコンからクラウドのIngressのIPにアクセスし、名前解決して各Podのコンテナにアクセスし、画面を見るなりAPI実行なり、という仕組みになります。
IngressのIPは外向けで、PodのIPは外からはどうでもいいようにするんですね。

なので、今までの

というわけです。時代は変わりました。

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓　採用サイトはこちら　↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓　ALHについてはこちら　↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓

↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓　もっとALHについて知りたい？　↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓