OllamaをDockerコンテナで運用する方法|docker-compose.ymlとGPU設定で本番環境に安定デプロイする

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Docker > OllamaをDockerコンテナで運用する方法|docker-compose.ymlとGPU設定で本番環境に安定デプロイする
「Ollamaをサーバーに直接インストールしたら依存ライブラリが競合して環境が壊れた」
「チームメンバーのUbuntuバージョンが違うせいで、同じ手順を実行しても動かない」

そんな悩みを抱えるインフラエンジニアやサーバー管理者は少なくない。Ollamaは単体でも動作するが、本番運用を見据えるとDockerコンテナ化が断然有利だ。この記事では、docker-compose.ymlを使ってOllamaをコンテナとして立ち上げ、GPUパススルー設定・リソース制限・Open WebUI連携・ヘルスチェック・日常運用コマンドまでをステップ順に解説する。さらに、docker-compose.override.ymlを活用した開発・本番設定の分離パターンも紹介する。Ubuntu Server 22.04 LTS + NVIDIA GPUの構成を基本とするが、GPUなしのCPU運用でも手順はほぼ同じだ。

この記事のポイント

・docker-compose.ymlとNVIDIA Container Toolkitで再現性のある運用環境を構築できる
・GPUパススルー・ヘルスチェック・環境変数の外部化で本番品質の構成に仕上げる手順を解説
・docker-compose.override.ymlで開発・本番設定を分離し、本番への誤設定混入を防ぐ方法も紹介
・deploy.resources.limitsでCPU/メモリを制限し、ホスト全体の安定性を守る方法も紹介
・docker statsで実消費量を把握してから制限値を設定する手順を解説
・Open WebUIをcomposeに同梱することでチーム共有UIをワンコマンドで起動できる
・よくあるコンテナ間通信エラーとGPU認識エラーの対処法をまとめて紹介


OllamaをDockerコンテナで運用する方法|docker-compose.ymlとGPU設定で本番環境に安定デプロイする

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜOllamaをDockerコンテナで動かすべきなのか

ローカルLLMの導入を検討するとき、「まずサーバーに直接インストールしてみる」というアプローチを取る人が多い。実際、Ubuntu ServerでローカルLLMを構築する方法で解説した手順は確かに手早く動作確認できる。ただし、直接インストールには「ライブラリの競合」「Pythonバージョン依存」「移行コスト」という3つの問題が伴う。

Dockerを使うと、これらの問題が構造的に解消される。コンテナはホストOSのライブラリに依存せず、docker-compose.ymlという1ファイルで全構成が記述される。チームメンバーがそのファイルを手元に持てば、同じ環境を数分で再現できる。バージョン管理リポジトリにcomposeファイルをコミットすれば、構成変更の履歴も自動で残る。

また、デフォルト設定のDockerコンテナはホストマシンのCPUとメモリを上限なく消費できる。Ollamaが大量の推論リクエストを受けたとき、同じホスト上の他のサービスが道連れになるケースが現場でよく見られる。docker-compose.ymlにリソース制限を明記しておくことで、こうした問題を事前に防げる。

現場で聞いた話では、検証段階は直接インストールで済ませ、社内展開フェーズでDockerに移行するケースが増えているという。直接インストール版とコンテナ版の主な違いは次のとおりだ。

直接インストール版はセットアップが速い半面、サーバー移行時に「どのバージョンを入れたか」が曖昧になりやすい。一方、Docker版はcomposeファイルが設計書として機能するため、「3ヶ月前の構成をそのまま再現したい」といった場面で威力を発揮する。チームで複数台のサーバーにOllamaを展開する予定があるなら、最初からDockerで構築する価値は高い。

この記事ではその「本番化」のステップを詳しく見ていく。

事前準備|Docker EngineとNVIDIA Container Toolkitを整える

1. Docker Engineのインストール確認

Ubuntu ServerへのDocker Engineのインストールは公式ドキュメントの手順が最も確実だ。既にインストール済みの場合はバージョン確認だけ行う。

