こんにちは。小宮です。 packerでhvmでもresize2fsをできるようにしてrebootを回避するというのをやってみました。

おなじことがcloud-initを用いてもできるような気がしています。 CentOS 6 (HVM)にcloud-initを設定してAmazon Linuxぽくする ｜ Developers.IO ただしpackerつかってるのでそっちでやったほうがラクというか。 何も設定せずにcloud-initいれただけのamiつくったらログインできなかったですorz 設定ファイルに書いた内容と具体的に裏で何してくれちゃうのかちゃんと理解できないとやりたくないけど調べるのが手間だったので。 軟弱ものですみません。

・事の発端 CentOS6.5のオレ俺AMIをもとにhvmのインスタンス作ったところ、 chefレシピで流して自動でresize2fsがrootボリュームに対して実施されたはずが サイズ変わらず。 10から50GBになるはずだったけど10GBのままになっていた

・とりあえずぐぐる 以下URL先で同様の現象と対策を知る EC2のCentOS-HVMでディスクのサイズを変更する | Hack fdiskで拡張するほかにこんなやり方もあったんだーと目からうろこ。 でもってreboot必須って詰んだー！と思いました。（手間と自動化的に） 具体的にいうとresize2fsはchefレシピ流してやってるのでログインしてやるのは二度手間です。

・問題提起というか相談してみた （ぎじゅつ的に）とんがり系のおかたに、 パーティションテーブルの問題なら以下URLのようなのをpackerに仕込んだらどうか 　と提案いただいたというか教えていただきました CentOS on Amazon EC2 でディスクサイズ変更しても変わらないときの対処方法 ｜ Developers.IO

・実際やってみたら成功した

packerに仕込んでるシェルスクリプトに以下を追加

+# growroot等をepelからインストール
+yum -y --enablerepo=epel install dracut-modules-growroot cloud-utils
+
+# rootパーティションテーブルをリサイズ
+dracut --force --add growroot /boot/initramfs-$(uname -r).img

で、packerでAMIをビルド、 そのAMIから作成したインスタンスにchefレシピを流してみると、 dfしてみたところディスクが拡張されてました。 rebootしなくて済んだ！！わーい！ めでたしめでたし。

・packerで俺オレAMIをビルドする方法について インストールはInstall Packer - Packer by HashiCorpで確認できます。 テンプレートは以下のような感じ（vpcつかってるとvpc_idやsubnet_idも必要です。今時はvpcつかわないのあんまりないかも。）

{
  "variables": {
    "aws_access_key": "AKB**********",
    "aws_secret_key": "Pga4**********",
    "aws_source_ami": "ami-53**********",
    "aws_region_name": "ap-so**********",
    "aws_instance_type": "t2.small",
    "aws_vpc_id": "vpc-0z**********",
    "aws_subnet_id": "subnet-0**********",
    "aws_create_date": ""
  },
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "{{user `aws_region_name`}}",
    "source_ami": "{{user `aws_source_ami`}}",
    "instance_type": "{{user `aws_instance_type`}}",
    "ssh_username": "root",
    "ssh_timeout": "10m",
    "subnet_id": "{{user `aws_subnet_id`}}",
    "vpc_id": "{{user `aws_vpc_id`}}",
    "associate_public_ip_address": true,
    "ami_name": "AMI_standard_{{user `aws_create_date`}}",
    "tags": {
      "Name": "AMI_standard_{{user `aws_create_date`}}"
    }
  }],
  "provisioners": [{
    "type": "shell",
    "execute_command": "sh {{ .Path }} {{user `aws_region_name`}}",
    "script": "ami-deploy.sh"
  }]
}

※provisionersに実行するスクリプトについて指定します こちらのページ[速報]Packerでさまざまな仮想マシンのテンプレートを作成する | Ryuzee.comにも解説が。 　スクリプトには自作AMI作るときにやるような基本的なベースの設定を仕込んどくとよいです。 　cloud-initで仕込むっぽい内容というかchefながす手前のセッティングなど。 　たとえば、 　　一般的なリポジトリや全部に絶対入れるやつ入れとく、sshまわりや最小限のユーザや自動起動設定などなど ※そもそもテンプレートで指定するAMIはhvmのが要ります。つくりかたは稲田さんの記事をどうぞご覧ください。⇒PV InstanceからHVM Instanceへ変換(CentOS6)

ビルドコマンドは以下のように実行します。 （標準出力に実行状況が色々出るのでバックグラウンドに渡さないほうがいいでしょう）

CREATE_DATE=`date +'%Y%m%d'`
packer build -var aws_create_date=${CREATE_DATE} templatefile.json

※20～30分くらいかかる感じでした windowsからも実行できるらしいけど、linuxでいけるlinuxのほうが得意っぽい処理をよりによって私がwinでやると詰みそう。心理的な障壁が高めでやる気がおきない。

とりあえず個人的にやりやすい方法で目的が達せられたのでこんなところで。 cloud-initもそのうち調べてやってみたいとは思ってます。脳内積みタスク優先順位低（強制的な機会がないとわすれそう）。

ではみていただいてありがとうございました。