MacでDockerComposeがすぐ動く！つまずかない初めの一歩ガイド

起動待ちのあいだ、クジラマークがアニメーションするので焦らず待つとスムーズです。

開発中にCompose設定を変えたら、docker compose down→up -dで再読み込みすると迷わず反映できます。

DockerDesktopを公式サイトから入れる方法

公式サイトから入手する方法は、ブラウザでDocker公式ページにアクセスして、Mac向けのインストーラ（.dmgファイル）をダウンロードするだけです。ファイルを開いたらアプリケーションフォルダへドラッグ＆ドロップして起動すれば、すぐにDockerDesktopが使い始められます。

公式インストーラ版を選ぶときのポイントは以下の通りです。

この方法は、コマンド操作に慣れていない方や、公式の安定版をサクッと入れたいときに特におすすめです。

①公式サイトにアクセスしてインストーラをダウンロード

CPUタイプを間違えるとインストールが進まないので「このMacについて」で確認を忘れずに。

ダウンロード完了後は「ダウンロード」フォルダにDockerDesktop.dmgが保存されています。

②ダウンロードしたdmgを開いてアイコンをApplicationsへドラッグ

③初回起動で権限を許可してセットアップを完了

鍵アイコンがグレーアウトしているときは、クリック後に管理者パスワードを入力する必要があります。

「セキュリティとプライバシー」はアップルメニューの「システム設定」→「プライバシーとセキュリティ」からも開けます。

④メニューバーのクジラをクリックしてCompose対応を確認

Composeが見つからない場合はDocker Desktopのバージョンが古いか無効になっています。設定画面のExperimentalFeaturesで有効化しましょう。

補足として、ターミナルでdocker compose versionを実行するとComposeをコマンドラインで使えるかすぐ確認できます。

HomebrewでDockerとComposeをまとめて入れる方法

Homebrewを使えば、ターミナルからたった一行でDocker DesktopとComposeプラグインをまとめてインストールできます。brew install –cask dockerを実行するだけで、最新のDockerアプリとComposeが自動的に揃うので、あれこれダウンロード先を探し回る必要がありません。

この方法ならバージョンアップの管理もHomebrewにお任せできて、brew upgradeだけでDockerとComposeをまとめて更新できます。コマンドライン操作が慣れている方や、インストール状況をすっきり管理したい方にぴったりです。

①ターミナルを開いてbrew updateを実行

ターミナルで数字のインストール進捗が表示されるので焦らず待つと安心です。

②brew installコマンドでdockerとdocker-composeをインストール

Dockerデスクトップアプリを使わずCLIだけで動かす場合は、自分でデーモン（バックグラウンドサービス）を立ち上げる必要があります。

補足として、Docker Desktopをお使いの場合は brew install --cask docker を使うとGUI版がインストールでき、その中にCompose機能も含まれています。

③docker –versionで動作をチェック

ターミナルを開いてDockerがきちんと動いているか確認します。

以下のコマンドを入力してください。

docker --version

バージョン情報として「Docker version 20.10.x」などが表示されれば準備完了です。もし「command not found」などのエラーが出たら、Docker Desktopが起動中か、またはインストール先パスに問題がないかチェックしましょう。

Tip PATH設定が原因でコマンドが見つからないことがあります。/usr/local/binあたりが含まれているか、echo $PATHで確認してみてください。

④compose.ymlを用意してdocker compose upを試す

version: "3.9"
services:
  app:
    image: nginx:latest
    ports:
      - "8080:80"

AppleSiliconとIntelMacどちらでもうまく動かすコツ

AppleSiliconとIntelMacで同じdocker‐compose.ymlを使うとき、ちょっとしたコツを押さえるとスムーズに動いてくれます。

これらを組み合わせると一度書いたCompose設定がAppleSiliconでもIntelMacでも迷わず動いてくれるようになります。次のステップでは、具体的なコマンドや設定例をご紹介します。

①Rosettaの有無を確認して設定を切り替える

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Rosetta対応のDockerは動作がやや遅くなる場合があります

Apple Silicon向けのCompose v2はネイティブ対応なので、Rosetta必須はCompose v1利用時のケースだけにしましょう。

②プラットフォームarm64指定のイメージを選ぶ

Docker Hubで公式イメージを開き、Architecture欄にarm64が含まれているか確認しましょう。

arm64非対応イメージはエミュレーションで動かせますが、起動やレスポンスが遅くなることがあります。

③–platformオプションで強制指定する

Intel向けイメージをARM環境で動かすための方法ですが、エミュレーションにより起動や動作が少し遅くなる点は覚えておくと安心です。

Composeコマンドで開発環境を一瞬で立ち上げる応用ワザ

