やりたいこと

環境に合わせたイメージ管理を一元化したい。
ローカル開発をDockerで、本番環境をAWS EC2で構築することを想定。
※ そもそもこの構成がよろしくない説はあります。。本番と開発環境が同環境と言えなくなるので。

環境

Packer 1.0.2
Docker 17.06.0
Itamae 1.9.11
direnv 2.12.1

ソース

全然量がないので、直接読む方が早いと思います。

内容

上記の通り、詳しくはソースをという感じなんですが、
注意点や詰まった点などを記しておきます。

構成

最低限のところをPackerのProvisionerで行い、それ以降はプロビジョニングツール(今回はItamae)を利用します。
最低限のところ = ruby,itamaeのインストール、itamaeの実行です。

PackerのProvisionerで頑張ってやりきることもできないこともないですが、コマンドを羅列し続けて可読性が良くなく管理しづらくなるので、プロビジョニングツールで対応しています。
Itamaeなのは慣れてるからってだけです。

Itamae側については特に通常と変わることはないです。

sudo

今回Dockerでは、公式のcentos7のImageを使っていますが、
sudoコマンドが入ってません。
(そもそもコンテナ内ではrootで処理が行われるためだと理解してます。)

これだと他環境でsudoが必要な場面でコマンドを分けないといけないので、共通化があまりできなくなります。
なので、下記のようにdockerの場合のみsudoコマンドのインストールを追加しています。

manifest.json

{
  "type": "shell",
  "inline": [
    "yum -y install sudo"
  ],
  "only": ["docker"]
},

マウントのされ方の違い

manifest.json

{
  "type": "file",
  "source": "{{user `itamae_repo`}}",
  "destination": "{{user `itamae_destination`}}",
  "only": ["amazon-ebs"]
},
{
  "type": "file",
  "source": "{{user `itamae_repo`}}/",
  "destination": "{{user `itamae_destination`}}",
  "only": ["docker"]
},

docker側にだけ、sourceの値の末尾に/をつけてます。
マウントのされ方が違くて、こうしないと想定通りのディレクトリ構成にならなかったのでこの形をとっています。

まとめ

とりあえず、やろうと思ったことはできました。
ただやりたいことのところでも触れましたが、
そもそもコンテナとVMを一緒に管理する必要があるかというと、やってみた結果微妙な印象は受けています。。
個別で処理を分けないといけない部分もそこそこあるので、中身が膨らんできたときにしんどそうなイメージです。
(あくまで1イメージを作るものだからそんなに大きくなることはない？)
また、1コンテナ1プロセスを守ると構成的にズレが出てくるので、本来は分けるべきものかなと思います。

ただ、チームで開発する際にはイメージとして固めた状態で配れると、各メンバーの環境構築の手間と時間はかなり減るのはメリットだと思います。
イメージ作って配って各自で立てる場合だと、マスターのイメージが秘伝のタレになっていくことが懸念されますが、その際にPackerでイメージの作成手順自体がコード管理されているというのは大きな安心感を与えてくれるのかなと思います。

PackerでDockerイメージとAMIを構築する

やりたいこと

環境

ソース

内容

構成

sudo

マウントのされ方の違い

まとめ