Colima × DockerでAWSリソースがデプロイできるTerraformコンテナを立ててみた(実践あり)

Colima × DockerでAWSリソースがデプロイできるTerraformコンテナを立ててみた(実践あり)

MacにインストールしたColimaの上に起動したDockerコンテナから、Terraformを実行してAWSリソースをデプロイしてみた経験を共有します。
2025.09.12

こんにちは。クラウド事業本部の桑野です。

今年9月にクラスメソッドにジョインしたばかりで、使うツールや新しい技術に対するキャッチアップで刺激を受ける毎日です。

私は普段プライベートで開発をする際、Dockerコンテナを立てて、なるべく複数の環境が混ざらないようにしています。

今回はmacOSでColima × Dockerを組み合わせて、AWSリソースがデプロイできるTerraformコンテナ環境を立ててみたという内容を共有します。
意外とこの3つを同時に取り上げた記事が見つからなかったので、誰かに刺さるといいなと思っています。

前提

下記の条件で検証しています。

  • OS:macOS Sequoia バージョン 15.6.1
  • チップ:Apple M4
  • Docker Client:28.4.0
  • Docker Server:28.3.3
  • Colima:0.8.4
  • docker compose:2.39.3

今回ColimaとDocker CLIのインストールにはHomebrewを使います。
Homebrewのインストールがまだの方、インストールはこちらから!

Colimaとは

https://github.com/abiosoft/colima

Colima means Containers on Lima.

「Lima上のコンテナを意味する。」だそうです(※Colimaより抜粋)
LimaというのはLinux Machineの略で、Linuxマシン上のコンテナということですね。

Dockerを使う際、Docker Desktopが真っ先に思い浮かぶかと思います。
ただし、様々な理由でDocker Desktopの採用を見送る場合、Docker Daemonを動かすためにLinux環境が必要となります。

別の方法としてLimaを使ったことがありますが、Dockerを始めるためのセットアップにかなり苦戦した記憶があります。

https://github.com/lima-vm/lima#examples

Colimaは最小限のセットアップでmacOS上でコンテナランタイムを提供することをプロジェクトの目標としています。

つまり、ColimaはDockerのセットアップを簡単にできるということですね。
早速始めてみましょう。

手順

1. Docker CLIをインストールする

Homebrewを使ってインストールします。

			
			brew install docker

		

2. Colimaをインストールする

同じようにColimaもHomebrewでインストールします。

			
			brew install colima

		

完了したら、Colimaを起動します。

			
			colima start

		

Colimaがちゃんと起動しているかチェックしてみましょう。

			
			colima status

		

↓こんな感じで表示されればOKです。

			
			INFO[0000] colima is running using macOS Virtualization.Framework 
INFO[0000] arch: aarch64                                
INFO[0000] runtime: docker                              
INFO[0000] mountType: virtiofs                          
INFO[0000] docker socket: unix:///Users/username/.colima/default/docker.sock 
INFO[0000] containerd socket: unix:///Users/username/.colima/default/containerd.sock

		

ここまでの手順は、以下の記事を参考にさせていただきました。(ありがとうございます)

https://dev.classmethod.jp/articles/migrating-from-rancher-desktop-to-colima-docker-environment/

コンテナランタイムの必要性や、Colimaの解説、さらにはRancher Desktopからの移行手順もまとめてくださっています。
ぜひチェックしてみてください!

3. Dockerfileを用意する

今回は公式が用意しているイメージをベースにAWSリソースのデプロイが可能なコンテナにしました。
Alpine Linuxがベースイメージのため、AWS CLIはapk addコマンドで簡単にインストールができます。

			
			FROM hashicorp/terraform:1.13

WORKDIR /terraform-runner

# 必要なパッケージのインストール
RUN apk update && \
    apk add --no-cache \
    aws-cli

		

今回は1.13で検証しました。
下記からお好みで選択していただければと思います。
https://hub.docker.com/r/hashicorp/terraform/tags

