容器

• OSとカーネルは共有し、プロセスを分離する仕組み。

コンテナ上で実行されたソフトウェアは単に1つのプロセスとして稼働しているにも関わらず、
コンテナ内のソフトウェアから見ると独立したOS環境を占有しているように見える。

容器与服务器虚拟化

• サーバー仮想化は複数のOSを同一のハードウェア上で実行する仕組み。

「仮想マシン」上に「ゲストOS」を動作させる。
例: Virtual box

– Qiita 上的基于服务器虚拟化技术的基础
– 简单了解各种虚拟化技术!! – Qiita
– 关于云端虚拟化技术

容器的优点 de

• 開発環境やステージング環境、プロダクション環境等、複数の環境間のアプリケーションの依存関係（ライブラリのバージョンのずれ等）を全てコンテナ内で完結でき、意識する必要がなくなる。

• サーバー仮想化と比較するとゲストOSやハードウェアのエミュレートが不要となり、プロセス単位で稼働するため効率的。

アプリケーションを動かすために必要となるコンピューティングリソースの消費は少なくなる。
アプリケーションの起動も高速。

Docker – 使用 Docker

DockerfileによりDockerイメージをビルドし、そのイメージが元となるコンテナ内で作業orコンテナを実行することができる。
アプリケーションや必要なファイルを、Dockerイメージに同梱して、コンテナとして実行していく。

例: Node.jsベースのイメージ（Node.jsが実行できるように環境を整えたLinux）を利用し、npmでのモジュールインストールやビルド処理をコンテナ内で実行する。

環境による差異が解消されたり、構成管理の容易さなどのメリットがある。

学习Docker基础
7nohe/docker-lessons
方向性和设置 – Docker文档
基础的”30分钟理解Docker容器开发和环境搭建” 由 インフラエンジニアBooks 提供

Dockerfile的中文释义是：Docker文件。

• Dockerイメージを作り上げるために実行するコマンドを含めたファイル。

主に以下のコマンドから構成される。

Dockerfile 参考资料 – Docker 文档

CMD vs ENTRYPOINT

[docker] CMD とENTRYPOINT の違いを試してみた – Qiita
ENTRYPOINTは「必ず実行」、CMDは「（デフォルトの）引数」 – POCKETSTUDIO.NET

复制 vs 添加

为什么在Dockerfile中更推荐使用COPY而不是ADD？- Qiita

Dockerfile的样本

# Dockerfile
# syntax=docker/dockerfile:1
FROM ruby:2.5
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install

# コンテナが実行されるたびに毎回実行されるスクリプト
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# イメージが起動中の時に実行するメインプロセスの設定
CMD ["rails", "server", "-b", "0.0.0.0"]

# entrypoint.sh
#!/bin/bash
set -e

# Railsのserver.pidが残っているかもしれないので、それを削除する.
rm -f /myapp/tmp/pids/server.pid

# コンテナのメインプロセス（DockerfileでCMDでセットされているもの）を実行する。
exec "$@"

Quickstart: Compose and Rails – Docker Docs

rails s -b 0.0.0.0 のオプション-bの意味 – Qiita
Railsのプロセスは、外部からのリクエストを受け付けるために、ホストが持っているIPアドレスに結び付けられる（デフォルトでは 127.0.0.1 ）。
（コンテナのネットワーク上の）localhost（= 127.0.0.1）で立ち上がっているプロセスは、外部（コンテナのネットワーク上から見た時のホストのネットワーク上など）からはアクセスできない。
0.0.0.0 は全てのIPアドレスを表す。
Railsのプロセスを（コンテナのネットワーク上の）全てのIPアドレスにバインディング（-b ‘0.0.0.0’）することによって、外部からアクセスできないIPアドレスである 127.0.0.1 だけではなく、外部からアクセス可能なIPアドレスでもRailsアプリケーションを立ち上げている。

用于Dockerfile的最佳实践

Dockerfile のベストプラクティス – Docker-docs-ja
コンテナ毎に１つのプロセスだけ実行、コンテナはエフェメラルであるべき、などのプラクティス。

