2020-12-22

Usacloud v1.0 - WASM対応や全ゾーン一括操作など様々な改善を含むメジャーバージョンアップ

f:id:febc_yamamoto:20201221102556p:plain — UsaConのメイン画面

はじめに

さくらのクラウド向けCLIUsacloudのメジャーバージョンアップとなるv1.0.0をリリースしました。

github.com

Usacloud v1.0.0ではWebAssemblyに対応しました。このリリースに合わせブラウザ上で手軽にUsacloudを実行できるようにするChrome拡張UsaConもリリースしました。

chrome.google.com

この記事ではUsacloud v1.0とUsaConを紹介していきます。

Usacloud v1.0

さくらのクラウド向けCLIとして2017年3月に初版となるv0.0.1がリリースされました。　　

初版のリリースが行われて以降、ご利用いただいた方々からのフィードバックを反映したりさくらのクラウド自体の進化に対応したりと地道にアップデートを重ねてきました。

f:id:febc_yamamoto:20201221103456p:plain — Usacloud 初版(v0.0.1)のリリース

これまでの累計ダウンロード数はGitHub ReleasesやDocker Hubを合計すると延べ10,000を超えました。

Usacloud v0系で不満だった点

私自身日常の作業にUsacloudを利用していたのですが、数年利用している中でいくつか不満を感じるようになってきていました。

例えば、

フラグ指定する際に指定する位置に気をつける必要がある
複数のゾーンに跨がる処理の実装が困難
bash以外のシェル補完が行えない

というような点です。

例えば1点目は--zone=is1aのような指定をしたい場合、以下のように指定するしないといけないということです。

OKな例: usacloud --zone=tk1a server list
NGな例: usacloud server list --zone=tk1a

指定忘れに気付いたらヒストリーから呼び出して所定の位置にカーソルを移動して、、というのが地味にストレスでした。
(option+←などのキーボードショートカットやctrl+aで先頭に戻ってから右へ移動とかでもOKなんですがそれもめんどくさい)

これらの問題を解決するには依存ライブラリの切り替えやアップグレードが必要で、Usacloud側も大幅に修正する必要がありましたのでメジャーバージョンアップして対応することにしました。

Usacloud v1.0系での改善や主な新機能

前述の細かな不満の解消や新機能の追加などを行なっています。

フラグ位置を気にしなくてよくなった
全ゾーン一括操作対応
操作対象リソースの指定にID or 名称 or タグを利用可能に
シェル補完でbash/zsh/fish/powershellをサポート(github.com/spf13/cobraのおかげ)
いわゆるDry Run機能(libsacloudのFakeドライバーというやつを利用)
ヘルプ表示の改善(候補値の表示やパラメータ例の追加など)
WebAssembly対応

他にも細かな改善がたくさん行われています。この中からいくつかピックアップして紹介します。

全ゾーン一括操作

--zoneフラグにallを指定することで全ゾーン一括操作が可能となりました。

# 全ゾーンのサーバを一覧表示
$ usacloud server list --zone=all

+------+--------------+---------+------+-----+--------+-----------+----------------+----------------+--------------+
| Zone |      ID      |  Name   | Tags | CPU | Memory | IPAddress | Upstream(Mbps) | InstanceStatus | InstanceHost |
+------+--------------+---------+------+-----+--------+-----------+----------------+----------------+--------------+
| tk1a | 100000000008 | example | -    | 1   | 1      | -         | -              | -              | -            |
| tk1b | 100000000011 | example | -    | 1   | 1      | -         | -              | -              | -            |
| is1a | 100000000012 | example | -    | 1   | 1      | -         | -              | -              | -            |
| is1b | 100000000010 | example | -    | 1   | 1      | -         | -              | -              | -            |
| tk1v | 100000000009 | example | -    | 1   | 1      | -         | -              | -              | -            |
+------+--------------+---------+------+-----+--------+-----------+----------------+----------------+--------------+

# 全ゾーンのサーバのうち、名称にexampleを含むサーバをシャットダウン
$ usacloud server shutdown --zone=all example

# 全ゾーンにサーバ作成
$ usacloud server create --name example ... --zone=all

参照系だけでなく、リソース作成や更新、電源操作なども一括で行えます。

操作対象リソースの指定にID or 名称 or タグを利用可能に

Usacloudはusacloud リソースコマンド操作対象リソースのような書式となっています。
この中の操作対象リソースの部分はv0系だとID or Nameだったのですが、v1からはタグも利用可能になりました。

# 全ゾーンのサーバのうち、env=stagingというタグがついているサーバを一括シャットダウン
$ usacloud server shutdown "env=staging"

いわゆるDry Run機能

libsacloudにはFakeドライバーという機能があり、さくらのクラウド API呼び出しをローカルで擬似的に行えるようになっています。主にテスト用途での利用を想定したものです。

