TerraformやAnsibleを直接インストールするのはやめよう：DockerでCLIを実行してホストマシンをクリーンに保つ方法 – ITFROMZERO

Table of Contents

「依存関係の地獄（Dependency Hell）」という悩み

プロジェクトAではTerraform 0.12が必要なのに、プロジェクトBでは最新の1.5を求められる、といった「笑えない状況」に陥ったことはありませんか？さらに厄介なことに、AI開発のためにPython 3.11をインストールしているのに、AnsibleがPython 3.8を要求することもあります。プロジェクトを切り替えるたびにインストールやPATHの設定をやり直し、気づけばOSの中身は収拾がつかないほどカオスな状態になってしまいます。

かつて私は、新しいEKS機能との互換性のために古いAWS CLI v1を完全に削除してv2をインストールするだけで、丸4時間を無駄にしたことがあります。その時、「なぜ自分の作業マシンを、これほど多種多様なツールの実験場にしなければならないのか？」と自問しました。Dockerはサーバーのためだけのものではありません。これらのツールを完全に分離してくれる「救世主」なのです。

50以上のプロジェクトを抱えるシステムを運用していた際、Docker CLIを導入したことで、環境に起因するエラーが90%減少し、不要なバイナリファイルによるストレージ容量を数十GBも節約することができました。

Docker：あらゆるCLIツールのための「クリーンな箱」

システムに直接binaryをインストールする代わりに、それらをコンテナの中に閉じ込めます。最大のメリットは、各コンテナが独立した環境であることです。特定のバージョンのTerraformが必要ですか？適切なイメージタグを呼び出すだけです。実行が終わればコンテナは自動的に破棄され、ホストマシンは新品同様にクリーンなままです。

「Dockerの中で動かして、ローカルのコードや認証情報をどうやって読み取るの？」と心配する方もいるでしょう。その鍵はボリュームマウント（-vパラメータ）にあります。現在の作業ディレクトリをコンテナ内にマッピングすることで、CLIは通常通りファイルを処理しつつ、ソフトウェア自体はDockerという「箱」の中に収まった状態を保てます。

1. AWS CLIを実行する：煩雑なインストーラーにさよなら

通常はMSIをダウンロードしたり、複雑なインストールスクリプトを実行したりする必要がありますが、DockerならS3バケットをリストアップするのもコマンド一行です：

docker run --rm -it \
  -v ~/.aws:/root/.aws \
  amazon/aws-cli s3 ls

パラメータの簡単な分析：

--rm: コンテナ終了時にその痕跡を完全に削除します。
-it: ターミナルとの対話を可能にします。パスワード入力やMFA認証が必要な場合に不可欠です。
-v ~/.aws:/root/.aws: ホストマシンの認証情報へのアクセスを共有し、コンテナ内のAWS CLIがアカウントを認識できるようにします。

2. Terraform Dockerでインフラ管理

tfenvやasdfを使う代わりに、HashiCorp公式イメージの使用を推奨します。main.tfがあるディレクトリにいると仮定しましょう：

docker run --rm -v $(pwd):/workspace -w /workspace hashicorp/terraform:1.5.0 init
docker run --rm -u $(id -u):$(id -g) -v $(pwd):/workspace -w /workspace hashicorp/terraform:1.5.0 plan

重要な注意点：

-w /workspace: コンテナ内の作業ディレクトリを指定します。
-u $(id -u):$(id -g): 生成されるファイルの所有者がrootにならないようにするためのフラグです。Linux/macOSでのパーミッションエラーを防ぎます。

別のプロジェクトで旧バージョンが必要ですか？1.5.0を0.12.31に書き換えるだけで、一瞬で切り替え完了です。

3. Ansible：Pythonライブラリ破損の恐怖からの解放

Ansibleは多くの依存関係を伴います。直接インストールすると、マシン上の他の重要なPythonスクリプトを壊してしまうことがよくあります。超軽量なAlpine版を試してみましょう：

docker run --rm -it \
  -v $(pwd):/ansible \
  -v ~/.ssh:/root/.ssh:ro \
  williamyeh/ansible:alpine-2.9 \
  ansible-playbook -i hosts site.yml

小技：SSHボリュームの末尾にある:roパラメータは、Ansibleがサーバー接続にキーを使用することを許可しつつ、元のキーファイルを変更したり削除したりすることを完全に禁止します。

Alias（エイリアス）を活用して、インストール済みのように快適に使う

terraform planを実行するたびに長いコマンドを打ちたい人はいません。.bashrcや.zshrcのaliasを活用して、操作を短縮しましょう：

# シェル設定ファイルに追加
alias terraform='docker run --rm -v "$(pwd)":/workspace -w /workspace hashicorp/terraform:latest'
alias aws='docker run --rm -it -v ~/.aws:/root/.aws -v "$(pwd)":/aws amazon/aws-cli'

保存後は、terraform planやaws s3 lsと打つだけです。マシンに直接インストールされているかのようなスムーズな操作感ですが、裏側ではDockerがすべてを処理してくれています。

トラブルを避けるための3つの重要な注意点

非常に便利ですが、いくつか注意すべき点があります：

相対パスを優先する: アプリはコンテナ内で動作するため、/Users/name/projectのような絶対パスは存在しません。常に./file_nameを使用してください。
起動のオーバーヘッド: Dockerコンテナの初期化には約0.5〜1秒かかります。通常のCLIコマンドなら問題ありませんが、スクリプトで数千回ループさせる場合は考慮が必要です。
ネットワーク通信: コンテナからホストマシンのlocalhostにアクセスする必要がある場合は、--network="host"フラグを忘れずに追加してください。

結論

CLIをDockerに移行することは、単なる技術的な「トレンド」ではありません。開発環境を安定に保つための、プロフェッショナルな働き方です。OSのアップデートやマシンの買い替えを恐れる必要はもうありません。今日からAWS CLIやTerraformで試してみてください。ツール管理がこれほどまでに楽になると実感できるはずです。