# Dockerのバージョン確認 $ docker --version Docker version 26.1.4, build 5650f9b # docker compose plugin(V2)の確認 $ docker compose version Docker Compose version v2.27.1

`docker-compose`(V1・ハイフン区切り)ではなく `docker compose`(V2・スペース区切り)が使える状態であることを確認する。V1は2023年にメンテナンス終了しているため、V2への移行を推奨する。インストールされていない場合は次のコマンドで追加できる。

# docker compose plugin(V2)の追加インストール $ sudo apt update $ sudo apt install -y docker-compose-plugin # 一般ユーザーでdockerコマンドを使えるようにグループ追加 $ sudo usermod -aG docker $USER # グループ変更を反映(再ログインが必要) $ newgrp docker

`newgrp docker` コマンドで現在のシェルセッションに変更を反映できる。ただし完全に反映するにはログアウト&再ログインが確実だ。

2. NVIDIA Container Toolkitのインストール

GPUを使ってOllamaを動かすには、NVIDIA Container Toolkitが必要だ。これはDockerコンテナからGPUにアクセスするためのランタイムで、ホストOS側にインストールする。

CUDAドライバーが既にインストール済みであることを前提とする(`nvidia-smi` コマンドで確認できる。未導入の場合はUbuntu ServerでGPUを使ってローカルLLMを動かす方法を参照してほしい)。

# NVIDIA Container Toolkitのリポジトリ追加 $ curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg $ curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list $ sudo apt update && sudo apt install -y nvidia-container-toolkit # Dockerランタイムへの登録 $ sudo nvidia-ctk runtime configure --runtime=docker $ sudo systemctl restart docker # 動作確認(コンテナ内でnvidia-smiが正常に動けばOK) $ docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

最後のコマンドでGPU情報が表示されれば、コンテナからGPUを正しく認識できている状態だ。`CUDA Version` や接続中のGPU名が表示されれば準備完了だ。

3. 作業ディレクトリの構成を整える

作業用ディレクトリを作成する。モデルファイルは数GB以上になるため、ストレージ容量が十分なパスに配置する。

# 作業ディレクトリを作成 $ mkdir -p ~/ollama-docker/{models,webui-data} $ cd ~/ollama-docker # ディレクトリ構成の確認 $ ls -la drwxr-xr-x 4 ubuntu ubuntu 4096 Jun 28 10:00 . drwxr-xr-x 12 ubuntu ubuntu 4096 Jun 28 10:00 .. drwxr-xr-x 2 ubuntu ubuntu 4096 Jun 28 10:00 models drwxr-xr-x 2 ubuntu ubuntu 4096 Jun 28 10:00 webui-data

`models` はOllamaのモデルデータ保存先、`webui-data` はOpen WebUIのデータ保存先として使う。この2ディレクトリにコンテナのデータを永続化するため、コンテナを削除・再作成してもデータが消えない構成になる。

Ollamaコンテナを最小構成で起動する方法

1. 最小構成のdocker-compose.ymlを作成する

まずシンプルな1サービス構成から始めて動作を確認する。`~/ollama-docker/` ディレクトリに以下の内容でdocker-compose.ymlを作成する。

# ~/ollama-docker/docker-compose.yml(最小構成) services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./models:/root/.ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]

各設定の意味を確認しておく。`volumes` の `./models:/root/.ollama` がポイントで、コンテナを削除・再作成してもモデルファイルはホスト側の `./models` に残るため再ダウンロードが不要になる。`restart: unless-stopped` により、サーバー再起動後もOllamaが自動で起動する。

GPUを使わないCPUのみの環境では `deploy.resources.reservations` ブロック全体を削除する。CPU運用でも動作するが、推論速度はGPUに比べて大幅に遅くなる(トークン生成速度が10分の1以下になることもある)。

2. コンテナを起動してモデルを取得する

