仕事では管理部門にいて、技術の現場からは少し離れた立ち位置になっているのですが、通っている大学院の講義で仮想化技術の演習をやることになりました。Dockerは趣味でもDocker Desktopを通じて触ってはいたものの、コマンドラインでイチから操作するのは正直久しぶりです。

「50代からの学び直し」なんて言うと大げさですが、やってみると忘れていたことや新しく気づくことが意外と多くて、なかなか新鮮な体験です。コンテナ技術が普及した今の時代の「当たり前」をちゃんと体で覚え直すのは、やはり大事だなと感じています。

このエントリでは Docker編 として、以降で書くKubernetes / Minikube編 の2部構成としています。

今回のエントリでは**Dockerの基本操作から応用までをひと通り体験し、以降はその環境をそのまま使ってMinikubeによるKubernetes入門に進みます。

参考

uepon.hatenadiary.com

この記事の対象読者

コンテナ技術を改めて学び直したい方（年齢は関係ないです😊）
Docker Desktopは触ったことがあるけど、コマンドラインでの操作は不慣れな方
Kubernetesに入る前に、まずDockerの基礎を固めておきたい方

実施環境

今回はあえてDocker Desktopを使わず、Windows上のVirtualBoxにLinuxを立ててDockerをインストールするという構成で進めました。「なぜわざわざそんな面倒なことを？」と思われるかもしれませんが、何かトラブルがあってもWindows側に影響を与えないためです。また自分自身GUIに頼らずコマンドで操作することで、Dockerの内部的な動作やコンテナのライフサイクルをより深く理解したかったというのもあります。結果的に、この選択は正解だったと思っています。

項目	内容
ホストOS	Windows 11
仮想化ソフト	VirtualBox 7.2.6 r172322
ゲストOS	Ubuntu 24.04 Server
VM プロセッサ数	2
VM メモリ	6128 MB
Docker	29.2.1

Note: 第2部で使うMinikube（1.38.0）やkubectlも同じVM上にインストールしていますが、今回の範囲では使いません。

構成としては Windows → VirtualBox → Ubuntu 24.04 Server → Docker → コンテナ という多層構造になります。この「仮想化の上に仮想化を重ねる」構成は少し特殊ですが、後述するようにネットワーク周りで独特のハマりポイントがあり、それはそれで学びになりました。

VirtualBoxのVM設定画面（プロセッサ数・メモリ量）

Windowsから以下でログイン

PS> ssh -p 2222 user2404@localhost

以降はこのシェルを使用して設定を行っていく。

事前準備　Dockerのインストール

VirtualBoxのゲストOSにはUbuntu 24.04 LTSを選びました。Server版のMinimal Installにすれば、VM上でも軽量に動作します。

Dockerのインストールは公式リポジトリから行います。aptのデフォルトリポジトリにもDockerはありますが、バージョンが古いことがあるので、公式リポジトリを追加してインストールするのが確実だと思います。

# 必要なパッケージのインストール
$ sudo apt update
$ sudo apt install -y ca-certificates curl gnupg

# Docker公式GPGキーの追加
$ sudo install -m 0755 -d /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
$ sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Dockerリポジトリの追加
$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Dockerのインストール
$ sudo apt update
$ sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 一般ユーザーでDockerを実行できるようにする
$ sudo usermod -aG docker $USER

# グループ変更を反映（再ログインでも可）
$ newgrp docker

インストールが終わったら動作確認をします。

# バージョン確認
$ docker --version

# デーモンの動作確認
$ docker info

# おなじみのHello World
$ docker run hello-world

Hello from Docker! のメッセージが表示されれば準備完了です。

docker run hello-worldの実行結果

基本操作編

ここからがDockerハンズオンの本番です。コンテナのライフサイクルに沿って、一つずつ操作を体験していきます。

イメージの取得（Pull）

