TerraformとUsacloud(CLI)がコア専有プランに対応しました

さくらのクラウド

さくらのクラウドに「コア専有プラン」が追加されましたね！！

cloud-news.sakura.ad.jp

manual.sakura.ad.jp

これまでにすでに提供されていた「専有ホスト」が物理的なホストを専有するのに対し、 こちらはホストは共用ながらコア単位で専有できるとのことです。

コアを占有しつつホストは共有するため専有ホストより手軽な価格になっており手を出しやすいですね。

ということでTerraformとUsacloud(CLI)をこのコア専有プランに対応させてみました。

Terraformでのコア専有プラン対応

さくらのクラウド向けプロバイダー terraform-provider-sakuracloudのv1.12.0で対応しました。

github.com

tfファイルでサーバリソースを定義する際、commitmentというパラメータを指定可能になっています。

デフォルトはstandard(通常のプラン)となっており、コア専有プランを利用する場合はdedicatedcpuという値を指定します。

resource "sakuracloud_server" "example" {
  name  = "example"

  #コア数
  core = 2

  #メモリサイズ(GB)
  memory = 4
  
  # コアプラン(共用or専有)
  commitment = "dedicatedcpu"  # or standard

  # ...その他パラメータ
}

注意点としては以下のような点があります。
特にcommitmentの変更時は再起動が必要になりますので稼働中のサーバに対する変更は計画的に行なってください。

  • 提供ゾーンはis1bとtk1aのみ
  • commitmentを変更した際はサーバのIDが変更となる
  • commitmentを変更した際、サーバが起動していると再起動が行われる

Usacloudでのコア専有プラン対応

CLIであるUsacloudでもv0.23.0でコア専有プランに対応しました。

github.com

いくつかのコマンドでTerraformで追加されたのと同名のパラメータ--commitmentが追加されました。

サーバ作成時にコア専有プランを指定

$ usacloud server build \
    --name example \
    --cpu 2 \
    --memory 4 \
    --commitment dedicatedcpu \
    ...

プラン変更時にコア専有プランを指定

$ usacloud server plan-change --core 2 --memory 4 --commitment dedicatedcpu <対象サーバのID or 名称>

なおプラン変更コマンドはサーバが停止していないとエラーとなります。 またプラン変更後はサーバのIDが変更になりますのでご注意ください。

ということで

ぜひ使ってみてくださいね！ 以上です。

Grabで拾ったタクシーでぼったくりにあった(返金済)

I got ripped off!!!

今セブ島に来ています。

セブ島といえば電車がなく、移動は専らジプニー(Jeepney)というバスやバイクタクシー、タクシーが中心となります。
この中でもジプニーやバイクタクシーはスリに会う可能性や怪我をする可能性が高く、慣れた方以外にはあまりオススメされていないようです。
なので移動はタクシーを中心的に使ってます。

その際に便利なのがGrabというアプリです。

www.grab.com

このアプリ、一言で言うと東南アジアのUberですね。 実際GrabはUberの東南アジア事業を買収してたりします。

news.mynavi.jp

Grabの使用感

まあUberと似たような使い勝手です。
何度か体験したのですが、セブでは現金だと結構お釣りがなくて購入を断られたりお店の方が両替してくるまで結構待たされます。
もちろんタクシーも同じ状況ですので、クレジットカードで決済できるGrabは非常に便利です。

使い方については解説サイトがいくつもありますので詳細は省きますが、こんな感じで使います。
ドライバーとの待ち合わせがうまくいかないことが結構ありますのでメッセージ機能は重宝します。

ドライバーのマッチング後の画面:

f:id:febc_yamamoto:20190317222055p:plain

ドライバーの情報表示:

f:id:febc_yamamoto:20190317222119p:plain

ドライバーとのメッセージのやりとり

f:id:febc_yamamoto:20190317222140p:plain

本題: ぼったくりにあった

という感じでGrabを便利に使っているのですが今日とうとうぼったくりにあってしまいました。
Grabはドライバー側のアプリに到着(drop off)機能がついており、目的地につくとドライバーさんが到着ボタンを押し、そこまでのメーターの金額を入力するようになっています。
(Grab Taxiの場合。Carの場合は最初に金額が決まるっぽい)

そして無事に決済されるとメール+プッシュ通知がくるようになっています。