# dry-run
$ usacloud server create --name example --fake

# 作成したリソースのデータを永続化しておきたい場合は--fake-storeを併用する
$ usacloud server create --name example --fake --fake-store ~/.usacloud/fake_store.json

Fakeドライバーはバックエンドストレージとしてインメモリ/ローカルファイルを選べるようになっており、ローカルファイルを用いればデータの永続化も行えるようになっています。
また、Terraformのさくらのクラウド向けプロバイダーやPrometheusのさくらのクラウド向けExporterでもFakeドライバーが利用可能で、例えばTerraformで作ったリソースをPrometheusで監視しつつUsacloudでリソースのCRUDや電源操作の動作確認、といったことを実際のリソースを作成することなく行えます。

RESTコマンドの追加

上級者向けではあるのですが個人的にお気に入りの機能なので紹介しておきます。

docs.usacloud.jp

さくらのクラウド APIをUsacloudやAPIライブラリlibsacloudの抽象化を通さずに直接叩くためのコマンドです。

# 特定サーバの電源をOFFにする: https://developer.sakura.ad.jp/cloud/api/1.1/server/#delete_server_serverid_power
$ usacloud rest -X DELETE -d '{"Force":true}' https://secure.sakura.ad.jp/cloud/zone/is1a/api/cloud/1.1/server/$ID/power 

# APIルートURLは省略可能
$ usacloud rest -X DELETE -d '{"Force":true}' /server/$ID/power 

# パラメータはファイルからでもOK
$ usacloud rest -X DELETE -d parameter.json /server/$ID/power

curlを直接使えば良い、という感はありますが、APIキーやゾーンの指定は結構面倒なのでなかなか便利です。

WebAssembly(WASM)対応

GOOS=js GOARCH=wasm go buildでビルドできるようになりました。実行するにはグルーコードが必要ですがnodejs上やブラウザ上でもUsacloudを動かせるようになりました。

# nodejs上でwasmを実行
$(go env GOROOT)/misc/wasm/go_js_wasm_exec usacloud.wasm -v

1.0.0 js/wasm, build c0ceb3ae

せっかくWebAssemblyに対応しましたのでブラウザ上でも動かせるように次で紹介するChrome拡張UsaConもUsacloud v1.0と同時リリースしました。

さくらのクラウドのコントロールパネル上でUsacloudを実行できるChrome拡張`UsaCon`

f:id:febc_yamamoto:20201222102242p:plain

chrome.google.com

利用方法についてはこちらのドキュメントを参照ください。 docs.usacloud.jp

UsaConは@wasmer/wasm-terminalというコンポーネントを用いて前述のUsacloud v1.0 WASM版を動かせるようにしたものです。 github.com

@wasmer/wasm-terminalはXterm.jsやComlinkなどを用いた、WASIという規格に対応したWASMをブラウザ上で実行できるコンポーネントなのですが、これをGoで作成したWASMを実行できるように改修して利用しています。

(この辺の実装の詳細については機会があればどこかに書いておこうと思っています。)

今はストレージもエディタも付属していないのですが、今後BrowserFSみたいなやつでバックエンドをオブジェクトストレージにしてみたり、vim.wasmみたいにエディタを動かせるようにしたりすると面白いんじゃないかなと思っています。(出来るかはまだわかりませんが)

なお、UsaConはAPIキーの保存にCredential Management APIのPasswordCredentialを利用していますのでChromeのみのサポートとなっています。 Firefox/Safariのサポートは今のところ出来ていません。Edgeはもしかしたら大丈夫かもしれませんが開発環境が手元にないので対応していません。

`UsaCon`スクリーンショット

f:id:febc_yamamoto:20201221175149p:plain — UsaConでサーバ作成したところ

f:id:febc_yamamoto:20201221175225p:plain — UsaConでサーバの電源をONにしたところ

Usacloud v1.0 / UsaConの注意点

Usacloud v1.0では過去のバージョンと互換性のない変更がいくつか行われています。

例えば(APIで取得できる)全種類のリソースのサマリーを表示するusacloud summaryコマンドやデータベースアプライアンスのログを表示するusacloud database logsコマンドなどの廃止、パラメータ名の変更(--nw-mask-len => --netmask)などです。 Usacloud v0系からアップグレードされる方は前述の--fakeモードなどでDryRunして動作確認してみることをお勧めします。

その他にもいくつか破壊的な変更点があります。網羅的ではありませんがアップグレードガイドを用意していますのでこちらもご一読ください。

docs.usacloud.jp

まとめ

様々な改善が行われたUsacloud v1.0をリリースしました
Usacloud v1.0をブラウザ上で動かすためのChrome拡張UsaConをリリースしました
Usacloud v1.0にはv0系と互換性のない変更も含まれるためアップグレードの場合は注意が必要

ということで是非ご利用ください。