まずはDocker Hubからコンテナイメージをダウンロードします。今回はコンテナは違いを見るためにUbuntu 22.04のイメージを使っています。

# Ubuntu イメージの取得
$ docker pull ubuntu:22.04

# 取得済みイメージの一覧を表示
$ docker images

docker images で一覧を見ると、イメージのサイズが表示されます。Ubuntu 22.04のイメージは約77MBほどで、VMのイメージ（数GB）と比べるとかなり軽量です。これがコンテナの「軽さ」を実感できる最初のポイントですね。かつてオンプレでOSのインストールに何時間もかけていた身からすると、この手軽さは隔世の感があります🤔

docker imagesの実行結果

コンテナの起動（Launch）

先程、取得したイメージからコンテナを起動します。今回はホストのUbuntuバージョンを24.04としていますが、わかりやすくするためにコンテナ側のUbuntuバージョンは22.04としています。好みの問題なので24.04にしても問題はありません。

# 対話モード（-it）でコンテナを起動し、bashシェルに入る
$ docker run -it --name my-ubuntu ubuntu:22.04 /bin/bash

-i（interactive）で標準入力を開いたまま、-t（terminal）で疑似TTYを割り当てています。 --name でコンテナに名前を付けておくと、後の操作でコンテナIDの代わりに名前で指定できるので便利です。

起動するとプロンプトが root@<コンテナID>:/# に変わります。ここはもうコンテナの中です。ホストOSとは完全に独立した環境になっています。

コンテナ起動後のプロンプトが変わった状態

👉** 特定のバージョンのLinux環境でテストしたいとき、docker run で即座にその環境を手に入れられます。「Ubuntu 22.04で動くか試したい」「CentOSで検証したい」といったケースで重宝します。

コンテナへの接続（Attach）と接続方法の使い分け

バックグラウンドで動いているコンテナに接続する方法は2つあります。私はよくここでハマるので丁寧めに書いておきます。

# バックグラウンドでコンテナを起動（-d: detached mode）
$ docker run -itd --name bg-ubuntu ubuntu:22.04 /bin/bash

# 方法1: attach（メインプロセスに直接接続）
$ docker attach bg-ubuntu

# 方法2: exec（新しいプロセスで接続）
$ docker exec -it bg-ubuntu /bin/bash

⚠️attach はコンテナのメインプロセス（PID 1のbash）に直接接続します。そのため、exit や Ctrl+D で抜けるとメインプロセスが終了し、コンテナ自体が停止してしまいます。一方、exec は新しいbashセッションを立ち上げて接続するので、exit してもメインプロセスには影響しません。コンテナは動き続けます。

自分も最初のうちは attach で入って exit してコンテナを止めてしまい、「あれ、コンテナ消えた？😫」となったことが何度かありました。普段Docker Desktopを使っているとこのあたりの挙動を意識しないんですよね。コマンドやオプションを思い出すのにも少し苦労しましたが、こういう「手で覚え直す」作業はやはり大事だなと感じます。

もし exit でコンテナを止めてしまった場合は、docker start bg-ubuntu で再起動できます。

👉️普段の作業では docker exec を使う方が安全です。attach はコンテナのメインプロセスの出力をリアルタイムで見たいとき（ログ監視など）に使います。

シェル操作とファイル操作

コンテナ内部では通常通りLinuxコマンドが使えます。

# OS情報の確認
$ cat /etc/os-release

# パッケージの更新とツールのインストール
$ apt update
$ apt install -y curl vim

# ホスト名（コンテナIDが表示される）
$ hostname

# プロセスの確認
$ ps aux

ps aux を実行すると、プロセスがほんの数個しか動いていないことがわかります。VMではOS全体が動いているのに対し、コンテナでは必要最小限のプロセスしか起動していません。この差がコンテナの軽量さの理由でもあります。

ファイル操作も普通にできます。

# ファイルの作成
$ echo "Hello from Docker Container!" > /root/hello.txt
$ cat /root/hello.txt