社内のDockerfileのベストプラクティスを公開します – FORCIA CLUB

Dockerfile的最佳实践 – Docker入门

Dockerfile 的最佳实践 – 知乎

Docker命令的示例

使用Dockerfile构建Docker镜像

$ docker image build -t yokoto/ansible_image:latest（イメージ名[:タグ]） .（Dockerfile配置ディレクトリのパス）

构建Docker镜像 – Docker文档
-t（–tag）: 指定要创建的Docker镜像的标签。

创建并启动一个新的容器，并在该容器中执行命令。

$ docker container run -p 9000:8080（ホストポート:コンテナポート） --name ansible_container（コンテナの命名） yokoto/ansible_image:latest（イメージ名[:タグ]） 

运行docker容器- Docker文档。

Container networking – Docker Docs
ローカルホストのポートへの通信をコンテナポートへ転送するポートフォワーディングの解説。
ポートフォワーディングの設定により、コンテナポートにホストポートでの通信を許可する。

docker runとdocker execの違いの解説 – めもたんす
docker container run は以下と等しい。

$ docker container create -p 9000:8000 --name ansible_container yokoto/ansible_image:latest
$ docker container start ansible_container

docker container create – Docker Docs
新たなコンテナを生成します。
docker container start – Docker Docs
1つまたは複数の停止中コンテナを起動します。

在正在运行的容器中执行命令。

$ docker container run --name ansible_container yokoto/ansible_image:latest
$ docker container exec -it ansible_container /bin/bash　

docker容器执行 – Docker文档

【Docker】「コンテナに入る」が何をしているか1分で理解する – Qiita
exec -itの解説。
-i: 標準入力を受け付けることを示すオプション。-iをつけないとキーボードからの入力を受け付けてくれない。
-t: tty。-tをつけないとコマンド入力用のターミナルが割り当てられない。
/bin/bash: 対話形式のbashシェルを起動する。

【Docker】解析docker run和docker exec之间的区别 – 随心所欲地书写
创建、启动和停止Docker容器 – Qiita

停止正在运行的容器。

$ docker container stop ansible_container
# or
$ docker container kill	ansible_container # 強制停止

停止 Docker 容器 – Docker 文档
杀死 Docker 容器 – Docker 文档

删除容器

$ docker container rm ansible_container
$ docker container prune # 全てのコンテナを削除

docker container rm – Docker Docs
docker container prune – Docker Docs

形象

• コンテナを実行するために必要なビルド済みパッケージ。

レジストリにおいて、「タグ」によってバージョン管理されている。

ruby – Docker Hub
ruby – 镜像仓库
ansible – Docker Hub
ansible – 镜像仓库

Dockerfile是Docker镜像的文件。
在GitHub上，ruby/3.0/alpine3.14/Dockerfile对应的是相应的Docker镜像。
而ansible/centos7/Dockerfile对应的也是GitHub上的Docker镜像文件。

注册表

• イメージのバージョン管理や配布を行えるサービス。

例: Docker Registory、Docker Hub、Amazon Elastic Container Registry（ECR）、GCP Container Registry（GCR）

公共登記 vs 私有登記

• リポジトリを非公開にしたり、イメージのプルに対するアクセス制御を行いたい場合は、プライベートリポジトリを作成する。

Docker Registry、ECR、GCPは、基本的にプライベートレジストリを作成する用途で利用される。

什么是容器注册表？公共注册表和私有注册表有什么区别？
现在可以将 ECR 用作公共注册表！ #reinvent
亚马逊 ECR 私有注册表

仓库

レジストリにおいて、各イメージが保管されている場所。

【Docker】Registry和Repository的区别- Stack Overflow

图像 vs 标签 vs 代码库

$ docker image ls # イメージの一覧
REPOSITORY               TAG     IMAGE ID       CREATED       SIZE
centos                   latest  91c95931e552   9 hours ago   812MB
ansible/centos7-ansible  latest  fb434121fc77   12 hours ago  605MB
tutum/centos             v1.1    1234abcd5678   21 hours ago  470MB