以上です。

2020-10-02

sakuracloud_exporter v0.13 − ショートメッセージサービス対応/GitHub Container Registryへの移行

さくらのクラウド Prometheus

さくらのクラウド向けPrometheus Exporterであるsakuracloud_exporterのv0.13をリリースしました。

github.com

主な変更点は以下2つです。

ショートメッセージサービスのサポート
GitHub Container Registryでのイメージ配布の開始

ショートメッセージサービスのサポート

ショートメッセージサービスとは

先月(2020年9月)に「さくらのクラウド　ショートメッセージサービス（SMS）」が提供開始されました。

cloud-news.sakura.ad.jp

携帯電話番号をAPIまたはコントロールパネルから指定すると6桁の番号をスマートフォンや携帯電話に送信することができるサービスです。
2要素認証で使うよくあるアレですね。

こんな感じのメッセージが送られてきます。

f:id:febc_yamamoto:20201002162528j:plain

6桁の数値はさくらのクラウド側で生成、またはAPI( or コンパネ)から指定することができます。

sakuracloud_exporterでのショートメッセージサービスのサポート

sakuracloud_exporterではショートメッセージサービスのサポートとして以下2つのメトリクスを追加しました。

sakuracloud_esme_info : ESME自体の情報の参照用、常に1を返す
sakuracloud_esme_message_count: 処理したメッセージ送信リクエストの数

それぞれ以下のような値となります。

# HELP sakuracloud_esme_info A metric with a constant '1' value labeled by ESME information
# TYPE sakuracloud_esme_info gauge
sakuracloud_esme_info{description="description",id="123456789012",name="example",tags=",tag1,tag2,"} 1

# HELP sakuracloud_esme_message_count A count of messages handled by ESME
# TYPE sakuracloud_esme_message_count gauge
sakuracloud_esme_message_count{id="123456789012",name="example",status="All"} 4
sakuracloud_esme_message_count{id="123456789012",name="example",status="Accepted"} 2
sakuracloud_esme_message_count{id="123456789012",name="example",status="Delivered"} 2

sakuracloud_esme_message_countの方にはラベルとしてstatusという項目を設けています。
2要素認証SMSのAPIでは各メッセージごとにステータスを持っていますのでそれを集計してます。

// ショートメッセージサービスAPIレスポンスの例(ログ取得API)
{
  "ESME": {
    "logs": [
      {
        "messageId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
        "status": "Delivered", <-- この値ごとに集計している
        "otp": "123456",
        "destination": "819012345678",
        "sentAt": "...",
        "doneAt": "...",
        "retryCount": 0
      },
      ...
    ]
  }
}

メッセージ全体の件数はstatusがAllのやつを見ればOKです。

GitHub Container Registryでのイメージ配布の開始

v0.13.1からDocker Hubでのイメージ配布に加えてGitHub Container RegistryでもDockerイメージの配布を行うようになりました。

github.com

当面は両方で配布しますが、将来的にはGitHub Container Registryに1本化するつもりです。

使い方は従来のイメージ指定部分にghcr.ioを付け加えるだけです。

# DockerHubのイメージを利用する場合(従来)
$ docker run docker run <options> sacloud/sakuracloud_exporter

# GitHub Container Registryを利用する場合
$ docker run <options> ghcr.io/sacloud/sakuracloud_exporter

既にドキュメント類もGitHub Container Registryを利用する方法に書き換えていますので、今からsakuracloud_exporterを利用し始める方はそちらをご利用ください。

余談: ESMEってなんの略?

今回追加されたショートメッセージサービスについてですが、さくらのクラウド API上ではesmeという名前になってます。

f:id:febc_yamamoto:20201002165823p:plain

なんの略だろうと調べてみたら、どうもExternal Short Message Entityの略っぽいですね。

k-tai.watch.impress.co.jp

なるほど。。勉強になりました。

ということで今回は以上です。是非ご利用ください。

2020-05-26

Terraform+GitHub Actionsでコミュニティープロバイダーを利用する方法について

Terraform

さくらのクラウド向けプロバイダーなどのTerraformのコミュニティプロバイダーをGitHub Actionsで利用する際に独自のGitHub Actionsを作成しているケースを見かけました。

ak1ra24.hatenablog.com

qiita.com

私が最近よく使っているhashicorp/setup-terraform+terraform.d配下にプロバイダーのバイナリーを置くという方法だとアクションを自作しなくても済むので今回紹介しておきます。

`hashicorp/setup-terraform`+`terraform.d`配下にプロバイダーのバイナリーを置く方法

こちらのリポジトリでさくらのクラウドプロバイダーを利用する例を公開しました。

github.com

Terraformで利用するtfファイル郡+GitHub Actionsとしてhashicorp/setup-terraformを利用する構成になっています。 (注: この例ではstateの扱いを手抜きしてます。本番環境で利用する際はTerraform Cloudを使うなどの対応が必要です)