# ディレクトリの作成とファイルの移動
$ mkdir -p /root/workspace
$ mv /root/hello.txt /root/workspace/
$ ls -la /root/workspace/

ただし、コンテナを削除するとこれらのファイルもすべて消えます。永続化が必要な場合はボリュームマウントを使う必要があります。

ネットワーク操作

コンテナのネットワーク設定を確認します。

# コンテナ内のIPアドレス確認
$ hostname -i

# ipコマンドで確認（要インストール）
$ apt install -y iproute2
$ ip addr show

# 外部への疎通確認
$ apt install -y iputils-ping
$ ping -c 3 8.8.8.8
$ ping -c 3 google.com

ホスト側からもネットワーク情報を確認できます。

# Dockerネットワーク一覧
$ docker network ls

# bridge ネットワークの詳細確認
$ docker network inspect bridge

コンテナはデフォルトでbridgeネットワークに接続され、Dockerが自動的にIPアドレスを割り当てます。コンテナから外部への通信はNATを通じて行われるため、特別な設定なしにインターネットにアクセスできます。

コンテナからのhostname -i と ping の実行結果

コンテナからの切断（Detach）

attach でコンテナに接続している場合、コンテナを停止せずに抜けるにはデタッチ操作を使います。

【Ctrl + P】 → 【Ctrl + Q】

このキーを入力すると、コンテナは動作したままホスト側に戻れます。exit や Ctrl+D ではコンテナが停止してしまうので、覚えておきましょう。

デタッチ後に docker ps を実行すると、コンテナがまだ動いていることが確認できます。

👉️長時間実行するバッチ処理やサーバープロセスをコンテナ内で起動し、デタッチしておくという使い方ができます。

コンテナの一時停止と再開（Suspend / Resume）

# コンテナの一時停止
$ docker pause my-ubuntu

# 状態確認（STATUS が "Paused" になっている）
$ docker ps

# コンテナの再開
$ docker unpause my-ubuntu

pause はプロセスを凍結（SIGSTOP）してメモリ上にそのまま残す操作で、stop はプロセスを終了（SIGTERM → SIGKILL）する操作です。

👉️リソースを一時的に解放したいけど、コンテナの状態は保持したいとき。たとえばデバッグ中に別のコンテナにリソースを回したい場面などで使えます。正直なところ、自分がオンプレ時代に運用していたシステムでは「プロセスの凍結」に相当する操作はかなり慎重に扱っていたので、こんなに手軽にできるのは時代の進歩を感じます😊

状態確認（Status check）

Dockerの状態確認コマンドはいくつかあり、それぞれ用途が異なります。

# 実行中のコンテナ一覧
$ docker ps

# 停止中を含むすべてのコンテナ一覧
$ docker ps -a

# コンテナの詳細情報（JSON形式）
$ docker inspect my-ubuntu

# コンテナのログ
$ docker logs my-ubuntu

# リソース使用状況をリアルタイム表示
$ docker stats
# （Ctrl+C で終了）

# コンテナ内のプロセス一覧
$ docker top my-ubuntu

特に docker ps -a はよく使います。「さっき起動したはずのコンテナが docker ps に出てこない」というときは、たいてい停止状態になっています。-a を付けると停止中のコンテナも表示されるので、まずはこれで状態を確認するクセをつけておくとトラブルシューティングが楽になります。自分はよく-aをつけ忘れるので、エイリアスに登録しようと思います😫

docker ps -a の実行結果

👉docker logs はコンテナ内のアプリケーションがエラーを出したときの原因調査に欠かせません。docker stats はコンテナのメモリ使用量やCPU使用率をリアルタイムで監視でき、パフォーマンス問題の切り分けに役立ちます。

コンテナのコミット（Commit）

現在のコンテナの状態を新しいイメージとして保存します。

