2016-08-05

Terraform 0.7.0での変更点

Terraform

とりあえず、ここに書いてあることのざっくりメモ

各providerのバイナリファイル(terraform-*)が不要になったので、消す
planで結果がmapだった場合foo#ではなくfoo% になった
concat()はstringでは動かなくなった、listのみ, stringの結合は${var}-fooみたいなシンタックスを使うこと
interpolations内で"をエスケープしなくて良い(したらエラーになる)
デフォルトでplanがstateファイルを更新しなくなった
- in memoryでの更新のみ、実際の更新はrefreshでやる
これらはresourceじゃなくてdata sourceにすることを推奨
- atlas_artifact
- template_file
- template_cloudinit_config
- tls_cert_request
list, mapが第一級オブジェクトになった
- output, moduleにstringに変換しなくても直接渡せる
- ${list[index]} 的な書き方が出来る
  - が、element() 関数と同じようなモジュラーな挙動はしない(エラーになる)
- mapの値の上書き方法が変わった
  - map_name.key = value -> map_name = {key = value}

2016-07-28

Terraformのcountでvariable以外のinterpolationを使えない

Terraform

version

Terraform 0.6.16

本文

ドキュメントにも書いてあったのですが、Terraformで複数リソースを一気に定義するときに count という項目を使うのですが、ここでは直接数字を入力するか、 variables で定義した値に対するinterpolationしか使えないようです。

例えばこんな感じで、AWSのsubnetごとに1つEC2インスタンスを作るようなtfファイルを書いた場合

resource "aws_subnet" "foo" {
  count = 2
  cidr_block = "${format("10.1.%d.0/24", count.index)}"
  vpc_id = "aaa"
}

resource "aws_instance" "var" {
  count = "${length(aws_subnet.foo.*.id)}"
  ami = "bbb"
  instance_type = "ccc"
  subnet_id = "${element(aws_subnet.foo.*.id, count.index)}"
}

terraform plan を実行するとエラーになります。

Error configuring: 1 error(s) occurred:

* strconv.ParseInt: parsing "${length(aws_subnet.foo.*.id)}": invalid syntax

上記の場合は単純に2をaws_instanceの方のcountに入れてあげれ良いのですが、ちと難しいのが別の tfstate から値を取ってくるような場合。

resource "terraform_remote_state" "foo" {
  backend = "s3"
  config {
    bucket = "kamatama41-tfstate"
    key = "example.tfstate"
  }
}

resource "aws_instance" "var" {
  count = "${length(split(",", terraform_remote_state.foo.output.subnet_ids))}"
  ami = "bbb"
  instance_type = "ccc"
  subnet_id = "${element(split(",", terraform_remote_state.foo.output.subnet_ids), count.index)}"
}

この場合countを計算することが出来ないし、以下のように単なる数字の2をoutputとして定義してもダメなので、現状完全にお手上げ状態です。。

resource "terraform_remote_state" "foo" {
  backend = "s3"
  config {
    bucket = "kamatama41-tfstate"
    key = "example.tfstate"
  }
}

resource "aws_instance" "var" {
  count = "${terraform_remote_state.foo.output.subnet_cidrs_count}"
  ami = "bbb"
  instance_type = "ccc"
  subnet_id = "${element(split(",", terraform_remote_state.foo.output.subnet_cidrs_count), count.index)}"
}

誰か解決策があったら教えて下さい！

Terraformの関連issue

github.com

2016-07-26

GitHubのissueを擬似的に消すためのRubyスクリプト

Ruby

GitHubのissueは削除することが出来ないので、タイトルと本文とコメントを全部消すことで、擬似的になかったことにします。 (これでもタイトルの変更履歴は残るので、完全に消すことは出来ないわけですが...)

require 'octokit'
require 'highline/import'

Octokit.auto_paginate = true
client = Octokit::Client.new(:access_token => ENV['GITHUB_TOKEN'])

repo = '<repository name>' # e.g. kamatama41/test
title = '<issue title>'

issue = client.issues(repo, state: :closed).find do |i|
  i.title.include? title
end

unless issue
  puts 'Issue is not found.'
  exit
end

confirm = ask("Remove the issue '##{issue.number} #{issue.title}'? [Y/N] ") { |yn| yn.limit = 1, yn.validate = /[yn]/i }
unless confirm.downcase == 'y'
  exit
