SLL #9｜Docker ComposeでNginxコンテナを管理してみた

個人学習プロジェクト 「Security Learning Lab（SLL）」 の学習記録です。

今回は、前回作ったDockerコンテナを外部公開する設定と、Docker Composeによるコンテナ管理を実践した内容についてまとめます。

学習時間
今日やったこと
学習内容
困ったこと・つまずいたこと
今日の学び・気づき
今日の達成
次回やること
今日のひとこと

学習時間

約1〜2時間

今日やったこと

セキュリティグループで8080番ポートを開放し、外部ブラウザからDockerコンテナに直接アクセスできることを確認
既存のコンテナ(my-nginx)を停止・削除
docker-compose.ymlを作成し、Docker Composeでのコンテナ管理を実践
Composeプラグインが標準リポジトリにないというエラーに遭遇し、GitHubからバイナリを直接取得して導入
sudo実行時にプラグインが認識されない問題が発生し、システム共有の場所にプラグインを再配置して解決
docker compose up -dでコンテナを起動し、psコマンドでプロセスの概念を復習
不要になった重複ファイルを削除し、lsで削除の確認まで実施

学習内容

ポートの2段階の橋渡し

外部からDockerコンテナにアクセスするには、セキュリティグループ(EC2への入口)とDockerのポートマッピング(コンテナへの入口)の両方が正しく設定されている必要がある。

Docker Composeの役割

複数コンテナの構成をYAML形式の設定ファイル(docker-compose.yml)にまとめて記述し、docker compose up1つでまとめて起動できる仕組み。YAMLはインデントで階層構造を表す記法で、Pythonと似た発想だが開発の経緯は無関係。

プロセスの概念

プロセスは「今動いているプログラムの実体」を指すIT用語。EC2起動時にsystemd(PID1)を起点に多数のプロセスが生成され、Dockerコンテナもその一部として動く。ホストに直接入れたNginxとコンテナ内のNginxは、名前が同じでも別プロセスとして完全に独立して動作していることをps auxで確認できた。

困ったこと・つまずいたこと

Amazon Linux 2023の標準リポジトリにComposeプラグインがなかった

何に困ったか:dnf install docker-compose-pluginを実行したところ「No match for argument」というエラーになった
どう解決したか:調べたところAmazon Linux 2023の標準リポジトリにはこのパッケージ自体が存在しないと判明し、GitHubから直接バイナリをダウンロードして~/.docker/cli-plugins/に配置する方法に切り替えた

sudo実行時にComposeプラグインが見つからなかった

何に困ったか:sudo docker compose up -dを実行すると「unknown shorthand flag」エラーが出た
どう解決したか:sudo実行時はrootユーザーの設定を見に行くため、ec2-user専用の場所ではなく、システム全体で共有される/usr/libexec/docker/cli-plugins/にプラグインを配置し直すことで解決した

作業ディレクトリが消えていた

何に困ったか:SSH接続が一度切れた影響で、以前作成したはずのdocker-practiceフォルダが見当たらなかった
どう解決したか:pwdで現在地を確認し、フォルダとdocker-compose.ymlを作り直すことで対応した

今日の学び・気づき

外部公開には複数の設定が層になって重なっていること(セキュリティグループ、ポートマッピング)を、実際にエラーなく繋がった瞬間に体感として理解できた
パッケージが標準リポジトリにない場合の対処法(公式配布元から直接バイナリを取得する)を、実際のトラブル対応を通じて学べた
ps auxで実際のプロセス一覧を見たことで、「ホストのソフトとコンテナ内のソフトは別物」という以前学んだ概念が、名前は同じでもPIDや起動時刻が異なる別プロセスとして目に見える形で裏付けられた
「削除した」と思い込まず、lsで実際に確認する習慣の大切さを再認識した