# コンテナをバックグラウンドで起動 $ docker compose up -d # 起動確認(STATUSがUpになればOK) $ docker compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS ollama ollama/ollama:latest "/bin/ollama serve" ollama 5 seconds ago Up 4 seconds 0.0.0.0:11434->11434/tcp # モデルの取得(コンテナ内でollama pullを実行) $ docker exec -it ollama ollama pull llama3.3:8b-instruct-q4_0 # テスト推論(APIが正常に応答するか確認) $ curl http://localhost:11434/api/generate -d '{"model":"llama3.3:8b-instruct-q4_0","prompt":"こんにちは","stream":false}'

`docker exec -it ollama ollama pull` というコマンド体系に最初は戸惑うかもしれない。外側の `docker exec -it ollama` がDockerのコマンドでコンテナ名を指定し、`ollama pull` がコンテナ内で実行するOllamaのCLIコマンドだ。モデル取得には数分かかる。curlのレスポンスに `"response"` フィールドが返ってきたら成功だ。

docker-compose.ymlで本番構成に仕上げる

1. 環境変数による設定の外部化

本番環境では、設定値を `.env` ファイルに切り出してdocker-compose.ymlから参照する構成が保守しやすい。チームで設定を共有しつつ、サーバーごとの差分は `.env` だけ変更すれば済む。

# ~/ollama-docker/.env OLLAMA_HOST=0.0.0.0 OLLAMA_MAX_LOADED_MODELS=2 OLLAMA_NUM_PARALLEL=4 OLLAMA_KEEP_ALIVE=30m

# docker-compose.yml(環境変数追加版) services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./models:/root/.ollama environment: - OLLAMA_HOST=${OLLAMA_HOST:-0.0.0.0} - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1} - OLLAMA_NUM_PARALLEL=${OLLAMA_NUM_PARALLEL:-2} - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-10m} deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]

`${変数名:-デフォルト値}` の形式にすると、`.env` ファイルがなくてもデフォルト値でコンテナが起動する。チーム展開時の安全弁として覚えておきたい。

`OLLAMA_MAX_LOADED_MODELS` はVRAMに同時に展開するモデルの上限数だ。VRAM 8GBの環境では `1` に絞ることを推奨する。`OLLAMA_KEEP_ALIVE` はモデルをVRAMに保持する時間で、頻繁にリクエストが来る環境では長めに設定するとレスポンスが速くなる。設定変更後は `docker compose up -d` で再起動すれば反映される。

2. ヘルスチェックの追加で本番品質に仕上げる

本番環境ではコンテナのヘルスチェックを設定しておく。サービスが応答しなくなったときに自動検知でき、後述するOpen WebUI連携の起動順制御にも使える。

# docker-compose.yml(ヘルスチェック追加・最終版) services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./models:/root/.ollama environment: - OLLAMA_HOST=${OLLAMA_HOST:-0.0.0.0} - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1} - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-10m} healthcheck: test: ["CMD", "curl", "-f", "http://localhost:11434/"] interval: 30s timeout: 10s retries: 3 start_period: 30s deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu]

設定後に `docker compose ps` を実行すると、STATUS列に `Up (healthy)` と表示されれば正常稼働している。`Up (health: starting)` は起動直後の状態で、30秒ほど待てば `healthy` に変わる。

3. CPUとメモリの制限でOllamaコンテナを安定稼働させる

デフォルト設定のDockerコンテナは、ホストマシンのCPUとメモリを上限なく消費できる。OllamaがGPUで推論しているときでも、モデルのロード処理や並列リクエスト処理でホストCPUとメモリを大量に使うことがある。`deploy.resources.limits` で上限を設けておくことで、ホスト全体の安定性を守れる。

注意: `deploy.resources.limits` によるCPU・メモリ制限はGPUパススルー(`reservations.devices`)と同一の `deploy.resources` ブロックに共存できる。

# docker-compose.yml(リソース制限追加版) services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - "11434:11434" volumes: - ./models:/root/.ollama environment: - OLLAMA_HOST=${OLLAMA_HOST:-0.0.0.0} - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1} - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-10m} healthcheck: test: ["CMD", "curl", "-f", "http://localhost:11434/"] interval: 30s timeout: 10s retries: 3 start_period: 30s deploy: resources: limits: cpus: '4.00' memory: 16G reservations: cpus: '1.00' memory: 4G devices: - driver: nvidia count: all capabilities: [gpu]