end

client.update_issue(repo, issue.number, '(deleted)', '') # Rename issue title and body
client.issue_comments(repo, issue.number).each do |comment|
  client.delete_comment(repo, comment.id)
end

2016-07-10

Recruit Technologies Open Lab #03 Infrastructure as Code に参加してきた

atnd.org

スピーカーが興味深い方ばかりだったので、参加してきました。

多くの方が Infra as Code の本質はインフラがコード化することで、ソフトウェア領域での知見が適用できるようになって来たと言っていたのが印象的でした。

バージョン管理するようになった
テストコードが記述可能になった
アプリケーションの構成要素のひとつになった
単なる手順化にとどまらずにデザインパターン、モデリングなどを適用するなった
コンウェイの法則が適用されるようになった
技術的負債になるようになった
マイクロサービス化で管理するものを少なくする方向性
人工知能、機械学習などの分野で応用される可能性

今まさにterraformやansibleでサーバ構成をコード化しているところなので、負債化しないように意識していきたいですね。

以下勉強会中にとったメモ書き

"Infrastructure as Code" から数年、結果どうなったか (naoyaさん)

Infra as code は単なる自動化では無かった。。。!
- Software で使われてるプラクティスをインフラにも適用する
naoyaさんにが思うinfra as code
- infraのモデリング..! (DDD的な)
- 負債を無くす、減らす
- そもそもDockerとかで小さく分割して管理するコード減らす方向性...?

Infrastructure as Code と企業文化 (ryuzeeさん)

Infra as Code
- インフラもソフトウェアを構成するコンポーネントの一部になる
- コンウェイの法則が働く
pattern 1: インフラとアプリが別組織
- インフラサービスが均質化して個別に対応できなくなってくる
pattern 2: インフラとアプリが同プロダクト所属(仮想チーム的な)
- コミュのオーバーヘッドは減るが、インフラエンジニア個人の資質に依存しがち
- 個別最適化はし易い
pattern 3: インフラとアプリが同組織(サービス)
- 一番変化に強い
- 技術マトリクス的なものを作って、SPOFを減らす
- 他のチームを意識しないので、一貫性がなくなりがち
  - 例) AWSのコンソール
- pattern 3-1: QAとかセキュリティ的なところだけ別部署
  - スピードと安全性のバランスが取れている
ryuzeeさんの本をもらった
Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-
- 作者: 荒木靖宏,大谷晋平,小林正人,酒徳知明,高田智己,瀧澤与一,山本教仁,吉羽龍太郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/06/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る

Infrastructure as Code のこれまでとこれから (mizzyさん)

O'reilly の infrastructure as code の4本柱
- Dynamic Infrastructure Platforms
- Infra Definition Tools
- Server Configuration Tools
- Infrastructure Services
Infra as Code に影響を与えそうなもの
- Container
- MicroServices
- Server Configuration Tools は重要性↓
Infrastructure Services
- 設定を外部化するだけではなく内部で調整可能にする
  - 学術的なプローチ
    - グラフ理論、形式手法、ディープラーニング
  - Nginxでluaやmrubyで自律的に動かすとか
- Consumer-Driven Contract testing パターン
  - http://techlife.cookpad.com/entry/2016/01/04/094705
モニタリング is dead
- https://speakerdeck.com/grepory/monitoring-is-dead
- 数字じゃなくて振る舞いをモニタリング(テスト)する的な

運用・監視もコード化する。開発者が監視まで考える方法論 (songmuさん)

メトリックを返すエンドポイントがあるとよろし
監視 as Code
- じつは既に、監視は結構コード化, Plugin化されてる
  - muninとかもそうだった記憶が
- なのでどんどん書いていこう
- webhookには夢がある

プロビジョニングツールはMakeで決まりだろ (katzchangさん)

Makeはベターshell scriptである 2012
- http://tech.voyagegroup.com/archives/6286346.html
Immutable Infrastructureを実際にやってみた 2014
- https://atnd.org/events/47786 (これ？)
Makeは補完が効く
エラー処理: non-zeroだったら落ちる
宣言的適用と差分
- サーバは状態をもつので、冪等性の維持がむずい
手続き型への回帰: 提言
- サーバの単純化
- コンテナなどで、破棄可能な感じに(状態が無くなってきた)
- サーバレス