気づいた時には運転手は去っていた

今日は買い物のためにタクシーを使ったのですが、タクシーから降りてショッピングモールに入ろうとしている最中に決済通知が届きました。
今日行ったショッピングモールでは入場時にボディーチェック(カバンの中身もチェックされる)が行われており、そちらに気を取られてすぐに通知を確認しなかったのが今回の反省点です。。。

その後ショッピングモールに入り決済通知を確認すると、、、「あれ？なんか高いぞ」と。
通常Grab Taxiを使うとメーター+30ペソ(手数料)が取られます。

降りる時にメーターをみたら90ペソくらいだったから120ペソくらいの決済のはずが、、、170ペソほど来てました。

慌てて降車したところに戻るもドライバーの姿はすでになく、、、やられました。

対応: Grabアプリ内から問い合わせ(苦情)

Grabは降車してしまうとドライバーと直接連絡を取ることができないようでした(見つけられなかっただけかも?)。
しょうがないのでヘルプを眺めているとそれっぽいのがありました。

f:id:febc_yamamoto:20190317224058p:plain

この中のI paid more than quotedってやつがまさに今回のケースですね。
これをタップすると説明書き+メール送信ができる画面に遷移します。

f:id:febc_yamamoto:20190317224317p:plain

とりあえずここから「最後にメーターみたときは90だったのに170も請求が来ました。おかしいですよね？」的なメールを送りました。

解決: サポートセンターから数時間後に回答が来た

数時間後、サポートセンターから連絡があり、結果としては差額分は返金されることとなりました。

回答としては、

  • ドライバーにはサポートセンターから確認中
  • 正しい金額はまだ判明していないがサポートセンターにて詳しく調査する
  • 調査の結果、もしドライバーに責があると判明した場合はドライバーに対し何らかの処罰を行う(the driver will be sanctioned)
  • とりあえず差額についてはGrabPayで返金する

というような感じでした。

そしてすぐにGrabPayのtop-up(入金)の通知が来て無事返金されました。素早い。

反省点

ということでGrabではドライバーが金額を入力するため、ぼったくりにあったり、悪意はなくとも金額の入力間違いが発生する可能性があります。
なので降車の際は金額を声に出して確認(ドライバーさんにメーターの金額を聞くのが早い)、またはドライバー側アプリへの入力を見届けてから降りるようにした方が無難そうです。

あとは通知は毎回きちんと確認しましょうというところですかね。

終わりに

ということで異国の地でぼったくりに会い悲しい思いをしましたがサポートセンターの素早い対応により無事解決しました。
とはいえメール送信したりという手間がかかりますのでやはり自衛するのが大事ですね。。。

以上です。

おまけ

せっかくセブに来ているので人気のアトラクションだというCrown Agency Hotel & ResortsのSky Adventureを体験してきました。 ビルの38階の外側に沿って歩道が設けられておりそこを歩くというやつでした。

f:id:febc_yamamoto:20190316140224j:plain

怖かったですねー。。。しばらくはもう高いところに登りたくないです。。。

sakuracloud_exporterでエンハンスドロードバランサをサポートしました

さくらのクラウド Prometheus

sakuracloud_export v0.2.1で対応しました。

github.com

Grafanaだとこんな感じで使えるはずです。

f:id:febc_yamamoto:20190307175557p:plain

エンハンスドロードバランサのメトリクス

以下のようなものがサポートされています。 詳細はGitHubのREADMEを参照してください。

ProxyLB

Metric Description Labels
sakuracloud_proxylb_info ProxyLB自体の情報 plan, vip, proxy_networks, sorry_server_ipaddress, sorry_server_port, tags, description
sakuracloud_proxylb_up ProxyLBの有効状態 id, name
sakuracloud_proxylb_bind_port_info プロキシするポートの情報 id, name, bind_port_index, proxy_mode, port
sakuracloud_proxylb_server_info 実サーバの情報 id, name, server_index, ipaddress, port, enabled
sakuracloud_proxylb_cert_info 証明書の情報 id, name, common_name, issuer_name
sakuracloud_proxylb_cert_expire 証明書の有効期限(UnixTime) id, name
sakuracloud_proxylb_active_connections 同時コネクション数 id, name
sakuracloud_proxylb_connection_per_sec 新規コネクション数 id, name

