読者です 読者をやめる 読者になる 読者になる

LIVESENSE made*

リブセンスのエンジニアやデザイナーの活動や注目していることをまとめたブログです。

MENU

Terraform & Packer での運用におけるサーバの構成変更

AWS Insfrastructure as Code Terraform インフラ 開発 運用 Packer

こんにちは、エンジニアの野本です。先日、door 賃貸をオンプレから AWS に移行した際、Terraform & Packer を中心に行ったという話を紹介しました。サーバの構成変更が必要な場合は Packer & Ansible で AMI を再作成、Terraform にて入れ替えるといういわゆる Immutable Infrastructure な運用をしているのですが、基本的には無停止でオンラインで入れ替える必要があり、それを行うのに工夫している部分をご紹介します。

Packer / Terraform による構成管理

Packer による AMI の作成

Packer の build にて、Ansible を利用して以下のようなものをプロビジョニングするようにします。

  • 各種ミドルウェアとその基本的な設定
  • 監視 / ログ収集 / デプロイのエージェント

この際、ステージング環境や本番環境に依存するような設定は、実際の起動時に cloud-init で設定を注入出来るように設定ファイルのテンプレートを配置しておくなどの対応をして、その環境の差分をなくすように構築するようにしておきます。

Terraform でのインスタンス起動時の user-data の利用

Packer にて作成した AMI を元にインスタンスを起動しますが、先の Packer のところで説明したように、環境が決まって初めて決定される設定項目は cloud-init を利用して設定を行います。 cloud-init で実行する基本的な user-data を template_file (0.7 以降であれば data として) で作成、Terraform の実行時に環境毎の vars で設定してある内容で user-data を生成するようにします。

このように Packer と Terraform の設定を行い、ステージングでも本番環境に対して行うのとほぼ同等のオペレーションを実施 / 検証出来るようになっています。

Terraform でのサーバの入れ替えの為の設定 / 作業

Auto Scaling グループに対する ELB 付け外しの利用

現在の Auto Scaling グループは ELB の付け外しが出来るようになっているので、これを利用します。Auto Scaling は blue / green の2系統を用意、ELB も本番用 / 確認用の2つを用意しています。

基本的な Terraform の設定はこちら。各設定は説明のために簡略化されてます。

autoscale.tf
resource "aws_launch_configuration" "blue" {
  image_id = "${var.blue_ami_id}"
  instance_type = "${var.blue_instance_type}"
  user_data = "${template_file.user_data_blue.rendered}"
  ...
}

resource "aws_autoscaling_group" "blue" {
  launch_configuration = "${aws_launch_configuration.blue.id}"
  min_size = "${var.blue_min_size}"
  max_size = "${var.blue_max_size}"
  load_balancers = ["${var.blue_elb_name}"]
  ...
}

resource "aws_launch_configuration" "green" {
  image_id = "${var.green_ami_id}"
  instance_type = "${var.green_instance_type}"
  user_data = "${template_file.user_data_green.rendered}"
  ...
}

resource "aws_autoscaling_group" "green" {
  launch_configuration = "${aws_launch_configuration.green.id}"
  min_size = "${var.green_min_size}"
  max_size = "${var.green_max_size}"
  load_balancers = ["${var.green_elb_name}"]
  ...
}
elb.tf
resource "aws_elb" "prd" {
    name = "elb_prd"
    ...
}

resource "aws_elb" "test" {
    name = "elb_test"
    ...
}
codedeploy.tf
resource "aws_codedeploy_app" "app" {
  name = "app"
}

resource "aws_codedeploy_deployment_group" "app" {
  app_name = "${aws_codedeploy_app.app.name}"
  deployment_group_name = "app"
  autoscaling_groups = [
    "${aws_autoscaling_group.blue.id}",
    "${aws_autoscaling_group.green.id}"
  ]
  ...
}
variables.tfvars
blue_ami_id = "ami-12345xyz"
blue_min_size = "2"
blue_max_size = "4"
blue_elb_name = "elb_prd"