`hashicorp/setup-terraform`

HashiCorp社が公開しているGitHub Actionsです。前述の記事ではhashicorp/terraform-github-actionsが参照されていましたが、こちらの後継がhashcorp/setup-terraformです。

www.terraform.io

こちらの記事に新旧比較がありました。

tech.medpeer.co.jp

hashicorp/setup-terraformを利用すれば基本的なTerraformでの操作は行えそうですね。

コミュニティプロバイダーの配置

コミュニティプロバイダーは~/.terraform.d/plugins/配下以外にもいくつか有効な置き場所があります。

www.terraform.io

特にワーキングディレクトリのterraform.d配下に置く方法は

tfファイル類と同じリポジトリ内に配置できる -> コードとプロバイダーのバージョン管理が容易
プロバイダーのダウンロードが行えないような環境(Air-Gap)でも利用できる

といった利点があります。Terraform Cloudなどでコミュニティプロバイダーを利用する場合もこの方法を利用しますね。

febc-yamamoto.hatenablog.jp

この2つを組み合わせることでGitHub Actionsでコミュニティープロバイダーを利用可能となります。

実行例: https://github.com/yamamoto-febc/terraform-github-action-test/runs/709137993?check_suite_focus=true

おまけ: Terraform v0.13以降では

febc-yamamoto.hatenablog.jp

こちらの記事のようにコミュニティプロバイダーがTerraform Registryに登録されていればプロバイダーのバイナリーをterraform.d配下に置く必要もなくなります。この辺も楽になりそうですね。

終わりに

ということでTerraform+GitHub Actionsでコミュニティープロバイダーを利用する方法について紹介しました。
コミュニティプロバイダーでも割と簡易な手順で利用できますので是非お試しください。

以上です。

2020-05-15

Terraform v0.13開発版でプロバイダーの自動インストール/更新を試す

Hashicorp Terraform TerraformRegistry さくらのクラウド

今年の1月にTerraform Registryでプロバイダー(3rd含む)を配布できるようにするというアナウンスがありました。

www.hashicorp.com

ベータテストへの参加を募集していたので申し込んでおいたのですが、本日(2020/5/15)参加できるようになったとの連絡をいただいたので早速プロバイダーの公開&自動インストールを試しました。

Terraform Registryでのプロバイダーの配布

従来はterraform initを実行してもgithub.com/terraform-providers配下のプロバイダーのみが自動インストールされるだけで、コミュニティが開発しているプロバイダーは~/.terraform.d/plugins/配下に格納しておくなど手動でのインストール作業が必要でした。

これがTerraform Registryにあらかじめプロバイダーの登録を行っておくことで自動でインストール/更新が可能となりました。

試しにさくらのクラウド向けプロバイダーをTerraformRegistryで公開してみました。

f:id:febc_yamamoto:20200515100233p:plain

registry.terraform.io

(ベータテスト中は上記のプロバイダー自体が予告なく削除される可能性もあります)

プロバイダーのインストール/更新

公開したプロバイダーのインストール/更新を試してみます。

Terraform v0.13開発版のビルド

試すにはTerraform v0.13の開発版が必要です。今はビルド済みのバイナリが提供されていないため、GitHubからソースをクローンしてビルドする必要があります。 Goの開発環境を用意して以下でビルドします。

$ git clone https://github.com/hashicorp/terraform.git ; cd terraform
$ make dev

これで$GOPATH/bin/terraformが作成されます。

tfファイルの準備

以下のようなブロックをtfファイルに記述する必要があります。

terraform {
  required_providers {
    sakuracloud = {
      source = "sacloud/sakuracloud"
      version = "~> 2"
    }
  }
}

`terraform init`の実行

あとはterraform initを実行するだけです。

f:id:febc_yamamoto:20200515101128p:plain

インストールされましたね！インストールされたプラグインはカレントディレクトリ配下の.terraform/plugins配下のディレクトリ内に格納されます。

f:id:febc_yamamoto:20200515101353p:plain

これは便利ですね！ 3rd プロバイダーは更新が面倒なために一度インストールしたらなかなか更新してもらえないという問題があったのですが、これで更新も行えるようになるため非常に楽になると思います。 (もちろんバージョンをピンすることもできます)

ということで正式リリースがとても楽しみです！！

プロバイダー開発者向け: Terraform Registryでの配布までの作業

ここからはプロバイダー開発者向けにTerraform Registryでプロバイダーを配布するまでに必要な作業をまとめておきます。

全体的には以下のような作業が必要となります。