実際に組み合わせると、たとえば docker-compose up -d --build --force-recreate --parallel だけで、変更を反映しつつ不要な再起動やキャッシュの不整合を避けながらサクッと開発環境を立ち上げられます。普段は煩わしかったログ確認も、docker-compose logs -f と併用すればリアルタイムでトラブルもすぐキャッチできます。

複数サービスをリンクしてフロントとバックを同時起動

フロントエンドとバックエンドを別々のDockerサービスとして定義し、Composeでまとめて起動すると、「一度のコマンドで開発環境がそろう」ので手軽です。

サービス同士はComposeが自動的にネットワークでつないでくれるため、ホスト名でアクセスできるようになります。依存関係をdepends_onで書いておくと、バックエンドが先に立ち上がり、続いてフロントエンドが起動するように調整できます。

この方法はバックエンドAPIと組み合わせた画面開発や、変更をリアルタイムに反映しながらテストしたいときにおすすめです。ボリュームマウントやキャッシュ設定を工夫しておくと、コード修正からのリロード時間がグッと短くなります。

compose.ymlにwebとapiを定義する

docker-compose.ymlにwebとapiを並べるだけで、開発環境が一気に楽しくなります。ここではweb（フロント用）とapi（バックエンド用）のサービスを具体的に書いていきます。

version: '3.8'
services:
  web:
    build:
      context: ./web
      dockerfile: Dockerfile
    ports:
      - '3000:3000'
    volumes:
      - ./web:/app
    environment:
      - NODE_ENV=development

  api:
    build:
      context: ./api
      dockerfile: Dockerfile
    ports:
      - '8000:8000'
    volumes:
      - ./api:/app
    environment:
      - FLASK_ENV=development
    depends_on:
      - web
networks:
  default:
    driver: bridge

こちらの例ではwebとapiそれぞれにビルド設定とポートマッピングを用意しています。volumesを使うことでローカルコードがそのまま反映され、ファイル変更のたびにコンテナを再起動しなくてすみます。

depends_onを追加すると、apiの起動前にwebが起動するよう順序を保証できます。

経験上、複数サービスで同じネットワークにいるとお互いのホスト名（webやapi）で通信できて便利でした。

依存関係をdepends_onでつなぐ

version: '3.8'
services:
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: example

  app:
    build: .
    depends_on:
      - db

depends_onは起動順のみを制御します。データベースが接続可能になるまで待つわけではない点に注意してください。

もしサービスの準備完了を待ちたい場合は、healthcheckを組み合わせて運用するとより安心です。

docker compose upで両方まとめて起動する

ボリュームを使ってデータを残したままコンテナを作り直す

コンテナを作り直すと、ふつうは中のデータがリセットされてしまいます。でも、ボリュームを使えば作り直してもデータが消えないので、データベースやアップロードファイルを安心して扱えます。

DockerComposeならyamlに「volumes」で名前をつけるだけでOKです。コンテナを削除しても、ボリュームだけはそのまま残るので、次に同じ名前のボリュームをマウントすれば一瞬で復活します。初学者の頃に何度かデータを飛ばしてしまった経験があるなら、まずはここを設定してみてください。

volumesセクションに名前付きボリュームを書く

namedボリュームを使うとコンテナを再作成してもデータが残って安心です。ここではdocker-compose.ymlにvolumeの名前を書く方法を順番にまとめます。

volumes:
  db_data:

services:
  db:
    image: mysql
    volumes:
      - db_data:/var/lib/mysql

既存の同名ボリュームがあるとマウント先が上書きされるので、名前はプロジェクト単位でユニークにすると安全です。

namedボリュームはdocker volume lsで管理できます。データの中身を確認したいときはdocker run -v db_data:/data –rm busybox shなどで直接見ると便利です。

docker compose downしてもデータが消えないことを確認

開発データを維持したまま再立ち上げする

cd ~/projects/my-app

docker-compose down
docker-compose up -d

docker-compose down に-v を付けるとボリュームが消えてしまうので注意してください。

実体験ではMySQLコンテナを再起動するとき、データベースが消えて焦ったことがあるので、いつもこの手順でデータを守っています。

環境変数ファイルで設定を切り替えてチーム共有

チームでDockerComposeを使うとき、環境ごとの設定がバラバラだと「あれ、このDBパス誰の？」と混乱しがちです。

そこでおすすめなのが、環境変数ファイルを切り替える方法です。たとえば、開発用は.env.development、本番用は.env.productionというようにファイルを分けておくと、設定の使い回しがグッと楽になります。

この方法ならチームメンバーごとにローカル設定を上書きしつつ、共通のComposeファイルはそのまま共有できます。加えて、CI環境でも同じファイル名を使うだけで本番準備がスムーズなので、設定ミスが減るのが嬉しいポイントです。

