備忘録:Docker

調査研究

概要

Dockerは、アプリケーションとその実行環境をコンテナとしてパッケージ化し、開発・テスト・本番環境で一貫した動作を実現するためのプラットフォームです。仮想マシンと比較して軽量かつ高速に起動でき、環境構築の自動化やアプリケーションの移植性向上に役立ちます。

本資料では、Dockerの基本概念（イメージ、コンテナ、ボリューム、ネットワークなど）から、日常的によく利用するコマンド、Dockerfileによるイメージ作成、Docker Composeを用いた複数コンテナの管理までを備忘録として整理します。実務で頻出する操作を中心にまとめ、必要な情報を素早く参照できることを目的とします。

サービスの起動

Dockerでは、コンテナを起動することでアプリケーションやサービスを実行する。

コンテナの起動

既存のコンテナを起動する。

docker start <コンテナ名またはコンテナID>

例:

docker start web-server

コンテナの作成と起動

イメージから新しいコンテナを作成し、起動する。

docker run <オプション> <イメージ名>

例:

docker run -d --name web-server -p 8080:80 nginx
  • -d : バックグラウンドで実行
  • --name : コンテナ名を指定
  • -p : ホストとコンテナのポートをマッピング

Docker Composeによるサービス起動

docker-compose.yml または compose.yml に定義されたサービスを起動する。

docker compose up -d
  • up : サービスを作成・起動
  • -d : バックグラウンド実行

起動中コンテナの確認

docker ps

停止中も含めて確認する場合:

docker ps -a

ログ確認

起動したサービスのログを確認する。

docker logs <コンテナ名>

リアルタイムで監視する場合:

docker logs -f <コンテナ名>

Dockerサービスが裏でやっていること
Dockerはコンテナを起動したあとも、ただ見守っているだけではなく、裏でコンテナの「お世話」を付きっきりでやっています。主に以下のような仕事です。
状態の管理（監視）をしています。
コンテナの中で走っているプログラムが正常に動いているか、エラーで落ちていないかをずっと監視しています。
プロセスの自動再起動も致します。
もしコンテナ内のプログラムが異常終了した場合、設定に応じて「自動でコンテナを再起動させる」といった制御を行います。
ネットワークの交通整理をします。
コンテナと外の世界（インターネットやあなたのパソコン）、あるいはコンテナ同士が通信できるように、仮想的なネットワークを構築して通信を仲介しています。
データの管理（ストレージ）でも活躍します。
コンテナが消えてもデータが消えないように、パソコンの特定のフォルダとコンテナを繋ぐ（マウントする）仕事を管理しています。
ログも管理します。
コンテナの中で出力されたエラーログなどを集め、人間がいつでも確認できるように保存しています。

サーバーへのデプロイ（稼働環境のサーバー起動）

Dockerを利用することで、ローカル開発環境で動作確認したアプリケーションをサーバー環境へ容易に移行できます。アプリケーション本体だけでなく、実行に必要なライブラリや設定もコンテナイメージに含まれるため、環境差異による問題を最小限に抑えることができます。

サーバー上にDocker環境を構築し、ローカルで利用していたDockerイメージや Dockerfile、compose.yml を配置することで、ほぼ同一の構成を再現できます。そのため、「ローカルでは動くがサーバーでは動かない」といった問題を減らし、効率的にサービスを公開できます。

一般的な流れは以下の通りです。

  1. ローカル環境でDockerコンテナを作成・動作確認する
  2. DockerイメージをGitHubのリモートにプッシュします。
  3. サーバー上でGitHubよりプルします。
  4. docker compose up -d などでサービスを起動する
  5. ドメインやリバースプロキシを設定して外部公開する

Dockerを利用することで、開発環境と本番環境の構成を統一しやすくなり、デプロイ作業の簡素化や運用負荷の軽減につながります。

サーバー公開までの具体的な手順

1. ローカル環境でDockerコンテナを作成・動作確認する

Dockerイメージをビルドし、コンテナを起動して動作を確認します。

docker compose up --build

または

docker build -t myapp .
docker run -p 8080:8080 myapp

ブラウザやAPIクライアントからアクセスし、正常に動作することを確認します。

2. ソースコードをGitHubへプッシュする

GitHubリポジトリへアプリケーションを登録します。（初回のアップロード）

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin <GitHubリポジトリURL>
git push -u origin main