HashiCorp社にベータテストへの参加を申し込む(こちらの記事を参照)
受付メールがきたら以下をHashiCorp社の担当者さんに伝える
- ベータテストに参加する人のGitHubのユーザー名(Terraform Registryへのログインに使うアカウント)
- 署名用GPG公開鍵
(HashiCorpさん側でTerraform Registryでのベータテストを有効にしてもらう)
プロバイダーのビルド/署名(GoReleaserのテンプレートが提供される)
- 各OS/プロバイダー向けにビルド&zipアーカイブ作成
- チェックサム(sha256sum)を生成
- チェックサムに対し署名
- gitタグを打ち、GitHubへpush、リリース(pre-releaseでも可)
(初回のみ) Terraform Registry上からプロバイダーの登録

Note: これ以外にもプロバイダーのリポジトリ内にドキュメントを指定のフォーマットで準備しておく必要があります。
プロバイダーのテンプレートなどを参考に準備しておきましょう。

これらはベータテスト参加時に提供されるドキュメント(多分一般公開されてるやつ)に書いてありますのでそちらに従って作業していけば大丈夫です。

Terraform Registry上での公開は以下のような感じです。

まず、ベータテストに参加すると右上のPublishメニュー内にProviderというメニューが生えます。

f:id:febc_yamamoto:20200515102956p:plain

これを選ぶと次にGitHub上のオーガニゼーションを選択する画面が出てきます。
プロバイダーのリポジトリがあるオーガニゼーションを選択しましょう。

f:id:febc_yamamoto:20200515103035p:plain

オーガニゼーションを選択すると、公開するプロバイダーのリポジトリを選択する画面になります。

f:id:febc_yamamoto:20200515103140p:plain

あとはPublishボタンを押すだけです。規約に同意したらチェックを入れてPublishボタンを押せば公開されます。

f:id:febc_yamamoto:20200515103220p:plain

ドキュメントもterraform.ioのように綺麗に表示されてますね。

f:id:febc_yamamoto:20200515103347p:plain

なお、古くからプロバイダーを書いている場合、ドキュメントの手直しが少々必要かもしれません。具体的には各リソースのドキュメント(.md)の先頭にサブカテゴリー(サイドバー)の定義を書いていく必要があります。この辺はTerraformのドキュメントを参照の上適切に直しておきましょう。

ということでTerraform v0.13の機能を先取りで試してみました。

従来の3rdプロバイダーは更新が面倒なために、古いバージョンを使っていること起因の問題がよく発生していました。これを解消できますのでかなり期待しています。

v0.13のリリースが待ち遠しいですね！

以上です。

2020-05-08

TerraformerでGmailフィルタプロバイダーのコードをリバース生成する

Terraform Terraformer Gmail

はじめに: TerraformerへGmailフィルタプロバイダー対応がマージされた

既存の環境からTerraformのコード(tfファイル)+Stateファイル(terraform.tfstate)を生成してくれるTerraformerというツールがあります。

github.com

本日、このTerraformerにGmailフィルタプロバイダー対応を追加するPRがマージされました。

github.com

これにより、既にブラウザからある程度フィルタを作成済みのアカウントでもterraform-provider-gmailfilterを利用しやすくなりました。

背景

terraform-provider-gmailfilterについては以前以下の記事を書きました。

febc-yamamoto.hatenablog.jp

このプロバイダーはgmailfiltersというツールにインスパイアされて作成したものです。
ただ、gmailfiltersには既存のフィルタをエクスポートする機能がありますがこのプロバイダーでは実装していませんでした。

このため、既にGmail上でラベルやフィルタを作成済みのアカウントではGmailフィルタプロバイダーを導入するのが若干面倒でした。 (インポート機能は実装済みなため、tfファイルを書いて個別にインポートしていけば対応できてましたが面倒ですよね)

エクスポートについては、既に既存の環境からTerraformのコード(tfファイル)+Stateファイル(terraform.tfstate)を生成してくれるツールがいくつか存在するため、プロバイダー側で提供するのではなくそれらを利用した方が良いと考えていたからです。

このために、それらのツールの中でも個人的に１番のお気に入りであるTerraformerにGmailフィルタプロバイダー対応を行い、本日無事にマージされました。

使い方

Terraformerのビルド

今はまだマージされたばかりでこの変更を含めたリリースが行われていない状態ですので、利用するにはソースからビルドする必要があります。
README.mdを参考に手元でビルドします。

今回はDocker上でビルドしてみました。

# ソース一式をクローン
$ git clone https://github.com/GoogleCloudPlatform/terraformer.git; cd terraformer

# ビルド用コンテナ起動
$ docker run -it --rm -v $PWD:$PWD -w $PWD golang:1.14

# 依存モジュールのダウンロード
$ go mod download

# ビルド(ここではmacos向けにビルドしてます)
$ GOOS=darwin GOARCH="amd64" go build -v

これでカレントディレクトリにterraformer実行ファイルが生成されます。

Gmailフィルタプロバイダーのインストール