2019年3月31日までエンハンスドロードバランサ自体がベータ版ということなので まだまだ細かな仕様が変わる可能性があると思いますのでその辺はご注意ください。 (もちろん仕様が変わった際は追随して更新するつもりです。)

それでは良きPrometheusライフを!

以上です。

sakuracloud_exporterでエンハンスドロードバランサをサポートしました

さくらのクラウド Prometheus

sakuracloud_export v0.2.1で対応しました。

github.com

Grafanaだとこんな感じで使えるはずです。

f:id:febc_yamamoto:20190307175557p:plain

エンハンスドロードバランサのメトリクス

以下のようなものがサポートされています。 詳細はGitHubのREADMEを参照してください。

ProxyLB

Metric Description Labels
sakuracloud_proxylb_info ProxyLB自体の情報 plan, vip, proxy_networks, sorry_server_ipaddress, sorry_server_port, tags, description
sakuracloud_proxylb_up ProxyLBの有効状態 id, name
sakuracloud_proxylb_bind_port_info プロキシするポートの情報 id, name, bind_port_index, proxy_mode, port
sakuracloud_proxylb_server_info 実サーバの情報 id, name, server_index, ipaddress, port, enabled
sakuracloud_proxylb_cert_info 証明書の情報 id, name, common_name, issuer_name
sakuracloud_proxylb_cert_expire 証明書の有効期限(UnixTime) id, name
sakuracloud_proxylb_active_connections 同時コネクション数 id, name
sakuracloud_proxylb_connection_per_sec 新規コネクション数 id, name

2019年3月31日までエンハンスドロードバランサ自体がベータ版ということなので まだまだ細かな仕様が変わる可能性があると思いますのでその辺はご注意ください。 (もちろん仕様が変わった際は追随して更新するつもりです。)

それでは良きPrometheusライフを!

以上です。

【さくらのクラウド】エンハンスドロードバランサとTerraform ACMEプロバイダでHTTPS環境を作る

さくらのクラウド

さくらのクラウドに「エンハンスドロードバランサ」というhttp/httpsに特化した新しいロードバランサアプライアンスが追加されました。

cloud-news.sakura.ad.jp

また、タイミングが良いことにTerraformのAMCEプロバイダーでさくらのクラウドDNSを利用できるようになるバージョン v1.1.0も先日リリースされました。

www.terraform.io

今回はTerraform+AMCEプロバイダーを利用してさくらのクラウドのエンハンスドロードバランサでHTTPS環境を作ってみます。

エンハンスドロードバランサとは

エンハンスドロードバランサについてはこちらに詳細がまとめられています。

manual.sakura.ad.jp

振り分け先にはさくらインターネットの提供するグローバルIPアドレスが指定可能ということですので、 クラウドだけでなくVPSや専用サーバもOKということになります。 (ちょっと確認できてないですが、プランによってはレンタルサーバでもOKじゃないかと思います)

また、証明書を登録しておけばSSL終端も可能です。

エンハンスドロードバランサの注意点

実サーバにはグローバルIPが必要なため、例えばVPC内へのアクセスするためのゲートウェイとして利用するといったことはできませんのでその辺は注意です。

また、現時点ではパスベースのルーティングはできません。

プレスリリースには

また今後、DDoS対策、リクエストURLパス単位のルーティング、ユーザー定義のパケットフィルタなどの機能を実装していく予定です。

とありますので今後対応予定はあるようですね。期待してます。

TerraformのACMEプロバイダのさくらのクラウド対応

先日ACMEプロバイダー v1.1.0がリリースされました。
このプロバイダーは内部でlegoというライブラリを使っており、このlegoがさくらのクラウドに対応しています(させた)。
このためACMEプロバイダーで利用するlegoをバージョンアップするPullRequestを半年ほど前に送っていたのですが最近になってようやくマージされ、 この度無事にそれらを含むバージョンとしてv1.1.0がリリースされました。長かった。。。

Terraform v0.12で構築してみる

ということで早速これらを用いてエンハンスドロードバランサを構築してみます。

なお、今回は現在βテスト中であるTerraform v0.12を利用します。
Terraform for さくらのクラウドではv0.12対応を進めており、エンハンスドロードバランサはv0.12以降向けブランチでのみサポートする予定だからです。