# コンテナを新しいイメージとして保存
$ docker commit my-ubuntu my-custom-ubuntu:v1

# 保存されたイメージを確認
$ docker images

# 保存したイメージから新しいコンテナを起動して確認
$ docker run -it --name test-custom my-custom-ubuntu:v1 /bin/bash

# 先ほどインストールしたツールや作成したファイルが残っていることを確認
$ which curl
$ cat /root/workspace/hello.txt

コミットしたイメージには、コンテナ内で行った変更（インストールしたパッケージやファイル）がすべて含まれています。「この状態をとっておきたい」というときに便利です。

ただし、コミットには「何を変更したか」の記録が残らないという弱点があります。後から「このイメージ、何が入ってるんだっけ？」となりがちです。再現性が求められる場面では、後述するDockerfileを使ってイメージを構築するのがおすすめです。

docker commit 後の docker images 結果

👉️開発環境のスナップショットを取りたいとき、試行錯誤した環境を一旦保存しておきたいときに使います。ただし本番向けのイメージ作成にはDockerfileがおすすめ。

ファイルコピー（File copy from/to）

ホストとコンテナ間でファイルをコピーします。

# ホスト → コンテナ
$ echo "File from host" > /tmp/host-file.txt
$ docker cp /tmp/host-file.txt my-ubuntu:/root/host-file.txt
$ docker exec my-ubuntu cat /root/host-file.txt

# コンテナ → ホスト
$ docker cp my-ubuntu:/root/workspace/hello.txt /tmp/container-file.txt
$ cat /tmp/container-file.txt

👉️設定ファイルの投入やログファイルの回収、デバッグ用データの注入など。ただし頻繁なファイルのやり取りが必要な場合はボリュームマウント（-v オプション）を使う方が効率的です。

コンテナの停止と削除

# コンテナの停止（グレースフルシャットダウン）
$ docker stop my-ubuntu

# 停止確認（STATUS が "Exited"）
$ docker ps -a | grep my-ubuntu

# 停止したコンテナの再起動
$ docker start my-ubuntu

docker stop はSIGTERMを送り、デフォルトで10秒の猶予後にSIGKILLを送ります。アプリケーションが接続中のリクエストを処理してから終了できるため、通常は stop を使います。応答しなくなったコンテナには docker kill で強制終了します。

コンテナの削除は以下のように実行します。

# 停止中のコンテナを削除
$ docker stop my-ubuntu
$ docker rm my-ubuntu

# イメージの削除
$ docker rmi my-custom-ubuntu:v1

# 未使用のリソースを一括削除
$ docker system prune

docker rm は停止中のコンテナにのみ実行可能です。実行中のコンテナを強制削除するには -f オプションが必要になります。

docker system prune は地味に重要なコマンドです。開発中は不要なイメージやコンテナ、ネットワークが蓄積しやすく、ディスク容量を圧迫します。定期的に掃除する習慣をつけておくと「ディスクが足りない」というトラブルを防げるようです。私は今回このコマンドを知りました😊

応用操作編

基本操作を一通り終えたところで、ここからはもう少し実践的な内容に入ります。

コンテナ間通信

マイクロサービスアーキテクチャでは、Webサーバー・APIサーバー・データベースなどが別々のコンテナとして動作し、相互に通信します。ここではその基本を体験します。

ユーザー定義ネットワークの作成

# ネットワークの作成
$ docker network create my-network

# ネットワークの確認
$ docker network ls

👉️なぜ、ユーザー定義ネットワークを作るのか？

Dockerのデフォルト bridge ネットワークではコンテナ名によるDNS解決ができません。つまりIPアドレスを直接指定する必要があるのですが、コンテナのIPは起動のたびに変化するため、これは実用的ではありません。

ユーザー定義ネットワークを作成することで、Docker内のDNSサーバーが有効になり、コンテナ名で通信できるようになります。