次にGmailフィルタプロバイダーをインストールしておきます。こちらのリリースページから実行ファイルをダウンロードし、~/.terraform.d/plugins/darwin_amd64/配下(macosの場合)に配置しておきます。

Gmail APIの認証(Gmailフィルタプロバイダーを利用したことがない方)

次にGmail APIを有効にし、APIを利用するための認証設定を行なっておきます。今回はApplication Default Credentialsを利用します。

まずは以下に従いAPIコンソールからGmail APIを有効化します。

support.google.com

次にクレデンシャルの作成、OAuthクライアントの作成、シークレットファイルのダウンロードを行います。ダウンロードしたファイルはclient_secret.jsonという名前で保存しておきます。

保存したら以下のコマンドを実行します。

gcloud auth application-default login \
  --client-id-file=client_secret.json \
  --scopes \
https://www.googleapis.com/auth/gmail.labels,\
https://www.googleapis.com/auth/gmail.settings.basic

実行するとブラウザでアクセスを許可しても良いか尋ねる画面が開きますので画面に従い許可していきます。

これで準備完了です。

Terraformerの実行

あとはTerraformerを実行するだけです。
以下のコマンドで既存のラベルとフィルタからtfファイル+terraform.tfstateファイルを生成できます。

$ ./terraformer import gmailfilter -r label,filter

デフォルトだとカレントディレクトリ配下のgenerated/gmailfilter/{filter,label}ディレクトリに以下のようなファイルが生成されます。

例: generated/gmailfilter/filter/filter.tf

resource "gmailfilter_filter" "tfer--ANe1BmgZqKtSU0e8o24MkdHlWUd6JsoQ9PRIug" {
  action {
    add_label_ids    = ["${data.terraform_remote_state.label.outputs.gmailfilter_label_tfer--Google_id}"]
    remove_label_ids = ["INBOX"]
  }

  criteria {
    exclude_chats  = "false"
    has_attachment = "false"
    query          = "from:mail-noreply@google.com"
    size           = "0"
  }
}

resource "gmailfilter_filter" "tfer--ANe1BmiABTbNsxNxhKfdIlJN-002D-2BJRicNJdqRYQ" {
  action {
    add_label_ids    = ["${data.terraform_remote_state.label.outputs.gmailfilter_label_tfer--parent_child_id}"]
    remove_label_ids = ["INBOX"]
  }

  criteria {
    exclude_chats  = "false"
    from           = "foobar@example.com"
    has_attachment = "false"
    size           = "0"
  }
}

# ...

例: generated/gmailfilter/label/label.tf

resource "gmailfilter_label" "tfer--Google" {
  label_list_visibility   = "labelShow"
  message_list_visibility = "show"
  name                    = "Google"
}

resource "gmailfilter_label" "tfer--parent" {
  label_list_visibility   = "labelShow"
  message_list_visibility = "show"
  name                    = "parent"
}

resource "gmailfilter_label" "tfer--parent_child" {
  label_list_visibility   = "labelShow"
  message_list_visibility = "show"
  name                    = "parent/child"
}

リソース名が若干長いのが気になりますが、1からtfファイルを書くよりこれを編集していく方が楽だと思います。

注意点

生成されるコードではサブラベルでの親ラベルへの依存の設定がうまくいかないです。サブラベルを利用している場合は適宜tfファイルを書き換える(label.tfのnameなど)必要がありますのでご注意ください。

# 変更前
resource "gmailfilter_label" "tfer--parent_child" {
  label_list_visibility   = "labelShow"
  message_list_visibility = "show"
  name                    = "parent/child"
}

# 変更後
resource "gmailfilter_label" "tfer--parent_child" {
  label_list_visibility   = "labelShow"
  message_list_visibility = "show"
  name                    = "${gmailfilter_label.tfer--parent.name}/child"
}

終わりに

ということでTerraformerを併用することでGmailプロバイダーのコードを書くのが少し楽になりそうです。
是非お試しください。

以上です。

2020-04-26

Gmailのフィルタを管理するためのTerraformプロバイダーを作った

Terraform Gmail

少し前にこちらの記事でgmailfiltersというツールを知りました。

kakakakakku.hatenablog.com

github.com

gmailfiltersはとても良さそうなのですが、なんでもTerraformおじさん的にはTOMLよりHCLで設定を書きたいなと思ったのでこの土日でTerraformプロバイダーを実装してみました。

github.com

Gmailのフィルタ/ラベルを設定するTerraformプロバイダー `terraform-provider-gmailfilter`

Gmail APIでフィルタやラベルの登録/更新/削除が行えます。

例えばfoobar@example.comから来たメールをexampleラベルに振り分けるには以下のようなHCLコードとなります。

# ラベル"INBOX"を参照するためのデータソース
data gmailfilter_label "INBOX" {
  name = "INBOX"
}