必要なもの/準備

※Terraform v0.12ではまだOfficialプロバイダーでもTerraform v0.12対応版のリリースがされていないものがあるため、 terraform initを実行してもエラーとなるケースがあります。 このため現在は各プロバイダーのスナップショット版をダウンロードして~/.terraform.d/plugins配下などに配置しておく必要があります。

また、さくらのクラウド APIキーについては以下のように環境変数に設定しておいてください。

export SAKURACLOUD_ACCESS_TOKEN=アクセストークン
export SAKURACLOUD_ACCESS_TOKEN_SECRET=シークレット

実サーバは(さくらの)グローバルIPを持ちhttpでアクセスできるものを用意しておきます。
もしお持ちでない場合は適当にサーバを作成してdocker run -d -p 80:80 nginx:latestなどとでもして用意しておきましょう。

作成

tfファイルは以下のようになります。variablesを適当に設定してください。

# ホスト名(Let's Encryptで証明書を取得する際に利用)
variable common_name {
  default = "www"
}

# ドメイン名(さくらのクラウドDNSに登録したゾーン名)
variable target_domain {
  default = "example.com"
}

# 実サーバのIPアドレスのリスト
variable servers {
  type    = list(string)
  default = ["192.2.0.1"]
}

locals {
  fqdn = format("%s.%s", var.common_name, var.target_domain)
}


# エンハンスドロードバランサの作成
resource "sakuracloud_proxylb" "foobar" {
  name = "terraform-test-proxylb-import"
  health_check {
    protocol   = "http"
    path       = "/"
    delay_loop = 20
  }
  bind_ports {
    proxy_mode = "https"
    port       = 443
  }

  # v0.12以降で使えるdynamicを利用
  dynamic servers {
    for_each = var.servers
    content {
      ipaddress = servers.value
      port      = 80
    }
  }

  certificate {
    server_cert       = acme_certificate.cert.certificate_pem
    private_key       = acme_certificate.cert.private_key_pem
    intermediate_cert = acme_certificate.cert.issuer_pem
  }
}

# さくらのクラウド DNS(エンハンスドロードバランサに割り当てられるVIPに対しAレコード登録)
data sakuracloud_dns "zone" {
  name_selectors = [var.target_domain]
}

resource sakuracloud_dns_record "record" {
  dns_id = data.sakuracloud_dns.zone.id
  name   = var.common_name
  type   = "A"
  value  = sakuracloud_proxylb.foobar.vip
}

# ACMEプロバイダーでLet's Encrypt証明書取得
provider "acme" {
  server_url = "https://acme-staging-v02.api.letsencrypt.org/directory" # ステージング環境用
}

resource "tls_private_key" "private_key" {
  algorithm = "RSA"
}

resource "acme_registration" "reg" {
  account_key_pem = tls_private_key.private_key.private_key_pem
  email_address   = "your-mail-address@example.com"
}

resource "acme_certificate" "cert" {
  account_key_pem = acme_registration.reg.account_key_pem
  common_name     = local.fqdn

  dns_challenge {
    provider = "sakuracloud"
  }
}

AMCEプロバイダーでdns_challengeにprovider="sakuracloud"を指定することで、さくらのクラウドDNSを用いてLet's Encryptで証明書を取得してくれます。
環境変数にさくらのクラウドAPIキーを設定しておけばそれを利用するようになっています。
(もちろんtfファイル上で明示することも可能)

あとはterraform applyすれば証明書取得やエンハンスドロードバランサに向けたDNSレコードの登録が行われます。 その後指定したFQDN(この例だとwww.example.com)にHTTPSでアクセスできるようになるはずです。

終わりに

パスベースのルーティング待ってます！！！

以上です。

田舎は辛い: CKA取得のために会議室を借りたかった

ぼちぼちCKA取っておきたい

そろそろCKA取っておくかという気持ちになったので準備を進めてます。 が、受験する場所の確保で難儀してまして、その辺の愚痴です。

CKAを受験する際の場所

adtech.cyberagent.io

こちらの記事などにあるように、余計なものを置いていない環境を準備する必要があります。

Candidate Handbookには以下のように書かれてますね。