green_ami_id = "ami-12345xyz"
green_min_size = "0"
green_max_size = "0"
green_elb_name = "elb_test"

参考にしたものはこちら

また、今回は blue green deploy の話ではないのですが、CodeDeploy を利用して blue / green のAuto Scaling ともに同じ deployment group を設定しておくと、新しく構築した系統のサーバにアプリケーションが自動的にデプロイされて便利です。

実際のオペレーションの手順

前述のように、同一の AMI でステージングでその AMI の検証と Terraform でのオペレーションの確認を行えるようになっています。なので、以降の手順は基本的にはステージングで全く同じ手順で確認作業を行い、問題がなければまた本番で同じ手順で作業を行うという運用を行っています。 ここでは、blue が稼動中の以下のような状態からどのような動きになるのか説明していきます。

f:id:livesense-made:20160905130036p:plain

各手順においての主な作業は、各手順の下部に記載している variables.tfvars の変数を変更し terraform apply で適応するというものになります。

1. green の設定変更 / 起動

green の台数を指定して、green サーバを起動します。この際、Auto Scaling と Code Deploy の連携により前回成功時のアプリケーションが自動的に green にデプロイされます。

この時はまだ本番の ELB ではなく確認用の ELB にぶら下がっています。起動とデプロイノ完了を確認したら確認用の ELB に対して動作確認を行います。

f:id:livesense-made:20160905130048p:plain

# variables.tfvars

blue_ami_id = "ami-12345xyz"
blue_min_size = "2"
blue_max_size = "4"
blue_elb_name = "elb_prd"

green_ami_id = "ami-98765abc"       # 新しい AMI を設定
green_min_size = "2"                # AutoScale の台数を設定し EC2 を起動
green_max_size = "4"                # 同上
green_elb_name = "elb_test"         # 確認用の ELB を設定
2. green サーバ群を本番 ELB に設定

正常に動作することが確認出来たら、green サーバ群を本番 ELB に設定します。ここでも Terraform の変数化した ELB の設定箇所を変更し apply します。完了したら green サーバ群でエラーが起っていないか確認を行います。

f:id:livesense-made:20160905130100p:plain

# variables.tfvars

blue_ami_id = "ami-12345xyz"
blue_min_size = "2"
blue_max_size = "4"
blue_elb_name = "elb_prd"

green_ami_id = "ami-98765abc"
green_min_size = "2"
green_max_size = "4"
green_elb_name = "elb_prd"       # ELB を本番に
3. blue サーバを本番 ELB から切り離す

エラーもなく問題がなければ blue サーバ群を本番 ELB から切り離します。green サーバのみになった後もエラーが起きていないかを確認。問題があれば blue をまた ELB に戻すよう設定を行います。

f:id:livesense-made:20160905130112p:plain

# variables.tfvars

blue_ami_id = "ami-12345xyz"
blue_min_size = "2"
blue_max_size = "4"
blue_elb_name = ""              # blue の ELB を無効に

green_ami_id = "ami-98765abc"
green_min_size = "2"
green_max_size = "4"
green_elb_name = "elb_prd"
4. blue の台数を 0 に

green サーバ群のみで問題がなければ移行は無事完了ということで blue サーバ群を退役させます。

以降は green サーバ群が稼働中となり、次回入れ替え時は blue を green に置き替えて 1. からまた作業を実施します。

f:id:livesense-made:20160905130122p:plain

# variables.tfvars
blue_ami_id = "ami-12345xyz"
blue_min_size = "0"             # EC2 を起動しないように
blue_max_size = "0"             # 同上
blue_elb_name = ""

green_ami_id = "ami-98765abc"
green_min_size = "2"
green_max_size = "4"
green_elb_name = "elb_prd"

実際に運用してみて

  • Terraform の変数と AWS の各種機能の連携で導入はさほど難しくない
  • ステージング / 本番で全く同様の手順で操作出来る環境を作っておくことで、作成した AMI のテストや Terraform の挙動などの確認も行える
  • 段階を踏んで入れ替えることでより安全に作業を行える