# ラベル"example"を作成
resource gmailfilter_label "example" {
  name = "example"
}

# フィルタの登録
resource gmailfilter_filter "example" {
  criteria {
    from = "foobar@example.com"
  }
  action {
    add_label_ids    = [gmailfilter_label.example.id]
    remove_label_ids = [data.gmailfilter_label.INBOX.id]
  }
}

フィルタには以下のような項目が指定可能です。

resource gmailfilter_filter "example" {
  criteria {
    from            = "foobar@example.com"
    exclude_chats   = false
    has_attachment  = false
    negated_query   = "from:someuser@example.com rfc822msgid: is:unread"
    query           = "from:someuser@example.com rfc822msgid: is:unread"
    size            = 1000
    size_comparison = "larger"
    subject         = "example"
    to              = "example@"
  }
  action {
    add_label_ids    = [gmailfilter_label.example.id]
    remove_label_ids = ["INBOX"]
    forward          = "destination@example.com"
  }
}

利用例: 入れ子になったラベル(サブラベル)の管理

サブラベルも作成できます。

resource gmailfilter_label "top" {
  name = "top-level"
}

resource gmailfilter_label "child1" {
  name = "${gmailfilter_label.top.name}/child1"
}

resource gmailfilter_label "child2" {
  name = "${gmailfilter_label.child1.name}/child2"
}

これをterraform applyすると以下のようになります。

f:id:febc_yamamoto:20200426173455p:plain

利用例: 添付メールに Attachment ラベルを付ける

元記事にで紹介されてた例です。こちらは以下のようなコードになります。

# Attachmentラベルの作成
resource gmailfilter_label "attachment" {
  name = "Attachment"
}

# フィルターの作成
resource gmailfilter_filter "attachment" {
  criteria {
    has_attachment  = true
  }
  action {
    add_label_ids    = [gmailfilter_label.attachment.id]
  }
}

利用例: Amazon 購買メールに Amazon ラベルを付ける

こちらも元記事で紹介されていた例です。
元記事ではqueryOrを用いてますが、このプロバイダーではqueryOrに相当するものは提供していません。
代わりにHCL上で利用できる、Terraformに組み込みのFunctionsを利用してクエリを組み立てていきます。

# 対象のメールアドレスのリスト
locals {
  addresses = [
    "from:shipment-tracking@amazon.co.jp",
    "from:auto-confirm@amazon.co.jp",
    "from:order-update@amazon.co.jp",
  ]
}

# Amazonラベルの作成
resource gmailfilter_label "amazon" {
  name = "Amazon"
}

# フィルターの作成
resource gmailfilter_filter "amazon" {
  criteria {
    query = join(" OR ", local.addresses) # joinでqueryを組み立てる
  }
  action {
    add_label_ids    = [gmailfilter_label.amazon.id]
    remove_label_ids = ["INBOX"]
  }
}

おまけ: 実装について

gmailfiltersではqueryToなどの便利機能を提供していますが、このプロバイダーではその辺を提供せず、GmailのAPIをそのままTerraformでラップしたような形としました。
入力/編集できる項目や値はAPIドキュメントを見ればわかるようになっています。

Terraformを使う層であれば自分でAPIドキュメントを読むくらいするだろうという想定です。
なので出来ることの詳細はGmailのAPIをみていただくのが一番早いと思います。

Gmail:ラベルAPI: https://developers.google.com/gmail/api/v1/reference/users/labels
Gmail:フィルターAPI: https://developers.google.com/gmail/api/v1/reference/users/settings/filters

注意事項

このプロバイダーでは転送先アドレスの管理は実装していません。もしフィルタで転送を行いたい場合はあらかじめWebブラウザなどから転送先アドレスを登録しておく必要があります。参考: Gmail のメールを他のアカウントに自動転送する

また、フィルタを作成しても既存のメールには適用されないようでした。
APIで出来るのかもしれないのですがまだちゃんと調べてないです。

もし適用方法をご存知の方がいらっしゃいましたら教えてもらえると嬉しいです。 (PRもらえるともっと嬉しいです)

終わりに

G Suiteにも対応しておりなかなか便利だと思います。
Terraform好きな方はぜひお試しくださいー。

以上です。

2020-04-23

HashiCorp Certified: Terraform Associateを受験した

Terraform Hashicorp

本日(2020/4/22)HashiCorpの認定試験であるHashiCorp Cloud Engineer Certification Programが一般公開され、Terraform/Vaultのアソシエイトレベルの試験が開始されました。

We’ve had this in beta for awhile (since HashiConf last year when we ran some free in-person trials) and we’re happy to announce the HashiCorp Cloud Engineer Certification Program! Vault and Terraform associate available now, Consul + Advanced coming soon. https://t.co/9GoZluRC6t pic.twitter.com/oh4AMsHXYA
— Mitchell Hashimoto (@mitchellh) 2020年4月21日