個人的にはコンテナ間の通信はデフォルトの bridge ネットワークでは名前解決ができないのは不便で、ユーザー定義ネットワークを作るひと手間が必要になります。一方、後述するDocker Composeでは同一のymlファイルに定義したサービス同士が自動的に同一ネットワークに配置され名前解決できるので、実運用ではComposeを必須だなと感じました🤔

コンテナの起動と通信テスト

# コンテナ1（サーバー役）: Nginxを起動
$ docker run -d --name web-server --network my-network nginx

# コンテナ2（クライアント役）: Ubuntuを起動
$ docker run -it --name client --network my-network ubuntu:22.04 /bin/bash

# クライアント側からサーバーに通信（コンテナ内で実行）
$ apt update && apt install -y curl
$ curl http://web-server
# → Nginxのデフォルトページが表示されれば成功

# コンテナ名で名前解決されていることを確認
$ apt install -y iputils-ping
$ ping -c 3 web-server

curl http://web-server でNginxのウェルカムページが返ってくれば成功です。IPアドレスではなくコンテナ名で通信できていることがポイントです。

curl http://web-server でNginxのデフォルトページを取得と名前解決

クリーンアップ

この実験が修了したら作成したリソースを削除しておきます。使う場合には実行しなくても大丈夫です。

$ exit
$ docker stop web-server client
$ docker rm web-server client
$ docker network rm my-network

リソース割り当て

コンテナに割り当てるCPUやメモリを制限できます。リソース制限は、1つのコンテナが暴走してホスト全体に影響を及ぼすことを防ぐために重要です。

# メモリ256MB・CPU 0.5コアに制限してコンテナを起動
$ docker run -itd --name limited-container \
  --memory=256m \
  --cpus=0.5 \
  ubuntu:22.04 /bin/bash

# リソース制限の確認
$ docker inspect limited-container | grep -A 5 "Memory\|Cpu"

# リアルタイム確認
$ docker stats limited-container
# （Ctrl+C で終了）

docker stats の実行結果

オプションは次のようになっています。

オプション	説明
`--memory=256m`	メモリ上限を256MBに制限
`--cpus=0.5`	CPUを0.5コア分に制限
`--memory-swap=512m`	メモリ+スワップの合計を512MBに制限
`--cpu-shares=512`	CPU使用比率の重み付け（デフォルト: 1024）

メモリ制限を超えるとOut Of Memory Killerが発動します。試しに stress ツールで確認してみましょう。

$ docker exec -it limited-container /bin/bash
$ apt update && apt install -y stress
$ stress --vm 1 --vm-bytes 300M --timeout 10s
# → 256MB制限を超えようとするため、エラーになる可能性がある

stressの実行画面

👉️本番環境では、メモリリークしたコンテナがホスト全体のメモリを食い尽くすのを防ぐために、メモリ上限の設定は必須と言えます。Kubernetesでもリソースリミットの設定は基本中の基本になります。自分が24時間稼働のシステムを運用していた頃は、メモリリークの対処に冷や汗をかいた経験が何度もあるので、コンテナ単位でリソースを制限できるこの仕組みは非常にありがたいなと思います😊

Dockerfileを使用する

ここまでの操作で docker commit を使ってイメージを保存しましたが、「何を変更したか」が記録に残らないという問題がありました。Dockerfileを使えば、イメージの構築手順をコードとして記述でき、再現性のあるイメージ作成が可能になります。

Dockerfileの作成

今回はテストとして、NginxでWebサーバーのコンテナを起動してみます。

$ mkdir -p ~/docker-sample && cd ~/docker-sample

Dockerfile

# ベースイメージ
FROM ubuntu:22.04

# メタデータ
LABEL maintainer="your-name"
LABEL description="Custom Docker Image"