実際に使う際は、リポジトリに.env.exampleを置いて必要な変数を一覧にし、個人ファイルは.gitignoreに入れておくと安心です。こうすると初めてプロジェクトに参加するメンバーでも迷わず設定を準備できます。

.envファイルを用意して秘密情報を分離する

.envファイルには機密情報が含まれるため、必ず.gitignoreに追加してバージョン管理対象外にしてください。

compose.ymlで${}記法を使って参照する

変数にスペースや特殊文字が含まれる場合は、必ずダブルクォートで囲んでください。

.envはプロジェクトごとに異なる設定を管理しやすくするので、複数人開発でも安心です。

環境ごとに.env.exampleを用意して共有する

よくある質問

DockerDesktopのインストール時に必要な権限が求められるのはなぜ？

Macのセキュリティ設定でシステム変更に管理者権限が必要になるためです。案内に従いシステム環境設定＞セキュリティとプライバシー＞一般タブでDockerDesktopを許可すれば続行できます。

docker-composeコマンドが見つからないと出るときは？

最新バージョンではdocker compose（スペースあり）が推奨です。ターミナルで

docker compose version

を実行して動作を確認してみてください。

コンテナが停止しないときはどうすればいい？

まずdocker ps -aqで対象IDを確認しdocker stop IDを試します。強制終了したいならdocker kill IDを使います。それでも残る場合はDockerDesktopのUIからコンテナを削除するとすっきりします。

DockerDesktopは有料なの？

DockerDesktopは個人利用や売上規模が小さいチームなら無料で使えます。

ただし会社の売上が一定を超える場合はサブスクリプション契約が必要です。次のようなプランが用意されています。

最新バージョンをインストールするとプランの選択画面が表示されるので、自分の利用ケースに合ったプランを選んでください。

compose.ymlとdocker-compose.ymlはどう違う？

docker-compose.ymlはDocker Composeが何も指定しないときに自動で探す標準ファイル名です。

compose.ymlはあくまでも任意のファイル名なので、Docker Composeに使いたいファイルを明示的に伝える必要があります。たとえば、docker compose -f compose.yml upのように書くイメージです。

中身のフォーマットや書き方は完全に同じなので、サービス定義やネットワーク・ボリュームの設定も両方でまったく同じように動きます。

実際の現場では環境ごとにファイルを分けるときに、compose.dev.ymlやcompose.prod.ymlといった命名にすると管理しやすくなります。

brewで入れたDockerとDockerDesktopは一緒に使える？

brewで入れたDocker（CLIツール）とDockerDesktop（GUI付き環境）は同じマシンに置いても問題ありません。ただし、どちらもデフォルトで同じUNIXソケット（/var/run/docker.sock）を使おうとするため、同時に起動すると衝突することがあります。

実際には、brew版Dockerはコマンドだけ提供していて、DockerDaemonは別途起動が必要です。一方、DockerDesktopはバックグラウンドでデーモンを管理してくれるので、初心者にはこちらのほうが手軽です。日常的にGUIからコンテナを操作したいなら、DockerDesktopに揃えておいたほうがトラブルが減ります。

どうしてもbrew版のdockerコマンドだけ使いたい場合は、DockerDesktopをインストールした状態でbrew版を残し、DockerDesktopのデーモンを動かしている状態でbrew版のCLIを使うようにすると混乱を避けられます。軽い試し運用ならbrew版、GUIで楽に操作したいならDockerDesktopと、お好みに合わせて使い分けてみてください。

AppleSiliconで動かないイメージはどうする？

AppleSiliconだとIntel向けのイメージは起動時にアーキテクチャエラーで止まってしまいます。そんなときに頼れるのがマルチアーキテクチャ対応イメージやQEMUエミュレータです。

具体的にはDockerHubでarm64タグ付きのイメージを探すか、buildxで自分のマシン向けに再ビルドするのがいちばん手軽でした。どうしてもそのまま使いたいイメージがあるときはRosetta2でamd64環境をエミュレートする方法もあります。

ネットワークが重い時のpullを速くする方法は？

ネットワークが重くてpullがちっとも進まないとイライラしますよね。そんな時はレジストリミラーを活用すると驚くほどスピードアップします。

Docker Desktopの設定画面で国内のミラーURLをポンと貼り付けるだけ。手元から遠い海外サーバーを経由せずにダウンロードできるので、通信がスムーズになります。

社内ネットワークが安定しているなら、自前のローカルレジストリを立てるのもおすすめです。イメージを一度キャッシュしておけば、以降はネット混雑を気にせず高速に取得できます。

この方法なら、大きなイメージを何度もpullする場面でもストレスフリーになります。ぜひ気軽に試してみてくださいね。

まとめ

MacでDockerDesktopを手軽に使い始めるなら、ここまでのステップで準備万端になりました。