`limits` がハードリミット(上限値)、`reservations` がソフトリミット(最低保証量)だ。`limits.memory` の値はモデルのサイズに合わせて設定する。7Bモデル(量子化4bit)なら最低4GB、13Bモデルなら8GB以上が目安だ。制限値を決める前は、後述の `docker stats` で実際の消費量を計測してから数値を決めることを強く推奨する。

設定後に `docker inspect ollama --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'` を実行して制限値が反映されているか確認できる。

4. docker-compose.override.ymlで開発・本番設定を分離する

Ollamaを本番に展開するとき、「開発中はデバッグログを有効にしていたのに本番でもそのままだった」「検証機ではAPIポートをホストに直接公開していたが本番では閉じるべきだった」という設定混入は現場でよく起きる。こうしたミスを構造的に防ぐのが docker-compose.override.yml を使った環境別設定の分離だ。

`docker compose up` を実行すると、DockerはカレントディレクトリのComposeファイルを2段階で読み込む。まず `docker-compose.yml`(共通ベース定義)を読み込み、次に `docker-compose.override.yml` が存在すれば自動的にmergeする。このoverride.ymlに開発専用設定を切り出すことで、本番へのデプロイ時に開発設定が混入しなくなる。

開発環境向けのoverride.yml例を示す。

# docker-compose.override.yml(開発環境専用の設定。本番には含めない) services: ollama: environment: - OLLAMA_DEBUG=1 # デバッグログを有効化(開発時のみ) - OLLAMA_KEEP_ALIVE=5m # VRAMを早めに解放して他の作業と共存させる ports: - "11434:11434" # 開発機からAPIを直接叩けるようにホスト公開 deploy: resources: limits: cpus: '2.00' # 開発機なので本番より緩い上限 memory: 8G

本番デプロイ時は `-f` オプションでファイルを明示指定する。`-f` を1つでも指定するとoverride.ymlの自動読み込みが無効になるため、ベースファイルと本番専用ファイルを両方 `-f` で渡す。

# 本番デプロイ(override.ymlを読ませない) $ docker compose -f docker-compose.yml -f compose.prod.yml up -d # mergeされた最終設定を事前確認(デプロイ前の必須チェック) $ docker compose -f docker-compose.yml -f compose.prod.yml config | grep -A10 environment # 開発環境での起動(override.ymlが自動適用される) $ docker compose up -d

`docker compose config` コマンドはmerge後の最終設定を出力する。「意図しない環境変数が入っていないか」「ポートが余分に開いていないか」をデプロイ前に確認する習慣をつけると、本番トラブルを未然に防げる。

compose.prod.ymlには本番特有の設定(固定タグのイメージ、strictなリソース制限、restart設定など)をまとめる。`.env` と同様に本番パスワードを直書きしたファイルは `.gitignore` に必ず追加すること。

Open WebUIを同一composeに追加してチームで使う

1. docker-compose.ymlにOpen WebUIサービスを追加する

OllamaにOpen WebUIを導入する方法でも紹介したOpen WebUIは、同じdocker-composeファイルで一元管理できる。以下の `open-webui` サービスブロックを追加する。

# docker-compose.yml(Ollama + Open WebUI完成構成) services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped volumes: - ./models:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 - OLLAMA_MAX_LOADED_MODELS=${OLLAMA_MAX_LOADED_MODELS:-1} - OLLAMA_KEEP_ALIVE=${OLLAMA_KEEP_ALIVE:-10m} healthcheck: test: ["CMD", "curl", "-f", "http://localhost:11434/"] interval: 30s timeout: 10s retries: 3 start_period: 30s deploy: resources: limits: cpus: '4.00' memory: 16G reservations: cpus: '1.00' memory: 4G devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - "3000:8080" volumes: - ./webui-data:/app/backend/data environment: - OLLAMA_BASE_URL=http://ollama:11434 depends_on: ollama: condition: service_healthy