$ docker search centos # イメージの検索
NAME                     DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
centos                   The official build of CentOS.                   1034      [OK]
ansible/centos7-ansible  Ansible on Centos7                              43                   [OK]
tutum/centos             Centos image with SSH access. For the root...   13                   [OK]
...

# Image ID
centos # 91c95931e552
ansible/centos7-ansible:latest # fb434121fc77
ansible/centos7-ansible:v1.1 # fb434121fc77
tutum/centos:v1.1 # 1234abcd5678

Docker初学者对于镜像和仓库的区别感到困惑 – Qiita
镜像和仓库有什么区别？- Stack Overflow
Docker Hub 上的仓库 – Docker-docs-ja
Docker的仓库名称和镜像名称是同一样的吗？

建筑套件

Dockerでは、BuildKitというビルドの拡張機能が18.09から導入された。

交接机密情报

• これにより、docker build 時に –secret オプションを渡すことで、機密情報を受け渡せるようになった。

機密情報は、最終的にイメージ内に保存されることはないので、安全に取り扱うことができる。

機密情報には、Docerfile の RUN が実行される際にアクセスすることができる。

$ echo 'WARMACHINEROX' > mysecret.txt

# syntax=docker/dockerfile:1.2

FROM alpine

# デフォルトの機密情報の置き場所から機密情報を表示する
RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret

# カスタムの機密情報の置き場所から機密情報を表示する
RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

$  docker build --no-cache --progress=plain --secret id=mysecret,src=mysecret.txt .
...
#  [2/3] RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret
#       digest: sha256:5d8cbaeb66183993700828632bfbde246cae8feded11aad40e524f54ce7438d6
#          name: "[2/3] RUN --mount=type=secret,id=mysecret cat /run/secrets/mysecret"
#       started: 2018-08-31 21:03:30.703550864 +0000 UTC
#  1.081 WARMACHINEROX
#     completed: 2018-08-31 21:03:32.051053831 +0000 UTC
#      duration: 1.347502967s
#  [3/3] RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
#        digest: sha256:6c7ebda4599ec6acb40358017e51ccb4c5471dc434573b9b7188143757459efa
#          name: "[3/3] RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar"
#       started: 2018-08-31 21:03:32.052880985 +0000 UTC
#  1.216 WARMACHINEROX
#     completed: 2018-08-31 21:03:33.523282118 +0000 UTC
#      duration: 1.470401133s

使用BuildKit构建映像- Docker文档

缓存特定目录

• コンパイラやパッケージマネージャ（bundler等）用のディレクトリをキャッシュすることができる。

• キャッシュディレクトリの内容は、ビルド間で保持される。

キャッシュマウントは、パフォーマンスを向上させるためだけに使用する。

# syntax=docker/dockerfile:1
FROM golang
RUN --mount=type=cache,target=/root/.cache/go-build \
  go build ...

# syntax=docker/dockerfile:1
FROM ubuntu
RUN rm -f /etc/apt/apt.conf.d/docker-clean; echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' > /etc/apt/apt.conf.d/keep-cache
RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \
  --mount=type=cache,target=/var/lib/apt,sharing=locked \
  apt update && apt-get --no-install-recommends install -y gcc

全力以运用Docker缓存 – Zenn
Docker 18.09 新功能（图像构建和安全）- Medium
buildkit/frontend/dockerfile/docs/reference.md – GitHub

多层次建筑

• Dockerfileに FROM を複数記述することで複数のビルドを展開すること。

• 1ビルドの単位をステージと呼ぶ。

イメージをビルドする際に、使用しないファイル等が減り、結果作成されるイメージサイズが小さくなる。

# syntax=docker/dockerfile:1
FROM golang:1.16 AS builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
# COPY --from=builder: builderステージを利用してファイルをコピー
COPY --from=builder /go/src/github.com/alexellis/href-counter/app ./
CMD ["./app"]

