Dockerについて深くまとめてみた - その2 Docker周辺ツール(Docker Compose,Kubernetes)編

※本記事は下記の記事の続編となっておりますが、Dockerに関する基礎知識があれば本記事単体でもお楽しみいただけます。
blog.ecbeing.tech

「Dockerって名前だけは知ってるけどよくわからない」「前回記事が気になる！」という方は、ぜひ上記記事をご一読ください。

はじめに

こんにちは! ecbeing新卒1年目のいかちゃんです。
前回は「Docker〜概要編〜」ということで、Dockerに関することをざっくりとまとめてみました。

ちなみに前回記事はとってもご好評?だったようで…。
はてなブックマークや暖かなブックマークコメントをたくさん頂きました…!もう本当に筆者冥利に尽きます…!!
今回記事も前回記事に負けないくらいボリューミーなのでぜひぜひ!

さて気を取り直しまして…。
今回は「Dockerを取り巻く外部サービス編」ということで、Dockerと密接な繋がりがあるツールやサービス、例えば「Docker Compose」や「Kubernetes」についてまとめていこうと思います!

ちなみに本シリーズ記事のロードマップはこちら:

Dockerとは?概要紹介
Dockerを取り巻く外部サービス ←今ここ
Dockerの構成と仕組み
Dockerのメリット
Dockerの歴史
Dockerの今

それではいきましょう！

はじめに
Dockerの周辺サービスについて
- 余談: Docker Toolboxについては…
Docker Composeとは
Kubernetesとは
- Kubernetesとは
- Kubernetesの詳細
まとめ & 次回記事へ続く…
Tips
- Tips1: Docker Swarm
- Tips2: Kubernetesの語源

Dockerの周辺サービスについて

「Dockerの周辺ツール・サービス」といっても、その分類は様々ありますが…。
大きく分けると下記になるかなと思います:

Docker Compose
Kubernetes
各クラウドベンダー提供サービス
- AWS: ECS/EKS
- Azure: AKS
- GCP: Kubernetes Engine
- Alibaba Cloud: Container Service

Docker ComposeはDocker出現当初から盛り上がってたイメージですが、Kubernetesは割とここ最近…でもないですが、出てきたサービスな様に思えます。