# パッケージのインストール
RUN apt update && apt install -y \
    curl \
    vim \
    nginx \
    && rm -rf /var/lib/apt/lists/*

# 作業ディレクトリの設定
WORKDIR /var/www/html

# カスタムHTMLファイルをコピー
COPY index.html /var/www/html/index.html

# ポートの公開
EXPOSE 80

# コンテナ起動時のコマンド
CMD ["nginx", "-g", "daemon off;"]

HTMLファイルの作成

index.html

<!DOCTYPE html>
<html>
<head>
    <title>Docker Exercise</title>
</head>
<body>
    <h1>Hello from Custom Docker Image!</h1>
    <p>This page is served by a container built from a Dockerfile.</p>
</body>
</html>

イメージのビルドと実行

# イメージのビルド
$ docker build -t my-web-app:v1 .

# ビルドされたイメージの確認
$ docker images | grep my-web-app

# コンテナの起動（ホストの8080番ポートをコンテナの80番ポートにマッピング）
$ docker run -d --name my-web -p 8080:80 my-web-app:v1

# 動作確認
$ curl http://localhost:8080

curl でカスタムHTMLが表示されれば成功です。

docker build の実行過程と curl http://localhost:8080 の結果

⚠️⚠️ここで1つ注意点があります⚠️⚠️

今回の構成はWindows → VirtualBox → Ubuntu → Docker → コンテナという多段構造なので、WindowsのブラウザからコンテナのWebサーバーにアクセスしたい場合は、VirtualBoxのポートフォワード設定が必要です。VirtualBoxの設定で「ホストポート8888 → ゲストポート8080」のルールを追加すれば、Windowsのブラウザから http://localhost:8888 でアクセスできるようになります。

この「仮想化が多段になることで生じるネットワークの複雑さ」は、今回の構成ならではの苦労ポイントでした。ただ、昔オンプレでネットワーク設計をしていた頃の知識が「ああ、これはNATの階層が増えているだけだな」と理解する助けになったように感じます。

VirtualBoxのポートフォワーディング設定とWindowsからのブラウザアクセス

👉️Dockerfileはインフラのコード化（Infrastructure as Code）の第一歩です。チーム全員が同じ開発環境を再現できるようになり、「自分の環境では動くのに…」という問題を解消できます。CI/CDパイプラインでのイメージ自動ビルドにも使われているようです。

Docker Composeを使用する

Docker Composeは複数のコンテナを一括管理するためのツールです。先ほどのコンテナ間通信では手動でネットワークを作成してコンテナを起動しましたが、Composeを使えばYAMLファイルに構成を定義して docker compose up 一発で起動できます。

docker-compose.yml の作成

今回はテストとして、WordPressとMySQLの2つのコンテナを連携させる構成を作ります。

$ mkdir -p ~/compose-sample && cd ~/compose-sample

docker-compose.yml

services:
  db:
    image: mysql:8.0
    container_name: wp-db
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppassword
    volumes:
      - db-data:/var/lib/mysql
    restart: unless-stopped

  wordpress:
    image: wordpress:latest
    container_name: wp-app
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wppassword
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp-data:/var/www/html
    restart: unless-stopped

volumes:
  db-data:
  wp-data:

ポイントは、depends_on でWordPressがDBの後に起動するよう依存関係を定義しています。

WORDPRESS_DB_HOST: db:3306 のようにサービス名（db）でデータベースを参照できるのは、Compose側で自動的に同一ネットワークを作成してDNS解決を有効にしてくれるからです。先ほど手動でネットワークを作った苦労が、Composeなら不要になります便利😊

Composeの操作

# バックグラウンドで起動
$ docker compose up -d

# コンテナの状態確認
$ docker compose ps

# ログの確認
$ docker compose logs

# WordPress特定のログのみ確認
$ docker compose logs wordpress

docker compose ps でWordPressとMySQLが起動している状態

VirtualBoxのポートフォワードを設定している場合は Windows側のブラウザで http://<ホストのIPアドレス>:8888 にアクセスすると、WordPressのセットアップ画面が表示されます。

ブラウザでWordPressのセットアップ画面が表示された状態

Composeサービスの停止と削除

# 停止（コンテナは保持）
$ docker compose stop

# 再開
$ docker compose start

# 停止してコンテナ・ネットワークを削除
$ docker compose down

# ボリュームも含めてすべて削除
$ docker compose down -v

docker compose down と docker compose down -v の違いは重要です。-v を付けるとボリューム（データベースのデータなど）も削除されます。開発中に「まっさらな状態からやり直したい」ときは -v を付け、「データは残しておきたい」ときはつけないでください。

👉️開発環境の構築に最適です。新メンバーが git clone → docker compose up -d するだけで、アプリケーション・データベース・キャッシュサーバーなどを含む完全な開発環境が立ち上がります😊クソ便利。

操作のまとめ

最後に、今回実施した操作をまとめておきます。

操作	コマンド
Pull	`docker pull`
Launch	`docker run`
Attach	`docker attach` / `docker exec`
Shell操作	コンテナ内でコマンド実行
File操作	コンテナ内でファイル作成・編集
Network操作	IPアドレス確認、疎通確認
Detach	`Ctrl+P, Ctrl+Q`
Suspend / Resume	`docker pause` / `docker unpause`
Status check	`docker ps` / `docker inspect` / `docker stats`
Commit	`docker commit`
File copy	`docker cp`
Terminate	`docker stop` / `docker kill`
Delete	`docker rm` / `docker rmi`

応用操作	内容
コンテナ間通信	ユーザー定義ネットワークでコンテナ名による通信
リソース割り当て	メモリ・CPU制限付きコンテナ起動
Dockerfile	カスタムイメージのビルドと実行
Docker Compose	複数コンテナの一括管理（WordPress + MySQL）

おわりに

普段はDocker Desktopで済ませていた操作をコマンドラインでイチからやり直してみて、改めて**Docker＊＊の内部的な動作への理解が深まりました。「知っているつもり」と「手を動かして理解している」の間にはやはり差があるなと痛感します😫

docker attach 後に exit でコンテナが停止してしまう挙動や、停止済みコンテナが残っているために同名のコンテナを作成できないエラーなど、CLI操作ならではの注意点を改めて認識しました。若い頃にオンプレのシステムを触っていたときは、サーバーの起動・停止は一大イベントでしたが、コンテナだと数秒で起動して数秒で破棄できる。この感覚の違いは、実際に手を動かしてみないとなかなか腹落ちしないものです。

今回の実験環境が、Windows → VirtualBox → Ubuntu → Docker → コンテナという多層構造だったため、VirtualBoxのポートフォワードの設定が必要になるなど、仮想化が多段になることで生じるネットワークの複雑さも実感しました。面倒ではありましたが、昔やっていたネットワーク設計の知識が役に立つ場面もあり、経験は無駄にならないなと思えたのは、学び直しをしている身としては嬉しいポイントでした。

デフォルトの bridge ネットワークではコンテナ名による名前解決ができないという点は不便に感じていましたが、Docker Composeでは自動的に同一ネットワークが作成され名前解決もできるため、実運用ではComposeの利用が事実上必須だという実感が湧きました。

「50代からの学び直し」と構えなくても、手を動かしてみれば自然と理解は深まりますね。この記事がこれからDockerを触る方の参考になれば幸いです。

次回予告：Kubernetes（Minikube）編

今回構築した同じVirtualBox + Ubuntu環境にMinikubeをインストールし、Kubernetesの基本操作を体験します。Dockerでは手動で行っていたコンテナの管理が、Kubernetesではオートヒーリング・スケーリング・ローリングアップデートといった仕組みで自動化されていく様子を体感できます。私は今回Kubernetesの使用するのが初めてでしたが、非常に楽しく学ぶことができました。というか、大規模設備ではシフトしないとやばいでしょう。良かったら続きもぜひお読みください。

参考