LoginSignup
6
5

More than 5 years have passed since last update.

packerでhvmでもresize2fsをできるようにしてrebootを回避する

Last updated at Posted at 2014-12-16

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

おなじことがcloud-initを用いてもできるような気がしています。
http://dev.classmethod.jp/cloud/centos-6-x86_64-with-updates-hvm-cloud-init/
ただしpackerつかってるのでそっちでやったほうがラクというか。
何も設定せずにcloud-initいれただけのamiつくったらログインできなかったですorz
設定ファイルに書いた内容と具体的に裏で何してくれちゃうのかちゃんと理解できないとやりたくないけど調べるのが手間だったので。
軟弱ものですみません。

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

・とりあえずぐぐる
以下URL先で同様の現象と対策を知る
http://hack.aipo.com/archives/6940/
fdiskで拡張するほかにこんなやり方もあったんだーと目からうろこ。
でもreboot必須とか詰んだー!と思いました。(手間と自動化的に)

・問題提起というか相談してみた
(ぎじゅつ的に)とんがり系のおかたに、
パーティションテーブルの問題なら以下URLのようなのをpackerに仕込んだらどうか
 と提案いただいたというか教えていただきました
http://dev.classmethod.jp/etc/centos-on-ec2-disksize-change/

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

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をビルドする方法について
インストールはhttp://www.packer.io/intro/getting-started/setup.htmlで確認できます。
テンプレートは以下のような感じ(vpcつかってるとvpc_idも必要です。今時はvpcつかわないのあんまりないかも。)

{
  "variables": {
    "aws_access_key": "AKI**********",
    "aws_secret_key": "Pca4**********",
    "aws_source_ami": "ami-54**********",
    "aws_region_name": "ap-so**********",
    "aws_instance_type": "m3.medium",
    "aws_vpc_id": "vpc-0a**********",
    "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に実行するスクリプトについて指定します
こちらのページにも解説が↓
http://www.ryuzee.com/contents/blog/6697
 スクリプトには自作AMI作るときとかにやるような基本的なベースの設定を仕込んどくとよいです。
 cloud-initで仕込むっぽい内容というかchefながす手前のセッティングなど。
 たとえば、
  一般的なリポジトリや全部に絶対入れるやつ入れとくとか、sshまわりや最小限のユーザや自動起動設定などなど
※そもそもテンプレートで指定するAMIはhvmのが要ります。つくりかた⇒http://devlab.isao.co.jp/hvm_instance/

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

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

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

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

6
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
5