指定舞台进行构建

builder と名付けたステージのみビルドする。

$ docker build --target builder -t alexellis2/href-counter:latest 

前にビルドしたステージを参照して用いる

# syntax=docker/dockerfile:1
FROM alpine:latest AS builder
RUN apk --no-cache add build-base

FROM builder AS build1
COPY source1.cpp source.cpp
RUN g++ -o /binary source.cpp

FROM builder AS build2
COPY source2.cpp source.cpp
RUN g++ -o /binary source.cpp

マルチステージビルドの利用 – docker docs
1つのDockerfileだけでGoの開発環境(ホットリロード)と本番環境(マルチステージビルド)を記述する – Qiita
Docker multi stage buildで変わるDockerfileの常識 – Qiita
至高のDockerイメージ生成を求めて -2019年版- – Qiita
Docker のマルチステージビルドで Rails イメージを軽くする – Zenn

Docker Compose

• Docker Composeは、複数のコンテナで動作するDockerアプリケーションの定義・実行をするためのツール。

Dockerfileによって作成したイメージを組み合わせて1つのコマンド（docker　compose up など）で実行することができる。
コンテナだけではなく、Dockerのネットワークとボリュームも管理できる。
本番環境、ステージング環境、開発環境において動作し、CIワークフローとしても利用することができる。

docker-compose.yml 文件

• docker-compose.ymlは、Dockerコンテナを用いるアプリケーションの設計図に相当する。

複数のコンテナ実行を一括で管理できる、主に以下を定義しているyaml形式のファイル。

docker-compose.yml的示例

version: "3.9" # YAMLのバージョン管理
services: # サービス（コンテナ）を定義するセクション
  db: # dbサービスの定義
    image: postgres # postgres公式イメージを使用
    volumes: # ボリュームに関する指定
      - ./tmp/db:/var/lib/postgresql/data # `./tmp/db` を `/var/lib/postgresql/data` コンテナ内のにマウント
    environment: # コンテナ内で利用できる環境変数の指定
      POSTGRES_PASSWORD: password # パスワードを指定
  web: # webサービスの定義
    build: . # Dockerfileのあるパスを指定
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" # デフォルトのコマンドを上書きする
    volumes:
      - .:/myapp # ホスト上の現在のディレクトリ `./` を `/myapp` にコンテナ内のマウント
      - logvolume01:/var/log # 名前付きボリューム `logvolume01` をコンテナ内の `/var/log` にマウント
    ports: # ポート公開指定
      - "3000:3000" # ホスト側のポート3000を、コンテナ内のポート3000にマッピング
    depends_on: # サービスの依存関係を指定
      - db # dbに依存している
  redis: # redisサービスの定義
    image: "redis:alpine" # redis公式イメージを使用
volumes: # ボリュームを定義するセクション
  logvolume01: {}

Docker Compose の概要 / Overview – Docker Docs
Docker Compose をはじめよう – Docker Docs
Compose specification – Docker Docs

Docker Compose – docker-compose.yml リファレンス – Qiita
Difference between Docker Compose Vs Dockerfile

Docker Composeコマンドのサンプル

サービスのビルド・再ビルド

$ docker compose build

如果您修改了服务的Dockerfile，可以使用该命令重新构建服务。

创建并启动所有容器

$ docker compose up -d 
Creating network "wordpress_wordpressnet" with the default driver
Creating volulme "wordpress_wordpress_db_volume" with default driver
Creating wordpress_wordpress-db_1 ... done
Creating wordpress_wordpress-app_1 ... done

在中文中，将以下内容翻译为“docker compose up – Docker Docs”

列出所有的容器

$ docker compose ps 

docker compose ps – Docker Docs：列出当前正在运行的 Docker Compose 项目中的所有服务。

docker network ls – Docker Docs：显示当前系统中的 Docker 网络列表。

docker compose logs – Docker Docs：显示 Docker Compose 项目中所有服务的日志。