課題や今後

  • terraform apply する回数が多い / 自動化しづらい

    • 各手順において確認を行いたいので今のところ無理に自動化はしていないがやはり若干の手間は感じている
  • blue green 'deployment'

    • 本サイトのデプロイ頻度などの要因を顧み、平常時のデプロイにおいて blue / green のデプロイは現在行っていない
    • blue / green のデプロイを行える基盤は出来ているので、大幅な改修のデプロイ時には活用出来る
  • Packer build の時間がかかる

まとめ

この仕組みで移行後しばらく運用し、実際に入れ替え作業も何度も行っていますが、問題なく行いたい作業は実現出来ています。カジュアルにサーバを捨てたり入れ替えたり出来る仕組みがあるのは、何か問題があった際は準備してあるサーバを入れ替えてしまえば良いという運用が出来るので、心理的に大分楽になったと思います。

また、クラスメソッドさんのこちらの記事でも同様のオペレーションを実現しており、大変参考になると思います。

以上 Terraform & Packer を使った運用の一部を紹介させていただきました。何かのご参考になればと思います。

チームによる継続運用を意識したAWS環境におけるTerraformの活用

AWS 開発 Terraform Insfrastructure as Code インフラ
  • 概要
  • 背景
    • 複数人数で一つの環境をコードで管理する場合の移行期と運用期の特性
      • 移行期
      • 運用期
  • Terraformの採用理由
  • 実際の運用
    • ディレクトリ構成
    • stateファイルの配置
  • 環境の定義
    • tfvarsによる切り替え
    • 環境固有のリソース定義
  • GitHubのPRフロー
  • よかったこと・課題
    • よかったこと
    • 課題

概要

どうも。篠田です。

「特定の"インフラ担当"・"開発メンバー"」や「古の記憶」に頼らず、『開発メンバー全員が拡張や移行作業を気軽にできるインフラ』を実現するために、私のチームで採用しているTerraformを使ったAWS環境運用フローをご紹介いたします。

Terraformで移行および運用するフローにしたことで、構成全体に対する変更の柔軟性が高まり、コードがあることで運用および拡張期において設計の変更や手戻りを恐れずに開発を進められるようになりました。

次は概要図です。

f:id:livesense-made:20160711112710p:plain

続きを読む

あなたはどれだけ知ってる?〜監視&モニタリングツール19選〜

SaaS 監視 まとめ

創造開発部インフラグループです。(中の人:水野、中西)

今回の記事は、前回のログ収集基盤ツールまとめのサーバモニタリング版となります。

made.livesense.co.jp

リブセンスでは過去 Nagios/Munin で行っており、現在では mackerel を利用していますが、この界隈も変化が激しく多種多様なツールが登場しているため良いところどりをして運用の向上になればと思っています。

それでは早速まとめです。

注: 有名な mackerel/Datadog については省略させていただいています。我々が知らないツールのまとめとなりますことをご了承ください。

続きを読む

ログ収集を効率的に行うために知っておきたい、イマドキのログ収集基盤ツール8選

SaaS まとめ

創造開発部インフラグループです。 (中の人:水野、中西)

昨今、SaaS 系のインフラツールが台頭してきています。

リブセンスでもかつて nagios で行っていたサーバ監視は、mackerel へと置き換わっています。 自社で持つものを厳選し、出せるものは外に出していくことで Web 企業のインフラエンジニアとして注力したい箇所へリソースを割くためにもこの手の SaaS 系ツールには注目しています。知らないだけで便利なサービスは他にもあるだろうということでリサーチを開始しました。

今回は、数ある SaaS のツールの中でもログ収集系に絞ったまとめとなります。

続きを読む

プログラマーが「ネットワーク怪しくない?」と思った時に覚えておくと便利なことまとめ

まとめ ネットワーク

インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。

「ネットワークって難しい/よくわからない」

最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。

続きを読む