The workstation on which the hardware (i.e. desktop or laptop) is placed must, aside from the required hardware, reveal a clean surface with no obstructions overhead or underneath. Candidates should ensure that their webcam is capable of being moved in case the proctor requests that the Candidate pan their surroundings to check for potential violations of exam policy.
If multiple Candidates are taking an exam at the same time in one location, then at least four feet (1.2 meters) of empty space on all sides must be enforced or privacy partitions must be installed.

通常は会社の会議室などを借りればいいかと思いますが、フリーランスで自宅が仕事場だと難しいと思います。
(ちゃんと片付ければいいだけなのですがめんどくさい)

そこで貸し会議室やレンタルルームを利用しようと色々探してみました。

大分県宇佐市ってのは田舎でして

私は現在、大分県宇佐市というところに住んでます。USAです。

全国の約44,000社の八幡宮の総本社である宇佐神宮や焼酎「いいちこ」を製造している三和酒類のあるところですね。唐揚げ発祥の地でもあります。
総人口 約55,000人という小さい町で、最寄りの都会まではどこに行くにしても車で1時間以上かかる(しかも高速道路使って)というような場所です。

市のホームページなんかをみてもいまだにトップページのどでかいバナー用にFlashプレイヤーが必要というのが時が止まったかのような現状を表しているようでちょっと悲しいです。

f:id:febc_yamamoto:20190228140759p:plain

引用元: http://www.city.usa.oita.jp/

良い面としては、LTなんかをするときに「今日ははるばる飛行機に乗ってUSAから来ました！」ってネタが使えるあたりですかね。 使ったことないですが。

余談ですが、開発にGo言語を使う方向けに「私はGoに住んでます！」と言える場所もあります。

www.google.com

これで「ごう」って読むのです。

会議室なんてあるの??

調べたところ会議室的なところとしては以下のようなものがありました。

この他にも宇佐市庁舎にも会議室がありますが、一般向けには貸し出ししていないらしいので除外しました。

お、あるじゃん！！いけるか！？！？

次の課題: WiFiが使える?

CKAはオンライン試験ですので当然インターネット接続が必要です。
宇佐市はWiFiが使える(カフェ的な)お店すら少ないのに会議室でWiFiが使えるところがあるのか、、、？？

調べてみました。

WiFiが使えるか調べる

まず各所のHPをみましたがWiFi有無は書いていない、、、なので泣きながら電話して確認してみました。

電話したけど、、、

はい、結果としては全滅でした。

ウサノピア(一部でフリーWi-Fiあり)

ウサノピアは電話したら受付のお姉さんらしき方が対応してくれました。
曰く、フリーWiFi(おんせんおおいたWi-Fi)があるが、ロビーのみで会議室では電波が届かない、とのことでした。残念。

まあ仮におんせんおおいたWi-Fiが使えたとしても1回15分/1日12回と言う制限があるので、3時間あるCKA試験では使い物にならないですし。

宇佐市商工会議所(現状なし、今後対応するかも)

こちらも受付のお姉さんが対応してくれましたが即答でWiFiはないとお答えいただきました。

ただし、今後の課題として認識しており、いつになるかは未定だけど導入するつもりはあるとのことでした。

公民館(ダメ)

ダメです。電話対応もダメダメでした。

まず四日市公民館の方はよくわかってなさそうなおじいちゃんが電話対応してくれました。
まず「WiFi」が伝わらない。パソコンの通信するのに必要なやつ、、と2分ほど説明してやっと理解したのか確認に入ってくれました。
数分後、結局使えないと。。。辛い。

そして最後に宇佐公民館、ここはどうやらWiFiが使えるらしいのですが、最終的にダメっぽかったです。

電話で会議室を借りたい旨とその際にWiFiが使えるか確認したのですが、まず利用目的を細かく聞かれ、受験で使いたい旨を説明するもそもそもオンライン試験と言う存在そのものを知らなかったらしく説明にかなりの時間を取られました。

その上でWiFiが使えるか改めて確認すると、、「使えるけど、(宇佐公民館で)WiFiが使えるという噂になると困る」とか「前例のない利用方法なので市(の教育委員会など?)に確認しないといけない」、「確認は結構時間がかかる」というなんともやる気の感じられない回答でした。

つまり、「WiFiは使えるけど公民館の使用方法によっては市の確認が必要」と言うことらしいです。
最初にこう回答してくれればよかったのに結局この回答をもらえるまで10分以上通話してましたね。