docker volume ls – Docker Docs：列出当前系统中的 Docker 卷列表。

停止和销毁所有容器。

$ docker compose down
Stopping wordpress_wordpress-app_1 ... done
Stopping wordpress_wordpress-db_1 ... done
Removing wordpress_wordpress-app_1 ... done
Removing wordpress_wordpress-db_1 ... done
Removing network wordpressnet

查看 Docker 组合服务状态 – Docker 文档

サービスとコンテナの違い

サービスは、1つまたは複数のコンテナで実行できる。

Docker で “コンテナ” を処理する。
Docker Compose で “サービス” を処理できる。

以下の例では、2つのサービス持つDocker Composeが、
1つのサービス（web）をスケーリングをスケーリングすることで、6つのコンテナを作成している。

$ docker ps -a
CONTAINER ID   IMAGE        COMMAND          ...      NAMES
1c1683e871dc   test1_web    "nginx -g"       ...      test1_web_1
a41360558f96   test1_db     "postgres -d"    ...      test1_db_1

$ docker compose up --scale web=5
Creating and starting 2 ... done
Creating and starting 3 ... done
Creating and starting 4 ... done
Creating and starting 5 ... done

$ docker ps -a  
CONTAINER ID   IMAGE        COMMAND         ...      NAMES
1bf4c939263f   test1_web    "nginx -g"      ...      test1_web_3
d3033964a44b   test1_web    "nginx -g"      ...      test1_web_4
649bbda4d0b0   test1_web    "nginx -g"      ...      test1_web_5
a265ea406727   test1_web    "nginx -g"      ...      test1_web_2
1c1683e871dc   test1_web    "nginx -g"      ...      test1_web_1
a41360558f96   test1_db     "postgres -d'   ...      test1_db_1

在Docker Compose中，服务和容器的区别是什么？- stack overflow

永续化·卷载

• Docker Compose では、サービスによって利用されているボリューム（Docker管理下のストレージ領域）をすべて維持する。

docker compose up が実行されたときに、コンテナーがそれ以前に実行されていれば、以前のコンテナーから現在のコンテナーに向けてボリュームをコピーする。

この処理において、ボリューム内に作り出されていたデータは失われることはない。

音量调节

• コンテナの特定のディレクトリをボリュームとしてホストマシン側で管理すれば、コンテナが削除されてもデータが消失しなくなる。

例: Docker Engineというデータ領域に確保したボリューム（例: mysqlvolume）を、mysqlコンテナの /var/lib/mysql ディレクトリにマウントして起動することで、コンテナを削除してもDBのデータを残すこと（永続化）ができる。

# ボリュームマウントする。ボリューム（`mysqlvolume`）が作られていないときは新規にボリュームを作成する。
$ docker container run --name db01 \
  --volume mysqlvolume:/var/lib/mysql \
  --env MYSQL_ROOT_PASSWORD=password \
  mysql:5.7
# ボリュームマウントする。ボリューム（`mysqlvolume`）が作られていないときは新規にボリュームを作成せずエラーを発生する。
$ docker container run --name db01 \
  --mount type=volume,src=mysqlvolume,dst=/var/lib/mysql \
  --env MYSQL_ROOT_PASSWORD=password \
  mysql:5.7

又或者

services:
  db:
    volumes:
    - mysqlvolume:/var/lib/mysql

以下のように詳細に指定することもできる。

services:
  db:
    volumes:
      - type: volume
        source: mysqlvolume
        target: /var/lib/mysql

実践 Docker – ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 Chapter 19 ３部: Docker Compose – Zenn
第3章 コンテナアプリケーション開発のライフサイクル Build・Ship・Run 永続化データとネットワークモデル インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」 – SpeakerDeck
さわって学ぶクラウドインフラ docker 基礎からのコンテナ構築 5-2 データを独立させる
MySQLのデータディレクトリを移動する – Qiita
MySQLがデータを保管する場所　〜　データディレクトリ – 日常メモ
4.4.3 mysql_install_db — MySQL データディレクトリの初期化 – MySQL
Docker Machine 概要 Docker Engine と Docker Machine の違いは何ですか？ — Docker-docs-ja