去年のHashiConfでベータ版としてアナウンスされてたやつですね。

受験費用は$70.5(税別)となんとか手が出る価格だったので早速受験してみました。

結果

無事合格しました。満点取れるかなと思ったのですがいくつか取りこぼしちゃいましたね。。。

f:id:febc_yamamoto:20200423000343p:plain

ひとまず安心しました。

www.youracclaim.com

今後受験する人向けに書ける範囲でメモを残しておきます。

試験の概要/試験範囲

www.hashicorp.com

受験までの流れ

上記サイトから申し込み
申込サイト(ondemand.questionmark.com)にてアカウント作成
同サイトにてシステム要件のチェック(Webカメラ、スピーカー、マイクなど。専用のチェックページがログイン後の画面にある)
Buy ExamというタブがあるのでそこからHashiCorp Certified: Terraform Associateを購入
同サイトから受験する日時をスケジューリングする(多分PDTなのでJSTの日中は選べない)
(重要) 案内メールが来る
このメールに受験のルールなどの詳細が記載されているので必ず目を通す
時間になったら同サイトから試験開始

事前に用意しておくもの

国が発行した写真付きの身分証明書(パスポートなど)

勉強した内容

とりあえず試験範囲をざっと眺めて、Terraformのドキュメントを通読しました。

www.terraform.io

このドキュメントにはTerraform v0.12以前/以降両方のドキュメントが含まれるのですが、今回の試験はTerraform v0.12以降が対象ですのでv0.12以前のバージョンについて書かれたドキュメントについては無視して構いません。

また、試験用の教材として以下の2つが用意されていますのでこれらを読むのも良いかもしれません。

learn.hashicorp.com

合格後の特典

Credly’s Acclaim platformの提供するデジタルバッジがもらえるとのことでした。

↓↓こんなやつです。

f:id:febc_yamamoto:20200423002531p:plain

出典: https://www.youracclaim.com/org/hashicorp/badge/hashicorp-certified-terraform-associate

合格後10日以内に案内のメールが来るらしいです。

4/29 追記: その後無事に届きました。

www.youracclaim.com

感想

内容よりも英語が大変でした。
記憶力だけを問う意地の悪い問題はなかったので、丁寧に試験範囲のドキュメントを読んでおけば十分じゃないかなと感じました。

終わりに

次はVaultを受けてみます。。。お小遣いが貯まったら。

以上です。

はじめに

Usacloud v1.0

Usacloud v0系で不満だった点

Usacloud v1.0系での改善や主な新機能

全ゾーン一括操作

操作対象リソースの指定にID or 名称 or タグを利用可能に

いわゆるDry Run機能

RESTコマンドの追加

WebAssembly(WASM)対応

さくらのクラウドのコントロールパネル上でUsacloudを実行できるChrome拡張UsaCon

UsaConスクリーンショット

Usacloud v1.0 / UsaConの注意点

まとめ

ショートメッセージサービスのサポート

ショートメッセージサービスとは

sakuracloud_exporterでのショートメッセージサービスのサポート

GitHub Container Registryでのイメージ配布の開始

余談: ESMEってなんの略?

hashicorp/setup-terraform+terraform.d配下にプロバイダーのバイナリーを置く方法

hashicorp/setup-terraform

コミュニティプロバイダーの配置

おまけ: Terraform v0.13以降では

終わりに

Terraform Registryでのプロバイダーの配布

プロバイダーのインストール/更新

Terraform v0.13開発版のビルド

tfファイルの準備

terraform initの実行

プロバイダー開発者向け: Terraform Registryでの配布までの作業

はじめに: TerraformerへGmailフィルタプロバイダー対応がマージされた

背景

使い方

Terraformerのビルド

Gmailフィルタプロバイダーのインストール

Gmail APIの認証(Gmailフィルタプロバイダーを利用したことがない方)

Terraformerの実行

注意点

終わりに

Gmailのフィルタ/ラベルを設定するTerraformプロバイダー terraform-provider-gmailfilter

利用例: 入れ子になったラベル(サブラベル)の管理

利用例: 添付メールに Attachment ラベルを付ける

利用例: Amazon 購買メールに Amazon ラベルを付ける

おまけ: 実装について

注意事項

終わりに

結果

試験の概要/試験範囲

受験までの流れ

事前に用意しておくもの

勉強した内容

合格後の特典

感想

終わりに

さくらのクラウドのコントロールパネル上でUsacloudを実行できるChrome拡張`UsaCon`

`UsaCon`スクリーンショット

`hashicorp/setup-terraform`+`terraform.d`配下にプロバイダーのバイナリーを置く方法

`hashicorp/setup-terraform`

`terraform init`の実行

Gmailのフィルタ/ラベルを設定するTerraformプロバイダー `terraform-provider-gmailfilter`