実践編:コンテナでAmazon VPCをデプロイしてみる

ここからは先ほどのDockerfileを使って実際にコンテナを構築し、AWS上にVPCをデプロイした手順を共有します。
実施には下記のツールが必要になります。

作成するリソース

  1. VPC
  2. 1のVPCに紐づくデフォルトセキュリティグループ(インバウンドルールとアウトバウンドルールを空に設定)

下記のGitHubリポジトリで実践してみましょう!

https://github.com/k-kuwan0/colima-docker-terraform

1. docker composeを使えるようにする

Homebrewでdocker-composeをインストールをしてもdocker composeが使えませんでした。
ですので、CLIプラグインを登録する方法で対応しました。
下記のコマンドを順に実行すればOKです。

			
			mkdir -p ~/.docker/cli-plugins
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-darwin-aarch64 -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

		

プラグインの手動インストールについては下記に載っていました。

https://docs.docker.com/compose/install/linux/#install-the-plugin-manually

2. コンテナを構築する

リポジトリのルートでビルドコマンドを実行します。

			
			docker compose build

		

イメージが作成できたら、そのままコンテナを起動します。

			
			docker compose up -d

		

3. コンテナにアクセスする

dockerコマンドで接続しても良いですが、Dev Containersを使うのが個人的におすすめです。

VSCodeのコマンドパレットを開きます。

			
			>Dev Containers: Open Folder in Container...

		

開発コンテナー: コンテナーでフォルダーを開く…を選択しましょう。
すると、Finderが表示されるので、terraform-runnerを開きます。

4. AWS CLIのプロファイルを作成する

TerraformでAWSリソースをデプロイするにはプロファイルの作成が必要です。

今回は新しくcolima-docker-terraformというプロファイル名で作ります。
IAMユーザーのクレデンシャルを指定するので、あらかじめアクセスキーとシークレットアクセスキーを発行しておきましょう。

			
			aws configure --profile colima-docker-terraform

		

ウィザードに従って各種情報を入力します。
リポジトリルートにある.awsディレクトリの中にconfigcredentialsが出来上がっていればOKです。

使用したIAMポリシーは下記の通り、Pikeで生成しました。
PikeはTerraformコードから必要なIAMポリシーを自動生成するツールです。

			
			{
    "Version": "2012-10-17",
    "Statement": [
	    {
		    "Sid": "VisualEditor0",
		    "Effect": "Allow",
		    "Action": [
			    "dynamodb:DeleteItem",
			    "dynamodb:DescribeTable",
			    "dynamodb:GetItem",
			    "dynamodb:PutItem"
		    ],
		    "Resource": [
			    "*"
		    ]
	    },
	    {
		    "Sid": "VisualEditor1",
		    "Effect": "Allow",
		    "Action": [
			    "ec2:AuthorizeSecurityGroupEgress",
			    "ec2:AuthorizeSecurityGroupIngress",
			    "ec2:CreateTags",
			    "ec2:CreateVPC",
			    "ec2:DeleteTags",
			    "ec2:DeleteVPC",
			    "ec2:DescribeAccountAttributes",
			    "ec2:DescribeNetworkAcls",
			    "ec2:DescribeSecurityGroups",
			    "ec2:DescribeVpcAttribute",
			    "ec2:DescribeVpcs",
			    "ec2:ModifyVpcAttribute",
			    "ec2:ModifyVpcTenancy",
			    "ec2:RevokeSecurityGroupEgress",
			    "ec2:RevokeSecurityGroupIngress",
			    "ec2:DescribeSecurityGroupRules"
		    ],
		    "Resource": [
			    "*"
		    ]
	    },
	    {
		    "Sid": "VisualEditor2",
		    "Effect": "Allow",
		    "Action": [
			    "s3:DeleteObject",
			    "s3:GetObject",
			    "s3:ListBucket",
			    "s3:PutObject"
		    ],
		    "Resource": [
			    "*"
		    ]
	    }
    ]
}

		