バインドマウント

ホスト側のディレクトリをコンテナ内のディレクトリと共有する。
ソースコードのディレクトリをコンテナにバインドマウントしてホストマシン側と共有すれば、ホストマシンでコードを変更した際に同期や転送が不要になる。

例1: DBコンテナのイメージを配布する時点では用意できなかったDBの初期化クエリを、DBコンテナにマウントする。
例2: 開発時のソースコードなど、ホストマシンで変更したいがコンテナに随時反映したいものをコンテナ内のディレクトリにマウントする。

バインドマウントは、実体の面倒を見ているのがホストマシン上である。

「仮想環境だから」と安易に削除すると、影響がホストマシンに波及する。

まずはボリュームを検討し、どうしてもだめならバインドマウントを使う。

services:
  web:
    build: .
    volumes:
      - ".:/myapp"

以下のように詳細に指定することもできる。

services:
  web:
    build: .
    volumes:
      - type: bind
        source: "."
        target: "/myapp"

実践 Docker – ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 Chapter 16 ３部: バインドマウント

卷装装载方式 vs 绑定装载方式

由于不太理解Docker的Volume功能，所以我在Qiita上查找了相关信息。

容器的网络（桥接，主机，无）

• コンテナはそれぞれIPアドレスを持つ。

• コンテナ間で通信や負荷分散を行いたいとき、通信先のコンテナをIPアドレスを指定するのではなく、コンテナ名で指定することができる。

コンテナ間の通信でIPアドレスとコンテナ名の名前解決を行うには、自分で「ブリッジネットワーク」を作成する必要がある。

Dockerでは、複数のプロセス（コンテナ）を動かす必要がある時は、（ソケットではなく）ネットワークで通信を行うことが推奨されている。

桥接网络

• ブリッジとは、別々のネットワーク間で通信できるようにする働きを持つ一般的なネットワークの機能。

同じブリッジネットワーク上に接続しているコンテナは、お互いに通信できる。

コンテナ間で通信できるようにするためには、自分でブリッジ・ネットワークを作成する必要がある。

Docker Compose入门（3）～ 加深对网络的理解～ – 樱花的知识
使用桥接网络 – Docker文档

网络驱动程序

Dockerのネットワークには3種類のネットワークドライバがある。

将Docker容器加入任意网络的命令。

コンテナは、接続されているブリッジネットワークを通じて、割り当てられたIPアドレスを介して互いに自由に通信できる。

# 新しいブリッジネットワークを作成する
$ docker network create mybridge_network
# 作成したブリッジネットワークを指定して、コンテナを作成 or 実行する
$ docker container run --name mycontainer1 myimage --net mybridge_network
# or
$ docker container create --name mycontainer1 myimage --net mybridge_network
# 同じブリッジネットワークを指定して、コンテナを作成する
$ docker container create --name mycontainer2 myimage --net mybridge_network
# コンテナに対して通信する
$ docker container run --name mycontainer1 myimage --net mybridge_network ping mycontainer2
64 bytes from 172.25.0.3: seq=0 ttl=64 time=0.119 ms
64 bytes from 172.25.0.3: seq=1 ttl=64 time=0.127 ms
64 bytes from 172.25.0.3: seq=2 ttl=64 time=0.132 ms

Docker 网络概述 – 知乎
网络 – Docker 入门
Docker 的卷和网络基础 – 从30岁开始的编程

使用Docker创建基本的Rails应用程序/命令链接

快速入门：Compose 与 Rails – Docker文档
快速入门：Compose 和Rails – Docker文档
docker-compose运行 – Docker文档
docker compose运行 – Docker文档

$ docker compose run --rm web bundle exec rails console

对于名为Web的服务，执行”bundle exec rails console”命令。
–rm选项会在处理完成后删除容器。