要領を得ない会話が続き、電話対応してくれた方に対する不信が募るばかりだったので結局宇佐公民館を借りるのはやめました。

オンライン申し込み? 知らない子ですね。

なお全ての会議室においてオンラインでの申し込みなんていう洒落たものはなく、現地で手続きするか、郵便/FAXで申し込む必要があるとのことでした。

FAXって。今2019年ですよね。

結局ホテルの部屋での受験になりそう

貸し会議室が全滅だったので泣く泣く近所のビジネスホテルになりそうです。
とはいえホテルでもロビーでしかWiFi使えないところもあるので下見必須ですが。

普段から閑散としたホテルで価格も安いとはいえ無駄な出費です。辛い。

ということで

3月は色々予定を詰めてしまったので、多分4月に受験すると思います。

受験場所の確保だけでこんなに疲れるとは思わなかった。。。
何かモチベーションを上げるための手を打たないとダメですね。

以上です。

さくらのクラウド プロバイダーでのTerraform v0.12対応状況(2019/02)

さくらのクラウド

2019/3/1 更新: Terraform v0.12-beta1がリリースされました！

https://www.hashicorp.com/blog/announcing-terraform-0-1-2-beta1

terraform-provider-sakuracloud v2.0(alpha)を動かしてみましたがうまく動いているようです。

Terraform v0.12 β版リリースは近い??

リリースが待ち遠しいTerraform v0.12ですが、最近になってterraform-providers配下の各プロバイダーでGo Modulesへの切り替え作業が進んでいたりと 着実にβ版のリリースが近づいているようです。

そんな中、さくらのクラウド向けプロバイダーであるterraform-provider-sakuracloud(Terraform for さくらのクラウド)についても Terraform v0.12対応すべく準備を進めています。

github.com

まだ一部のテストが通らないといった問題は残っていますが、v0.12対応で入れたかった機能については概ね揃ってきたため 本日alpha版をリリースしました。

Release v2.0.0-alpha.2 : v0.12.0-alpha4.0.20190227014701-6e7016008b79 · sacloud/terraform-provider-sakuracloud · GitHub

今回はこのalpha版でv0.12+さくらのクラウドの雰囲気を紹介したいと思います。

Terraform v0.12 alpha版の利用

GitHub上のTerraformのリポジトリではv0.12系のタグとしてv0.12.0-alpha4があります。
このバージョンはGitHub上でTerraformのバイナリを配布しておらず、以下のサイトで配布を行なっています。

releases.hashicorp.com

ここでダウンロードできるTerraformバイナリは各プロバイダー(v0.12対応させたもの)をバンドルしたものとなっており、Officialプロバイダーであればすぐに使えるようになっています。

しかし若干古い(2018/12/8)ためDockerやGoの開発環境を用意した上でmasterブランチをビルドするのがおすすめです。

さくらのクラウドプロバイダーのv0.12対応を試す

v0.12対応のさくらのクラウドプロバイダーはこちらからダウンロードして適切なディレクトリに配置しておきます。

Release v2.0.0-alpha.2 : v0.12.0-alpha4.0.20190227014701-6e7016008b79 · sacloud/terraform-provider-sakuracloud · GitHub

まずはv0.11までのtfファイルをアップグレード

Terraform v0.12では以下の記事にもあるように大きな変更が行われています。

https://www.hashicorp.com/blog/terraform-0-1-2-preview/

特にtfファイルで用いるHCLは大きく構文が変わり、v0.11までのtfファイルはそのままでは利用できなくなっています。 これに対応するためTerraform側でアップグレード用のコマンドterraform v0.12upgradeが用意されています。

例えばv0.11で以下のtfファイルを利用していたとします。

# v0.11でのtfファイル

variable password {}

data sakuracloud_archive "ubuntu" {
  os_type = "ubuntu"
}

resource "sakuracloud_switch" "sw" {
  name = "sw"
}

# ディスク定義
resource "sakuracloud_disk" "example" {
  name = "disk01-01"
  source_archive_id = "${data.sakuracloud_archive.ubuntu.id}"
}