また、各クラウドベンダー提供サービスは「Docker」という括りよりかは、Dockerが持つ大きな側面「コンテナサービス」という視点から、サービスを提供している様にも思えます。
((特にオートスケールは、Dockerがもともと持っていた概念とは離れたものにも感じますし…。
これは前回の記事のはてなブックマークへ頂いたコメント:

むしろDockerの重要度はだんだん下がってきている。
Container Runtime Interface (CRI)がスタンダードになった今，「コンテナを使う」＝「Dockerをつかう」ではなくなってきた。

t-tanakaさんのコメントから。

…を見て、なんとなくそう思いました。
t-tanakaさん、素敵なコメントありがとうございます…!!

…ちょっと所感が長くなっちゃいました…。
さてここからは、各ツール・サービスについてより深掘りしていこうと思います！

…が、流石に上記全てを今回記事だけで見ていこうとすると大変なので、今回は1と2の項目(Docker ComposeとKubernetes)に絞って見ていこうと思います！

余談: Docker Toolboxについては…

今回…というより、本シリーズではDocker周辺ツール・サービスの1つの「Docker Toolbox」については扱いません。
というのも、Docker for Windows/Macがリリースされた今、Docker Toolboxはもう用済みになってしまっているので…。
この辺りについて詳しく知りたい方は、こちらの項をお読みください:
Dockerについて深くまとめてみた - その1 Docker概要編 - ecbeing labs（イーシービーイング・ラボ）

Docker Composeとは

docs.docker.jp

例えばこんな時に…

例えば「Docker上でWebシステムを構築する」ことを考えてみましょう。

Webシステムに必要なサービス(Webサーバー、DBサーバー…)を全て「1つのDockerコンテナ」に押し込んでしまうことも可能ですが…。
「システム部分にちょこっと機能追加を行いたい」時に、DBサーバーごとまたコンテナ…もといイメージから構築し直さないといけないし、
「利用ユーザーが増えてDBアクセスが多くなってきたから、コンテナ数を増やしてDBアクセスの性能を上げたい」時にも、Webサーバーも余計に増やさないといけないし…と、様々な問題点が発生します。
そうこんな感じに…。:

"1コンテナに全部のサービスを詰め込んだ状態を示す図"

上記の様な事態にならない様、Dockerを用いてWebシステムを構築する際は、「サービスごとにコンテナを分解する」のが常です。
こうすることで「システム部分にちょこっと機能追加を行いたい」時もDBサーバー側には触れなくて済みますし、
「利用ユーザーが増えてDBアクセスが多くなってきたから、コンテナ数を増やしてDBアクセスの性能を上げたい」時にもDBサーバーのみ増やすことができます。
そうこんな感じに…。:

"複数コンテナにサービスを分割した状態を示す図"

さて、上記の様にコンテナを分割してしまうと、当然「コンテナを管理する」コストがかかります。
これまでは1コンテナの面倒を見ていけば良かったのですが、上記の様になると複数コンテナの面倒を見てあげないといけません…いやはやとっても面倒ですよね。
そんな時にこそ、Docker Composeは役に立つのです!

Docker Compose概要

Docker Composeは「複数のコンテナを扱うDockerアプリケーションを定義・実行するためのツール」です。

Docker Composeの世界では、コンテナはあくまで「1つのアプリケーションを構成する1要素」でしかありません。
1コンテナに対し与えられる役割は、例えばWebサーバーかWebアプリケーションサーバー、もしくはDBサーバー…等であり、 1コンテナだけでアプリケーションがされることはありません 。
そしてこの「複数のコンテナが集まったアプリケーション」を、後述するDocker Composeの設定ファイルで一元管理できるのです。

イメージとしてはこんな感じです:

"Docker-Composeの概要イメージ図"

また、Docker Composeを実行する際「以前に実行されたコンテナ」が見つかれば、 そのコンテナから新しく生成するコンテナにボリューム(コンテナ内のデータ)をコピーしてくれる ため、大切なDB情報などが失われることなく、アプリケーションの状態を保持できます。
加えて、Docker Composeでコンテナを生成する際は 変更のあったコンテナのみ再作成してくれる (コンテナ作成時に使う設定情報をキャッシュしてくれる)ため、サービスの再起動が高速に行えます。
素のDockerでは困難だった「コンテナ毎にサービスを区分けする」事が、Docker Composeを用いれば簡単かつ便利、そして柔軟に行えるのです!

そんなDocker Composeの記事執筆現在(2019/10/09)での最新バージョンは1.24.0(2019/03/28リリース)であり…。(ソース)
最近はどうもアップデートはしていないっぽいです。(2019年のアップデートは上記の1つだけですし。)
((もうDocker Composeは古いのでしょうかね…Kubernetesもありますし…。

ちなみに動作環境は「OS X」「Windows」「64-bit Linux」のいずれかです。
無論、Dockerがインストールされていない環境でないと動きません。
インストールについては公式Docsに分かりやすくまとまっておりましたのでこちらを参照に。
とっても簡単にできそうです!

Docker Composeの具体的な利用方法は下記の通りです:

各コンテナのビルド内容をDockerfile内に記載
各コンテナの設定などをdocker-compose.ymlで定義
docker-compose upコマンドを実行
docker-compose.ymlで定義したアプリケーションが実行される!

上記手順内において、最も重要なのは項目2です。
項目2にて設定するdocker-compose.ymlにて、複数のコンテナに様々な設定を行うのですが…。設定可能な範囲が非常に多く一言では説明しきれないため、次項目にて`詳しく見ていこうと思います!

`docker-compose.yml`について

docker-compose.ymlファイルは、下記の様なyamlファイルとなっています:
※公式Docsやこちらの記事の内容を参考にさせていただきました

# Docker Compose自体のバージョンを指定する
# ここの項目を省略するとversion: '1'として扱われる
version: '2'

services:
  app:
    # depends_onで依存関係を示す
    # appでmysqlを使いたいのでdbコンテナを指定.
    depends_on:
        - db
    # build はDockerfileからビルドすることを示す.
    # pathは相対パスになるので、build/app/Dockerfileが読まれる.
    build: "./build/app"
    # ports でポートフォワーディングを指定.
    ports:
        - "8888:80"
    # volumes でマウントの指定.こちらも相対パス.
    volumes:
        - "./volumes/app:/var/www/html"
        - logvolume01:/var/log
    # links で連携させるコンテナを示す.
    # depends_onはビルド時に依存関係を考慮してビルドさせるために指定.
    # links は appコンテナの/etc/hostsにdbのipを記述してくれる.
    links:
        - db
  db:
    # image はbuildをせず既存イメージを用いる場合に使う.
    image: mysql
    # environment は環境変数などのexportをしてくれる.
    # mysqlのようにenvironmentで指定が必須の変数もあるので、公式イメージを利用する際には注意.
    environment:
        MYSQL_ROOT_PASSWORD: root
        MYSQL_DATABASE: database
    ports:
        - "13306:3306"
    # 永続化が必要なものに対してはvolumesなどでホスト側に残す
  volumes:
    - logvolume01: {}

※余談:versionについて

Docker Composeには大きく分けて2つのバージョンが存在しております。
記事執筆現在(2019/10/09)では、バージョン1と2が存在しており、各バージョンの違いは下記の通りです:

バージョン1:
- Docker Compose1.6.xまででサポート
  - 将来的に廃止予定…参考記事:http://docs.docker.jp/compose/compose-file.html#compose-file-versioning
- volumes、networks、build引数は使用不可
バージョン2:
- Docker Compose1.6.0(2016/01/15リリース)以上でサポート
- 実行にはDocker Engine 1.10.0以上が必要

docker-compose.ymlには大きく分けて「サービス(services)」「ネットワーク(networks)」「ボリューム(volumes)」の3項目を定義することができます。
各項目はDockerの既存コマンドの下記とよく似ています:

サービス(service): docker run
ネットワーク(network): docker network create
ボリューム(volumes): docker volume create

ちなみに「ネットワーク」の設定については、「サービス間で異なるネットワークとしたい」時以外は用いないかなと思います。
…が、「ネットワーク」設定を用いて下記の様に設定を組むと、「proxyサービスとdbサービスをネットワークレベルで独立させ、appサービスのみが両方と通信できる」アプリケーションを組むことが可能です!とっても便利!!:
※公式Docsの内容をお借りさせていただきました

version: '2'

services:
  proxy:
    build: ./proxy
    networks:
      - front
  app:
    build: ./app
    networks:
      - front
      - back
  db:
    image: postgres
    networks:
      - back

networks:
  front:
    # Use a custom driver
    driver: custom-driver-1
  back:
    # Use a custom driver which takes special options
    driver: custom-driver-2
    driver_opts:
      foo: "1"
      bar: "2"

また、docker-compose.ymlではシェル上の環境変数を用いることも可能です。
例えば下記の様に記述することで、シェル上のEXTERNAL_PORTという環境変数を用いることが可能となります:
※公式Docsの内容をお借りさせていただきました

web:
  build: .
  ports:
    - "${EXTERNAL_PORT}:5000"

なお、docker-compose.ymlには上記以外にも様々な情報を定義可能です。
詳しくは公式Docs - Composeファイルリファレンスをご参照ください。

余談ですが、Docker Composeはbashとzshシェル向けにコマンドライン補完も用意してくれているとのこと…!
詳しくは公式Docs - コマンドライン補完を参照に…。

お次は「Docker Composeの機能を生かし、アプリケーションを公にデプロイする」あたりも見ていきましょう!

追記@2019/11/21

記事公開後、こんな感じのコメントをいただきました…！

linksはもう廃止予定なので説明ごと削除すべき＆Docker ComposeのYAMLは3.7が最新なので、2よりは3を使うべき
http://docs.docker.jp/ は公式じゃないしとても古いので、https://docs.docker.com/compose/ の情報を信じたほうがいいです。

はてなブックマークのコメントより: https://b.hatena.ne.jp/entry/4676445630257490850/comment/inductor

本記事を書くにあたり、私が参考にしたのは「日本語版のDocker Docs」だったのですが、公式と情報の鮮度にずれがあったみたいですね…。
※現行のDocker DocsのVerはv19.03(参考)ですが、日本語版のDocker Docsはv1.11.1(参考)なようです

折角なのでこの情報を元に、もう一度簡単にですが、調べ直してみました。
inductorさん、コメントありがとうございます！

本記事ではdocker-compose.ymlファイルのバージョンは2までと述べましたが、コメントにもあったように今はVer3が最新です。
正確には、Docker EngineのVer18.06.0~に対応したdocker-compose.ymlVer3.7が最新とのこと。
※執筆当時にもう一度Docker Engineのバージョンを確認したところ、v19.03が最新でした(参考)。
Ver18.06.0は2018年7月18日にリリースしたもののようです…。

Ver2とVer3の変更点はこちらを参考に。

Docker Composeを製品リリースとして用いるには

Docker環境下において、開発環境で構築したアプリケーションを公にデプロイするには様々なことを考慮しないといけません。
例えば普段の開発環境では考慮しなくて良い下記の様な事項も:

コードの内容が漏洩しない様、コンテナ内にはソースコードを置かない
ポートの割り当て
環境変数の設定(ログ出力をするかしないかフラグや、メールの送信を有効化するフラグや…)
etc...

「本番環境」においては十分に考慮しなければなりません…。
ユーザーが実際に用いるWebサイトで、エラー画面にログが出まくったり、メールの送信が行われないとなると大問題ですしね。

また、アプリケーションには「開発環境」と「本番環境」の他にも、「ステージング(お客様向け検証)環境」や場合によっては他の目的の環境など、様々な環境を立ててやる必要があります。
そしてその環境毎に必要となる設定(ログ出力は行って良いか?メール送信機能は有効化しても良いか?DBの接続先は?)も多種多様であり…。
これらを素のDockerで、1つ1つのコンテナ単位で管理するのは大変でしょう。

しかしここでも、Docker Composeは役に立つのです!
実はDocker Composeの設定ファイルdocker-compose.ymlは、複数個のファイルで1つの設定を定義することも可能なのです。
この特性を活用し、例えば下記の様な`docker-compose.yml構成にし…:

docker-compose.yml: 全ての環境に共通な設定を記載
docker-compose.development.yml: 開発環境に必要な設定を記載(メール送信機能をOFFにしたり、ログ出力をONにしたり…)
docker-compose.staging.yml: ステージング環境に必要な設定を記載(デバッグ用のページにはアクセス不可としたり)
docker-compose.production.yml: 本番環境に必要な設定を記載(メール送信機能をONにしたり、ログ出力をOFFにしたり…)

例えば開発環境ではdocker-compose.ymlとdocker-compose.development.ymlの2ファイルを用いて構築する様にすれば…。
異なる環境でも設定を使いまわせたり、環境が異なっても適用する設定ファイルを変えてしまえば各環境用のコンテナ群をビルド可能となります。
((ステージング環境ではdocker-compose.development.ymlではなく docker-compose.staging.ymlを用いるだけでいい感じです

また、docker-compose.ymlには他にも「各コンテナの設定値を別ファイルとして記載する事も可能」なのです!
例えばこんな感じに…:
※公式Docsの内容をお借りさせていただきました

web1:
  extends:
    # 他の`docker-compose.yml`ファイルを読み込ませることが可能!
    file: common-services.yml
    service: webapp
web2:
  extends:
    # 他の`docker-compose.yml`ファイルを読み込ませることが可能!
    file: common-services.yml
    service: webapp

common-services.yml:

webapp:
  build: .
  ports:
    - "8000:8000"
  volumes:
    - "/data"

この様にすれば、複数のコンテナの設定値を1つのファイルに集約させる事が可能です!
もちろん、他ファイルとして読み込んだ設定値を読み込み元のファイル内で上書きして変更することも可能です。

「複数個のファイルで1つの設定を定義可能」「各コンテナの設定値を別ファイルとして記載可能」、これら2つの特性を上手に使えば、少なくとも素のDockerを用いるよりはアプリケーションデプロイが容易になるでしょう。
(まぁ後述するKubernetesを用いる方がよほど容易にはなるのですが…)
もし本項目についてより詳細に知りたいという方は、下記の公式Docsをご参照ください!
Compose 設定をファイルとプロジェクト間で共有 — Docker-docs-ja 24.0 ドキュメント
 Compose を本番環境(production) で使う — Docker-docs-ja 24.0 ドキュメント

本項のおわりに

かなりボリューミーにまとめてみましたが、いかがでしたでしょうか。
もし本記事で取り上げた以外にもDocker Composeについて詳しく知りたいという方は、ぜひ「公式Docs」を見てみてください。
ボリューム盛りだくさん&美しい日本語訳がなされており、Docker Composeの詳細を理解するには非常にもってこいだと思います!

また、公式DocsにはDocker Composeについてのディープな部分…。
例えば公式Docsのよくある質問と回答には、「データベースが起動するのを待ってからアプリケーションを起動できるか」や「サービスの再作成や停止に10秒かかるのはどうしてなのか」など、細かな点について詳細に書かれておりますし…。
Docker Composeを用いたRuby on Railsを運用するためのスタートガイドやWordPressを運用するためのスタートガイドといった記事もありますので、興味のある方は是非!

お次は近年?注目を集めている「Kubernetes」について見ていきましょう!

Kubernetesとは

kubernetes.io

KubernetesはGoogleが作成した「コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うためのオープンソースのコンテナオーケストレーションシステム」です。
噛み砕いて言うと「コンテナ技術を主軸とし、アプリケーションを コンテナ単位で デプロイしたりスケーリングしたり、その管理が行えるオープンソースなシステム」…といったところでしょうか。

Google公式ページによれば、元々はGoogle Cloudで開発、運用されてきたものとのこと。
オープンソースとしては2014年にリリースされたそうです。
また、公式ページにはこんな一文も…近年注目を集めている事から割と新しめな技術と思いきや、そこそこ歴史ある技術の様です。

Kubernetes は、15 年間にわたって Google のコンテナ化されたワークロードを実行してきた経験と、オープンソースコミュニティによる価値ある貢献のもと、構築されています。

そんなKubernetesの記事執筆現在(2019/10/10)の最新バージョンは、v1.16.1(2019/10/03)。プレバージョンのv1.17.0-alpha.1も同日に出ております。
リリースバージョン数は述べ564! 今年に入ってからも絶え間なくバージョンアップされており、勢いを感じさせるOSSだなと思います。
Githubリポジトリを見ると、えぐい数のStarやWatch、Forkが付けられております…。

"記事執筆現在(2019/10/10)のKubernetesのGithubリポジトリページのスクリーンショット" — 圧巻の数値が並びます

ちなみに現在は「Google自体は」Kubernetesの開発を牽引している訳ではなく、CNCF(Cloud Native Computing Foundation)と言う別団体がホストとなっている様です。
※CNCFは「持続可能なネイティブエコシステムの構築やコミュニティの育成を通じ、クラウドネイティブOSSの成長と健全性をサポート」する団体であり、「Kubernetesなどのクラウドネイティブソフトウェアにおける重要なプロジェクトの主を担う、非営利のLinux Foundationの一部」であるそうです。
ちなみにどこのベンダー(GoogleやAmazonなど)にも属さない中立の組織として活動しているそうです…。
詳細ついてはこちらの記事が非常に参考になりますのでぜひ。

Kubernetesの概要としてはこんなところですが…。
「結局Kubernetesって何?」というところがちょっとあやふやになっちゃいました。
「コンテナ技術を主軸とし、アプリケーションを コンテナ単位で デプロイしたりスケーリングしたり、その管理が行えるオープンソースなシステム」といっても具体的に何を指すのか…。
そこで、次からは「Kubernetesとは何か」を、難しい用語なしにふんわりと理解していこうと思います!

Kubernetesとは

参考記事: 数時間で完全理解！わりとゴツいKubernetesハンズオン！！ #AWS - Qiita

先ほどDocker Composeの項で述べた例と同様に、「Docker上でWebシステムを構築する」事を考えてみます。
後々の機能改修のしやすさやスケールのしやすさ等を考慮し、WebサーバーとWebアプリケーション、DBサーバーは1コンテナずつで稼働するとした時、素のDockerでは管理が大変になる…。
そんな時にDocker Composeは役に立つのですが…。

例えば下記の様にDocker Composeアプリケーションを組むと:

"Docker-Composeを利用したアプリケーション図"

こんな事態が考えられます…:

耐故障性を上げるため、各コンテナは複数個稼働させたいが…
- 複数のコンテナを1つのサーバーに属させるのは現実的でないため、複数台のサーバーでコンテナを分けるのにいちいちdocker-compose.ymlを作成しないといけない
- ログ管理はどこで行う?
- ロードバランサーの設定をしないと…
- 複数台のDocker Composeアプリケーションの管理を人間が行う…??
スケールが全て手作業になってしまう…
コンテナが何らかの原因で動作しなくなった時、どうやって気づく事ができるか&回復できるか

図にするとこんな感じです:

"Docker Composeを利用する際のデメリットに関する図" — もはや地獄

これら問題を、丸っと解決してくれるのが「Kubernetes」なのです!
Kubernetesのイメージとしては、「Docker Composeアプリケーションみたいな群を管理してくれる」システム…と言う感じでしょうか。
Kubernetesはあらかじめ設定した「仕様書(マニフェストファイル)」に基づき、Docker Composeの更にもう1段階上から見て、様々な事を行ってくれます。

先の問題点も、Kubernetesという上位のシステムを導入する事で下記の様に丸っと解決できます!:

"Docker Compose->Kubernetesに変えた図" — 平和な世界

Kubernetesとは何か、ふわっと理解したところで…。
お次はKubernetesの詳細について、少し詳しく見ていこうと…思いますが…。

調べていくとどうも Kubernetesの沼がめちゃくちゃ深そう で…。
構成要素がDocker Composeと比べられないくらい多いので、流石にこの内容を本記事1本に収めるのは厳しいと判断しましたため…。
ここからは「あくまでKubernetesの大枠を掴む」程度の勢いで、軽めに見ていこうと思います。

Kubernetesの詳細

Kubernetesを利用する環境は、大まかに以下3つに分けることができます:

手持ちのローカルマシン上で利用
- Minikube(ローカル環境でKubernetesを実行するためのもの)で構築するのが手取り早い
構築ツール(Rancher、Kubesprayなど)を利用し、オンプレミス環境で利用
GCPやAWS、Azureなどのクラウドベンダーが提供する「マネージドKubernetesサービス」を経由して利用

そして、Kubernetes上でアプリケーションを稼働させるのは、「Kubernetesクラスタ」と言う単位で行われます。
このKubernetesクラスタは下記の3つのコンポーネントから成り立ちます:

マスターコンポーネント
- クラスタの最上位部分に存在
- スケジューリング等クラスタ全体に関わる決定を行う
- クラスタのイベントを検知し、応答する(例えばコンテナが動作停止した際、動作停止した旨を検知し新しくコンテナを立ち上げる)
ノードコンポーネント
- Docker Composeアプリケーションに相当する部分の、管理を行う
- スケールする際は、このノードコンポーネントと一緒にノードが増えていくイメージ
- 稼働中のPod(Dockerの1コンテナに相当)の管理を行う
アドオン
- クラスタ自身の機能(DNSやコンテナリソース監視など)が実装された、Podとサービス

また、Kubernetesには実行するアプリケーションや各種設定などを指し示す「リソースオブジェクト」という概念も存在します。
リソースオブジェクトについては、詳しくはさくらのナレッジさんが素敵にまとめてくださってたので引用します:

Kubernetesでは、実行するアプリケーションや各種設定などは「リソースオブジェクト（resource object）」（単に「リソース」などとも呼ばれる）という単位で定義・管理する。
主なリソースとしては下記があり、たとえば使用するコンテナや実行するプログラムは「Pod」というリソースで定義・管理する。

Pod: 使用するコンテナや実行するプログラムを定義する
Deployment: Podの管理方法を定義する
Job: 非定常的に処理を実行するジョブを定義する
CronJob: 定期的に実行されるジョブを定義する
Service: ネットワークサービスを定義する
ConfigMap: コンテナで使用される各種設定リソースを定義する
Secret: コンテナで使用される各種設定リソースを定義する
Volume: コンテナに割り当てるストレージを定義する
Namespace: 管理のための名前空間を定義する

※参考記事: 2019年版・Kubernetesクラスタ構築入門 | さくらのナレッジ

まとめ & 次回記事へ続く…

本記事ではDockerを取り巻く外部ツール・サービスについて、その種類や内容を深掘りして見ていきました。
次回記事では、本記事では紹介しきれなかった分「Dockerを取り巻く各クラウドベンダー提供サービス」についてまとめていく予定です！

最後に、本文とはあまり関連性のない、DockerやDockerの周辺サービスに関するよりディープな?部分をまとめたものをTipsとしてまとめてみました。
宜しければご覧ください。

それではまた次回記事にて！

Tips

Tips1: Docker Swarm

実は、Kubernetesの類似サービスとしてDocker側が公式にリリースしている(Docker Composeと似た様な感じで出している)サービスがあります。
その名はDocker Swarm。
恥ずかしながら筆者は記事を書くまでこのサービスを知りませんでした…。

また、どうやらDocker Composeとの相性がすごく良さそうであり…。
例えば:

Docker Composeでコンテナを管理
Docker Swarmで各Docker Composeアプリケーションを管理

…としていけば、結構良さげに運用できそうです。
また、Docker Swarmのサービス自体が「1つのDockerイメージとして配布されている」ため、Dockerさえインストールしてしまえば他のソフトウェアが不要であることもありがたいですね。
※参考記事: Docker Swarm の入手方法 — Docker-docs-ja 24.0 ドキュメント

ただ、公式Docsを見た感じだとDocker Swarmはかなり利用しにくそうです。
こちらのチュートリアルをみる感じ、どうもインフラ構成まで全部自力で構築しなければならない様で…。
KubernetesならAWSやAzure、GCP経由でサクッと触れる事ができますし、余程のこだわりがない限りはKubernetesでいいんじゃないかな…と個人的には思います。

Tips2: Kubernetesの語源

Kubernetesというサービスの名前ですが、Docker…もといコンテナ技術を用いているにも関わらず、DockerのDの字もなければ「Container」と言う言葉を匂わせる単語も内包されていない様に思えます。
「きっと何か語源があるな」、そう思った筆者はKubernetesドキュメントに足を運びました…。

するとこんな記述が:

Kubernetesという名前はギリシャ語で操舵手やパイロットという意味があり、知事やサイバネティックスの語源にもなっています。
K8sは、8文字の「ubernete」を「8」に置き換えた略語です。

引用元: https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/#kubernetes%E3%81%A3%E3%81%A6%E3%81%A9%E3%81%86%E3%81%84%E3%81%86%E6%84%8F%E5%91%B3-k8s%E3%81%A3%E3%81%A6%E4%BD%95

ギリシャ語から引っ張ってくるとはなんともおしゃれな…。
「操舵手」と言う意味は「オーケストレーションサービス=コンテナの指揮を取る様にする」事から…なのでしょうかね?
また、文中にある「サイバネティックス」とは人工頭脳学のことで、通信工学と制御工学を融合し、生理学、機械工学、システム工学を統一的に扱うことを意図して作られた学問とのこと。

ちなみに完っ全に余談ですが、ギリシャ語の発音では「Kubernetes」は「ッゥーベーネース」…みたいな感じで発音されてるっぽいです。
(Google先生の発音を聞く)
世間的にはKubernetesは「クーべネティス」だったり「クーベルネティス」と発音されている様ですが、たまには語源に忠実になって発音してみるのも面白いかもしれません。

～ecbeingでは技術を深堀りしてまとめてくれる、探究心のあるエンジニアを大募集中です！～ careers.ecbeing.tech

※記事公開後に二番目のイラスト画像のリンク先が間違っていましたので修正いたしました。