n8nをAmazon Linux 2023にDockerで構築すると初手で失敗する理由

EC2（AWSの仮想サーバーサービス）上でn8n（オープンソースのワークフロー自動化ツール）を自前運用しようとして、最初のコマンドで詰まった経験はないでしょうか。手順書通りにsudo dnf install -y dockerを実行し、続けてdocker compose up -dを叩くと「docker: 'compose' is not a docker command」というエラーで止まります。この記事は、n8nに限らずAmazon Linux 2023でDocker Composeを使うすべてのインフラ担当者に向けた、原因の分解と再発防止の整理です。

何が起きるか

事象はシンプルです。Docker本体のインストールには成功しているのに、docker composeサブコマンドだけが認識されません。

この状態でCI/CDパイプラインの一部としてEC2上に自動プロビジョニングを組んでいると、影響範囲はさらに広がります。手動SSHでの検証時には気づかず、Terraformのuser_dataやAnsibleのプレイブックに同じインストール手順を埋め込んでしまい、本番デプロイのタイミングで初めて失敗に気づくケースが典型です。

影響を受けるのはn8nだけではありません。Docker Composeファイルでサービスを定義する構成全般（マイクロサービス構成のローカル検証環境や、監視スタックのdocker-compose.yml運用など）が同じ壁にぶつかります。

なぜ起きるか

原因は、Docker Composeの配布形態がバージョンによって変わった歴史にあります。

以前のCompose（v1系）はdocker-composeという独立した実行ファイルでした。しかしCompose v2以降は、Docker CLI（コマンドラインインターフェース）のプラグインという形式に変わりました。プラグインは/usr/local/lib/docker/cli-plugins/のようなディレクトリに配置され、CLIがそこを探しに行く仕組みです。

問題は、ディストリビューションごとにDockerエンジンとComposeプラグインの同梱状況が違う点にあります。Ubuntu系でDocker公式のaptリポジトリを使う場合、docker.ioパッケージとdocker-compose-pluginパッケージを別々にインストールする流れが定着しているため、手順書の作者はComposeが自動で付いてくる感覚で書きがちです。

一方Amazon Linux 2023のdnf install dockerは、Dockerエンジン本体だけをインストールし、Composeプラグインは含みません。つまりガイドの作者がUbuntuやVPS（仮想専用サーバー）で検証した手順を、そのままAL2023に適用すると必ず同じ場所で壊れます。これはn8nのドキュメントに限った話ではなく、AL2023をベースにしたDocker運用手順全般に共通する構造的な穴です。

自分の環境が該当するか確認する方法

影響を受けるかどうかは、次の2つのコマンドで簡単に切り分けられます。

sudo docker --version
sudo docker compose version

Dockerのバージョンだけ表示されてComposeの方がエラーになる場合、まさにこの落とし穴に該当します。加えて、使っているAMI（Amazon Machine Image）がAmazon Linux 2023系かどうかは、次のコマンドで確認できます。

cat /etc/os-release

ID="amzn"かつVERSION_ID="2023"と表示されれば対象です。TerraformでEC2を構築している場合は、aws_instanceリソースのami引数、あるいはdata "aws_ami"のフィルタ条件でamzn2-ami系かal2023-ami系かを見れば、apply前に判断できます。IaC（Infrastructure as Code、インフラをコードで定義・管理する手法）でプロビジョニングを自動化しているなら、user_dataスクリプトの中身を検索してdnf install -y dockerという行があるかどうかも確認しておく価値があります。

対策の手順

対策はComposeプラグインを手動で正しい場所に配置することです。手順は次の通りです。

sudo dnf install -y docker
sudo mkdir -p /usr/local/lib/docker/cli-plugins
sudo curl -fsSL \
  https://github.com/docker/compose/releases/download/v2.29.7/docker-compose-linux-x86_64 \
  -o /usr/local/lib/docker/cli-plugins/docker-compose
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose
sudo systemctl enable --now docker

ポイントはmkdirとcurlの2行です。CLIプラグインが探すディレクトリに、GitHub Releasesで配布されているバイナリを直接置いています。

docker --versionだけ確認して「動いた」と判断せず、必ずdocker compose versionも合わせて確認する二段階チェックを習慣にしてください。

ここでもう一つ見落としやすいのがCPUアーキテクチャです。ダウンロードURLの末尾がx86_64になっているため、これはIntel系（t3など）のインスタンス向けです。Graviton系（t4gなど、ARMアーキテクチャ）のインスタンスで同じURLを使うと、インストール自体は成功するものの実行時に「exec format error」で落ちます。ARMインスタンスの場合はファイル名をdocker-compose-linux-aarch64に変更してください。インスタンスタイプはec2-metadata --instance-typeや、AWSコンソールのインスタンス詳細から確認できます。

バージョンについては、上記のv2.29.7は執筆時点の一例です。運用ルールとして固定バージョンを使うか最新版を追いかけるかは、GitHubのdocker/composeリリースページで最新タグを確認したうえで、Terraformのuser_dataやAnsibleのvariablesにバージョン番号を変数化しておくと、更新時の変更箇所が一目で分かります。

この手順をIaCに落とし込む場合、user_dataスクリプトやAnsibleのtasksに上記5行をそのまま組み込み、CI側でterraform planやmolecule testの中にdocker compose versionを通すヘルスチェックを1行加えておくと、同じ穴に二度落ちることを防げます。オブザーバビリティ（システムの内部状態を外部から観測できるようにする設計）の観点では、これはアプリケーションのメトリクスというより「環境構築自体が期待通りに終わったか」を検証するプロビジョニングテストに近い扱いです。CloudWatchのカスタムメトリクスやログではなく、デプロイパイプライン内のスモークテストとして組み込むのが自然です。

まとめ

Amazon Linux 2023でDockerを使う際は、エンジンとComposeプラグインが別物である点を前提に手順を組み立てる必要があります。

確認すべきことは3点です。まずdocker --versionとdocker compose versionを両方叩いて二段階で確認すること。次にAMIがal2023系かどうかを/etc/os-releaseかTerraformの設定で確認すること。最後にインスタンスのCPUアーキテクチャに合わせてComposeバイナリのURLを選ぶことです。

この3点をプロビジョニング自動化のスクリプトやCIのスモークテストに組み込んでおけば、本番デプロイの初手でつまずくリスクはかなり減らせます。手順書をコピーする前に、まず自分の環境のAMIとアーキテクチャを確認するところから始めてみてください。