RioでGitHubリポジトリからのRunを試す
新しくなったRio
KubeCon EUにあわせ新しくなったRioがアナウンスされました。
Rio自体は以前からOSSとして公開されていましたが、今回はRancher Labsからのリリースアナウンスもありある程度開発に区切りがついたということなのでしょう。
公式サイトもできてました。
今回は新しくなったRioを軽く触ってみました。
なおRioについては以前ブログ書いてますのでこちらもご一読ください。
事前準備
Kubernetesクラスタ
以前のRioはスタンドアロンという、embeddedなk8sクラスタ(後のk3s)を起動してくれるモードがありましたが、 新しいRioではk8sクラスタはあらかじめ準備しておく必要があります。
お好みのクラスタを用意しておきましょう。
k3sやDocker for Mac(のk8s)、minikubeもOKですし、GKE/AKS/EKSももちろんOKとのことです。 なおk8s v1.13以降が必要とのことですのでバージョンには注意しておいてください。
rioコマンドのインストール
フロントエンドとなるコマンドrioをインストールしておきます。
以下のコマンドでOKです。
$ curl -sfL https://get.rio.io | sh -
上記コマンドで実行されるシェルスクリプトの確認がめんどくさい場合はGitHubのReleaseページから直接バイナリをダウンロードしてもOKです。
Releases · rancher/rio · GitHub
Rioのセットアップ
各種コンポーネントのデプロイ
まずはRioの各種コンポーネントをk8sクラスタ上にデプロイします。
rio installコマンドを実行することでrio-systemというnamespaceにデプロイされます。
$ rio install Creating namespace rio-system Defaulting cluster CIDR to 10.43.0.1/16 Deploying Rio control plane.... Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for rio controller to initialize Waiting for all the system components to be up. Not ready component: [autoscaler build-controller buildkit cert-manager grafana istio-citadel istio-pilot istio-telemetry kiali prometheus registry webhook] Waiting for all the system components to be up. Not ready component: [autoscaler build-controller buildkit cert-manager grafana istio-citadel istio-pilot istio-telemetry kiali prometheus registry webhook] Waiting for all the system components to be up. Not ready component: [autoscaler buildkit cert-manager grafana istio-citadel istio-pilot istio-telemetry kiali webhook] Waiting for all the system components to be up. Not ready component: [cert-manager grafana istio-pilot kiali] Waiting for service loadbalancer to be up Waiting for service loadbalancer to be up Waiting for service loadbalancer to be up Waiting for service loadbalancer to be up rio controller version v0.1.1-rc3 (2771703b) installed into namespace rio-system Please make sure all the system pods are actually running. Run `kubectl get po -n rio-system` to get more detail. Controller logs are available from `rio systemlogs` Welcome to Rio! Run `rio run https://github.com/rancher/rio-demo` as an example
なお、ここでtype=LoadBalancerなserviceが使えない場合はこのまま待つかHostPortsを使うか聞かれます。
コードを見るとそのほかにも分岐するパターンが結構あるようですね。
環境に合わせ適宜回答しましょう。
デプロイされたか確認
rio installが完了したらkubectl get pod -n rio-systemで確認してみます。
$ kubectl get pod -n rio-system NAME READY STATUS RESTARTS AGE autoscaler-696866b8f7-9fbcq 1/1 Running 0 9m11s build-controller-94b48b58f-m5kgw 2/2 Running 0 8m38s buildkit-7f46884f98-qkjv9 2/2 Running 0 9m6s cert-manager-57b4f876c5-hnxq6 1/1 Running 0 8m43s grafana-68c6d8494d-rt9gg 2/2 Running 0 9m6s istio-citadel-d76685f74-kczqs 1/1 Running 0 9m3s istio-gateway-4ssl5 2/2 Running 0 8m57s istio-gateway-872gl 2/2 Running 0 8m57s istio-gateway-979xb 2/2 Running 0 8m57s istio-pilot-85b894cd75-gg4n5 2/2 Running 0 8m54s istio-telemetry-6b686cbbf5-bzwq5 2/2 Running 0 9m7s kiali-7d4b6dc78c-mm5r2 2/2 Running 0 8m46s prometheus-59c5655d9c-rw8mp 1/1 Running 0 9m11s registry-6c4fddb8b6-2bvrm 2/2 Running 0 8m40s registry-proxy-46ftw 1/1 Running 0 9m8s registry-proxy-shjf9 1/1 Running 0 9m8s registry-proxy-smszz 1/1 Running 0 9m8s rio-controller-86c4bf9698-6blb5 1/1 Running 0 9m27s webhook-5f6fc8f6f9-q6h6w 2/2 Running 0 8m28s
AutoScalerやKnativeのbuild-controller、buildkit、cert-manager、grafana、istio、kiali、prometheus、、、、と色々なPodが並んでますね。
Rioの新機能を試す - GitリポジトリからのRun
前回Rioを試した時にはなかった機能としてGitHubのリポジトリのURLを指定してRunする機能が入っていました。
RioはデフォルトでKnative+buildkitでイメージをビルドするようになっているようです。
(オプションでbuildpackなども使えるようですがまだ試してないです)
ということで早速試してみました。
確認にはこちらのリポジトリを用意しました。
これはgolangでHTTPサーバを立ち上げHello Rio!というメッセージを返すだけの簡単なもので、main.goとDockerfileの2ファイルだけで構成されているリポジトリとなっています。
main.goは以下の通りです。
package main import ( "fmt" "log" "net/http" "time" ) func handler(w http.ResponseWriter, r *http.Request) { time.Sleep(100 * time.Millisecond) fmt.Fprintln(w, "Hello Rio!!") } func main() { http.HandleFunc("/", handler) log.Fatal(http.ListenAndServe(":8080", nil)) }
Dockerfileは以下の通りです。
FROM golang:1.11.1 ENV GOPATH="/go" RUN ["mkdir", "-p", "/go/src/github.com/yamamoto-febc/rio-demo"] COPY * /go/src/github.com/yamamoto-febc/rio-demo/ WORKDIR /go/src/github.com/yamamoto-febc/rio-demo RUN ["go", "build", "-o", "demo"] CMD ["./demo"]
Runしてみる
ということで早速Runしてみました。
# -pオプション: 公開するポート -nオプション: 名前(今回はbuildという名前) $ rio run -p 8080/http -n build https://github.com/yamamoto-febc/rio-demo
rio psを実行してみるとイメージのビルドを待機中と出ました。
$ rio ps # イメージのビルド待ち NAME CREATED ENDPOINT REVISIONS SCALE WEIGHT DETAIL default/build 2 seconds ago https://build-default.7vlxuv.on-rio.io:9443 v0 0/1 100% v0 NotReady; v0 waiting on build
しばらく待つとイメージがビルドされ、コンテナの起動~公開まで行われました。
# イメージがビルドされ、コンテナ起動~公開までされた状態 $ rio ps NAME CREATED ENDPOINT REVISIONS SCALE WEIGHT DETAIL default/build 6 minutes ago https://build-default.7vlxuv.on-rio.io:9443 v0 1 100% # エンドポイント宛てにリクエストしてみる $ curl https://build-default.7vlxuv.on-rio.io:9443 Hello Rio!!
無事表示されましたね！！！
コードの修正〜pushを試す
次にコードを修正し、コミットとプッシュを試してみます。 Rioはデフォルトではmasterブランチへのタグ/コミットのpushをポーリングで検知してくれるとのことです。 (オプションでWebhookも利用できるとのこと)
ということで先ほどのコードを修正しpushして反映されるか確認してみます。
# メッセージを書き換えてみる: "Hello Rio!" から"Bonjour Rio!"へ $ vi main.go $ コミットしてpush $ git add main.go $ git commit -m"Update messages" $ git push origin master
pushしたらRioが検知しているかrio revisionコマンドで確認してみます。
$ rio revision default/build NAME IMAGE CREATED SCALE ENDPOINT WEIGHT DETAIL default/build:v0 localhost:5442/default/build:ff1d967decbfd34ecd1268d72b5a4e8e1067f9ee 19 minutes ago 1 https://build-v0-default.7vlxuv.on-rio.io:9443 100 default/build:v37d26 28 seconds ago 0/1 https://build-v37d26-default.7vlxuv.on-rio.io:9443 0
default/buildに:v37d26というリビジョンができてますね。こちらをビルド中のようです。
しばらく待つと次のようになりました。
rio revision default/build NAME IMAGE CREATED SCALE ENDPOINT WEIGHT DETAIL default/build:v0 localhost:5442/default/build:ff1d967decbfd34ecd1268d72b5a4e8e1067f9ee 21 minutes ago 1 https://build-v0-default.7vlxuv.on-rio.io:9443 0 default/build:v37d26 localhost:5442/default/build-169daa9-b92af:37d2632cb0d649dda800f5375b48b19419836f93 2 minutes ago 1 https://build-v37d26-default.7vlxuv.on-rio.io:9443 100
新しい方のリビジョンのビルドが終わり、そちらに切り替わっているようですね。WEIGHTが新しいリビジョンの方に100%となりました。
では先ほどのエンドポイントあてに再度リクエストしてみます。
# 再度エンドポイント宛てにリクエストしてみる $ curl https://build-default.7vlxuv.on-rio.io:9443 Bonjour Rio!!
お！！！！更新されてますね！
この手軽さはなかなか良いですね！
ということで
時間と体力切れのため今回はここまでです。 とっつきにくいKubernetesのあれこれを上手く覆い隠すフロントエンド、という印象を持ちました。
モニタリング面なども面白そうなので時間を見つけてもう少し触ってみたいところです。
以上です。
k3os on さくらのクラウド
k3osを試してみましたのでメモ残しておきます。
Update: 2019/5/29
さくらのクラウド側でk3OSのISOイメージが提供されるようになりました。
この記事でのISOイメージのダウンロード/アップロードの部分は不要となりました。
===Updateここまで
k3osって?
kubernetesに特化した軽量OSで、軽量kubernetesディストリビュージョンである「k3s」を組み込んだOSとなっています。
Public Keyでも取り上げられましたね。 www.publickey1.jp
前見たときはリリースページにARM向けのISOファイルしかなかったのですが、今日改めて確認したらAMD64向けもちゃんと提供されるようになってたので試してみました。
試してみる
インストール
流れとしては以下の通りです。
ISOファイルのダウンロード〜さくらのクラウドへアップロード
curlコマンドでダウンロード、usacloudコマンド(さくらのクラウド向けCLI)でISOファイルをアップロードします。
# ISOファイルのダウンロード $ curl -LO https://github.com/rancher/k3os/releases/download/v0.2.0/k3os-amd64.iso # アップロード $ usacloud iso-image create --iso-file k3os-amd64.iso --name k3os
サーバ作成〜ISOイメージの挿入〜起動
以下のコマンドでサーバ作成〜ISOイメージを挿入〜起動まで行います。
$ usacloud server build --name k3os \ --core 2 \ --memory 4 \ --disk-size 40 \ --iso-image-id `usacloud iso-image read -q k3os`
VNCで接続
サーバが起動したらコンパネからコンソールを開くかVNC接続して操作できるようにします。
今回は以下のコマンドでVNC接続を行います。(windowsの方は拡張子.vncが適切に関連付けされていれば動くはずです)
$ usacloud server vnc --wait-for-boot k3os
うまくいけばこんな感じの画面が表示されるはずです。牛ですね！
ユーザー名rancherでパスワードなしでログインできるはずです。
ディスクへのインストール
ディスクへのインストールは表示されている通りsudo os-configコマンドを実行すればOKです。
いくつか聞かれますが適当に進めていきます。
途中でSSH用の公開鍵をGitHubから取ってくるか聞いてくれます。この機能便利ですよね。
あとはインストールが進みます。インストールが終わると再起動されるはずです。
SSHで接続してみる
ディスクへのインストール&再起動まで終わったらSSHで接続してみます。
$ ssh rancher@<サーバのIPアドレス>
動作確認
とりあえずkubectlしてみました。
OKっぽいですね。
次にpodを起動してみます。
kubectl run nginx --image=nginx
、、、あれ？いつまでたっても上がってこない? ということでログなどを確認すると、どうも自身のホスト名が名前解決できないってエラーが出てるようでした。
Waiting for hostname sv-NNNNNNNNNNNN to be resolvable: lookup sv-NNNNNNNNNNNN on 133.242.0.3:53: no such host
このIssueですかね。 cannot run k3s server · Issue #60 · rancher/k3s · GitHub
ひとまず/etc/hostsを編集したら動きました。
時間なくなっちゃったので細かな検証はまた今度。
終わりに
k3sの環境構築が楽に行えるのが確認できました。 細かいところはまだ確認できてませんが追々試していきます。
2019/5/20 追記
Packerでk3osのアーカイブ(AWSでのAMIみたいなやつ)作るサンプルを作成しておきました。
毎回ISOイメージからインストールするのが面倒という場合などにどうぞ。
===追記ここまで
以上です。
TerraformとUsacloud(CLI)がコア専有プランに対応しました
さくらのクラウドに「コア専有プラン」が追加されましたね！！
これまでにすでに提供されていた「専有ホスト」が物理的なホストを専有するのに対し、 こちらはホストは共用ながらコア単位で専有できるとのことです。
コアを占有しつつホストは共有するため専有ホストより手軽な価格になっており手を出しやすいですね。
ということでTerraformとUsacloud(CLI)をこのコア専有プランに対応させてみました。
Terraformでのコア専有プラン対応
さくらのクラウド向けプロバイダー terraform-provider-sakuracloudのv1.12.0で対応しました。
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でコア専有プランに対応しました。
いくつかのコマンドで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というアプリです。
このアプリ、一言で言うと東南アジアのUberですね。
実際GrabはUberの東南アジア事業を買収してたりします。
Grabの使用感
まあUberと似たような使い勝手です。
何度か体験したのですが、セブでは現金だと結構お釣りがなくて購入を断られたりお店の方が両替してくるまで結構待たされます。
もちろんタクシーも同じ状況ですので、クレジットカードで決済できるGrabは非常に便利です。
使い方については解説サイトがいくつもありますので詳細は省きますが、こんな感じで使います。
ドライバーとの待ち合わせがうまくいかないことが結構ありますのでメッセージ機能は重宝します。
ドライバーのマッチング後の画面:
ドライバーの情報表示:
ドライバーとのメッセージのやりとり
本題: ぼったくりにあった
という感じでGrabを便利に使っているのですが今日とうとうぼったくりにあってしまいました。
Grabはドライバー側のアプリに到着(drop off)機能がついており、目的地につくとドライバーさんが到着ボタンを押し、そこまでのメーターの金額を入力するようになっています。
(Grab Taxiの場合。Carの場合は最初に金額が決まるっぽい)
そして無事に決済されるとメール+プッシュ通知がくるようになっています。
気づいた時には運転手は去っていた
今日は買い物のためにタクシーを使ったのですが、タクシーから降りてショッピングモールに入ろうとしている最中に決済通知が届きました。
今日行ったショッピングモールでは入場時にボディーチェック(カバンの中身もチェックされる)が行われており、そちらに気を取られてすぐに通知を確認しなかったのが今回の反省点です。。。
その後ショッピングモールに入り決済通知を確認すると、、、「あれ？なんか高いぞ」と。
通常Grab Taxiを使うとメーター+30ペソ(手数料)が取られます。
降りる時にメーターをみたら90ペソくらいだったから120ペソくらいの決済のはずが、、、170ペソほど来てました。
慌てて降車したところに戻るもドライバーの姿はすでになく、、、やられました。
対応: Grabアプリ内から問い合わせ(苦情)
Grabは降車してしまうとドライバーと直接連絡を取ることができないようでした(見つけられなかっただけかも?)。
しょうがないのでヘルプを眺めているとそれっぽいのがありました。
この中のI paid more than quotedってやつがまさに今回のケースですね。
これをタップすると説明書き+メール送信ができる画面に遷移します。
とりあえずここから「最後にメーターみたときは90だったのに170も請求が来ました。おかしいですよね？」的なメールを送りました。
解決: サポートセンターから数時間後に回答が来た
数時間後、サポートセンターから連絡があり、結果としては差額分は返金されることとなりました。
回答としては、
- ドライバーにはサポートセンターから確認中
- 正しい金額はまだ判明していないがサポートセンターにて詳しく調査する
- 調査の結果、もしドライバーに責があると判明した場合はドライバーに対し何らかの処罰を行う(the driver will be sanctioned)
- とりあえず差額についてはGrabPayで返金する
というような感じでした。
そしてすぐにGrabPayのtop-up(入金)の通知が来て無事返金されました。素早い。
反省点
ということでGrabではドライバーが金額を入力するため、ぼったくりにあったり、悪意はなくとも金額の入力間違いが発生する可能性があります。
なので降車の際は金額を声に出して確認(ドライバーさんにメーターの金額を聞くのが早い)、またはドライバー側アプリへの入力を見届けてから降りるようにした方が無難そうです。
あとは通知は毎回きちんと確認しましょうというところですかね。
終わりに
ということで異国の地でぼったくりに会い悲しい思いをしましたがサポートセンターの素早い対応により無事解決しました。
とはいえメール送信したりという手間がかかりますのでやはり自衛するのが大事ですね。。。
以上です。
おまけ
せっかくセブに来ているので人気のアトラクションだというCrown Agency Hotel & ResortsのSky Adventureを体験してきました。 ビルの38階の外側に沿って歩道が設けられておりそこを歩くというやつでした。
怖かったですねー。。。しばらくはもう高いところに登りたくないです。。。
sakuracloud_exporterでエンハンスドロードバランサをサポートしました
sakuracloud_export v0.2.1で対応しました。
Grafanaだとこんな感じで使えるはずです。
エンハンスドロードバランサのメトリクス
以下のようなものがサポートされています。 詳細は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でエンハンスドロードバランサをサポートしました
sakuracloud_export v0.2.1で対応しました。
Grafanaだとこんな感じで使えるはずです。
エンハンスドロードバランサのメトリクス
以下のようなものがサポートされています。 詳細は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に特化した新しいロードバランサアプライアンスが追加されました。
また、タイミングが良いことにTerraformのAMCEプロバイダーでさくらのクラウドDNSを利用できるようになるバージョン v1.1.0も先日リリースされました。
今回はTerraform+AMCEプロバイダーを利用してさくらのクラウドのエンハンスドロードバランサでHTTPS環境を作ってみます。
エンハンスドロードバランサとは
エンハンスドロードバランサについてはこちらに詳細がまとめられています。
振り分け先にはさくらインターネットの提供するグローバル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以降向けブランチでのみサポートする予定だからです。
必要なもの/準備
- さくらのクラウド APIキー
- さくらのクラウドDNS (ゾーン登録しておく)
- 実サーバ(httpでアクセスできるもの)
- Terraform v0.12-beta
- Terraform v0.12対応版 ACMEプロバイダー
- Terraform v0.12対応版 TLSプロバイダー
- Terraform 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でアクセスできるようになるはずです。
終わりに
パスベースのルーティング待ってます！！！
以上です。
