TerraformerでGmailフィルタプロバイダーのコードをリバース生成する
はじめに: TerraformerへGmailフィルタプロバイダー対応がマージされた
既存の環境からTerraformのコード(tfファイル)+Stateファイル(terraform.tfstate)を生成してくれるTerraformerというツールがあります。
本日、このTerraformerにGmailフィルタプロバイダー対応を追加するPRがマージされました。
これにより、既にブラウザからある程度フィルタを作成済みのアカウントでもterraform-provider-gmailfilterを利用しやすくなりました。
背景
terraform-provider-gmailfilterについては以前以下の記事を書きました。
このプロバイダーは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を有効化します。
次にクレデンシャルの作成、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プロバイダーのコードを書くのが少し楽になりそうです。
是非お試しください。
以上です。
Gmailのフィルタを管理するためのTerraformプロバイダーを作った
少し前にこちらの記事でgmailfiltersというツールを知りました。
gmailfiltersはとても良さそうなのですが、なんでもTerraformおじさん的にはTOMLよりHCLで設定を書きたいなと思ったので この土日でTerraformプロバイダーを実装してみました。
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すると以下のようになります。
利用例: 添付メールに 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好きな方はぜひお試しくださいー。
以上です。
HashiCorp Certified: Terraform Associateを受験した
本日(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(税別)となんとか手が出る価格だったので早速受験してみました。
結果
無事合格しました。満点取れるかなと思ったのですがいくつか取りこぼしちゃいましたね。。。
ひとまず安心しました。
今後受験する人向けに書ける範囲でメモを残しておきます。
試験の概要/試験範囲
受験までの流れ
- 上記サイトから申し込み
- 申込サイト(
ondemand.questionmark.com)にてアカウント作成 - 同サイトにてシステム要件のチェック(Webカメラ、スピーカー、マイクなど。専用のチェックページがログイン後の画面にある)
Buy ExamというタブがあるのでそこからHashiCorp Certified: Terraform Associateを購入- 同サイトから受験する日時をスケジューリングする(多分PDTなのでJSTの日中は選べない)
- (重要) 案内メールが来る
このメールに受験のルールなどの詳細が記載されているので必ず目を通す - 時間になったら同サイトから試験開始
事前に用意しておくもの
国が発行した写真付きの身分証明書(パスポートなど)
勉強した内容
とりあえず試験範囲をざっと眺めて、Terraformのドキュメントを通読しました。
このドキュメントにはTerraform v0.12以前/以降両方のドキュメントが含まれるのですが、今回の試験はTerraform v0.12以降が対象ですのでv0.12以前のバージョンについて書かれたドキュメントについては無視して構いません。
また、試験用の教材として以下の2つが用意されていますのでこれらを読むのも良いかもしれません。
合格後の特典
Credly’s Acclaim platformの提供するデジタルバッジがもらえるとのことでした。
↓↓こんなやつです。
出典: https://www.youracclaim.com/org/hashicorp/badge/hashicorp-certified-terraform-associate
合格後10日以内に案内のメールが来るらしいです。
4/29 追記: その後無事に届きました。
感想
内容よりも英語が大変でした。
記憶力だけを問う意地の悪い問題はなかったので、丁寧に試験範囲のドキュメントを読んでおけば十分じゃないかなと感じました。
終わりに
次はVaultを受けてみます。。。お小遣いが貯まったら。
以上です。
Zabbix+さくらのクラウドAPIでクラウド上のリソースを監視する
はじめに
先日teratailに以下のような質問が投稿されていました。
回答を書きながらいくつか資料を探してみたのですが、さくらのクラウド+Zabbix 4系の記事があまり見当たりませんでしたので自分で試した時のメモを残しておくことにしました。
この記事で扱う内容
この記事ではさくらのクラウド上のリソースをZabbix+さくらのクラウドAPIを利用して監視する方法について取り扱います。
具体的には以下のような内容となっています。
- 外部チェック/ユーザーパラメータなどを通じてcurl/usacloudコマンドでさくらのクラウドAPIを叩く
- HTTP agentを利用してさくらのクラウドAPIを叩く
- ZabbixとPrometheusのExporterを組み合わせる
Zabbixのインストールや、そもそもの監視設計(監視対象の選択や通知の設計など)については扱いませんので他サイトなどを参照してください。
それでは早速本題に入っていきます。
ZabbixでさくらのクラウドAPIを通じてクラウド上のリソースを監視する
ZabbixからさくらのクラウドAPIを通じてクラウド上のリソースを監視するにはいくつかの方法があります。
- 1: 外部チェック/ユーザーパラメータ
- 2: HTTP agent(Zabbix 4.0以降)
- 3: PrometheusのExporter + Prometheusチェック(Zabbix 4.2以降)
順番にみていきます。
1. 外部チェック/ユーザーパラメータ
Zabbixサーバ上、またはエージェント上でスクリプト/バイナリを実行じその結果を受け取る方法です。
少々古いバージョンのZabbix(2.2とか)でも利用できます。
参考:
- 外部チェック(External checks): https://www.zabbix.com/documentation/current/manual/config/items/itemtypes/external
- ユーザーパラメータ: https://www.zabbix.com/documentation/current/manual/config/items/userparameters
標準出力に何か出力しておけばそれをZabbixから参照できるということですね。
さくらのクラウドAPIを叩く場合はcurlコマンド、またはCLIであるUsacloudを利用し、
出力をjqコマンドなどで加工してあげると良いと思います。
単純な値をcurlで取得する
# curlでサーバのメモリサイズを取得 $ export TOKEN="さくらのクラウドAPIトークン" $ export SECRET="さくらのクラウドAPIシークレット" $ export ZONE=is1a $ export SERVER_ID=123456789012 # サーバのID $ curl --user "$TOKEN":"$SECRET" https://secure.sakura.ad.jp/cloud/zone/$ZONE/api/cloud/1.1/server/$SERVER_ID | jq ".Server.ServerPlan.MemoryMB" 4096
2020/01/23 コード誤りを修正
アクティビティグラフの値をcurlで取得する
スペックなどを取得する場合はjqコマンドが単純で済むのですが、アクティビティグラフAPIを使用してCPU利用時間やディスクの読み書き量を取得するとなるとちょっと難易度が上がります。
具体的には、アクティビティグラフAPIは以下のようなJSONを返します。
# サーバのCPU-TIMEを取得 $ curl -s --user "$TOKEN":"$SECRET" https://secure.sakura.ad.jp/cloud/zone/is1a/api/cloud/1.1/server/$SERVER_ID/monitor | jq . { "Data": { "2020-01-17T16:45:00+09:00": { "CPU-TIME": 0.043333333333 }, "2020-01-17T16:50:00+09:00": { "CPU-TIME": 0.046666666667 }, "2020-01-17T16:55:00+09:00": { "CPU-TIME": null }, "2020-01-17T17:00:00+09:00": { "CPU-TIME": null }, "2020-01-17T17:05:00+09:00": { "CPU-TIME": null }, "2020-01-17T17:10:00+09:00": { "CPU-TIME": null }, "2020-01-17T17:15:00+09:00": { "CPU-TIME": null }, "2020-01-17T17:20:00+09:00": { "CPU-TIME": null } }, "is_ok": true }
日付がキーとなっていること、値にnullが入っていることでjqコマンドの書き方が難しいですね。
これを処理する場合、
Data配下の要素からCPU-TIMEの値を抜き出し- nullを除去
- 配列の最後の値を取得(昇順になっているため、最新の値は末尾にある)
という感じになります。面倒ですね…
ひとまず手元で確認したところ、jq '[.Data[]["CPU-TIME"]] | del(.[] | nulls) | .[-1]'でいけました。
# curlでアクティビティグラフAPIを叩き値を抽出 $ curl --user "$TOKEN":"$SECRET" https://secure.sakura.ad.jp/cloud/zone/is1a/api/cloud/1.1/server/$SERVER_ID/monitor | jq '[.Data[]["CPU-TIME"]] | del(.[] | nulls) | .[-1]' 0.046666666667
これで外部チェック/ユーザーパラメータからアクティビティグラフAPIの値を活用できそうですね。
アクティビティグラフの値をusacloudで取得する
usacloudコマンドを利用すればさらに楽に値を抽出できます。
というのも、usacloudコマンドは以下のようにAPIから返されるJSONを変換し、単純な配列にしてから出力するからです。null値のフィルタリングもしてくれてます。
こちらの形の方がjqなどで加工しやすいですよね。
$ usacloud server monitor-cpu -o json $SERVER_ID [ { "CPUTime": "0.043333333333", "Key": "sakuracloud.server.123456789012.cpu", "TimeStamp": "2020-01-17 16:45:00 +0900 JST" }, { "CPUTime": "0.046666666667", "Key": "sakuracloud.server.123456789012.cpu", "TimeStamp": "2020-01-17 16:50:00 +0900 JST" } ]
これを利用すると、先ほどのcurlコマンドの例は以下のように書き直せます。
# usacloudでアクティビティグラフAPIを叩き値を抽出 $ usacloud server monitor-cpu -o json $SERVER_ID | jq '.[-1].CPUTime|tonumber' 0.046666666667
2. HTTP agent(Zabbix 4.0以降)
Zabbix 4.0以降で利用できるHTTP agentを利用する方法です。
参考:
とりあえずAPIを叩くだけであれば簡単にできます。
まずアイテム作成画面でタイプがHTTPエージェントなアイテムを作成します。 この時、URLにはさくらのクラウドAPIのURLを入力し、http認証をBasicにしてユーザー名/パスワード欄にそれぞれAPIトークン/シークレットを入力します。
次にこのアイテムをマスターにした依存アイテムを作成します。
ポイントは「保存前処理」を追加する部分ですね。 単純なJSONならJSONPathが使えるのですが、前述のアクティビティグラフAPIのレスポンスのような複雑なものを扱う場合はJavaScriptを使うのが良いと思います。
ここでは取得したJSONからCPU-TIMEの値を抜き出し、nullでない末尾の値を抽出するスクリプトを記載しておきます。
// コピペ用 const data = JSON.parse(value).Data; return Object.keys(data).map(function(v){return data[v]["CPU-TIME"]}).filter(function(v){ return v}).pop()
少々回りくどい書き方になっているのはZabbix 4.4の時点でもES6/ES7は部分的なサポートのみだからです。
なのでObject.values()やアロー関数が使えないんですよね。。。
これはZabbixが採用しているJavaScriptのエンジンDuktape由来です https://duktape.org/
ともあれこれでHTTP agentを利用してアクティビティグラフAPIを叩くことができました。 テンプレート化して汎用化する必要はありますが、単体のリソースを監視する程度であればこの方法だけでも十分使えると思います。
PrometheusのExporter + Prometheusチェック(Zabbix 4.2以降)
Zabbix 4.2以降というのをクリアできれば正直この方法が一番楽だと思います。
さくらのクラウド向けのPrometheus Exporterであるsakuracloud_exporterと組み合わせる方法です。
設定自体も簡単で、以下の記事などを参考にすれば設定で迷うことはないと思います。
Exporterを別途起動しておく必要がある点には注意してください。
ということでZabbix+さくらのクラウドAPIを利用するための3つの方法について紹介しました。
終わりに
今回はZabbix+さくらのクラウドAPIでクラウド上のリソースを監視する方法を紹介しました。
これだけで全ての監視を賄えるわけではないですが、多様な角度から監視する上での選択肢の1つにはなると思います。
以上です。
作業メモ: TeamCity on さくらのクラウド+エンハンスドロードバランサ
JetBrainsのTeamCityをさくらのクラウド上に構築した時のメモです。
概要
構成
- サーバ1台(パケットフィルタ込み)
- エンハンスドロードバランサ(100cps プラン)
- SSL終端
- Let's Encryptでの証明書取得/更新
- TeamCityはDockerで起動
サーバ上で直接証明書取得 & SSL終端してもよかったのですが、環境構築がめんどくさかったのでエンハンスドロードバランサを利用します。
また、サーバへのアクセスはエンハンスドロードバランサに限定するためにパケットフィルタも合わせて利用します。
構築手順
- サーバ作成/Dockerインストール
- エンハンスドロードバランサ作成
- エンハンスドロードバランサで発行されたVIP or FQDNをDNS登録(A or CNAMEレコード)
- エンハンスドロードバランサの設定(待ち受けポート/実サーバ/Let's Encryptなど)
- パケットフィルタ作成 & サーバにアタッチ
- TeamCityをDocker上で起動
- TeamCityのエージェントをDocker上で起動
各手順の詳細
サーバ作成/Dockerインストール
まずはサーバを作成します。今回は2CPU/4GBメモリ/共有セグメントに接続、というスペックで作成しました。
サーバ作成後はDockerがインストールされていない場合はインストールしておきます。
エンハンスドロードバランサ作成
次にエンハンスドロードバランサを作成します。
VIPフェイルオーバを有効にする/しないでこの後作成するDNSレコードの種別が変わりますのでご注意ください。
エンハンスドロードバランサで発行されたVIP or FQDNをDNS登録(A or CNAMEレコード)
エンハンスドロードバランサを作成したらFQDN or VIPが払い出されます。この値をDNS登録しておきます。
前述の通りVIPフェイルオーバの有効/無効に応じて登録するDNSレコード種別が変わります。
VIPフェイルオーバを有効にした場合
FQDNが発行されますのでCNAMEレコードを登録します。
VIPフェイルオーバを無効にした場合:
VIP(Virtual IP Address)が発行されますのでAレコードを登録します。
エンハンスドロードバランサの設定
次にエンハンスドロードバランサの設定を行います。
待ち受けポート
以下のように2つ登録します。
(1) HTTP
- プロキシ方式:
http - 待受ポート番号:
80 - httpsへのリダイレクト:
有効
(2) HTTPS
- プロキシ方式:
https - 待受ポート番号:
443 - HTTP/2のサポート:
無効
実サーバ
IPアドレスに先ほど作成したサーバのIPを入力して登録します。
ポート番号は8111、サーバグループは空のままとします。
Let's Encryptの設定
次に右上のSSH証明書の設定 -> Let's Encryptの設定に進み、Let's Encryptでの証明書自動取得/更新を有効化します。
先ほどCNAMEレコードまたはAレコードを登録したFQDNを指定してください。 (エンハンスドロードバランサから払い出されたFQDNではありません)
パケットフィルタ作成 & サーバにアタッチ
次にサーバへのアクセスをエンハンスドロードバランサからだけに絞るためにパケットフィルタを作成してサーバにアタッチします。
まず、エンハンスドロードバランサが実サーバにアクセスする際のアクセス元IPレンジをメモしておきます。
エンハンスドロードバランサの詳細画面のプロキシ元ネットワークという項目です。
次にパケットフィルタを作成し、エンハンスドロードバランサからのアクセスだけ許可、以外は拒否するルールを設定します。
(この例では管理用にtcp/10022ポートの許可を追加してます)
作成したらサーバの詳細画面からNICに対してパケットフィルタを接続(アタッチ)しておきましょう。サーバを起動したままでアタッチ可能です。
TeamCityをDocker上で起動
ようやくTeamCityのインストールです。 以下のマニュアルからDockerでのインストール周りへと辿ります。
余談ですが、日本語版マニュアルが
jetbrains.comじゃなくてpleiades.ioなのが気になって調べたら↓↓が出てきました。
https://blog.jetbrains.com/jp/2018/10/18/1355
Pleiadesは昔大変お世話になりました。
今回は以下のように起動しました。
# bridgeネットワークを作成しておく $ docker network create teamcity # TeamCityサーバ起動 $ docker run -d --name teamcity-server-instance \ -v teamcity-data:/data/teamcity_server/datadir \ -v teamcity-log:/opt/teamcity/logs \ -p 8111:8111 \ --network teamcity \ jetbrains/teamcity-server
面倒だったのでDocker ComposeやKubernetesを使わずにDockerコマンドを直接使ってます。
TeamCityのエージェントをDocker上で起動
次にTeamCityのエージェントをDocker上で起動します。 (リスクのある方法ですので以下のドキュメントをちゃんと読んでおきましょう)
https://hub.docker.com/r/jetbrains/teamcity-agent/
今回は以下のように起動しました。
$ docker run -d --name teamcity-agent-01 \ -e SERVER_URL="http://teamcity-server-instance:8111" \ -e AGENT_NAME="agent-01" \ -v teamcity-agent-data:/data/teamcity_agent/conf \ --network teamcity \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /opt/buildagent/work:/opt/buildagent/work \ -v /opt/buildagent/temp:/opt/buildagent/temp \ -v /opt/buildagent/tools:/opt/buildagent/tools \ -v /opt/buildagent/plugins:/opt/buildagent/plugins \ -v /opt/buildagent/system:/opt/buildagent/system \ jetbrains/teamcity-agent
アクセスしてみる
ブラウザでAレコード or CNAMEレコードを登録したFQDNにアクセスするとTeamCityの画面が開くはずです。
あとは画面の指示/マニュアルを参考に進めていけばOKなはずです。
終わりに
今回はバックアップなど運用面をあまり気にしてませんので実運用の際はオプションの精査などをしっかり行ってください。
以上です。
TerraformのRKEプロバイダーをRancher Labsに移管しました
はじめに
Rancher Labsが提供するRKE(Rancher Kubernetes Engine)をTerraformから扱えるようにするRKEプロバイダーを私の個人リポジトリからRancher Labs配下へ移管しました。
移管によりこれまで以上にRKE本体との連携も進むでしょうし、今後はより一層安定してご利用いただけるようになりそうです。
TerraformのRKEプロバイダーって何？
こちらで紹介しています。
どんな人がRKEプロバイダーを使ってるの?
国外での利用が多いです。AWS(EC2)やAzure、OpenStack、vSphere、DigitalOceanとの組み合わせあたりでご利用いただくケースが多いです。
Rancher Labsが公開しているブログやYouTubeチャンネルなどで紹介されたこともあります。
以下のようなところで紹介されました。
Rancher Labsブログ
RanchCast(YouTube)
www.youtube.com (32:50秒あたりから)
Medium
使ってみた系記事: medium.com
RKEプロバイダーを組み込んだtk8というツール blog.kubernauts.io
これからRKEプロバイダーはどうなるの?
私は開発から一歩引き、今後はRancher Labs主導で開発が進められます。
Rancher LabsにはすでにRancher2プロバイダーがあり、一見RKEプロバイダーと機能的に重複して見えますが 利用シーンが異なるためある程度コードベースの統合はあってもプロバイダー自体は独立して開発が続くのではないかと思っています。
ちょうどそろそろRKEもv1.0に到達しようとしています。
(2019/11/18現在はv1.0.0-rc5までリリースされています)
これに追随してRKEプロバイダーもバージョンアップしていくのではないかと期待しています。
終わりに
Rancher Labs主導で開発が行われることでより安心して利用できるようになると思います。
ぜひご利用ください！
RancherによるKubernetes活用完全ガイド (Think IT Books)
- 作者: 市川豊,藤原涼馬,西脇雄基
- 出版社/メーカー: インプレス
- 発売日: 2019/07/23
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Terraformからウェブアクセラレータの証明書を管理する
Terraformからウェブアクセラレータを参照/一部の操作ができるように
Terraformのさくらのクラウドプロバイダー v1.18.1からウェブアクセラレータ向けのリソースが追加されました。
sakuracloud_webaccel: サイト情報を参照するためのデータソースsakuracloud_webaccel_certificate: サイトに登録する証明書リソース
sakuracloud_webaccelデータソース
サイト情報を参照するためのものです。
名前 or ドメインを指定して対象サイトの情報を参照できます。
以下のようなtfファイルで利用します。
data sakuracloud_webaccel "example" { domain = "www.example.com" # または # name = "example" }
以下のような情報が参照可能です。
$ terraform show data "sakuracloud_webaccel" "example" { cname_record_value = "xxxxxx.user.webaccel.jp." domain = "www.example.com" domain_type = "own_domain" has_certificate = true id = "xxx" name = "example" origin = "192.0.2.1" site_id = "xxx" status = "enabled" subdomain = "xxxxx.user.webaccel.jp" txt_record_value = "webaccel=xxxxx.user.webaccel.jp" }
利用例: サイト有効化に必要なDNSレコードの登録
ウェブアクセラレータでは独自ドメイン利用時にCNAMEまたはTXTレコードの設定が必要になります。
このデータソースはそのための値を持っており、以下のようにすることでレコードの登録が簡単に行えます。
data sakuracloud_webaccel "example" {
domain = "www.example.com"
}
data sakuracloud_dns "zone" {
name_selectors = ["example.com"]
}
# webaccelデータソースの値を参照してDNSレコード登録
resource "sakuracloud_dns_record" "webaccel" {
dns_id = sakuracloud_dns.zone.id
name = "www"
type = "CNAME"
value = data.sakuracloud_webaccel.example.cname_record_value
}
証明書の登録/更新が行えるsakuracloud_webaccel_certificateリソース
以下のようなコードで証明書の登録/更新が行えるようになりました。
data sakuracloud_webaccel "site" { name = "example" } resource sakuracloud_webaccel_certificate "example" { site_id = data.sakuracloud_webaccel.site.id certificate_chain = file("crt") private_key = file("key") }
応用例: TerraformのACMEプロバイダーと組み合わせる
ウェブアクセラレータに登録する証明書をTerraformのACMEプロバイダーを用いてLet's Encryptで取得してみます。
今回はDNSを用いて取得します。ACMEプロバイダーではDNSプロバイダーとしてさくらのクラウドDNSがサポートされていますのでこちらを利用します。
コードは以下のようになります。
data sakuracloud_webaccel "site" { name = "example" } resource sakuracloud_webaccel_certificate "foobar" { site_id = data.sakuracloud_webaccel.site.id certificate_chain = "${acme_certificate.cert.certificate_pem}${acme_certificate.cert.issuer_pem}" private_key = acme_certificate.cert.private_key_pem } provider "acme" { # レートリミットに注意 server_url = "https://acme-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 = "nobody@example.com" #自分のメールアドレスに置き換える } resource "acme_certificate" "cert" { account_key_pem = "${acme_registration.reg.account_key_pem}" common_name = "www.example.com" # 任意のドメインに変更 subject_alternative_names = ["www2.example.com"] # 任意のドメインに変更 dns_challenge { provider = "sakuracloud" config = { # APIキーを環境変数から指定する場合は以下2つの指定は不要 # SAKURACLOUD_ACCESS_TOKEN = "APIトークン" # SAKURACLOUD_ACCESS_TOKEN_SECRET = "APIシークレット" SAKURACLOUD_PROPAGATION_TIMEOUT = "300" } } }
あとは定期的にterraform applyするようにすれば良いでしょう。
終わりに
ぜひご利用ください！