Dockerを用いてRuby on Railsの環境構築をする方法( Docker初学者向け ) – Qiita
Docker Compose でローカルの Rails 開発環境を作る – Qiita
DockerでRails開発環境を作るワンライナー [Rails7/M1 Mac対応] – Qiita

容器编排

请将“オーケストレータ”翻译成中文。

• 本番環境では多くの場合、サーバーを複数台用意し、負荷分散を行ったり耐障害性を高めたりする構成を作るため、本番環境でコンテナを利用したい場合、複数のコンテナを連携させる必要が出てくる。

• 多数のコンテナを、複数のホストから構成されたクラスターに対し、負荷分散やファイルオーバーを行うサービスをオーケストレータと呼ぶ。

例: Kubernetes、Amazon Elastic Container Service（ECS）、Amazon Elastic Kubernetes Service（EKS）

Kubernetes

• Kubernetesはコンテナ化されたアプリケーションのデプロイ、スケーリングなどの管理を自動化するためのプラットフォームであり、コンテナオーケストレーションエンジンです。

Docker単体では複数のホストで構成される一定規模以上のプロダクション利用に耐えうるシステムを構築するのは難しく、今日ではそのようなシステムを構築するには、Kubernetesに代表されるコンテナオーケストレーションエンジンを利用することが一般的です。

Kubernetes完全ガイド 第2版

群集

• 1つ以上のマスターノードと１つ以上のワーカーノードから成り立つもの。

• コンテナ化されたアプリケーションを実行する、ノードと呼ばれるワーカーマシンの集合。

• すべてのクラスターには少なくとも1つのワーカーノードがある。

• Kubernetesクラスターは以下の2種類のリソースで構成されています

マスターがクラスターを管理する
ノードがアプリケーションを動かすワーカーとなる

標準化用語集 – Kubernetesドキュメント
Minikubeを使ったクラスターの作成 – Kubernetesドキュメント

部署

• アプリケーションのインスタンスを作成および更新する責務がある。

• コンテナのデプロイ状態。

• Kubernetesクラスター上にコンテナ化アプリケーションをデプロイするために必要な設定。

アプリケーションのインスタンスを作成し、更新する方法を指示する。

Deploymentを作成すると、KubernetesマスターはDeployment内に含まれるアプリケーションインスタンスをクラスター内の個々のノードで実行するようにスケジュールする。
Deploymentを作成するときは、アプリケーションのコンテナイメージと実行するレプリカの数を指定する必要がある。

使用kubectl创建部署 – Kubernetes文档

部署规模的扩展

• トラフィックが増加した場合、ユーザーの需要に対応するためにアプリケーションをスケールする必要がある。

スケーリングは、Deploymentのレプリカの数を変更することによって実現可能。

Deploymentをスケールアウトすると、新しいPodが作成され、使用可能なリソースを持つノードにスケジュールされる。

スケールすると、Podの数が増えて新たな望ましい状態になる。

执行多个应用程序实例- Kubernetes文档

节点

• Podは常にノード上で動作する。

• ノードはKubernetesではワーカーマシンであり、クラスターに応じてVMまたは物理マシンになる。

• 複数のPodを1つのノードで実行できる。

• すべてのKubernetesノードでは少なくとも以下のものが動作する。

Kubelet: Kubernetesマスターとノード間の通信を担当するプロセス。マシン上で実行されているPodとコンテナを管理します。

レジストリからコンテナイメージを取得し、コンテナを解凍し、アプリケーションを実行することを担当する、Dockerのようなコンテナランタイム。

Pod和节点 – Kubernetes文档

豆荚

• 一番小さく一番シンプルなKubernetesのオブジェクト。

• クラスターで動作しているいくつかのコンテナのまとまり。

• Podの中でコンテナが起動する。

• Podは常にノード上で動作する。

• Podは通常Deploymentによって管理される。

• Podは1つ以上のアプリケーションコンテナ(Dockerなど)のグループであり、共有ストレージ(ボリューム)、IPアドレス、それらの実行方法に関する情報が含まれています。

• Podには以下のものが含まれます:

共有ストレージ(ボリューム)
ネットワーキング(クラスターに固有のIPアドレス)
Dockerイメージのバージョンや使用するポートなどの、各コンテナをどう動かすかに関する情報

Podの例

Node.jsアプリケーションを含むコンテナとNode.js Webサーバによって公開されるデータを供給するコンテナを含んだオブジェクト

Kubernetes上にDeploymentを作成すると、そのDeploymentはその中に(コンテナを直接作成するのではなく)コンテナを持つPodを作成する。

各Podは、スケジュールされているノードに関連付けられており、終了(再起動ポリシーに従って)または削除されるまでそこに残る。
コンテナ同士が密接に結合され、ディスクなどのリソースを共有する必要がある場合は、コンテナを1つのPodにまとめてスケジュールする必要がある。

標準化用語集 – Kubernetesドキュメント
Podとノードについて – Kubernetesドキュメント

宣言书

• Pod等の定義の記述。

JSONまたはYAMLフォーマットでのKubernetes APIオブジェクトの定義。

服务

• Podの論理セットを定義する。

それらのPodに対する外部トラフィックの公開、負荷分散、およびサービス検出を可能にする抽象化層。

YAML(推奨)またはJSONを使って定義される。

Serviceによって、アプリケーションはトラフィックを受信できるようになります。

各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスターの外部に公開されません。
ServiceSpecでtypeを指定することで、Serviceをさまざまな方法で公開することができる。

Serviceには、公開されたDeploymentのすべてのPodにネットワークトラフィックを分散する統合ロードバランサがある。

Serviceは、エンドポイントを使用して実行中のPodを継続的に監視し、トラフィックが使用可能なPodにのみ送信されるようにする。

ClusterIP (既定値)

クラスター内の内部IPでServiceを公開する。
この型では、Serviceはクラスター内からのみ到達可能になります。

NodePort

ClusterIPのスーパーセット。
NATを使用して、クラスター内の選択された各ノードの同じポートにServiceを公開する。

:を使用してクラスターの外部からServiceにアクセスできるようにする。

LoadBalancer

NodePortのスーパーセット。
現在のクラウドに外部ロードバランサを作成し(サポートされている場合)、Serviceに固定の外部IPを割り当てる。

ExternalName

仕様のexternalNameで指定した名前のCNAMEレコードを返すことによって、任意の名前を使ってServiceを公開する。
プロキシは使用されない。
このタイプはv1.7以上のkube-dnsを必要とする。

使用Service来发布应用程序- Kubernetes文档
在Kubernetes文档中，执行多个应用实例

入口

• クラスター外からクラスター内ServiceへのHTTPとHTTPSのルートを公開する。

トラフィックのルーティングはIngressリソース上で定義されるルールによって制御される。

Serviceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できる。
NGINX Ingress Controller for Kubernetesを使用することで、Nginx Webサーバー(プロキシ)として動作することができる。

Ingress – Kubernetes文档
Ingress控制器 – Kubernetes文档

参考链接

Kubernetes文档/教程 – Kubernetes
标准化术语集 – Kubernetes
Kubernetes原理简单学习 内部结构和架构 – slideshare
ECS / Fargate / EKS实操资料总结 – Qiita
通过差异来理解Kubernetes #k8sjp / 通过亚马逊ECS镜头看Kubernetes – SpeakerDeck
EKS真的比ECS难吗？ – Classmethod
AWS EKS与ECS的比较与选择准则 – Zenn
容器技术的得力助手！”Kubernetes”（上篇）
在大约10分钟内了解为何Kubernetes和EKS很方便 – Qiita
数小时完全理解！强大的Kubernetes实操！！ – Qiita
为Docker Compose用户献上的Kubernetes入门 – Zenn
AWS EKS与ECS的比较与选择准则 – Zenn
通过差异来理解Kubernetes #k8sjp / 通过亚马逊ECS镜头看Kubernetes – Speaker Deck
Kubernetes道场2018年圣诞日历 – Qiita