この記事でまとめること
こちらを元に勉強いたしました。最低限、覚えておくべきことをつらつらとまとめます。
Docker/Kubernetes 実践コンテナ開発入門
コンテナの押さえるべき基本事項
コンテナとは
ホストOS上に論理的な区画（コンテナ）を作り、アプリケーションを動作させるのに必要なライブラリやアプリケーションを一つにまとめ、あたかも個別のサーバーのように使うことができるようにしたもの
仮想化マシンとの比較
●「仮想化している対象が異なる」ということを理解しておく
コンテナ管理ソフト（dockerなど）が仮想化するのは「コンテナ」で、仮想化マシンが仮想化するのは「OS」である。コンテナを用いる環境ではホストOSのみが必要である一方、仮想環境ではホストOSに加えゲストOSも必要となる。それゆえにコンテナ環境では、仮想環境に比べてオーバーヘッドが少ない。
オーバーヘッド：仮想化を行うために必要となるCPUリソース/ディスク容量/メモリ使用率のこと
ハイパーバイザー：ハードウェア上に仮想化を専門に行うソフトウェア（windows:Hyper-Vなど）
●システムリソースの使い方が違う
仮想環境では、ホストOS（もしくはゲストOS）上で複数のアプリケーションを動かすのが常であるため、環境下のミドルウェアやライブラリのバージョンの統一を管理する必要がある。
一方で、コンテナ環境下においては、簡単にアプリケーションを独立化することができるため、システム環境のバージョン管理は各々ですれば良い。
継続的デリバリーの底力
アプリケーション開発において「開発」→「テスト」→「ステージング」→「プロダクションリリース」のウォーターフォールが基本であるが、各々の工程で開発環境化を統一する必要がある。「開発」「テスト」で上手く動作したとしても、提供先での環境とマッチしていなければ、サービスリリースは不可能である。
コンテナ管理ソフトを活用すれば、コンテナイメージの雛形による「環境の統一化」を容易に実現でき、環境の変化に対しても悠々と対応できる。
開発からプロダクトリリースまで首尾一貫してデプロイできる、という高い継続的デリバリー力を持っている。
また、ライブラリのバージョン管理やリソースの構築などに時間を省く手間がなくなり、開発に重きを置けるという点も非常に魅力的である。
ステージング：システムを公開する手前の段階で、実際にサービスを提供する環境（本番環境）とほぼ同じ環境にシステムを反映させ、動作や表示などの最終確認を行う段階、もしくは環境のことである。
参照：https://codezine.jp/article/detail/11336
Docker
コンテナ管理ソフト「Docker」の基本機能
大まかにdockerユーザーが主体的に行うことは以下の3つ。
Build：イメージを作る機能。インフラ構成情報のコード(dockerfile)から作成。
Ship：イメージを共有する機能。
Run：コンテナを動かす機能。
上記の機能を動かすコンポーネントとして、以下のようなツール、エンジンが動いている。
DockerEngine : イメージの生成やコンテナの起動などを行うコア機能
DockerRegistry : Dockerイメージを公開/共有するためのレジストリ機能
DockerCompose : 複数のコンテナ環境を一元管理するツール
DockerMachine : クラウド環境にdockerの実行環境をコマンドで自動生成するためのツール
DockerSwarm : 複数のDockerホストをクラスタ化するためのツール
Dockerの動く仕組み
- ネットワーク構成
・コンテナには仮想NICが付属
・dockerをインストールした時点で、ホストsあーバーの物理NICとdocker0仮想ブリッジが連結する
・単一ホスト上のコンテナ間の通信は、仮想ブリッジを経由して行われる
・コンテナを実行するとプライベートIPアドレスがコンテナeth0に自動で割り振られる。
・外部ネットワークとの通信を行うときは、NAPT昨日を使っている
このイメージ図を頭に入れておくとコンテナ内外通信のイメージがつきやすい。
Namespace : コンテナを区画化する技術
→例：グループごとにリソースを制限することで、特定のコンテナがリソースを使い尽くして他のコンテナに影響を与えてしまうことを防ぐ。
Cgroups : リソース管理
→親子関係のGroupに分けて、子が親の制限を超えるような設定を行うことができないようにする。
NIC : ネットワークインターフェースコントローラー
→コンピュータなどの機器を通信ネットワーク（LAN）に接続するためのカード型の拡張装置
ethX : イーサネットのポート。イーサネットとは、ネットワークやコンピューター間での通信モデル TCP/IPプロトコルのネットワークインターフェース層に対応する有線の規格。
ネットワークブリッジ：1台のパソコン（複数の有線LAN端子や無線LANアダプターを搭載するパソコン）をハブのように利用できる機能
Dockerのインストール
こちらなどを参照する。
https://qiita.com/kurkuru/items/127fa99ef5b2f0288b81
webサーバーを動かすには、こちらなどを参考にする
https://qiita.com/mtakehara21/items/d7be42cf12772f3ada25
複数のコンテナ管理
・以下にチュートリアルあり
https://github.com/asashiho/dockertext2.git
※バージョン指定
compose定義ファイルのバージョンとdockerEngineのバージョンが合っているかどうか確かめる。
version: '3.3' #versionの指定
services: #構成するサービスを列挙
# WebServer config
webserver:
build: . #カレントディレクトリにある「dockerfile」をビルド
ports:
- "80:80"
depends_on:
- redis
# Redis config
redis:
image: redis:4.0
以下より、docker-compose.ymlに従い、コンテナを構成
docker-compose up
ブラウザからlocalhostのポート80版にアクセスするとサンプルが以下のように動作する
以下より、docker-compose.ymlに従い、コンテナを停止
docker-compose stop
YAML : 構造化データを表現するためのデータフォーマット
マルチホスト環境とクラスタリング
ホストマシンでのdocker環境を構成してきたが、ホストマシンで障害が起きてしまうとサービスは停止してしまい、可用性、冗長性を担保できない。
そのためにはdocker machineを用いる。
docker machine : ホストマシン/クラウド/仮想環境にdockerなどの実行環境を作成できるコマンドラインツール。
可用性：システムが継続して稼働できる度合いや能力のこと。
冗長性：耐障害性を高めるためにネットワークを含むシステム全体を二重化して予備システムを準備すること。
Kubernetes
クラウド環境でのdockerオーケストレーション
dockerコンテナは開発環境などのように一台のマシンで稼働させるときは、手動で導入できる。しかし、マルチホストで構成された本番環境をクラスタ構成で稼働させるには、コンテナ起動/停止などの操作だけでなく、ホスト間のネットワーク接続やストレージの管理、コンテナをどのホストで稼働させるかなどのスケジューリング機能が必須である。これを実現するのが「kubernetes」である。
以下が、kubernetesを構成するサーバー一覧
●マスターサーバー
kubernetesクラスタないのコンテナを操作するためのサーバー。
マスターサーバーがkubectlコマンドによるリクエストを受け取って処理を実行する。
利用者からあたかも１台のサーバーで操作しているかのように振舞うことができる。
●etcdサーバー
分散キーバリューストア。クラスタの構成情報を管理する。ここには、クラスタを構成するための設定情報が書き込まれている。
●ノード
実際にdockerコンテナを動作させるサーバー。ノードが複数集まったものがクラスタ。ノード内には、dockerコンテナの集合体であるpodが存在している。
以下が、アプリケーションを構成する要素一覧
●Replica Set
kubernetesであらかじめ指定されたPodを作成/起動しておくもの。Podを監視し、障害などでコンテナが停止してしまった場合、該当のpodを削除し、新たなpodを起動する。
●Deployment
podとReplicaSetの履歴を管理するもの。pod内のコンテナのバージョンアップを行いたいときにシステムを停止することなくアップデートできたりする。
以下がネットワークを管理する要素一覧
●Service
kubernetesクラスタ内で起草したpodに対して外部からアクセスするときはServiceを定義する。
●Label
リソース管理のためLabelを用いて識別しやすいようにする。