以降の更新時は次のコマンドを実行します。

git add .
git commit -m "Update application"
git push

3. サーバー上でソースコードを取得する

SSH接続設定の簡略化

Dockerコンテナをサーバーへデプロイする際は、SSHで頻繁にサーバーへ接続することになります。

通常は以下のような長いコマンドを毎回入力する必要があります。

ssh -i ~/.ssh/my-key-pair.pem ubuntu@192.168.xx.xx

SSHの設定ファイル（config）を利用すると、接続先情報や秘密鍵を事前に登録できるため、以降は以下のような短いコマンドで接続できます。

ssh myserver

複数のサーバーを管理する場合や、Dockerアプリケーションのデプロイ作業を頻繁に行う場合に便利です。

1. SSH設定ディレクトリへ移動

Linux・macOSの場合:

cd ~/.ssh

ディレクトリが存在しない場合:

mkdir -p ~/.ssh
cd ~/.ssh

2. configファイルを作成

nano config

Windowsの場合は、メモ帳でconfig(拡張子なし）ファイルを作ってください

3. 接続情報を登録

以下は設定例です。

Host myserver
    HostName 192.168.xx.xx
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/my-key-pair.pem

各項目の意味は次のとおりです。

項目内容
Host接続時に利用するエイリアス名
HostNameサーバーのIPアドレスまたはドメイン
Userログインユーザー
PortSSHポート番号
IdentityFile使用する秘密鍵ファイル名

保存後、エディタを終了します。

4. パーミッション設定

Lnuxの場合は、SSHは設定ファイルの権限を厳しくチェックするため、適切なパーミッションを設定します。

chmod 600 ~/.ssh/config

秘密鍵にも同様の設定を推奨します。

chmod 600 ~/.ssh/*.pem

5. 接続確認

登録したエイリアス名で接続できることを確認します。

ssh myserver

複数サーバーを管理する場合

開発環境と本番環境を分けて管理する場合は、複数の接続先を登録できます。

Host dev-server
    HostName 192.168.1.10
    User ubuntu
    IdentityFile ~/.ssh/dev.pem

Host prod-server
    HostName example.com
    User ubuntu
    IdentityFile ~/.ssh/prod.pem

接続時は以下のように指定します。

ssh dev-server
ssh prod-server

Docker運用との組み合わせ

Dockerアプリケーションをサーバーへデプロイする場合、以下のような流れで利用します。

ssh prod-server 'SSHで接続

cd my-project　’プロジェクトが含まれるディレクトリへ移動

git pull origin main　'Gitから最新をプル

docker compose up -d --build　’Dockerを立ち上げる（同時にシステムも稼働する）

SSH設定を行っておくことで、サーバー接続作業を簡略化でき、デプロイや保守運用を効率的に進められます。

サーバーへSSH接続後、GitHubからリポジトリを取得します。

ssh user@server

初回のダウンロード

git clone <GitHubリポジトリURL>
cd <リポジトリ名>

２回目以降のダウンロード

cd <リポジトリ名>
git pull origin main

4. Docker Composeでサービスを起動する

サーバー上でコンテナをビルド・起動します。

docker compose up -d --build

起動状態を確認します。

docker ps

ログを確認する場合:

docker compose logs -f

5. ドメインやリバースプロキシを設定して外部公開する

例としてNginxをリバースプロキシとして利用する場合の設定例です。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

設定反映:

sudo nginx -t
sudo systemctl reload nginx

SSL証明書を取得する場合はCertbotを利用します。

sudo certbot --nginx -d example.com

これにより、ローカル環境で確認したDockerアプリケーションをサーバー上で同様に実行し、インターネットへ公開できます。

サーバー環境とローカル環境の差異への対応

Dockerを利用すると、ローカル環境とサーバー環境をほぼ同じ構成で運用できます。しかし、実際にはOSやCPUアーキテクチャ、環境変数、ネットワーク設定などの違いにより、ローカルでは正常に動作していてもサーバー上では問題が発生する場合があります。

そのため、本番環境へデプロイする前に、環境差異を確認し必要に応じて調整を行います。

Dockerイメージを再ビルドする

環境設定や依存ライブラリを変更した場合は、イメージを再作成します。

docker compose build --no-cache

または

docker compose up -d --build

環境変数を確認する

ローカル環境とサーバー環境で .env ファイルや環境変数の内容が異なる場合があります。

設定内容を確認します。

cat .env

コンテナ内の環境変数を確認する場合:

docker exec -it <コンテナ名> env

機密情報はGitHubへコミットせず、サーバー側で個別に管理することを推奨します。

コンテナ内部へ接続して確認する

サーバー上で問題が発生した場合は、コンテナ内部へ入り直接調査します。

docker exec -it <コンテナ名> bash

Alpine Linux系のイメージの場合:

docker exec -it <コンテナ名> sh

ログを確認する

アプリケーションエラーや設定ミスはログから確認できます。

docker compose logs

リアルタイム監視:

docker compose logs -f

特定サービスのみ確認:

docker compose logs -f web

CPUアーキテクチャの違いに対応する

開発用PCがApple Silicon（M1/M2/M3）で、サーバーがIntel/AMDの場合、アーキテクチャの違いによりイメージが正常に動作しない場合があります。

サーバー向けアーキテクチャを指定してビルドします。

docker build --platform linux/amd64 -t myapp .

Docker Composeの場合:

services:
  app:
    platform: linux/amd64

ボリュームやファイル権限を確認する

ローカルでは動作していても、サーバーではファイル権限の違いによりアクセスエラーが発生することがあります。

権限を確認します。

ls -la

必要に応じて権限を変更します。

chmod -R 755 storage

ネットワーク設定を確認する

コンテナ間通信や外部公開設定に問題がある場合は、ポート設定やネットワーク構成を確認します。

起動中コンテナのポート確認:

docker ps

Dockerネットワーク確認:

docker network ls

動作確認の流れ

サーバーで期待どおりに動作しない場合は、以下の順で確認すると効率的です。

  1. コンテナが起動しているか確認する
docker ps
  1. ログを確認する
docker compose logs -f
  1. コンテナ内部へ接続する
docker exec -it <コンテナ名> bash
  1. 環境変数や設定ファイルを確認する
env
  1. 必要に応じて再ビルドする
docker compose up -d --build

Dockerを利用することで環境差異は大幅に減らせますが、「完全に同一になる」わけではありません。デプロイ後はログ確認やコンテナ内部の調査を行いながら、ローカル環境との差異を調整していくことが重要です。

おまけ：リバースプロキシを構築する

Dockerコンテナで起動したアプリケーションを外部公開する場合、Nginxなどのリバースプロキシを利用すると便利です。

リバースプロキシを使うことで、外部からのアクセスを一度Webサーバーで受け取り、内部で動作しているDockerコンテナへ転送できます。

1. Dockerコンテナ側のポートを確認する

まず、アプリケーションがどのポートで起動しているか確認します。

docker ps

例:

0.0.0.0:3000->3000/tcp

この場合、ホスト側の 3000 番ポートでアプリケーションにアクセスできます。

2. Nginxをインストールする

Ubuntuの場合:

sudo apt update
sudo apt install nginx -y

起動確認:

sudo systemctl status nginx

3. Nginxの設定ファイルを作成する

sudo nano /etc/nginx/sites-available/myapp

以下のように設定します。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

example.com は実際に利用するドメイン名へ変更します。
3000 はDockerコンテナが公開しているホスト側のポート番号に合わせます。

4. 設定を有効化する

作成した設定ファイルを有効化します。

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/

設定内容に問題がないか確認します。

sudo nginx -t

問題がなければNginxを再読み込みします。

sudo systemctl reload nginx

5. ブラウザで確認する

以下のURLへアクセスして、Dockerコンテナのアプリケーションが表示されるか確認します。

http://example.com

6. HTTPS化する

本番環境ではHTTPS化も行います。
Certbotを利用すると、Let’s EncryptのSSL証明書を簡単に設定できます。

sudo apt install certbot python3-certbot-nginx -y

証明書を取得します。

sudo certbot --nginx -d example.com

設定後、以下のURLでアクセスできることを確認します。

https://example.com

Docker運用時の注意点

Docker Composeでアプリケーションを起動する場合、compose.yml でホスト側ポートを公開しておきます。

services:
  app:
    build: .
    ports:
      - "3000:3000"

Nginx側では、ホスト側に公開したポートへ転送します。

proxy_pass http://localhost:3000;

これにより、外部からは https://example.com でアクセスし、内部ではNginxからDockerコンテナへリクエストを転送できます。

コメント