# サーバー定義
resource "sakuracloud_server" "example" {
  name  = "example"
  disks = ["${sakuracloud_disk.example.id}"]

  nic         = "${sakuracloud_switch.sw.id}"
  ipaddress   = "192.2.0.1"
  nw_mask_len = 24

  display_ipaddress = "192.2.0.2"
  password          = "${var.password}"
}

これに対しterraform 0.12upgradeを実行すると以下のようになります。

# v0.12upgrade実行後のtfファイル

variable "password" {
}

data "sakuracloud_archive" "ubuntu" {
  os_type = "ubuntu"
}

resource "sakuracloud_switch" "sw" {
  name = "sw"
}

# ディスク定義
resource "sakuracloud_disk" "example" {
  name              = "disk01-01"
  source_archive_id = data.sakuracloud_archive.ubuntu.id
}

# サーバー定義
resource "sakuracloud_server" "example" {
  name  = "example"
  disks = [sakuracloud_disk.example.id]

  nic         = sakuracloud_switch.sw.id
  ipaddress   = "192.2.0.1"
  nw_mask_len = 24

  display_ipaddress = "192.2.0.2"
  password          = var.password
}

"${sakuracloud_disk.example}"のような部分がsakuracloud_disk.exampleとなっていますね。
これでv0.12への移行はかなり楽になると思います。

v0.12で導入されるdynamicブロック

Terraform v0.12での変更点の中でも個人的に大きな期待を寄せているのがdynamicブロックです。

ドキュメント: terraform/expressions.html.md at 4ba8504e86f62fe98ed239a614763fbaab7538f8 · hashicorp/terraform · GitHub

これまではリソースを動的に扱いたい場合は親子リソース(例えばDNSゾーンリソースとレコードリソースみたいな)にしておいて、子リソースの方でcount+variableを用いて頑張るといった方法を取らざるを得なかったのがdynamicブロックで簡単に扱えるようになります。

例えばv0.11では以下のようなtfファイルを用いていました。

variable "allow_hosts" {
  type    = "list"
  default = ["192.2.0.1", "192.2.0.2"]
}

resource "sakuracloud_packet_filter" "foobar" {
  name = "example"
}

resource sakuracloud_packet_filter_rule "rules" {
  count = "${length(var.allow_hosts)}"

  packet_filter_id = "${sakuracloud_packet_filter.foobar.id}"
  protocol         = "ip"
  source_nw        = "${var.allow_hosts[count.index]}"
  allow            = true
  order            = "${count.index}"
}

親リソースとしてsakuracloud_packet_filter、子リソースとしてsakuracloud_packet_filter_ruleを定義しています。
variablealllow_hostsで指定されたIPアドレスの分だけルールを動的に作成するようになっています。

この例では親子リソースにする痛みはあまりないのですが、例えばロードバランサやVPCルータなどの場合、 子リソース側の作成/変更/削除を行うには親リソース側をロックする必要があったり電源操作を都度行う必要があるなど色々と不便な面があります。

これがTerraform v0.12では以下のようにdynamicブロックを用いて親リソース側の定義だけで済ませることができるようになります。

variable "allow_hosts" {
  type    = list(string)
  default = ["192.2.0.1", "192.2.0.2"]
}

resource "sakuracloud_packet_filter" "foobar" {
  name = "example"

  # dynamicブロックで動的にブロック生成
  dynamic "expressions" {
    for_each = var.allow_hosts
    content {
      protocol  = "ip"
      source_nw = expressions.value
      allow     = true
    }
  }
}

先ほど挙げたロードバランサやVPCルータであれば電源操作が親リソースの分だけですむようになりapplyやdestroyにかかる時間がかなり短くなります。

さくらのクラウドプロバイダーでのv0.12対応

先ほどのdynamicブロックをより活用するために、これまで親子リソースとなっていたものを親リソース側で定義できるようにしていきました。

以下のリソースにおいて親リソース側にインラインで子リソースの分も定義できるようになっています。

上記それぞれが各リソースのドキュメントへのリンクとなっています。
どのような記述ができるようになったのかは各ドキュメントを参照ください。

終わりに

Terraform v0.12が待ち遠しいですね！ さくらのクラウド プロバイダーはTerraform v0.12がリリースされたらすぐに対応版をリリースする予定です。 さくらのクラウドプロバイダーでv0.12の雰囲気を味わってみたいという方はぜひチャレンジしてみてください。

github.com

以上です。