【Docker】(2)実運用解説

Docker の正しい使い方

1. プロジェクトの中に、アプリ本体と Docker 関連ファイルを置く
2. 別環境では、そのフォルダ一式を持っていき、そこで build して run する
3. Container は持っていかない
4. Image も普通は持っていかない
5. ただし、オフライン配布や完全同一バイナリ配布なら Image を持っていく

つまり、あなたの感覚で言うと、

  • 持っていく主役
    アプリ本体 + Dockerfile + composeファイル(.yml) + 依存関係ファイル
  • 普通は持っていかない
    Container
  • 場合によって持っていく
    Image

です。

何をプロジェクト単位として持つべきか

最小限、こういう形にしておくのがわかりやすいです。

myapp/
├─ app/
│  └─ generate.py
├─ requirements.txt
├─ Dockerfile
├─ docker-compose.yml
├─ .dockerignore
└─ .env.example

役割はこうです。

  • app/
    アプリ本体。Python なら .py、Node なら .js や package.json など
  • requirements.txt
    Python の依存関係
  • Dockerfile
    イメージを作る設計書
  • docker-compose.yml
    どう起動するかの実行定義。環境変数、ポート、ボリュームなどを書く
  • .dockerignore
    不要ファイルを build に含めないための設定
  • .env.example
    必要な環境変数の見本。実際の秘密値は入れない

このフォルダ一式を Git で管理する、あるいは zip で持っていくのが基本です。

何を別環境に持っていくべきか

基本形

別環境に持っていくのは、これです。

  • アプリ本体
  • Dockerfile
  • docker-compose.yml
  • 依存関係ファイル
  • 必要なら README.md
  • 必要なら .env.example

つまり、
「その環境で Image を再生成できる材料一式」
を持っていきます。

これがいちばん正しい運用です。

Image は必要か

普通は不要

普通は不要です。
なぜなら、別環境でこうすれば済むからです。

docker compose build
docker compose up

つまり、Dockerfile から別環境で Image を作り直すのが基本です。

Image が必要な場面

ただし、次のときは Image を持っていく意味があります。

  • 相手先がオフライン
  • 相手先にソースを渡したくない
  • build 時間を減らしたい
  • 完全に同じ実体をそのまま渡したい
  • build 環境差分を避けたい

このときは docker save / docker load を使います。

docker save -o myapp.tar myapp:latest

持っていった先で

docker load -i myapp.tar

です。

なので、

  • 開発・保守前提ならソース + Dockerfile を持っていく
  • 完成品配布・オフライン運用なら Image を持っていく

と分けて考えるとわかりやすいです。

Container は持っていくべきか

基本的に 持っていきません。

Container は、
Image からその場で起動する実行体
です。

だから持ち運び対象ではなく、
消してまた作るもの
です。

Docker の正しい感覚はこれです。

  • Image は再利用する
  • Container は作り直す
  • データは Volume や bind mount に逃がす

です。

もし Container の中で手作業でいろいろ変更していて、それを持っていきたくなるなら、運用として少し危険です。
その変更は本来、

  • ソースコードに書く
  • Dockerfile に書く
  • 設定ファイルに書く

べきです。

正しいコマンドの打ち方

実務では、docker run 直打ちより、docker compose ベースのほうが管理しやすいです。

1. まずプロジェクトへ移動

cd myapp

2. Image を作る

docker compose build

これは docker-compose.yml を見て、必要な Image を作ります。

3. 起動する

docker compose up

バックグラウンドなら

docker compose up -d

4. ログを見る

docker compose logs -f

特定サービスだけなら

docker compose logs -f app

5. コンテナの中に入る

docker compose exec app bash

bash がなければ

docker compose exec app sh

6. 停止する

docker compose down

7. 作り直す

Dockerfile や依存関係を変えたら、基本はこれです。

docker compose down
docker compose build --no-cache
docker compose up -d

軽く作り直すだけなら

docker compose up -d --build

でも十分です。

単体コンテナだけならこう

Compose を使わない最小形ならこうです。

build

docker build -t myapp .

run

Linux/macOS:

docker run --rm -it -v $(pwd):/app myapp

Windows PowerShell:

docker run --rm -it -v ${PWD}:/app myapp

ただし、実務ではサービスが増えるので、やはり docker compose のほうが楽です。

典型的な Dockerfile

たとえば Python ならこんな感じです。

FROM python:3.12-slimWORKDIR /appCOPY requirements.txt /app/
RUN pip install --no-cache-dir -r requirements.txtCOPY app/ /app/app/CMD ["python", "app/generate.py"]

典型的な docker-compose.yml

services:
  app:
    build: .
    container_name: myapp
    working_dir: /app
    volumes:
      - ./app:/app/app
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
    tty: true

これなら、別環境に持っていくのは主にこの3つです。

  • app/
  • Dockerfile
  • docker-compose.yml

そこに加えて、

  • requirements.txt
  • .env.example

も持っていくのが普通です。

.env はどうするか

実際の秘密情報入り .env は、普通は Git に入れません。

持っていくのは通常、

  • .env.example
    変数名だけ書いた見本

です。

たとえば、

OPENAI_API_KEY=your_key_here

別環境では、これをもとに .env を作ります。

どの単位で持つべきか

おすすめは、Git リポジトリ = プロジェクト単位です。

つまり、1アプリにつき1フォルダ、1リポジトリです。

その中に

  • ソース
  • Dockerfile
  • compose
  • dependency ファイル
  • README
  • env example

を入れます。

これなら別環境では

git clone ...
cd myapp
docker compose up -d --build

で再現しやすいです。

逆に、持っていかなくてよいもの

普通は持っていかなくてよいものはこうです。

  • __pycache__/
  • .venv/
  • ローカルのログ
  • 一時ファイル
  • build キャッシュ
  • 既存 Container
  • 通常の Image

これらは .dockerignore や .gitignore で除外します。

迷ったときの判断基準

こう考えると整理しやすいです。

別環境でも再構築できればよい

持っていくのは

  • ソース
  • Dockerfile
  • compose
  • dependency定義

Image は不要です。

そのまま同じ完成物を即実行したい

持っていくのは

  • Image

場合によってはソース不要です。

かなり実務的な結論

あなたのケースなら、まずはこの運用がいちばんよいです。

持つべきもの

  • アプリ本体
  • Dockerfile
  • docker-compose.yml
  • requirements.txt
  • .dockerignore
  • .env.example
  • README.md

持たなくてよいもの

  • Container
  • 通常の Image
  • ローカル仮想環境

使うべきコマンド

docker compose build
docker compose up -d
docker compose logs -f
docker compose exec app bash
docker compose down

最後に一番大事な考え方

Docker の正しい使い方は、

Container を育てることではなく、いつでも捨てて再現できるようにすること

です。

なので、持ち運ぶ中心は Container ではなく、
再現材料一式です。

つまり基本は、

アプリ本体 + Dockerfile + compose + dependency ファイル群

です。
Image は必要なときだけ持っていく、で大丈夫です。

コメント

タイトルとURLをコピーしました