`OLLAMA_BASE_URL=http://ollama:11434` の `ollama` はコンテナ名だ。同じdocker-composeで立ち上げたコンテナは自動的に同一ネットワークに属するため、コンテナ名でホスト解決できる。`localhost` や `127.0.0.1` を指定すると別コンテナに届かないため、必ずコンテナ名を使う。

`depends_on` に `condition: service_healthy` を指定することで、Ollamaのヘルスチェックが通過してからOpen WebUIが起動する。起動順の依存を明示的に制御でき、「OllamaがまだAPIを受け付けていないのにOpen WebUIが先に起動してしまう」という問題を防げる。

2. 起動と動作確認

# 全サービスをまとめて起動 $ docker compose up -d # 全サービスのステータス確認 $ docker compose ps NAME IMAGE STATUS ollama ollama/ollama:latest Up (healthy) open-webui ghcr.io/open-webui/open-webui:main Up # Open WebUIのポートでアクセスできるか確認 $ curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/ 200

ブラウザで `http://サーバーIPアドレス:3000` にアクセスする。初回アクセス時に管理者アカウントの作成が求められる。その後、左上のモデル選択メニューで取得済みのモデルが表示されれば連携成功だ。

チームメンバーに共有する際はサーバーのIPアドレスとポート3000を伝えるだけでいい。composeファイルをgitで管理しておけば、新規サーバーへの展開も `git clone` + `docker compose up -d` の2コマンドで完了する。社内でChatGPTが使えない環境でのローカルLLM活用の背景については、社内でChatGPTが使えないときの代替手段も参照してほしい。

コンテナの日常運用|ログ監視・モデル更新・バックアップ

1. ログの確認方法

# 全サービスのログをリアルタイムで確認 $ docker compose logs -f # Ollamaのログのみ確認(推論状況・エラーはここで把握) $ docker compose logs -f ollama # 過去100行のみ表示 $ docker compose logs --tail=100 ollama # タイムスタンプ付きで表示 $ docker compose logs -f --timestamps ollama

推論リクエストのたびにログが出力される。モデルのロード時間・使用中のGPU・エラーはここで確認できる。本番サービスでは `journald` や `syslog` への転送設定も検討する価値がある。

2. モデルの追加・更新手順

# 新しいモデルを追加取得 $ docker exec -it ollama ollama pull mistral:7b-instruct-q8_0 # 現在取得済みのモデル一覧(SIZE列でストレージ使用量を確認) $ docker exec -it ollama ollama list NAME ID SIZE MODIFIED llama3.3:8b-instruct-q4_0 abc123def456 4.9 GB 2 days ago mistral:7b-instruct-q8_0 def456abc789 7.7 GB 1 minute ago # 不要なモデルの削除(ストレージ解放) $ docker exec -it ollama ollama rm phi-4:latest # Ollamaイメージ自体を最新版にアップデート $ docker compose pull ollama $ docker compose up -d ollama

モデルファイルはホスト側の `./models` ディレクトリに保存されているため、`docker compose pull` でOllamaイメージを更新してもモデルデータは消えない。イメージとデータが分離している点がDockerコンテナ運用の大きな利点だ。チームで採用するモデルを選ぶ際は、ローカルLLMのモデルを比較する方法も参考にしてほしい。

3. バックアップと別サーバーへの移行

composeファイルをgitで管理するのがベストプラクティスだ。モデルデータはOllamaの公式リポジトリから再ダウンロードできるため、基本的にバックアップは不要だ。ただし帯域・時間コストを節約したいなら、`./models` をそのまま別サーバーへ転送できる。

# composeファイルをgitで管理(.envはgitignoreに追加する) $ git init $ echo ".env" >> .gitignore $ git add docker-compose.yml .gitignore $ git commit -m "initial ollama docker setup" # モデルデータを別サーバーへrsyncで転送(大容量のため時間がかかる) $ rsync -avz --progress ./models/ user@new-server:~/ollama-docker/models/ # 移行先でcomposeを起動するだけで環境が復元される # (モデルを再ダウンロードする必要がない)