AdministratorAccessなどの強い権限を割り当てることも可能ですが、私は今回、極力小さい権限をIAMユーザーにインラインポリシーで付与して検証することにしました。

5. Terraform stateを保管するS3バケットを作成する

複数人で触っても良いように、stateファイルはS3に保管するようにします。

/terraform-runner/environments/dev/backend.tfファイルのbucketにお好みの文字列を指定し、同じ名称でS3バケットを作成しておいてください。

6. Terraformを実行する

terraform-runner/environments/devに移動し、Terraformコマンドを実行していきます。

			
			# 実行するtfファイルのあるディレクトリに移動
cd /terraform-runner/environments/dev

# terraformコマンドを実行する
terraform init

# 作成されるリソースがVPCとデフォルトのセキュリティグループ(ルールが空)の2つであることを確認してください。
terraform plan

# planの内容で作成して問題なければ、yes を入力しましょう!
terraform apply

		

terraform planでは下記の通り、terraformが操作するリソースが出力されます。

			
			Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
  + create

Terraform will perform the following actions:

  # aws_default_security_group.default will be created
  + resource "aws_default_security_group" "default" {
    + arn                    = (known after apply)
    + description            = (known after apply)
    + egress                 = (known after apply)
    + ingress                = (known after apply)
    + owner_id               = (known after apply)
    + region                 = "ap-northeast-1"
    + revoke_rules_on_delete = false
    + tags                   = {
        + "Name" = "colima-docker-terraform-dev-vpc-default-security-group"
      }
    + tags_all               = {
        + "Name" = "colima-docker-terraform-dev-vpc-default-security-group"
      }
    + vpc_id                 = (known after apply)
  }

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
    + arn                                  = (known after apply)
    + cidr_block                           = "10.0.0.0/16"
    + default_network_acl_id               = (known after apply)
    + default_route_table_id               = (known after apply)
    + default_security_group_id            = (known after apply)
    + dhcp_options_id                      = (known after apply)
    + enable_dns_hostnames                 = (known after apply)
    + enable_dns_support                   = true
    + enable_network_address_usage_metrics = (known after apply)
    + id                                   = (known after apply)
    + instance_tenancy                     = "default"
    + ipv6_association_id                  = (known after apply)
    + ipv6_cidr_block                      = (known after apply)
    + ipv6_cidr_block_network_border_group = (known after apply)
    + main_route_table_id                  = (known after apply)
    + owner_id                             = (known after apply)
    + region                               = "ap-northeast-1"
    + tags                                 = {
        + "Name" = "colima-docker-terraform-dev-vpc"
      }
    + tags_all                             = {
        + "Name" = "colima-docker-terraform-dev-vpc"
      }
  }

Plan: 2 to add, 0 to change, 0 to destroy.

		

7. 確認

AWSマネジメントコンソールにアクセスし、下の画面キャプチャのようにリソースが作成できていれば成功です。

vpc-screenshot

default-sg-screenshot

8. リソースの破棄

Terraform実行で作成したリソースは検証が終わったら削除しておきましょう。

			
			# 削除されるリソースがVPCとデフォルトのセキュリティグループ(ルールが空)の2つであることを確認してください。
terraform destroy

		

ここまでお疲れ様でした!!

まとめ

TerraformのDockerイメージがAlpineベースだったこともあり、Node.jsのyarn add xxxやPythonのpip install xxxのような感じで、apk add xxxコマンドでAWS CLIも簡単にインストールすることができました。
実際にやってみて、思っていたよりも短時間で用意することができるということがわかりました。
Docker環境は使用するツールがひと目でわかる、やり直しが効く、環境が分離できたりと検証にはもってこいだと考えています。

興味を持った方はぜひ試してみてください。

この記事をシェアする

FacebookHatena blogX

関連記事