さくらのクラウド+Container LinuxでPXEブート+Ignitionを使う
さくらのクラウド + Container Linuxでのプロビジョニング
さくらのクラウドでContainer Linuxを使う場合、プロビジョニングをどうするかは悩みどころです。
さくらのクラウドではプロビジョニングのための仕組みとしてスタートアップスクリプトは用意されているものの、Container Linuxでは利用できないという制限があります。
参考 スタートアップスクリプトは以下のOSに対応しています。
- CentOS
- Debian
- Ubuntu
- FreeBSD
- RancherOS
- VyOS
スタートアップスクリプト以外でプロビジョニングするには?
スタートアップスクリプト以外でプロビジョニングする方法としては以下のようなものが挙げられます。
- Ansibleなどのプロビジョニングツールを利用してサーバ起動後にSSHで操作
- ISOイメージ機能を利用してConfigDrive経由でcloud-configを流し込む
- PXEブート環境を構築しIgnitionを使う
2番目のISOイメージでConfigDriveを使う方法についてはこちらの記事が詳しいです。
3番目の方法は、前回紹介したcybozuさんのsabakanやCoreOS社の提供するMatchboxを使ってDHCPサーバやIgnitionファイルの管理/配布などを行う環境を作るというもので、導入/運用の敷居が少し高めとなっています。
参考: sabakanの紹介記事
もうちょっと楽にPXEブート+Ignitionの管理ができないか、、、
ということで今回の本題の「terraform-sakuracloud-matchbox」というモジュールを公開しました。
Terraform + Matchbox + さくらのクラウド = terraform-sakuracloud-matchbox
terraform-sakuracloud-matchbox
はMatchboxを手軽に導入するためのTerraformモジュールです。
以下のようなtfファイルの記述でMatchboxをセットアップすることが可能です。
module "matchbox" { source = "sacloud/matchbox/sakuracloud" #Matchboxを稼働させるサーバのパスワード server_password = "put-your-server-password" #DHCPサーバなどのPXEブート関連機能を動かすためのネットワークに接続するスイッチのID switch_id = "1234556789012" }
このモジュールは以下のような動きをします。
- サーバを1台作成
- サーバをインターネット(共有セグメント)と指定されたスイッチに接続
- サーバ上でMatchboxとdnsmasqを起動
- スイッチ側NIC上でMatchboxのHTTP APIエンドポイントを提供
- DHCPクライアントに対するデフォルトゲートウェイとして構成(ip_forward)
- MatchboxのgRPC API用にCA証明書、サーバ証明書/秘密鍵、クライアント証明書/秘密鍵を生成(オプションで指定も可能)
- インターネット側NIC上でMatchboxのgRPCエンドポイントを提供
- CoreOSの起動/インストール用イメージなどのアセットの提供
このモジュールはMatchboxサーバを提供するのみで、接続するスイッチ(VPC)やPXEブートするサーバなどは別途用意する必要があります。
また、Matchbox自体への設定の投入(IgnitionやMetadataなど)も別途用意する必要があります。
次にこのモジュールを使って実際にPXEブートしてContainerLinuxをブート/ディスクへのインストールまでを行ってみます。
terraform-sakuracloud-matchbox
でContainerLinuxの起動/プロビジョニングまで
実際にどうやって使うのかをみていきます。
準備
以下のものが必要になります。あらかじめ準備しておいてください。
さくらのクラウド/Matchbox向けのTerraformプロバイダーはCommunity ProviderでTerraform本体とは別で配布されており個別にインストールが必要です。
それぞれの最新版をGitHubからダウンロードし、~/.terraform.d/plugins/
配下などに配置しておいてください。
詳細は以下のドキュメントを参照してください。
さくらのクラウドAPIキーは環境変数などに設定しておいてください。
なお、今回は簡便のためモジュールわけなどせずに同じディレクトリ内にMatchboxサーバの定義とPXEブートするサーバ/Ignitionの定義などを格納します。
本来はライフサイクルが異なるため別モジュールに分けるべきと思いますので、実際に利用する際はこの辺りも考慮しておいてください。
Matchbox構築
まずはMatchboxを動かすためのサーバとPXEブートで利用するスイッチを作成します。
以下のようなtfファイルmatchbox.tf
を作成します。
resource sakuracloud_switch "switch" { name = "matchbox-internal" } module "matchbox" { source = "sacloud/matchbox/sakuracloud" server_password = "your-password" switch_id = "${sakuracloud_switch.switch.id}" server_public_key = "${file("~/.ssh/id_rsa.pub")}" server_private_key = "${file("~/.ssh/id_rsa")}" }
パスワードは適当なものに置き換えてください。
また、サーバに接続するためのSSH公開鍵/秘密鍵も合わせて指定しています。
~/.ssh/id_rsa
と~/.ssh/id_rsa.pub
が存在しない場合は適当にssh-keygen
などで作成しておいてください。
作成したらterraform init
してterraform apply
します。
$ terraform init ... Terraform has been successfully initialized! ... $ terraform apply ... Apply complete! Resources: 17 added, 0 changed, 0 destroyed.
これでサーバが作成されMatchboxが動いている状態となりました。
PXEブートするサーバの作成/Ignitionなどの定義
次にPXEブートするサーバやサーバに適用するIgnitionの定義を行います。
サーバの定義
まずはサーバの定義を行います。以下のようなtfファイルservers.tf
を作成してください。
locals { node_count = 1 } resource sakuracloud_server "server" { name = "node-${count.index+1}" core = 2 memory = 2 # Container Linuxは2GB以上のメモリが必要 nic = "${sakuracloud_switch.switch.id}" # 先ほど作成したスイッチに接続 disks = ["${sakuracloud_disk.disk.*.id[count.index]}"] count = "${local.node_count}" } resource sakuracloud_disk "disk" { name = "node-${count.index}" size = 20 count = "${local.node_count}" }
注意点は以下2つです。
本来はディスクの作成時にコピー元アーカイブの指定やサーバへのIPアドレスの指定などが必要なのですが、 今回はOSの入っていないブランクディスク、設定類はIgnitionで行うためこの指定となっています。
次にMatchboxで配布するIgnitionなどの定義を行います。
Matchboxの設定
Matchboxプロバイダーへのパラメータ指定
Ignitionなどの定義はMatchboxが提供するgRPC APIを用いて行います。
これをTerraformから行えるようにしてくれるのがTerraformのMatchboxプロバイダーです。
まずは先ほど作成したMatchboxサーバを利用するようにMatchboxプロバイダーへのパラメータ指定を行います。
以下のようなtfファイルをprovider_matchbox.tf
という名前で作成してください。
provider "matchbox" { endpoint = "${module.matchbox.matchbox_grpc_api_endpoint}" client_cert = "${module.matchbox.client_cert}" client_key = "${module.matchbox.client_key}" ca = "${module.matchbox.ca_cert}" }
接続するための情報は先ほどのterraform-sakuracloud-matchbox
モジュールが提供してくれますので、tfファイル上でモジュールの値を参照するように指定しています。
MatchboxのProfile/Group作成
次にMatchboxのProfileとGroupを作成します。
MatchboxでのProfileとは名前付きの設定テンプレートのことです。
Profileは iPXEやGRUB、Ignition configなどを保持します。
GroupとはMatchboxクライアントから提示されるMACアドレスやシリアル、UUIDなどを用いて クライアントとプロファイルを結びつけるものです。
と言ってもよくわからないですよね。実物を見るのが早いと思います。
まずProfileとして
- PXEブートした時に適用するProfile
- ディスクにOSをインストールした後に適用するProfile
の2種類を作成します。
以下のようなtfファイルをprofile.tf
として作成します。
UPDATE: 2019/2/17 00:25 argsの誤りを修正
// Create a CoreOS-install profile resource "matchbox_profile" "coreos-install" { name = "coreos-install" kernel = "${module.matchbox.matchbox_assets_coreos_kernel_path[0]}" initrd = ["${module.matchbox.matchbox_assets_coreos_initrd_path[0]}"] args = [ "initrd=coreos_production_pxe_image.cpio.gz", "coreos.config.url=${module.matchbox.matchbox_http_api_endpoint}/ignition", "coreos.first_boot=yes", "ipv6.disable=1", "console=tty0", "console=ttyS0", ] container_linux_config = <<EOF --- systemd: units: - name: installer.service enable: true contents: | [Unit] Requires=network-online.target After=network-online.target [Service] Type=simple ExecStart=/opt/installer [Install] WantedBy=multi-user.target storage: files: - path: /opt/installer filesystem: root mode: 0500 contents: inline: | #!/bin/bash -ex curl --retry 10 "{{.ignition_endpoint}}?os=installed" -o ignition.json coreos-install -d /dev/vda -C stable -V current -i ignition.json {{if index . "baseurl"}}-b {{.baseurl}}{{end}} udevadm settle systemctl reboot passwd: users: - name: core ssh_authorized_keys: - {{.ssh_authorized_key}} EOF } // Create a simple profile which just sets an SSH authorized_key resource "matchbox_profile" "simple" { name = "simple" container_linux_config = <<EOF --- passwd: users: - name: core ssh_authorized_keys: - {{.ssh_authorized_key}} EOF }
ちょっと長いですが順番にみていきましょう。
まずPXEブートした時に適用するProfileがmatchbox_profile.coreos-install
です。
ここではiPXEブート時に必要になるvmlinuzとinitrdのダウンロードURL、起動時のカーネルパラメータ、起動時に渡すcontainer_linux_config(Ignition)の内容を指定しています。
container_linux_configではcoreos-install
コマンドを用いたディスクへのOSインストールとユーザーcore
の作成、SSH用の公開鍵の登録を行っています。
次にディスクにOSをインストールした後に適用するProfileがmatchbox_profile.simple
です。
こちらはユーザーcore
の作成とSSH用の公開鍵を登録しているだけです。
ここでcontainer_linux_configの中で{{.xxx}}のようなパラメータ指定をしているのに気づかれた方もいらっしゃるかもしれません。
これは後述するGroupから渡されるパラメータです。Profileとしては設定のテンプレートを用意しておき、Groupから渡されるパラメータを反映することで具体的なcontainer_linux_config(Ignition)の内容となるということですね。
次にGroupです。
以下のようなtfファイルをgroup.tf
として作成します。
// Default matcher group for machines resource "matchbox_group" "default" { name = "default" profile = "${matchbox_profile.coreos-install.name}" # セレクタ未指定のため、パラメータ指定のない全てのマシンにマッチする metadata { ignition_endpoint = "${module.matchbox.matchbox_http_api_endpoint}/ignition" ssh_authorized_key = "${file("~/.ssh/id_rsa.pub")}" baseurl = "${module.matchbox.matchbox_http_api_endpoint}/assets/coreos" } } // Match machines which have CoreOS Container Linux installed resource "matchbox_group" "node1" { name = "node1" profile = "${matchbox_profile.simple.name}" selector { os = "installed" } metadata { ssh_authorized_key = "${file("~/.ssh/id_rsa.pub")}" } }
上の方がPXEブート時に利用されるGroup、下の方がディスクにOSインストール後に利用されるGroupです。 先ほどのProfile定義では以下のような記述がなされていました。
- PXEブート時のカーネルパラメータ:
coreos.config.url=${module.matchbox.matchbox_http_api_endpoint}/ignition
coreos-install
コマンドに渡すIgnition.jsonの取得コマンド:curl --retry 10 "{{.ignition_endpoint}}?os=installed" -o ignition.json
どちらもMatchboxサーバの/ignition
に対してHTTPでリクエストしてignition.jsonを取得しています。
後者はパラメータとしてos=installed
が指定されていますので、これを元にどののGroupなのか? -> どのProfileなのか? -> どのignition.jsonを返すか、をMatchboxが判定してくれます。
ここまできたらあとはterraform apply
を実行するだけです。
applyするとブランクディスクからサーバが作成され、PXEブート〜ディスクへのOSインストールが行われるはずです。
Profileの定義を変えることで様々なプロビジョニングが行えますね!
その他の機能: OS起動/インストールイメージのプリフェッチ
デフォルトではContainerLinuxのPXEブート/ディスクへのインストール用イメージをMatchbox上にプリフェッチするようになっています。
以下のパラメータを指定することでプリフェッチを無効化したり、異なるバージョンのイメージをプリフェッチしておくことが可能です。
# 対象のContainerLinuxのバージョン("1967.6.0"みたいに指定する) prefetch_coreos_assets_keys = ["current"] # 対象のChannel(https://coreos.com/releases/を参照) prefetch_coreos_assets_channel = "stable" # allowed values are: current/beta/alpha/custom # カスタムイメージを使う場合のダウンロードURL prefetch_coreos_assets_custom_url = ""
デフォルトはstable
チャンネルのcurrent
バージョンをプリフェッチします。
alpha
やbeta
も利用可能です。
prefetch_coreos_assets_keys
に空を指定することでプリフェッチを無効化可能です。
なお、プリフェッチを無効化した場合はMatchboxのProfile/Groupで各種ダウンロード先を変え忘れないように注意してください。
その他の機能: ゲートウェイ機能のON/OFF
デフォルトではMatchboxサーバはIPフォワードが有効化され、DHCPクライアントからの外部へのリクエストをSNATするようになっています。
この挙動は以下のパラメータで制御可能です。
# フォワードの有効/無効 server_enable_forward = true
例えば既存のVPC内に配置したり、デフォルトゲートウェイとしてVPCルータを利用すると言った場合にはこの設定を変更する必要があります。
また、この設定を変えた場合、DHCPで配布するデフォルトゲートウェイの設定も変える必要があります。
以下のあたりのパラメータを合わせて変更してください。
# Matchboxサーバ自身のプライベート側IPアドレス matchbox_ipaddress = "192.168.0.1" # Matchboxサーバのネットワークマスク長 matchbox_nw_mask_len = "24" # MatchboxのHTTP APIが利用するポート番号 matchbox_http_api_port = 8080 # MatchboxのgRPC APIが利用するポート番号 matchbox_grpc_api_port = 8081 # DHCPで配布するデフォルトゲートウェイのアドレス matchbox_gateway = "192.168.0.1" # DHCPで配布するアドレス範囲 dhcp_start = "192.168.0.101" dhcp_end = "192.168.0.200"
終わりに
このモジュールを利用することでTerraform + MatchboxでPXEブート + Ignitionの管理が行えるようになります。
Terraformで完結していますので既存のTerraformを用いたワークフローにも適合しやすいと思います。
ぜひ使ってみてください。
以上です。
ベアメタル環境でのサーバ構築/管理ツール 「sabakan」を試した
ベアメタル環境でのサーバ構築のためのツールや管理情報、APIなどを提供するsabakanを試してみましたのでメモを残しておきます。
sabakan
とは
サイボウズさんのインフラ刷新プロジェクトNeco
で用いられている機材管理ツールとのことです。
サーバの構成情報などを保持しておくインベントリ機能とそれらを用いてネットワークブート/プロビジョニングを行う機能を提供してくれます。
データストアとしてはetcdが用いられており、sabakan自体を複数起動して冗長構成にすることもできるようです。
(画像引用元: https://github.com/cybozu-go/sabakan)
使い方としては、サーバのシリアル情報や持たせたい役割を構成情報として投入し、スイッチに繋いだ上でサーバの電源を入れるとアプリケーションがデプロイできる状態になる、という感じなようです。
次にもう少し詳しく機能をみてみます。
sabakanの持つ機能
sabakanのREADMEによると以下のような機能を持っているとのことです。
sabakanの機能(一部抜粋):
- サーバの構成情報のインベントリ / IPアドレスの割り当て管理
- DHCP(UEFI/iPXE HTTPでのネットワークブート用)サービス
- HTTPサービス(OSイメージや任意のアセットの提供)
- サーバのライフサイクル管理用APIの提供
(詳しくはREADMEのFeaturesを参照してください)
サーバのOSにはContainer Linuxを想定しており、Ignitionでプロビジョニングを行うためのjsonを組み立てたりHTTPで配信する機能も持っています。
また、サーバの状態(まだ初期化してないよ、とか動いてるよ、とか退役する/したとか)も保持してます。
参考: sabakan/lifecycle.md at master · cybozu-go/sabakan · GitHub
注意点として、サーバの状態は保持するだけでその変更はAPIなどを用いて外部から行う必要ということがあります。
ヘルスチェックなどを通じて状態を操作するコントローラー的なものは必要に応じて別途用意しないといけないということですね。
類似プロダクト
類似のプロダクトとしてはCoreOSのMatchboxがあります。
Kubernetes環境の構築/管理ツールであるTectonicで足回りの構築に使われているものです。
Matchboxはsabakanと同じくiPXEなどでのネットワークブート、Ignitionによるプロビジョニングに対応しています。
違いとしてはsabakanの方はより物理的なインフラを意識している(ラックの指定とかBMC周りとか)点とサーバの状態管理を行なっている点があります。
Matchboxの方はMetadata APIやTerraformプロバイダーの提供を行なうなど、クラウドを含めより汎用的なインフラ環境上で動かせることを目指しているように感じてます。
どちらも単体で動かすようなものではなく、ビルディングブロックとして他のシステムと協調して動かすものとなっていますので やりたいことに応じて使い分ければ良さそうですね。
sabakanでサーバ構築してみる
概要を押さえたところで早速sabakanを試してみます。
動かし方はGitHub上にGetting startedがありますのでこちらを参考にします。
また、個人的な好みにより今回はさくらのクラウドで動かします。
さくらのクラウドはOSなしでサーバ作成が出来ますしPXEブートも可能なのでsabakanが使えるはずです。
インフラの準備
まずsabakanを動かすためのサーバ/スイッチなどをさくらのクラウド上で作成します。
今回は以下のような構成にします。
構成:
- sabakan用サーバ
- VPCでは
192.168.150.0/24
を用いる
今回はsabakanをDocker上で動かすつもりですので、サーバのOSはContainer LinuxかRancherOSを入れとくのが楽だと思います。
サーバは作成後にスイッチへの接続、スイッチと接続したNIC(eth1)ヘのIPアドレス設定を行なっておきます(今回は192.168.150.1/24
にします)。
sabakanの実行
インフラの準備ができたら早速sabakanを実行してみましょう。
以下はsabakan用サーバにssh接続して作業します。
sabakan用のconfigの作成
まずsabakan用のconfigファイルを用意します。
以下の内容をsabakan.yml
という名前で作成します。
etcd: endpoints: - http://localhost:2379 dhcp-bind: 192.168.150.1:67 advertise-url: http://192.168.150.1:10080
sabakanはconfigファイルだけでなくコマンドラインオプションで各種設定を指定可能ですが、configファイルとコマンドラインオプションを併用した場合はconfigファイルが優先され コマンドラインオプションでの指定が無視されますのでご注意ください(最初気付かずに数分悩みました)。
etcdとsabakanを起動
次にetcdとsabakanをDockerで起動します。
本来は各種オプションをしっかり指定しておくべきだとは思いますが今回はお試しということで色々手を抜いてます。
# etcd $ docker run -d --rm --name etcd --network=host --uts=host quay.io/cybozu/etcd:3.3 # sabakan $ docker run -d --name sabakan --network=host -v $PWD:/work -w /work quay.io/cybozu/sabakan:1.1 -config-file sabakan.yml
ネットブート用の設定類を投入
sabakanが起動したら次にネットブートを行うための各種設定を投入していきます。
sabakanのCLIクライアントsabactl
の準備
sabakanの操作を行うためのCLIクライアントsabactl
を準備しておきます。
今回はdocker exec
でsabakanコンテナ上でsabactlを実行するように以下のエイリアスを利用します。
$ alias sabactl='docker exec -it sabakan sabactl'
IPAM
まずIPアドレスの割り当て定義を投入します。
jsonファイルを作成してsabactl
というsabakanのCLIクライアントを用いて投入します。
以下のファイルをipam.json
という名前で作成してください。
{ "max-nodes-in-rack": 8, "node-ipv4-pool": "192.168.150.0/24", "node-ipv4-range-size": 4, "node-ipv4-range-mask": 24, "node-index-offset": 1, "node-ip-per-node": 1, "bmc-ipv4-pool": "192.2.0.0/24", "bmc-ipv4-offset": "0.0.0.1", "bmc-ipv4-range-size": 1, "bmc-ipv4-range-mask": 24, "bmc-ipv4-gateway-offset": 1 }
作成したら以下のコマンドで投入します。
$ sabactl ipam set -f ipam.json
投入できたかは以下のコマンドで確認できます。
$ sabactl ipam get
ipam.jsonで定義している項目については以下のドキュメントを参照してください。
sabakan/ipam.md at master · cybozu-go/sabakan · GitHub
なお、こちらもとりあえず動けば良いため値は適当にしてます。
DHCPサーバの設定
次にDHCPサーバの設定を投入します。 IPAMと同じくファイルを作ってsabactlで投入します。
以下のファイルをdhcp.json
として作成します。
{ "gateway-offset": 1, }
投入は以下のコマンドです。
$ sabactl dhcp set -f dhcp.json
設定項目についてのドキュメントはこちらです。
sabakan/dhcp.md at master · cybozu-go/sabakan · GitHub
PXEブート用のイメージ
次にPXEブートを行うためのイメージをCoreOSのWebサイトから取得してsabakanに投入します。
イメージはcurlコマンドで以下のように取得します。
$ curl -o kernel -Lf http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe.vmlinuz $ curl -o initrd.gz -Lf http://stable.release.core-os.net/amd64-usr/current/coreos_production_pxe_image.cpio.gz
取得したらsabactlで投入します。
$ sabactl images upload current kernel initrd.gz
なお、ここで指定しているcurrent
は各イメージにつけるIDで任意の名前をつけれるようになっています。
sabakanは複数のイメージを登録しておくことが出来、PXEブート時に自動的に最新のイメージを利用するという仕組みになっています。
サーバの定義投入〜サーバ起動
ここまででsabakanの準備が整いました。後はサーバの定義を投入した上でサーバの電源を入れるだけです。
ということで早速定義の投入を行なってみます。
サーバのシリアル(ID)を取得
sabakanにサーバの定義情報を登録する際にサーバのシリアルが必要になります。
物理サーバであれば購入時の保証書などに記載されていると思いますのでそれを利用します。
今回はさくらのクラウドで動かしますので、単純にサーバのIDがあればOKです。
こちらの記事にあるように、さくらのクラウドではシリアル番号=IDとなります。
なのでさくらのクラウド上でサーバを作成してIDを控えましょう。
サーバの作成(さくらのクラウド)
さくらのクラウドでサーバ作成を行います。
ここでは以下の条件でサーバ作成してください。
- サーバに接続するディスクはブランクディスクとする
- サーバのNICはスイッチに接続する
作成後すぐに起動
のチェックは外しておく
こんな構成になるはずです。
作成したらサーバのIDを控えましょう。
サーバの定義ファイルを作成
サーバのID(シリアル)が用意できましたので、sabakanに投入するサーバの定義ファイルを作成していきます。
まず以下のファイルをmachines.json
として作成します。
[ { "serial": "先ほど控えたサーバのID", "rack": 0, "role": "test", "bmc": { "type": "IPMI-2.0", "ipv4": "" } } ]
ここでは役割(role
)をtest
としました。後ほどこのロール名を用いてIgnition設定を投入していきます。
また、今回はBMCは利用しませんので空にしています。
投入は以下のコマンドです。
$ sabactl machines create -f machines.json
サーバのプロビジョニング用にIgnition設定
次にこのサーバをプロビジョニングするためのIgnitionの設定を投入します。
プロビジョニングでは本来はディスクへのインストールなどを行うべきところですが、
今回はユーザー名core
、パスワードがpassword
のユーザーを追加するだけとします。
まず以下のファイルをpasswd.yml
という名前で作成します。
users: - name: core passwordHash: "$1$2OsV8nCL$AaaGvkomzT5c/D6zApaMG0" groups: - name: sacloud gid: 10000
次に以下のファイルをignision.yml
という名前で作成します。
passwd: passwd.yml
次にsabactlで投入します。
$ sabactl ignitions set -f ignision.yml test サーバのID
これで準備が整いました。
サーバの電源投入
いよいよプロビジョニングしてみます。サーバの電源をONにしコンソールを眺めましょう。
さくらのクラウド CLI usacloudをご利用の方は以下のコマンドでVNCコンソールを開くことが可能です。
$ usacloud server vnc サーバのID
うまく設定出来ていればiPXEブートされている様子が見えるはずです。
起動したらユーザー名:core
、パスワード:password
でログインしてみましょう。
ログインできれば成功です。
今回はプロビジョニングの設定が適当でしたが、きちんと設定すればすぐにアプリケーションをデプロイできる状態にまで持っていけますね!!
おまけ: sabactlでサーバの状態を変えてみる
前述の通りsabakan自体はサーバの状態を変えることはなく、外部から何らかの形で変えてあげる必要があります。
本来はサーバのプロビジョニングの完了を検知して適切にハンドリングするなどが必要ですが、ここではsabactlで手動で状態を変えてみます。
まず、初期状態ではサーバの状態はuninitialized
になっています。
$ sabactl machines get-state サーバのID uninitialized
状態を変えるにはsabactl machines set-state
を使うようです。
# healthyにする sabactl machines set-state サーバのID healthy # retiringにする sabactl machines set-state サーバのID retiring # retiredにする!? sabactl machines set-state サーバのID retired Error: Bad Request: invalid request: invalid state: retired
retired
にするにはsabactl crypts delete
しなきゃいけないようです。
参考: sabakan/lifecycle.md at master · cybozu-go/sabakan · GitHub
$ sabactl crypts delete --force サーバのID # ちゃんとretiredになってるはず $ sabactl machines get-state サーバのID retired
終わりに
ということで今回はsabakanを試してみました。 周りのコントローラーを工夫すれば色々出来そうですね。
以上です。
Prometheus さくらのクラウド向け Exporter 「sakuracloud_exporter」
さくらのクラウド上のリソースの監視を行うためのPrometheusのExporter「sakuracloud_exporter」をリリースしました。
この記事ではsakuracloud_exporter
の機能や実践的な利用例を紹介します。
もしPrometheusになじみの薄い方は以下の連載記事などをあらかじめ読んでおくことをお勧めします。
sakuracloud_exporterの概要
sakuracloud_exporter
はPrometheusのExporterです。さくらのクラウドAPIを利用して各種メトリクスを収集します。
さくらのクラウドでのメトリクス関連API
さくらのクラウドではCPU-TIMEやディスクのread/write、NICのreceive/sendなどをAPIを通じて取得できるようになっています。
例えばCPU-TIMEであれば、GET /server/:serverid/monitor
というAPIで以下のようなJSONが取得可能です。
{ "Data": { "2019-02-03T14:50:00+09:00": { "CPU-TIME": 0.046666666667 }, "2019-02-03T14:55:00+09:00": { "CPU-TIME": 0.05 }, "2019-02-03T15:00:00+09:00": { "CPU-TIME": 0.053333333333 }, "2019-02-03T15:05:00+09:00": { "CPU-TIME": 0.05 }, "2019-02-03T15:10:00+09:00": { "CPU-TIME": 0.05 } }, "is_ok": true }
さくらのクラウドのコントロールパネルではこれを利用した「アクティビティ」という機能が提供されていますね。
sakuracloud_exporter
ではこれらのAPIを用いてPrometheus向けに各種メトリクスの収集/公開を行うようになっています。
sakuracloud_exporter
でサポートしているメトリクス
以下のようなリソース関連のメトリクスをサポートしています。
(各メトリクスの詳細はGitHub上のREADMEに記載されています。)
さくらのクラウドのメトリクス関連APIに加え、自動バックアップの状況やクーポン残高なども取得できるようになっています。
どんなことが出来るの?
Grafanaなどのツールを組み合わせての可視化や、AlertManagerを用いてのアラート機能など、 Prometheusを活用した様々な機能が利用できるようになります。 いくつかこのExporterで出来るようになることの例を挙げてみます。
グラフ作成
まずは王道的にGrafanaなどのツールを用いて各種メトリクスをグラフ化することが可能になります。
さくらのクラウドのコントロールパネルのアクティビティ機能ではサーバごとという風にある程度決まった単位での表示しか出来ませんが、
このExporterを用いることで柔軟に対応することが可能です。
例えば複数サーバを並べて比較したり(この辺はnode_exporterで取得することが多いと思いますが)、サーバと接続されているロードバランサやルータのトラフィックも合わせて確認するといった使い方も出来ますね。
複数サーバのCPU-TIMEを並べてみた例:
アラート機能
さくらのクラウドではシンプル監視で簡単なアラート機能を利用できますが、 例えばVPC内のサーバのように直接インターネット経由でアクセスできないようなサーバは監視できないといった制限があります。
そういった場合にこのExporterを利用することでさくらのクラウドAPIで取得した情報を元にアラートをあげるということが可能です。
例えば、このExporterではサーバの起動状況をsakuracloud_server_up
というメトリック名で公開しています。
これを利用してサーバがシャットダウンした際にアラートをあげることができます。
AlterManagerでサーバがシャットダウンされた時にアラートをあげる例:
- alert: server_down expr: sakuracloud_server_up == 0 # 起動していたら1、以外の場合は0となるため、0の時を条件にする for: 1m labels: severity: page annotations: summary: "Server {{ $labels.name }}(ID:{{ $labels.id }}) down" description: "{{ $labels.name }} of job {{ $labels.job }} has been down for more than 1 minutes."
工夫次第で色々便利に使えると思います。
sakuracloud_exporter
でサポートしているメトリクスの詳細
ここからはsakuracloud_exporter
がサポートしているメトリクスについて各リソースごとに詳しくみてみます。
全体で共通的な項目
各リソースには*_info
という、末尾に_info
がつく名前のメトリクスが用意されています。
これは情報参照用のメトリクスで、常に1を返すようになっています。
PrometheusではLabelの値が変更されると違う系列とみなされるため、頻繁に変更されるような項目は各項目のLabelには入れずinfoにまとめて入れると言う形にしています。 各メトリクスの参照時に対象リソースの詳しい情報が必要になった場合に*infoを利用するのが良いでしょう。
例えばサーバのCPU-TIME用のメトリクスsakuracloud_server_cpu_time
は以下のような値を持っています。
sakuracloud_server_cpu_time{id="000000000001",instance="localhost:9542",job="sakuracloud",name="example",zone="tk1a"} 0.5
ラベルはサーバを識別するための最低限の情報しかありません。 ここにサーバのCPU数をラベルとして付与しておきたい場合、以下のようなクエリを用いて*_infoから情報を引っ張ってくる、というようなことができます。
sakuracloud_server_cpu_time * on (zone,id) group_left(cpus) sakuracloud_server_info
このクエリの結果は以下のようになります。
{cpus="2",id="000000000001",instance="localhost:9542",job="sakuracloud",name="example",zone="tk1a"} 0.5
次にリソースごとに利用可能なメトリクスを見てみます。
自動バックアップ関連
Metric | Description | Labels |
---|---|---|
sakuracloud_auto_backup_info |
自動バックアップ情報の参照用 | id , name , disk_id , max_backup_num , weekdays , tags , descriptions |
sakuracloud_auto_backup_count |
この自動バックアップで作成されたアーカイブの現在の数 | id , name , disk_id |
sakuracloud_auto_backup_last_time |
最終バックアップ作成日時(UnixTime) | id , name , disk_id |
sakuracloud_auto_backup_archive_info |
この自動バックアップで作成されたアーカイブ情報 | id , name , disk_id , archive_id , archive_name , archive_tags , archive_description |
例えばこんな感じでバックアップがちゃんと取れているか確認するのに使えると思います。
クーポン関連
Metric | Description | Labels |
---|---|---|
sakuracloud_coupon_discount |
クーポン残高 | id , member_id , contract_id |
sakuracloud_coupon_remaining_days |
有効な残日数 | id , member_id , contract_id |
sakuracloud_coupon_exp_date |
クーポン期限切れ日時(UnixTime) | id , member_id , contract_id |
sakuracloud_coupon_usable |
クーポンが利用可能(有効期限内、かつ残高が1円以上)の場合に1 | id , member_id , contract_id |
後ほど実践的な例としてこのクーポン情報を利用したアラートの例を扱います。
データベース関連
Metric | Description | Labels |
---|---|---|
sakuracloud_database_info |
データベース情報参照用 | id , name , zone , plan , host , database_type , database_revision , database_version , web_ui , replication_enabled , replication_role , tags , description |
sakuracloud_database_up |
起動している場合は1 | id , name , zone |
sakuracloud_database_cpu_time |
CPU-TIME (単位:ms) | id , name , zone |
sakuracloud_database_memory_used |
メモリ使用量(単位:GB) | id , name , zone |
sakuracloud_database_memory_total |
総メモリサイズ(単位:GB) | id , name , zone |
sakuracloud_database_nic_info |
NIC情報参照用 | id , name , zone , upstream_type , upstream_id , upstream_name , ipaddress , nw_mask_len , gateway |
sakuracloud_database_nic_receive |
NIC受信(単位: Kbps) | id , name , zone |
sakuracloud_database_nic_send |
NIC送信(単位: Kbps) | id , name , zone |
sakuracloud_database_disk_system_used |
システムディスク使用量(unit:GB) | id , name , zone |
sakuracloud_database_disk_system_total |
総システムディスクサイズ(unit:GB) | id , name , zone |
sakuracloud_database_disk_backup_used |
バックアップディスク使用量(unit:GB) | id , name , zone |
sakuracloud_database_disk_backup_total |
総バックアップディスクサイズ(unit:GB) | id , name , zone |
sakuracloud_database_binlog_used |
binlogのディスク使用量(unit:GB) | id , name , zone |
sakuracloud_database_disk_read |
ディスク Read (unit: KBps) | id , name , zone |
sakuracloud_database_disk_write |
ディスク Write(unit: KBps) | id , name , zone |
sakuracloud_database_replication_delay |
レプリケーション遅延時間(unit:second) | id , name , zone |
スイッチ+ルータ
Metric | Description | Labels |
---|---|---|
sakuracloud_internet_info |
スイッチ+ルータ情報参照用 | id , name , zone , switch_id , bandwidth , tags , description |
sakuracloud_internet_receive |
受信(unit: Kbps) | id , name , zone , switch_id |
sakuracloud_internet_send |
送信(unit: Kbps) | id , name , zone , switch_id |
ロードバランサ
Metric | Description | Labels |
---|---|---|
sakuracloud_loadbalancer_info |
ロードバランサ情報参照用 | id , name , zone , plan , ha , vrid , ipaddress1 , ipaddress2 , gateway , nw_mask_len , tags , description |
sakuracloud_loadbalancer_up |
起動している場合は1 | id , name , zone |
sakuracloud_loadbalancer_receive |
NIC 受信(unit: Kbps) | id , name , zone |
sakuracloud_loadbalancer_send |
NIC 送信(unit: Kbps) | id , name , zone |
sakuracloud_loadbalancer_vip_info |
VIP情報参照用 | id , name , zone , vip_index , vip , port , interval , sorry_server , description |
sakuracloud_loadbalancer_vip_cps |
VIPごとの秒あたりのコネクション数 | id , name , zone , vip_index , vip |
sakuracloud_loadbalancer_server_info |
実サーバ情報参照用 | id , name , zone , vip_index , vip , server_index , ipaddress ,monitor , path , response_code |
sakuracloud_loadbalancer_server_up |
実サーバが稼働している場合は1 | id , name , zone , vip_index , vip , server_index , ipaddress |
sakuracloud_loadbalancer_server_connection |
実サーバごとのコネクション数 | id , name , zone , vip_index , vip , server_index , ipaddress |
sakuracloud_loadbalancer_server_cps |
実サーバごとの秒あたりのコネクション数 | id , name , zone , vip_index , vip , server_index , ipaddress |
モバイルゲートウェイ
Metric | Description | Labels |
---|---|---|
sakuracloud_mobile_gateway_info |
モバイルゲートウェイ 情報参照用 | id , name , zone , internet_connection , inter_device_communication , tags , description |
sakuracloud_mobile_gateway_up |
起動している場合は1 | id , name , zone |
sakuracloud_mobile_gateway_nic_receive |
NIC 受信(unit: Kbps) | id , name , zone , nic_index , ipaddress , nw_mask_len |
sakuracloud_mobile_gateway_nic_send |
NIC 送信(unit: Kbps) | id , name , zone , nic_index , ipaddress , nw_mask_len |
sakuracloud_mobile_gateway_traffic_control_info |
トラフィックコントロール情報参照用 | id , name , zone , traffic_quota_in_mb , bandwidth_limit_in_kbps , enable_email , enable_slack , slack_url , auto_traffic_shaping |
sakuracloud_mobile_gateway_traffic_uplink |
トラフィック(UP) (unit: KB) | id , name , zone |
sakuracloud_mobile_gateway_traffic_downlink |
トラフィック(DOWN) (unit: KB) | id , name , zone |
sakuracloud_mobile_gateway_traffic_shaping |
通信制限が行われている場合は1 | id , name , zone |
NFS
Metric | Description | Labels |
---|---|---|
sakuracloud_nfs_info |
NFS情報参照用 | id , name , zone , plan , host , tags , description |
sakuracloud_nfs_up |
起動している場合は1 | id , name , zone |
sakuracloud_nfs_free_disk_size |
空きディスク容量(unit: GB) | id , name , zone |
sakuracloud_nfs_nic_info |
NIC情報参照用 | id , name , zone , upstream_id , upstream_name , ipaddress , nw_mask_len , gateway |
sakuracloud_nfs_receive |
NIC 受信(unit: Kbps) | id , name , zone |
sakuracloud_nfs_send |
NIC 送信(unit: Kbps) | id , name , zone |
サーバ
Metric | Description | Labels |
---|---|---|
sakuracloud_server_info |
サーバ情報参照用 | id , name , zone , cpus , disks , nics , memories , host , tags , description |
sakuracloud_server_up |
起動している場合は1 | id , name , zone |
sakuracloud_server_cpu_time |
CPU-TIME (unit: ms) | id , name , zone |
sakuracloud_server_disk_info |
ディスク情報参照用 | id , name , zone , disk_id , disk_name , index , plan , interface , size , tags , description |
sakuracloud_server_disk_read |
ディスク Read (unit: KBps) | id , name , zone , disk_id , disk_name , index |
sakuracloud_server_disk_write |
ディスク Write (unit: KBps) | id , name , zone , disk_id , disk_name , index |
sakuracloud_server_nic_info |
NIC情報参照用 | id , name , zone , interface_id , index , upstream_type , upstream_id , upstream_name |
sakuracloud_server_nic_bandwidth |
NIC帯域(unit: Mbps) | id , name , zone , interface_id , index |
sakuracloud_server_nic_receive |
NIC 受信(unit: Kbps) | id , name , zone , interface_id , index |
sakuracloud_server_nic_send |
NIC 送信(unit: Kbps) | id , name , zone , interface_id , index |
この中でもsakuracloud_server_nic_bandwidth
は頑張って実装したものでなかなか便利だと思います。
さくらのクラウドではプランやサーバの搭載メモリで帯域が変わってくると言う仕様となっています。
sakuracloud_server_nic_bandwidth
はこの仕様を考慮して帯域幅を算出するようになっています。
sakuracloud_server_nic_receive
やsakuracloud_server_nic_send
と組み合わせて、どのくらい帯域を食っているかを見ることが可能です。
SIM
Metric | Description | Labels |
---|---|---|
sakuracloud_sim_info |
SIM情報参照用 | id , name , imei_lock , registerd_date , activated_date , deactivated_date , ipaddress , simgroup_id , carriers , tags , description |
sakuracloud_sim_session_up |
セッション中であれば1 | id , name |
sakuracloud_sim_current_month_traffic |
当月通信量 (unit: Kbps) | id , name |
sakuracloud_sim_uplink |
Uplink トラフィック (unit: Kbps) | id , name |
sakuracloud_sim_downlink |
Downlink トラフィック (unit: Kbps) | id , name |
VPCルータ
Metric | Description | Labels |
---|---|---|
sakuracloud_vpc_router_info |
VPCルータ情報参照用 | id , name , zone , plan , ha , vrid , vip , ipaddress1 , ipaddress2 , nw_mask_len , internet_connection , tags , description |
sakuracloud_vpc_router_up |
起動している場合1 | id , name , zone |
sakuracloud_vpc_router_session |
セッション数 | id , name , zone |
sakuracloud_vpc_router_dhcp_lease |
DHCPリースの現在の数 | id , name , zone |
sakuracloud_vpc_router_l2tp_session |
L2TP/IPsecのセッション数 | id , name , zone |
sakuracloud_vpc_router_pptp_session |
PPTPのセッション数 | id , name , zone |
sakuracloud_vpc_router_s2s_peer_up |
サイト間VPNのピアとのセッションが確立している場合に1 | id , name , zone , peer_address , peer_index |
sakuracloud_vpc_router_receive |
NIC 受信(unit: Kbps) | id , name , zone , nic_index , vip , ipaddress1 , ipaddress2 , nw_mask_len |
sakuracloud_vpc_router_send |
NIC 送信(unit: Kbps) | id , name , zone , nic_index , vip , ipaddress1 , ipaddress2 , nw_mask_len |
ゾーン情報
Metric | Description | Labels |
---|---|---|
sakuracloud_zone_info | ゾーン情報参照用 | id , name , description , region_id , region_name |
GrafanaのDashboardのVariablesで利用したいために追加したものです。 こんな感じで使ってます。
Exporter自身の情報
Metric | Description | Labels |
---|---|---|
sakuracloud_exporter_start_time |
Exporterの起動時間 | - |
sakuracloud_exporter_build_info |
Exporterのビルド情報 | version , revision , goversion |
sakuracloud_exporter_errors_total |
コレクターごとのエラー数 | collector |
特にsakuracloud_exporter_errors_total
は重要です。
API呼び出しで予期せぬエラーがあった場合などにこの項目の値が増えていきます。
本番環境で利用する際はこの項目も監視しておき、急激に増えた場合にアラートを出すようにしておいた方が良いでしょう。
実践的な使い方: クーポンの監視
最後に実践的な例としてクーポンの監視を行う例を紹介します。
さくらのクラウドのクーポンはイベントなどでよく配布されており、利用したとこのある方も多いと思います。
このクーポンには利用期限/金額が設定されており、利用期限をすぎたり利用額がクーポンの金額を超過した場合には実際に請求が発生してしまいます。
これを防ぐには以下のようなメトリクスを利用すればOKです。
sakuracloud_coupon_remaining_days
: クーポン有効期限までの日数sakuracloud_coupon_remaining_discount
: クーポンの残高
AlertManagerでこれらの値が閾値を超えた場合にアラートを出したい場合は以下のようにします。
この例では有効期限1週間前、または残高が2000円を下回った場合にアラートをあげるようになっています。
- alert: coupon_expiration expr: sakuracloud_coupon_remaining_days <= 7 labels: severity: page annotations: summary: "クーポン (ID:{{ $labels.id }})はあと{{ $value }}日で有効期限が切れます" description: "クーポン (ID:{{ $labels.id }})はあと{{ $value }}日で有効期限が切れます" - alert: coupon_discount expr: sakuracloud_coupon_discount < 2000 labels: severity: page annotations: summary: "アカウント({{ $labels.member_id}})のクーポン残高が2000円以下になりました。" description: "アカウント({{ $labels.member_id}})のクーポン残高が2000円以下になりました。"
終わりに
Prometheusとsakuracloud_exporter
を使うことでさくらのクラウドの監視が手軽に行えますね。
便利だと思いますのでぜひご利用ください。
なお使い方がわからないなどの場合は以下のSlackなどに質問を投げてもらえればできる限り回答しますのでこちらもあわせてご利用ください。
以上です。
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Prometheus: Up & Running: Infrastructure and Application Performance Monitoring
- 作者: Brian Brazil
- 出版社/メーカー: O'Reilly Media
- 発売日: 2018/07/28
- メディア: ペーパーバック
- この商品を含むブログを見る
usacloudでクーポン残高を監視してSlackへ通知する
さくらのクラウドで待望のクーポン残高取得APIが公開されましたね!!
これまではいつのまにか使いすぎてた、とか有効期限が切れてる、なんてこともあったかと思いますが、このAPIを利用すれば残高や有効期限を監視できますのでバッチリですね!!
[UPDATE] スクリプトの誤りを修正しました 2018/1/26 17:10
クーポン残高取得APIの使い方
APIドキュメントはこちらにあります。
今回はcurlコマンドを使う方法とさくらのクラウド CLI usacloudを使う方法を紹介します。
curl
コマンドを使う場合
curlコマンドで直接APIを叩く場合は以下のようにします。
$ TOKEN=APIトークン $ SECRET=APIシークレット $ ACCOUNT_ID=アカウントID $ curl --user "$TOKEN":"$SECRET" \ https://secure.sakura.ad.jp/cloud/zone/is1a/api/system/1.0/coupon/$ACCOUNT_ID
APIキー(トークン/シークレット)はコントロールパネルのAPIキー画面からコピペでOKです。
アカウントIDはアカウント画面のリソースID
というやつです。
レスポンスは以下のようになります。
{ "AllCount": 1, "CountPerPage": 1, "Coupons": [ { "AppliedAt": "2019-01-10T11:12:13+09:00", "ContractID": "111111111111", "CouponID": "xxxxxxxxxxxxxxxx", "Discount": 999999, // クーポン残高 "MemberID": "abc99999", "ServiceClassID": 50122, "UntilAt": "2019-03-31T23:59:59+09:00" // クーポン有効期限 } ], "Page": 1, "is_ok": true }
あとはこれを加工すれば良いですね。
さくらのクラウド CLI usacloud
を使う場合
usacloudにおいてもv0.18からクーポンAPIに対応しました。
usacloudの場合、アカウントIDは実行時にAPIキーに紐付いたアカウントの情報を参照して設定しますので、APIキーだけ用意すればOKです。
ということで早速試してみます。
今回はこちらのUsacloud Sandboxを利用して実行してみます。
こちらを開いて適当にウィンドウ内(黒い部分)をクリックするとusacloudが使えるようになります。
まずusacloud config
コマンドを実行してAPIキーを入力します。
デフォルトゾーン/出力タイプも聞かれますが何も入力しなくてOKです。
その後 usacloud coupon
コマンドを実行するとクーポン一覧が表示されます。
(このアカウントには有効なクーポンが適用されてないためDiscount列が表示されてませんが、本来はDiscount列に残高表示されます。)
出力をJSONにする-o json
オプションやJSONの加工が行える--query
オプションなどもありますので色々と試してみてください。
定期的にクーポン残高を取得してSlackに通知する
APIを直接叩いたりusacloudコマンドを使うことでクーポン残高の取得ができました。
次にこれを応用して定期的にクーポン残高を取得して、閾値を下回っていた場合にはSlackに通知するようにしてみます。
クーポン残高を取得してSlackに通知するスクリプト
ということでこんなスクリプトにしてみました。
#!/bin/bash # パラメータ URL=${SLACK_WEBHOOK_URL} REMAINING=${COUPON_MIN_REMAINING} # バリデーション if [[ -z "${URL}" ]]; then echo "SLACK_WEBHOOK_URL is empty. exit(2)" exit 2 fi expr "$REMAINING" + 1 > /dev/null 2>&1 RET=$? if [[ $RET -gt 1 ]]; then echo "COUPON_MIN_REMAINING is not a number. exit(2)" exit 2 fi # クーポン残高取得 DISCOUNT=`usacloud coupon --usable -o json --query 'sum([].Discount)' 2>/dev/null` if [[ -z "$DISCOUNT" ]]; then JSON="{ \"text\": \"さくらのクラウドに有効なクーポンが登録されていません。\" }" curl -s -X POST -H 'Content-Type: application/json' -d "$JSON" $URL exit 0 fi expr "$DISCOUNT" + 1 > /dev/null 2>&1 RET=$? if [[ $RET -gt 1 ]]; then echo "'usacloud coupon' command returns invalid value: '${DISCOUNT}'" exit 2 fi # 残高が閾値を下回っているか判定 if [[ "$DISCOUNT" -le "$REMAINING" ]]; then # SlackのWebHookを叩く JSON="{ \"text\": \"さくらのクラウドのクーポン残高が${DISCOUNT}円になりました。\" }" curl -s -X POST -H 'Content-Type: application/json' -d "$JSON" $URL fi
ポイントはusacloud
コマンドを実行してる部分です。
以下のように実行しています。
usacloud coupon --usable -o json --query 'sum([].Discount)'
まず--usable
オプションをつけることで、残高があり有効期限内のクーポン情報のみ取得するようにしています。
その後-o json
と--query
でクーポン残高を算出しています。
ここでは単純に各クーポン情報のDiscount
列を合計するようにJMESPathでsum([].Discount)
と指定しています。
これを適当なファイル名で保存/実行権付与して実行してみます。ここではusacloud-coupon-monitor.sh
としました。
SlackのWebhookURLは適当に取得しておきます。
$ export SAKURACLOUD_ACCESS_TOKEN=APIトークン $ export SAKURACLOUD_ACCESS_TOKEN_SECRET=APIシークレット $ export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/xxxx/xxxx/xxxxxxxx" # SlackのWebhookURL $ export COUPON_MIN_REMAINING=3000 # クーポン残高の閾値 $ ./usacloud-coupon-monitor.sh
これを実行するとSlackに以下のような通知が届くはずです。 (アイコンなどは適当にSlackのWebhook管理画面で編集してます)
クーポンが登録されていない/有効期限が切れた場合:
残額が閾値を下回った場合:
これでうっかりクーポンの有効期限切れ/使いすぎを防げますね!
あとはこれをcronなりlaunchdなりに登録して毎日実行するようにすればOKです。
終わりに
今回はクーポンAPIを試してみました。
今回のスクリプトでは期限が切れたら or 残額が閾値を下回ったら通知をしていますが、 少し工夫すれば有効期限が残りn日になったら通知、といったこともできると思います。
usacloudではjson以外にもcsvやtsv、Goテンプレートによるカスタム出力にも対応してますのでお好みの方法で色々試してみてください。
以上です。
さくらのクラウド 新プランとプラン移行ツール cloud-plan-migrate
昨年9月にさくらのクラウド 石狩第1ゾーンの新規申し込み受付が再開されました。
それに伴いサーバ/ディスクの新しいプランが提供され、同一性能のプランで比較すると新プランの方が安く提供されるようになりました。
今回はこの新プランを活用すべく、旧プランから新プランへの変更を行うためのツールcloud-plan-migrate
を作成しましたのでご紹介いたします。
石狩第1ゾーンの新規申し込み受付再開
2018/9/27に石狩第1ゾーンでの新規申し込みの受付が再開されました。
これまでは2016/7/1以降に新規作成されたアカウントでは石狩第1ゾーンを利用することができませんでした。
これが新規申し込み受付が再開されたことにより、アカウントの新旧問わずに石狩第1ゾーンが利用可能となりました。
新規申し込み受付再開と同時に新プランも提供開始
また、新規申し込みの再開と同時にサーバとディスクに新プランが提供されました。
新プランはプラン数が従来の石狩第2/東京第1ゾーンと同等にまで拡充され、同一性能のプランにおいては旧プランよりも低価格になるとのことです。
この新プランについて詳しく追ってみます。
新プランの特徴
新プランについての詳細は以下のさくらのクラウド マニュアルに記載されています。
これらによると、新プランの特徴として以下のようなものがあるとのことです。
- 選択できるプランの拡大(東京第1ゾーンとおなじく全94プランに)
- 同一性能プランにおいて値下げ
- 以下のディスクサイズが選択可能に
旧プランも継続利用可能(ただし前提条件あり)
また、これまで石狩第1ゾーンでサーバ/ディスクを利用していた場合(2016/7/1以前に作成されたアカウント)、
現在でも旧プランでサーバ/ディスクを作成することが可能です。
現時点でコントロールパネルにて石狩第1ゾーンのサーバ or ディスクの一覧画面を開いたときに、旧プラン
という表示がされたリソースが1つでもあれば旧プランを継続利用可能になっているはずです。
コントロールパネルでの新旧プラン表示の例:
新プランを利用する場合の注意点
注意点として、サーバとディスクを接続する場合はどちらも同じ世代(新/旧)のプランでないといけないという点があります。
例えば、新プランで作成したサーバに旧プランのディスクを接続することはできません。
同一性能プランでの新旧の価格比較
ディスクの価格については新旧プランで違いはないようです。
サーバについては同一性能プラン(コア数/メモリサイズが同一)で比較したところ以下のように新プランの方は全体的に値下げされていました。
新旧プラン価格比較:
コア数 | メモリサイズ(GB) | 旧プランとの価格差分 |
---|---|---|
1 | 1 〜 5 | ¥-10 〜 ¥-357 |
2 | 2 〜 6 | ¥0 〜 ¥-648 |
3 | 3 〜 12 | ¥-810 〜 ¥-2,268 |
4 | 4 〜 16 | ¥-1,620 〜 ¥-3,564 |
5 | 8 〜 24 | ¥-2,916 〜 ¥-5,508 |
6 | 12 〜 32 | ¥-4,212 〜 ¥-7,452 |
8 | 16 〜 48 | ¥-6,156 〜 ¥-11,340 |
10 | 24 〜 64 | ¥-8,748 〜 ¥-13,500 |
12 | 48 〜 128 | ¥-2,700 〜 ¥-14,796 |
個々のコア数/メモリサイズでの価格比較については以下の画像を参照ください。
注: この表/画像は2019/1/18時点で独自に調べたものです。もし誤りなどありましたらコメントください。最新の情報は公式サイトなどを参照ください。
2コア2GBメモリのプランでは新旧で価格の差がないですが、それ以外のプランは全て値下げされています。
特にハイスペックなプランほど値下げ幅が大きいですね。最大で12コア/64GBメモリで¥14,796の値下げです。
また、ここでは月額で比較しましたが、さくらのクラウドでは時間単位/日単位/月単位で課金額が変わります(その時点での最安値となる)。
時間単位/日単位の金額も月額と同じように新プランで値下げされていますので気になる方は比較してみると良いかもしれません。
(旧プランを継続利用している方はあまり時間単位/日単位での利用はしないのではないかという気もしますが)
旧プランから新プランへの移行
前述のマニュアルによると、プラン移行には以下の方法があるようです。
これ以外にも、自前で新規サーバを作成&プロビジョニングして必要なデータ類をコピーして移行といった方法も考えられますが、 この方法はプラン変更としては本質的にクローンする処理と同じですので説明は割愛します。
それぞれの方法をもう少し詳しくみてみます。
コントロールパネル/APIでプラン変更を行う
さくらのクラウドではサーバのプラン変更を行うためのAPIPUT /server/:serverid/plan
が提供されています。
このAPIは新プラン提供開始に伴いPlanIDの指定方法が変わりました。
旧APIのドキュメント: https://developer.sakura.ad.jp/cloud/api/1.1/server/#put_server_serverid_to_plan_planidAPIを利用する際は以下のプラン変更API利用時の注意を参照してください。
プラン変更API利用時の注意: https://manual.sakura.ad.jp/cloud/support/is1a-gen2.html#api
コントロールパネルからプラン変更
を行うことでこのAPI経由でプラン変更が行えます。
コントロールパネルからサーバのプラン変更を行なった場合、サーバのプランのみが変更されディスクのプランは変更されない点にご注意ください。
前述の通り、新プランのサーバに旧プランのディスクを接続したままの利用はできないため、このままだと起動時に以下のようなエラーが出ます。
このため、サーバのプラン変更時にはディスクのプラン変更も合わせて行う必要があります。
ディスクについてはディスクの新規作成時に旧プランのディスクをソースとして選択した上で新プランで作成するという形になります。
新プランでのディスクの作成後はサーバに対して旧ディスクの切り離し/新ディスクの接続という作業も必要になりますので忘れないようにしましょう。 また、ディスクソースとした旧プランのディスクは不要になりますので、新旧で2重に課金されないようにこちらも忘れずに削除しましょう。
コントロールパネル/APIでプラン変更を行う際の作業まとめ
ここまでをまとめると、コントロールパネル/APIでプラン変更を行うには以下のような作業が必要ということです。
- サーバのシャットダウン
- 旧プランのディスクをコピーして新プランのディスク作成(※1)
- サーバを新プランに変更
- 旧プランのディスクをサーバから切り離し(※1)
- 新プランのディスクをサーバに接続(※1)
- サーバの起動
- 旧プランのディスクを削除(※1)
※1: 複数のディスクを接続している場合は各ディスクに対して作業が必要
コントロールパネル/APIでプラン変更を行う際の注意点(特にTerraform関連)
この方法でプラン変更を行う場合、プラン変更後はサーバ/ディスクのIDが変更される点に注意が必要です。
これは特にリソースマネージャーやTerraform for さくらのクラウドを利用して構成管理している場合に問題になります。
Terraform for さくらのクラウドでは作成したリソースのIDを状態として保持(terraform.tfstate
ファイルなど)しておき、それを元にさくらのクラウドAPIを呼び出しています。
IDが変わってしまうとterraform apply
時に処理対象のリソースが見つからないということでリソースの新規作成を行おうとしてしまいます。
これを防ぐにはterraform.tfstate
ファイルの編集といった作業が必要になります。
Terraformをご利用中の場合は対応作業が発生する可能性を考慮しておいてください。 (不安な方はさくらのクラウドユーザーコミュニティ向けのSlackワークスペースなどでご相談ください)
旧サーバをクローンして新サーバを作成する
旧ディスクをコピーして新プランのディスクを作成、新たに作成したサーバと接続することでプラン移行する方法です。
これを行うために、コントロールパネルにて クローン機能 が提供されています。
クローン機能を用いることでサーバ/ディスクを同時に新プランへ移行することが可能です。
(なお、さくらのクラウド CLIであるusacloudではクローン機能に該当する機能は提供しておりません…クローン機能はコンパネが提供している便利機能なんですよね)
ただし、クローン機能を利用する場合、以下の点に注意が必要です。
プラン変更APIの場合は共有セグメント利用時に割り当てられたグローバルIPを保持したままプラン変更できますが、クローンの場合はサーバの新規作成となるためグローバルIPが変更されます。
スイッチ+ルータ(固定のIPアドレスブロックを確保するサービス)を利用している場合などは問題ないと思いますが、そうでない場合は注意が必要です。
また、追加NICや2つ目以降のディスクについても個別に対応が必要になります。
移行方法まとめ
それぞれの方法の特徴や注意点をまとめると以下のようになります。
移行方法 | 特徴 | 注意点 |
---|---|---|
プラン変更API | コンパネなどからプラン変更用のAPIを利用する | - あらかじめサーバのシャットダウンが必要 - サーバ/ディスクで個別に作業が必要 - プラン変更後はサーバのIDが変わる |
クローン機能 | 旧ディスクをコピーして新規作成したサーバに接続する | - サーバのグローバルIPが変更される場合がある - 追加NIC/追加ディスクがある場合は個別に作業が必要 |
旧プランから新プランに移行すべきか?
今の所は旧プランも(旧プランのリソースが残ってる限りは)継続して利用可能ですのですぐに移行する必要はないと思います。
しかし、新プランでは全体的に値引きされており、継続的に利用するサーバであれば新プランへ移行してしまった方がおトクです。
移行にはサーバの停止や移行作業(これらに伴う準備/検証などの作業も)が必要となりますので、それらの工数も考慮して移行すべきか決定すると良いでしょう。
このため基本的な方針としては、
- 一時的に止めても良いサーバであればプラン変更APIで移行する
- サーバを止められない場合は個別に検討する
といった形になるとおもいます。
移行する決定をした場合、出来るだけ速やかに移行した方が料金的におトクですのであまり手間をかけずサッと作業してしまいたいところですね。
プラン移行ツール cloud-plan-migrate
ということでやっと本題です。
前述の通り、プラン変更APIを利用するには結構手間がかかる & クローン機能を使うとグローバルIPが変わる、追加NIC/ディスクは個別に対応が必要、とどちらを選んでも結構手間がかかります。
1〜2台であれば手作業でも良いですが、それ以上、場合によっては数10〜数100台にもなった場合に手作業を行うのは大変です。
個別にAPIを叩くスクリプトを組んでも良いですが、今回限りのソリューションとなるため作り込むことをためらう方も多いと思います。
そこで、さくらのクラウド関連のOSSを集めたsacloudオーガニゼーション配下にcloud-plan-migrateというツールを公開しておきました。
cloud-plan-migrate
について
Go言語で書かれたCLIツール
cloud-plan-migrate
はGo言語で書かれた、プラン変更に特化したCLIツールです。
シングルバイナリでインストールは実行ファイルをダウンロードするだけ、さらにWindows/Linux/macOSなどの各種プラットフォームをサポートしています。
処理の流れ
cloud-plan-migrate
は前述のプラン変更APIを用いる方式を採用しています。
具体的にはさくらのクラウドAPIを用いて以下のような処理を行います。
- サーバのシャットダウン
- サーバに接続されたディスクをコピーして新プランのディスクを作成
- サーバに接続されたディスクの切り離し
- サーバのプラン変更
- 新プランのサーバに新プランのディスクを接続
- サーバの起動(オプションで無効化できる)
- 旧プランのディスクの削除(デフォルトで無効、オプションで有効化できる)
複数台のサーバを一気に処理することができるようになっており、 最大で同時に10サーバ分の処理を平行で行うようになっています。 (処理対象は10サーバ以上を指定可能です。)
プラン変更APIを利用しますので、以下の点は注意が必要です。
- 処理中はサーバがシャットダウンされる
- プラン変更後はサーバのIDが変更になる
その代わりにグローバルIPは保持したままとなりますので、プラン変更後にサーバ起動を起動した後はプラン変更前と変わらずご利用いただけるようになっています。
停止時間が許容できる、かつ複数台を一括でプラン変更したい場合などでご利用いただけるかと思います。
インストール
以下のGitHubリリースページから各プラットフォーム向けのバイナリをダウンロードするだけです。
使い方
実行時にさくらのクラウドのAPIキー(トークンとシークレット)が必要です。
APIキーには作成・削除
権限が必要となりますので忘れずに権限を設定しておいてください。
APIキーが準備できたら以下のように実行します。
$ cloud-plan-migrate <オプション> <対象サーバのID or 名称>
実行すると以下のようにAPIキーの入力が求められますので用意しておいたAPIキーを入力してください。
$ cloud-plan-migrate <ID or 名称> Your API AccessToken is not set Enter your token: <トークンを入力> Your API AccessTokenSecret is not set Eneter your secret: <シークレットを入力>
実行中は以下のようにサーバ/ディスクごとに処理状況が表示されます。
ディスクのコピー処理に時間がかかりますが、それ以外は数秒〜数10秒で終わるはずです。
ディスクのコピー処理はディスクサイズやクラウドAPI側の負荷状況にもよりますが数時間かかることもあります。
参考までに、コントロールパネルのディスクコピーを行う画面には 【完了までの目安時間】2TB: 約6時間, 4TB: 約12時間
と書かれています。
実行するタイミングでも結構上下していた感触です(私の手元のマシンで実行した際は20GBのディスクで2〜3分しかかからなかったこともありました。)。
実際に本番環境で実行する際はあらかじめ数回テスト用のサーバなどで試してどれくらいの時間がかかるか試しておくことをお勧めします。
(オプション) 環境変数でのAPIキーの指定
APIキーはコマンド実行時に対話入力する方法以外に、コマンドラインオプションで渡す or 環境変数で指定する方法もあります。
環境変数で指定する場合は以下のようにします。 (usacloudやTerraform/Packer for さくらのクラウドなどと共通の環境変数です)
$ export SAKURACLOUD_ACCESS_TOKEN="APIトークン" $ export SAKURACLOUD_ACCESS_TOKEN_SECRET="APIシークレット"
パラメータ/オプションについて
コマンドの引数としてプラン変更対象サーバのIDまたは名称を指定します。
名称を指定した場合、部分一致する全ての旧プランサーバが対象となります。
また、ID/名称以外にも--selector
オプションでサーバにつけられたタグを用いて対象を指定可能です。
例えば以下のようにした場合、app=web
というタグを持つサーバのみ対象とできます。
なおサーバの名称を指定する場合と異なり、完全一致するタグを持つサーバのみが対象となる点に注意してください。
$ cloud-plan-migrate --selector "app=web"
その他のオプションは以下のものが指定可能です。
APIキー関連
--token
: [必須] APIキー(トークン)、環境変数SAKURACLOUD_ACCESS_TOKEN
でも指定可能です。--secret
: [必須] APIキー(シークレット)、環境変数SAKURACLOUD_ACCESS_TOKEN_SECRET
でも指定可能です。
これらを省略した場合、実行時に入力を促すダイアログが表示されます。
マイグレーションの動作関連
--selector
: 対象サーバをタグで指定する--disable-reboot
: プラン変更後にサーバの起動を行わない--cleanup-disk
: プラン変更後に旧ディスクを削除する
その他
--assumeyes/-y
: 実行前の確認を省略する
コマンド実行のログ出力
コマンドを実行するとカレントディレクトリにmigrate-[日付].log
というファイル名でログ出力されます。
エラー発生時のトラブルシューティングなどにご利用ください。
エラー時の挙動について
API呼び出しでエラーが発生した場合、エラーが発生した対象のサーバの処理はスキップされます。 それ以外のサーバについては処理が続行されます。
Dockerでの実行
Docker向けのイメージも用意しています。
以下のようにすることでDockerを用いてcloud-plan-migrate
を実行できます。
# カレントディレクトリにログ出力されるため-vオプションを指定 $ docker run -it --rm -v $PWD:/work sacloud/cloud-plan-migrate <ID or 名称>
まとめ
今回は石狩第1ゾーンでの新プランについてと旧プランからの移行ツールcloud-plan-migrate
を紹介しました。
複数台のサーバ/ディスクのプラン変更を行う際に便利だと思いますのでぜひご活用ください。
皆様のお役に立てば幸いです。
もしプラン変更作業にお悩みの際はユーザーコミュニティ向けのSlackワークスペースでQAなどを行なっておりますので是非ご活用ください。 以下のURLから参加できます。
以上です。
external-dnsをさくらのクラウドで使う
kubernetes-incubator/external-dnsって何?
KubernetesでServiceやIngressなどの作成/更新を検知してDNSレコードを動的に設定してくれるexternal-dnsというプロダクトがkubernetes-incubator配下にあります。
例えば以下のようなIngressを作成するとnginx.example.org
というホスト名に対応するAレコードを作成してくれます。
kind: Ingress metadata: name: nginx annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: nginx.example.org http: paths: - backend: serviceName: nginx servicePort: 80
external-dnsの特徴的な点として、データソース(ServiceやIngressなど)とレコード作成先(プロバイダーと呼ばれている)が分離されており、 それぞれを任意の組み合わせで利用することが可能という点があります。 これにより様々なプラットフォームを統一的な手段でサポートできるようになっています。
データソースとしてはService/Ingressだけでなく、istio-gatewayや独自のCRD(Custom Resource Definitions)などがあり、 レコードの作成先については以下のような様々なプラットフォームがサポートされています。
external-dns v0.5時点で対応しているプロバイダー
- Google CloudDNS
- AWS Route 53
- AWS Service Discovery
- AzureDNS
- CloudFlare
- DigitalOcean
- DNSimple
- Infoblox
- Dyn
- OpenStack Designate
- PowerDNS
- CoreDNS
- Exoscale
- Oracle Cloud Infrastructure DNS
- Linode DNS
- RFC2136
これがさくらのクラウドに対応していませんでしたので今回forkして対応してみました。
当記事ではさくらのクラウドでのexternal-dnsの使い方について紹介します。
(なお今の所はupstreamへのマージは考えてません。使いたいという方が増えたら考えます。)
external-dnsをさくらのクラウドで使う
準備作業
まずはKubernetesクラスターの準備やさくらのクラウドDNSに管理対象のゾーンを登録しておく必要があります。
KubernetesクラスターについてはRancher2セットアップというスタートアップスクリプトが提供されていますのでそちらを利用して準備しておきます。
以下の記事などが参考になるかと思います。
また、さくらのクラウドへのDNSゾーン登録も必要です。
こちらは以下のスライドなどが参考になるかと思います。
www.slideshare.net
sacloud/external-dnsのデプロイ
準備が出来たらexternal-dnsをデプロイします。
manifestは以下のようになります。
apiVersion: v1 kind: ServiceAccount metadata: name: external-dns --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: external-dns rules: - apiGroups: [""] resources: ["services"] verbs: ["get","watch","list"] - apiGroups: [""] resources: ["pods"] verbs: ["get","watch","list"] - apiGroups: ["extensions"] resources: ["ingresses"] verbs: ["get","watch","list"] - apiGroups: [""] resources: ["nodes"] verbs: ["list"] --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: external-dns-viewer roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dns subjects: - kind: ServiceAccount name: external-dns namespace: default --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: external-dns spec: strategy: type: Recreate template: metadata: labels: app: external-dns spec: serviceAccountName: external-dns containers: - name: external-dns image: sacloud/external-dns:latest args: - --source=service - --source=ingress - --domain-filter=example.com # (optional, but we highly recommended to set this) limit to only example.com domains; change to match the zone created above. - --provider=sakuracloud env: - name: SAKURACLOUD_ACCESS_TOKEN value: "YOUR_API_KEY" - name: SAKURACLOUD_ACCESS_TOKEN_SECRET value: "YOUR_API_SECRET"
上の方がRBACの設定、Deploymentのcontainersの部分がexternal-dnsのコンテナの定義となっています。
RBACを使わない場合については以下のドキュメントを参照してください
external-dns/sakuracloud.md at master · sacloud/external-dns · GitHub
external-dnsのコンテナ定義部分だけ抜粋
containers: - name: external-dns image: sacloud/external-dns:latest args: - --source=service - --source=ingress - --domain-filter=example.com # (optional, but we highly recommended to set this) limit to only example.com domains; change to match the zone created above. - --provider=sakuracloud env: - name: SAKURACLOUD_ACCESS_TOKEN value: "YOUR_API_KEY" - name: SAKURACLOUD_ACCESS_TOKEN_SECRET value: "YOUR_API_SECRET"
以下の部分は各自で任意の値を設定してください。
--domain-filter
: 操作対象のゾーン(ドメイン)SAKURACLOUD_ACCESS_TOKEN
: さくらのクラウド APIトークンSAKURACLOUD_ACCESS_TOKEN_SECRET
: さくらのクラウド APIシークレット
この例では以下のような指定を行なっています。
動作確認
動作確認のためnginxコンテナをデプロイし、Ingressで外部からアクセスできるようにします。
まずはPodとServiceをデプロイします。
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx spec: template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx spec: selector: app: nginx type: ClusterIP ports: - protocol: TCP port: 80 targetPort: 80
続いてIngressをデプロイします。
ここではFQDNとしてexternal-dns.example.com
を指定しています。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-example namespace: default spec: rules: - host: external-dns.example.com http: paths: - backend: serviceName: nginx servicePort: 80
しばらく待つと対象のゾーンにAレコードとTXTレコードが追加されているのがコントロールパネルなどで確認できます。 後は指定したFQDNに対してアクセスするとNGINXのデフォルトページが表示されるはずです。
後片付け
Ingressを削除すると対応するDNSレコードも削除されるようになっています。
(この動作はexternal-dnsのオプション--policy
にデフォルトでsync
が指定されているためです)
終わりに
external-dnsを利用することでKubernetes側の操作だけでDNSレコードの登録/変更/破棄が行えます。
頻繁にアプリケーションのデプロイ/DNSレコードの更新を行うけど、
さくらのクラウドのコントロールパネル/APIヘのアクセスは集中管理したい/触れる人を限定したい、といった場合などで便利だと思います。
ぜひご利用ください。
以上です。
さくらのクラウド: スタートアップスクリプト「Rancher2 セットアップ」 〜 AA DOJO #1 LT 〜
Alternative Architecture DOJO Offline #1に参加してきました
2018/11/28にFukuoka Growth Next(通称:FGN)で開催された「Alternative Architecture DOJO Offline #1」というイベントでLTさせていただきました。
このイベントはConnpass上でのサブタイトルとして「クラウドネイティブを語りつくす!」と銘打たれており、 その名に恥じない濃く実践的な知見が数多く共有された素晴らしいイベントでした。
当日の様子:
元々このイベントには一般枠で申し込んでいたのですが、 当記事タイトルの「さくらのクラウド Rancher2セットアップ」というスタートアップスクリプトの リリースが開催に間に合うという幸運に恵まれたため、イベント当日急遽LTに申し込みをさせていただきました。
LTは無事行えたのですが、スライドが悪ふざけしすぎていて公開できる状態ではなかったのでこの記事で改めてこのスタートアップスクリプトについて紹介します。
さくらのクラウド Rancher2セットアップ スタートアップスクリプト
イベント開催当日(2018/11/28)にさくらのクラウドにおいてスタートアップスクリプト「Rancher2セットアップ」がリリースされました。
これは、さくらのクラウドでサーバをプロビジョニングするための仕組みである「スタートアップスクリプト」の中の一つで、 コントロールパネルから当該スクリプトを選んだ上でサーバ作成を行うことでRancher2のセットアップが出来るというものです。
このスクリプトはスタートアップスクリプトを公開しているGitHub上のリポジトリに対しPullRequestを送って追加していただいたものです。
以下の機能を持っています。
- Rancherサーバのインストール
- Rancherサーバの管理者パスワードの設定
- RancherサーバのURL設定(サーバのIPアドレスで固定)
- さくらのクラウド向けNodeDriverの登録
- NodeDriver向けのカスタムUIの登録(ui-driver-sakuracloud)
- 推奨構成でのノードテンプレートの登録(ノード作成用のさくらのクラウドAPIキーの指定を含む)
これにより、サーバ起動後すぐにさくらのクラウド上にKubernetesクラスタの作成が行える状態となっています。
しかもクラスタ作成時に必要な情報は最低限以下の3つだけという手軽さです。
どんな感じで使うのか見てみます。
使い方
まずはさくらのクラウドのサーバ作成画面でRancher用のスタートアップスクリプトを選択します。
この時に以下3項目を指定します。
後はそのままサーバ作成を行うだけでOKです。
(APIキーは「作成」権限の付いたものが必要な点に注意してください)
サーバ作成後に https://<作成したサーバのIPアドレス>
にアクセスするとRancherのログイン画面が表示されます。
(ダウンロードなどに時間がかかりRancher起動まで数分かかることもあります)
ユーザー名は admin
、パスワードはコントロールパネルで指定したものを入力することでログインできるようになっています。
なお、初回アクセス時は以下のような証明書警告が表示されると思います。
本来RancherはLet's encryptでの証明書取得などもサポートしているのですが、このスタートアップスクリプトではその辺りが非対応なため証明書の警告が出てしまいます。
将来的になんらかの形で証明書自動取得の仕組みを入れることができるかもしれませんが現状対応していませんので当面はこのまま接続してください。
ログイン後、クラスターの追加ボタンが表示されていますのでクリックしてクラスタ追加画面へ遷移します。
すると、最初からどこにクラスタを作成するかの選択肢としてさくらのクラウドが選択できる状態となっているはずです。
後はクラスタ名、ロールごとの台数、ノード名のプレフィックスを指定して作成ボタンを押すだけです。
Rancherからさくらのクラウド上にクラスタのノードを作成しているところ:
クラスタ作成後はRancherの豊富な機能を利用可能な状態となっています。
kubectl用のconfigをダウンロードしたり、ブラウザ上で直接kubectlコマンドを実行するといったことも可能です。
例: ブラウザ上でkubectlコマンドを実行しているところ:
手軽ですよね! 検証や開発といった用途に手軽にご利用いただけると思いますのでぜひお試しください。
おまけ: RancherのNode DriverとカスタムUIについて
Node Driverについて
このスタートアップスクリプトではRancherのNode Driverという仕組みを利用しています。
これはRancherが様々なプラットフォームに対応するための仕組みで、各プラットフォームでノードを作成するためのドライバーをプラグインできるというものです。
参考: Nodes Hosted in an Infrastructure Provider | Rancher Labs
NodeDriverの実体はDocker Machineのドライバーであり、DockerMachine向けのドライバーさえあればRancherのNodeDriverとして登録できます。
さくらのクラウドについてはdocker-machine-sakuracloudがありますのでこれを利用しています。
github.com (元々このドライバは私の個人リポジトリで開発していたものですが、今はsacloud配下にリポジトリ移転して開発を続けています)
RancherにはNode Driverの管理画面が用意されていますのでそちらからDockerMachineドライバーの実行ファイル(のURL)を指定すれば利用できるようになります。
登録されているNode Driverの一覧画面:
Node Driverの登録画面:
ここで登録しておけばノードテンプレート画面やクラスタ作成画面で利用できるようになります。
注: ノードテンプレートとは、Docker Machineでノードを作成する際に指定する、Docker Machineに渡すパラメータの定義のことです。OS種別やコア数、メモリサイズといったパラメータなどを指定します。
なお、この登録画面ではドライバーの実行ファイルのURLの他にカスタムUI(のjsのURL)も指定できるようになっています。
カスタムUIとはなんでしょうか?次に見ていきます。
カスタムUIについて
Node Driverを登録すると前述通りノードテンプレート画面で対象のドライバーが選択できるようになるのですが、デフォルトでは以下のように自動生成された味気ない入力項目が表示されます。
この例はさくらのクラウド向けのDockerMachineドライバーの例ですが、アイコンも表示されずテキストボックスが単純にズラズラと並んだだけのものとなっていますね。
入力項目が少ない場合はこれでも良いでしょうが、もう少し見栄え良くしたり、入力値のバリデーションを行ったりしたいこともあるかと思います。
Rancherではこのための仕組みとしてカスタムUIという仕組みを用意しています。
規則に沿ってjs/cssを作成し任意のWebサーバなどに配置しておけばRancherが動的にそれらを読み込んで画面表示を行ってくれます。
この辺ドキュメントがあまりないのですが、スケルトンが公開されていますしビルドインのNodeDriver向けのカスタムUIのコードは公開されていますのでそれらを参考に作っていくという形になります。
さくらのクラウド向けドライバーでもカスタムUIであるui-driver-sakuracloudを用意しており、これを利用することでノードテンプレート画面は以下のようになります。
ここではパラメータの入力にリストを用いたり、選択に応じてリストの値を変えたりと細々した処理が実装されています。
もちろんスタートアップスクリプトを使えばこの辺は全て設定済みとなっています。
終わりに
ということで今回はさくらのクラウドに追加された「Rancher2セットアップ」スタートアップスクリプトについて紹介しました。
2018/12/14までではありますが、さくらのクラウド7周年記念ということで7万円分のクーポンをもらえるキャンペーン(ただし新規法人会員のみ)をやっているらしいので、この辺も活用しつつぜひお試しください!!
以上です。