注意: `.env` ファイルはパスワードやAPIキーが含まれる可能性があるため、gitignoreに必ず追加してリポジトリから除外する。`.env.example` としてキーの雛形だけコミットするのが一般的なやり方だ。

OllamaのREST APIを業務システムに組み込む方法で解説したAPI連携を行う場合、この構成のポート11434をそのまま利用できる。

4. docker statsでリソース消費をリアルタイム監視する

本番運用では、制限値を設定する前に実際のリソース消費量を計測することが重要だ。根拠のない数値で上限を設けると、Ollamaがメモリ不足で落ちたり、逆に制限が緩すぎて他のサービスに影響が出たりする。`docker stats` で実消費量を把握してから制限値を決めるのが現場での鉄則だ。

# 全コンテナのリソース使用量をリアルタイム表示 $ docker stats # 実行結果(例) CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O a1b2c3d4e5f6 ollama 12.5% 6.8GiB / 16.0GiB 42.5% 8.2kB / 2.1kB 42MB / 120MB 7890abcdef12 open-webui 0.80% 128.3MiB / 16.0GiB 0.8% 1.2kB / 0.8kB 0B / 4.1MB # 1回だけ出力して終了(シェルスクリプトや定期確認に便利) $ docker stats --no-stream

各列の見方は次のとおりだ。

・CPU %: 直近の瞬間CPU使用率(ホスト全体に対する割合)
・MEM USAGE / LIMIT: 現在のメモリ使用量 / 設定上限(制限なしならホストの全メモリが表示される)
・MEM %: 設定上限に対する使用率
・NET I/O: コンテナのネットワーク送受信量
・BLOCK I/O: ディスクI/O量

負荷試験を実施したときのピーク MEM USAGE を確認し、その1.5倍程度を `limits.memory` の値として設定するのが目安だ。Ollamaは推論中だけでなくモデルのロード直後にもメモリを大量消費するため、モデルを切り替えながら計測することを推奨する。

よくあるトラブルと対処法

Dockerを使ったOllama運用でよく遭遇するトラブルとその対処をまとめる。

「Error response from daemon: could not select device driver "" with capabilities: [[gpu]]」
NVIDIA Container Toolkitが正しくDockerに登録されていない。`sudo nvidia-ctk runtime configure --runtime=docker` を再実行し、`sudo systemctl restart docker` でDockerを再起動する。それでも解消しない場合は `/etc/docker/daemon.json` に `"default-runtime": "nvidia"` が追記されているか確認する。

「open-webuiが "Failed to connect to Ollama" と表示される」
`OLLAMA_BASE_URL` が `http://localhost:11434` になっている場合に発生する。コンテナ間通信では `localhost` はそれぞれのコンテナ自身を指すため、Ollamaには届かない。`http://ollama:11434`(コンテナ名)に変更して `docker compose up -d open-webui` で再起動する。

「GPUが認識されているのに推論が遅い」
VRAM不足でモデルが自動的にCPUにオフロードされている可能性がある。`docker compose logs -f ollama` でログを確認し、「offloading N layers to CPU」のメッセージがあればモデルが大きすぎる。量子化レベルを `-q4_0` に下げるか、より小さいパラメータ数のモデルを選ぶ。

「docker compose up -d が "no space left on device" で失敗する」
モデルファイルがディスクを埋めている。`df -h` でパーティション使用率を確認し、不要なモデルを `docker exec -it ollama ollama rm モデル名` で削除する。`./models` ディレクトリは `du -sh ./models/` で容量を確認できる。

「モデルのダウンロード中にコンテナが停止する」
ネットワークタイムアウトまたはメモリ不足が原因なことが多い。`docker exec -it ollama ollama pull モデル名` を再実行すると途中から再開される。ホストのメモリ使用状況は `free -h` で確認する。

「Ollamaコンテナが突然停止してdocker compose psでExited (137)と表示される」
カーネルのOOM Killerによってプロセスが強制終了されている可能性が高い。次のコマンドで原因を確認する。

# OOM Killerで落ちたか確認する $ docker inspect ollama --format '{{.State.OOMKilled}} {{.State.ExitCode}}' # OOM Killedの場合の出力 true 137 # OOMKilled=true、ExitCode=137(SIGKILL)はメモリ上限超過を意味する # ホスト側のOOMログも確認する $ dmesg | grep -i 'oom\|killed'

`OOMKilled: true` が確認されたら `deploy.resources.limits.memory` の値が小さすぎる。`docker stats` で実消費量を確認し、制限値を増やすかアプリ側のメモリ使用量を最適化する。

「docker compose up -d 後にopen-webuiが起動しない」
Ollamaのヘルスチェックに時間がかかりタイムアウトしている場合がある。`healthcheck.start_period` を `60s` に延長する。また `docker compose ps` でOllamaのSTATUSが `Up (starting)` のままになっていないか確認する。

「override.ymlを変更したのに設定が反映されない」
`docker compose up -d` だけでは設定変更が反映されないことがある。environmentやvolumesの変更はコンテナの再作成が必要だ。`docker compose down && docker compose up -d` でコンテナを作り直すか、`docker compose up -d --force-recreate` を使う。反映されているかどうかは `docker compose config | grep -A5 environment` で事前確認できる。

「本番デプロイで -f を使っているのにoverride.ymlの設定が混入している」
`-f` を1つでも指定した場合、`docker-compose.yml` も `-f` で明示しなければ予期しない動作をすることがある。`docker compose -f compose.prod.yml up -d`(ベースファイルを省略)ではなく、`docker compose -f docker-compose.yml -f compose.prod.yml up -d` と両方指定する。`docker compose config` でmerge結果を事前確認するのが確実だ。

まとめ

この記事では、OllamaをDockerコンテナで運用するための手順をステップ順に解説した。直接インストールよりも手順は増えるが、一度docker-compose.ymlを整えてしまえば環境の再現・チーム展開・バージョン管理が格段に楽になる。
ステップ やること 主要コマンド
事前準備 Docker Engine / NVIDIA Container Toolkit導入 sudo apt install nvidia-container-toolkit
最小起動 docker-compose.ymlでOllamaを定義・起動 docker compose up -d
モデル取得 コンテナ内でollama pullを実行 docker exec -it ollama ollama pull llama3.3:8b-instruct-q4_0
本番化 環境変数外部化・ヘルスチェック追加 docker compose up -d(compose修正後)
リソース制限 deploy.resources.limitsでCPU/メモリ上限を設定 docker stats --no-streamで実消費量を確認後に設定
設定分離 override.ymlで開発・本番設定を切り分ける docker compose -f docker-compose.yml -f compose.prod.yml up -d
WebUI連携 Open WebUIをcomposeに追加 OLLAMA_BASE_URL=http://ollama:11434
日常運用 ログ確認・モデル更新・バックアップ docker compose logs -f ollama
OOM対処 コンテナの強制終了原因を調べる docker inspect ollama --format '{{.State.OOMKilled}}'

コンテナ化したOllamaをチームで活用する次のステップとして、業務特化AIアシスタントの構築がある。OllamaのModelfileでカスタムモデルを作る方法を参照して、部門ごとのプロンプト設定をチームで使い回す仕組みを整えてほしい。

Dockerによるコンテナ化は、ローカルLLMを「個人の試験環境」から「チームの業務基盤」へ格上げする実践的な手段だ。composeファイル1枚が、将来的な移行や展開のコストを大幅に下げてくれる。

Docker+OllamaのGPU構築を2日間のハンズオンで体験する

この記事で解説したdocker-compose構成やNVIDIA Container Toolkitの設定、Open WebUI連携を、実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、DockerコンテナによるローカルLLM基盤の構築から本番運用まで体系的に学べる講座を用意しています。
>> Dockerマスター講座の詳細はこちら

ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。