TerraformのRKEプロバイダーをRancher Labsに移管しました

はじめに

Rancher Labsが提供するRKE(Rancher Kubernetes Engine)をTerraformから扱えるようにするRKEプロバイダーを私の個人リポジトリからRancher Labs配下へ移管しました。

github.com

移管によりこれまで以上にRKE本体との連携も進むでしょうし、今後はより一層安定してご利用いただけるようになりそうです。

TerraformのRKEプロバイダーって何？

こちらで紹介しています。

febc-yamamoto.hatenablog.jp

speakerdeck.com

どんな人がRKEプロバイダーを使ってるの?

国外での利用が多いです。AWS(EC2)やAzure、OpenStack、vSphere、DigitalOceanとの組み合わせあたりでご利用いただくケースが多いです。

Rancher Labsが公開しているブログやYouTubeチャンネルなどで紹介されたこともあります。
以下のようなところで紹介されました。

Rancher Labsブログ

rancher.com

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)

Terraformからウェブアクセラレータの証明書を管理する

Terraformからウェブアクセラレータを参照/一部の操作ができるように

Terraformのさくらのクラウドプロバイダー v1.18.1からウェブアクセラレータ向けのリソースが追加されました。

• sakuracloud_webaccel: サイト情報を参照するためのデータソース
• sakuracloud_webaccel_certificate: サイトに登録する証明書リソース

github.com

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で取得してみます。

www.terraform.io

今回はDNSを用いて取得します。ACMEプロバイダーではDNSプロバイダーとしてさくらのクラウドDNSがサポートされていますのでこちらを利用します。

www.terraform.io

コードは以下のようになります。

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するようにすれば良いでしょう。

終わりに

ぜひご利用ください！

さくらのクラウドでUbuntuのクラウドイメージ+cloud-initを利用する

はじめに

さくらのクラウド上でUbuntuの「クラウドイメージ」を利用する機会がありましたので方法をまとめておきます。

手順

• Ubuntuのクラウドイメージをダウンロード、qcow2からrawに変換してさくらのクラウドにアップロード
• NoCloudデータソース用にISOイメージを作成してさくらのクラウドにアップロード

順番にみていきます。

Ubuntuのクラウドイメージの準備

cloud-initが構築済みの「クラウドイメージ」というものがUbuntuで提供されています。

gihyo.jp

今回はこれを利用します。ただし、さくらのクラウドはraw形式にのみ対応していますので、イメージをダウンロードした後変換してからさくらのクラウドへアップロードします。

なお、以下の手順では作業マシン上でqemu-imgコマンドとusacloudコマンドを利用します。

qemu-imgコマンドについてはyum install qemu-imgやapt install qemu-utilsなどでインストールしておきます。
usacloudコマンドはこちらを参考にインストール&APIキーの設定を済ませておきます。

# ダウンロード(今回は18.04を利用)
curl -sL -o ubuntu.img https://cloud-images.ubuntu.com/releases/bionic/release/ubuntu-18.04-server-cloudimg-amd64.img 

# qcowからraw形式(sparse)へ変換
qemu-img convert ubuntu.img ubuntu-sparse.raw

# non-sparseファイルにする
cp --sparse=never ubuntu-sparse.raw ubuntu.raw

# さくらのクラウド上にアーカイブとしてアップロード
usacloud archive create --name my-ubuntu --size 20 --archive-file ubuntu.raw  

qemu-imgでraw形式に変換後、non-sparseファイルにするのがポイントです。
(試しにsparseファイルのまま試したらサーバ起動できませんでした)

NoCloudデータソース用にISOイメージを作成&アップロード

次にNoCloudデータソース用のISOイメージを作成、アップロードを行います。 NoCloudデータソースについては以下の記事を参考に作成しました。 gihyo.jp

今回はubuntuユーザーにパスワードを設定しパスワード認証でSSH接続できるようにするという内容になってます。

# user-dataファイルの作成(!パスワードは任意の値に置き換えてください)
PASSWORD=your-password
cat >user-data <<EOF
#cloud-config
password: $PASSWORD
chpasswd: { expire: False }
ssh_pwauth: True
EOF

# meta-dataファイルの作成(とりあえず空でOK)
touch meta-data

# ISOイメージの作成(linux上で作業する場合)
mkisofs -R -V cidata -o cloud-init.iso ./

# ISOイメージの作成)mac上で作業する場合)
# hdiutil makehybrid -iso -joliet -default-volume-name cidata -o cloud-init.iso ./

# さくらのクラウド上にISOファイルをアップロード
usacloud iso-image create --name cloud-init --iso-file cloud-init.iso

作成したアーカイブ/ISOイメージを利用してサーバ作成

次にサーバの作成を行います。

usacloud server build \
  --source-archive-id=`usacloud archive read -q my-ubuntu` \
  --iso-image-id=`usacloud iso-image read -q cloud-init` \
  --name=example

この後作成したサーバに対しSSH接続できるようになっているはずです。

まとめ

• Ubuntuのクラウドイメージをダウンロード後、non-sparseなraw形式に変換してアップロード
• cloud-initのデータソースにはISOイメージファイルを作成してNoCloudデータソースを利用

ISOイメージファイルの作成部分をうまく自動化すれば色々活用できますね。

以上です。

GitHub ActionsでTerraformを実行する時にTerraform Cloudをバックエンドに指定する

某所で「GitHub ActionsからTerraform Cloudを使おうとしたが上手くいかなかった」という投稿を拝見しました。
うまいこと設定すればちゃんと動かせますのでその方法などについてまとめておきます。

TL; DR

• Terraform CloudでのExecution ModeはデフォルトでRemoteになってる
• クレデンシャルをGitHub側のSecretから環境変数として渡す場合はExecution ModeをLocalに変更する

最初に: やりたいこと

• Terraform Github Actionsを使ってGitHub Actionsでterraformコマンドを実行したい。
• tfstateはTerraform Cloudに保存したい

このために、リポジトリ上でGitHub Actionsの設定を行い、リポジトリにtfファイルをコミット、PullRequestの作成を行います。

利用するtfファイル

# バックエンドの設定
terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "your-organization-name"

    workspaces {
      name = "your-workspace-name"
    }
  }
}

# プロバイダー
provider "google" {
  project = "your-project-name"
  region  = "us-west1"
}

# リソースの例
data "google_project" "project" {}

output "project_number" {
  value = "${data.google_project.project.number}"
}

この例はGCPプロバイダーを使うようにしています。

Terraform CloudとGCPプロバイダーのクレデンシャルについてはGitHub ActionsのSecretに保存しておいて環境変数(TF_ACTION_TFE_TOKENとGOOGLE_CREDENTIALS)に指定します。

ワークフローファイルの定義

GitHub Actionsのワークフローファイルは以下を利用します。

参考: https://www.terraform.io/docs/github-actions/getting-started/index.html

on:
  pull_request:
    types: 
      - opened
      - synchronize
      - closed
    branches:
      - master
name: Terraform
jobs:
  terraform-fmt:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1.0.0

    - name: terraform-fmt
      uses: hashicorp/terraform-github-actions/fmt@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        # env
        TF_ACTION_WORKING_DIR: "."

  terraform-init:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1.0.0

    - name: terraform-init
      uses: hashicorp/terraform-github-actions/init@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

  terraform-validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1.0.0

    - name: terraform-init
      uses: hashicorp/terraform-github-actions/init@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

    - name: terraform-validate
      uses: hashicorp/terraform-github-actions/validate@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

  terraform-plan:
    needs:
    - terraform-fmt
    - terraform-init
    - terraform-validate
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1.0.0

    - name: terraform-init
      uses: hashicorp/terraform-github-actions/init@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

    - name: terraform-plan
      uses: hashicorp/terraform-github-actions/plan@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

  terraform-apply:
    needs:
    - terraform-plan
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1.0.0

    - name: terraform-init
      if: github.event.pull_request.merged == true
      uses: hashicorp/terraform-github-actions/init@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

    - name: terraform-apply
      if: github.event.pull_request.merged == true
      uses: hashicorp/terraform-github-actions/apply@v0.4.4
      env:
        # secrets
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        GOOGLE_CREDENTIALS: ${{ secrets.GOOGLE_CREDENTIALS }}
        TF_ACTION_TFE_TOKEN: ${{ secrets.TF_ACTION_TFE_TOKEN }}
        # env
        TF_ACTION_WORKING_DIR: "."

Secretに忘れずにTerraform CloudとGCPプロバイダーのクレデンシャルを登録しておいてください。

これでPR時にinit,fmt,validate,planが実行され、マージしたらapplyも実行されます。

クレデンシャルが見つからないエラーとなる

このままこのアクションを動かすとplan実行時に以下のようなエラーが出ます。

Error: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

  on terraform.tf line 14, in provider "google":
  14: provider "google" ***

原因

tfファイルなどでTerraform Cloudをバックエンドとして指定する際、指定したワークスペースが存在しない場合は新たに作成されます。
そして、新規作成されたワークスペースの場合、Remote Operationsがデフォルトで有効となっています。

Remote Operationsとは、Terraform CLIからplanやapplyを実行することで実際の処理をリモートのインフラ上で行える仕組みで、現在はTerraform Cloudでのみサポートされています。

www.terraform.io

Remote Operationsでは環境変数はTerraform Cloudのワークスペース上で定義されたものが利用されます。
なのでGitHub ActionsのSecretを設定、環境変数に指定してもそれが利用されず、クレデンシャルが見つからないというエラーとなります。

対応

ワークスペースの設定でExecution Modeという項目があります。
これはRemote Operationsの有効/無効を切り替えられるもので、この項目をLocalに設定することでplanやapplyはローカル(GitHub Actions上)で実行され、tfstateはTerraform Cloudに保存されるようになります。

まとめ

以下2点を押さえておきましょう。

• Terraform CloudでのExecution ModeはデフォルトでRemoteになってる
• クレデンシャルをGitHub側のSecretから環境変数として渡す場合はExecution ModeをLocalに変更する

あと、パブリックなリポジトリでGitHub Actionsを使ってapplyを実行するのは推奨されていない*1のでこの辺も理解した上で利用しましょう。

以上です。

*1:https://www.terraform.io/docs/github-actions/actions/apply.html

さくらのクラウド対応版Terraformerがv0.8系になりました

先月リリースしたさくらのクラウド対応版Terraformerが本家のバージョンアップに追随してv0.8系になりました。

sacloud/v0.8.1のリリースページ:

github.com

以前のsacloud/terraformerについての記事:

febc-yamamoto.hatenablog.jp

sacloud/terraformer v0.8系での主な変更点

• Terraform v0.12系対応
• 不要な依存関係の出力を抑制

Terraform v0.12対応

これまではTerraform v0.11系のみ対応でv0.12系だと色々とエラーが出ていましたが、このバージョンからv0.12系に対応しました。

ただしv0.11系には非対応となりましたので、もしv0.11系を使いたい場合はterraformer v0.7系を利用する必要があります。

不要な依存関係の出力を抑制

v0.7系では依存関係のあるリソースへの参照が不要な場合でも出力されていました。

terraformer import sakuracloud --resource=serverと指定した場合の出力例:

# 不要なdataブロックの出力が行われてしまう

data "terraform_remote_state" "cdrom" {
  backend = "local"

  config {
    path = "../../../generated/sakuracloud/cdrom/terraform.tfstate"
  }
}

data "terraform_remote_state" "disk" {
  backend = "local"

  config {
    path = "../../../generated/sakuracloud/disk/terraform.tfstate"
  }
}

data "terraform_remote_state" "icon" {
  backend = "local"

  config {
    path = "../../../generated/sakuracloud/icon/terraform.tfstate"
  }
}

# ...

これがv0.8系ではきちんと出力を抑制してくれます。
(もちろん--resource=server,icon)などとした場合は出力してくれます。

これでかなり使い勝手がよくなったと思います。

ぜひご利用ください！

以上です。

cert-managerでさくらのクラウドDNSを使ってワイルドカード証明書を発行する

cert-managerのさくらのクラウド対応版

Kubernetes上で証明書の発行/更新の自動化を行えるcert-managerをフォークしてさくらのクラウド対応版をリリースしました。

github.com

これを利用することでさくらのクラウドDNSを利用して証明書の発行/更新が行えるようになります。

今回はこのさくらのクラウド対応版cert-managerを利用して証明書を発行する方法をご紹介します。

なお今回は現時点(2019/10/3)の最新版のv0.11.0-alpha.0を利用します。
v0.11系はまだalpha版となっており、今後細かな仕様変更などがあるかもしれない点には留意ください。

発行までの手順

以下のような流れとなります。

• さくらのクラウド対応版cert-managerのインストール
• さくらのクラウドAPIキーをSecretに格納
• Issuer or ClusterIssuerの作成
• Certificateリソースを作成して証明書を発行

準備しておくもの

• Kubernetesクラスタ
• kubectlコマンド
• helmコマンド
• さくらのクラウドAPIキー
• さくらのクラウドDNSへのゾーン登録

最後のさくらのクラウドDNSヘのゾーン登録ですが、証明書を発行したいドメインをさくらのクラウドDNSへあらかじめ登録しておくということです。
(レコードは登録しておかなくても構いません)

ゾーン登録後に表示されるDNSサーバに対して権限移譲を行うところまでは済ませておいてください。

manual.sakura.ad.jp

さくらのクラウド対応版cert-managerのインストール

Helm Chartを用意していますのでこちらを利用してインストールします。

helm init

まずはhelm initしておきます。
(以下はRBACが有効なクラスタでhelm initする場合の例です。)

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller

helm lsなどを実行してエラーが出ないことを確認しておきます。

もしError: could not find a ready tiller podが表示されたら少し待ちましょう。

cert-managerのインストール

まずCRDの作成とNameSpaceの作成を行い、その後helm installを実行します。

# CRDの登録
kubectl apply -f https://raw.githubusercontent.com/sacloud/cert-manager/sacloud/v0.11.0-alpha.0/deploy/manifests/00-crds.yaml

# NameSpaceの作成
kubectl apply -f https://raw.githubusercontent.com/sacloud/cert-manager/sacloud/v0.11.0-alpha.0/deploy/manifests/01-namespace.yaml

# sacloudリポジトリの追加
helm repo add sacloud https://sacloud.github.io/helm-charts/

# cert-managerのインストール
helm install --name cert-manager --namespace cert-manager --version v0.11.0-alpha.0 sacloud/cert-manager

これでcert-managerのインストールができました。

さくらのクラウドAPIキーをSecretに格納

次にcert-managerからさくらのクラウドDNSをAPIを通じて操作する際に利用するAPIキーをSecretとして作成します。

まず以下のようなyamlファイルを作成します。 (ここではsecret.yamlというファイル名にしました)

apiVersion: v1
kind: Secret
metadata:
  name: sakuracloud-dns
  namespace: cert-manager
type: Opaque
data:
  access-token: <BASE64エンコードしたAPIトークン>
  access-secret: <BASE64エンコードしたAPIシークレット>

APIキーのトークン/シークレットはBASE64エンコードした値に置き換えてください。
(BASE64エンコードはecho '<APIトークン>' | base64などのコマンドでOK)

その後kubectlで登録します。

kubectl apply -f secret.yaml

今回は後ほどClusterIssuerを利用するつもりですのでSecretのNameSpaceをcert-managerにしています。
ClusterIssuerではなくIssuerを利用する場合は適宜修正してください。

参考: https://docs.cert-manager.io/en/release-0.11/reference/clusterissuers.html

Issuer or ClusterIssuerの作成

次にIssuer、またはClusterIssuerを作成します。

参考: - https://docs.cert-manager.io/en/release-0.11/reference/issuers.html - https://docs.cert-manager.io/en/release-0.11/reference/clusterissuers.html

今回はClusterIssuerを作成します。

まず以下のようなyamlファイルを作成します。 (今回はissuer.yamlというファイル名にしました)

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: example-issuer
spec:
  acme:
    email: <メールアドレス>
    # ステージング
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # 本番
    #server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: example-issuer-account-key
    solvers:
      - dns01:
          sakuracloud:
            accessTokenSecretRef:
              name: sakuracloud-dns
              key: access-token
            accessSecretSecretRef:
              name: sakuracloud-dns
              key: access-secret

メールアドレスの部分は適宜修正してください。

その後kubectlで登録します。

kubectl apply -f issuer.yaml

これで証明書の発行を行う準備が整いました。続いて早速証明書の発行を行います。

Certificateリソースを作成して証明書を発行

以下のようなyamlファイルを作成します。
(今回はcert.yamlというファイル名にしました)

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
 name: example-tls
 namespace: default
spec:
  secretName: example-tls
  commonName: '*.<ゾーン名>'
  dnsNames:
    - '*.<ゾーン名>'
  issuerRef:
    name: example-issuer
    kind: ClusterIssuer    

ゾーン名の部分は各自で適切に置き換えてください。
例えばexample.comというゾーン名に対し*.hoge.example.comというワイルドカード証明書を発行する場合、spec.commonNameとspec.dnsNames[*]には*.hoge.example.comを指定します。

あとはkubectlで登録するだけです。

kubectl apply -f cert.yaml

確認

取得できているか確認してみます。

$ kubectl describe cert example-tls

Name:         example-tls
Namespace:    default
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"example-tls","namespace":"default"},"sp...
API Version:  cert-manager.io/v1alpha2
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-10-03T06:26:57Z
  Generation:          5
  Resource Version:    2951
  Self Link:           /apis/cert-manager.io/v1alpha2/namespaces/default/certificates/example-tls
  UID:                 ccde4ca9-e5a6-11e9-a60d-9ca3ba2833af
Spec:
  Common Name:  *.example.com
  Dns Names:
    *.example.com
  Issuer Ref:
    Kind:       ClusterIssuer
    Name:       example-issuer
  Secret Name:  example-tls
Status:
  Conditions:
    Last Transition Time:  2019-10-03T06:29:12Z
    Message:               Certificate is up to date and has not expired
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Not After:               2020-01-01T05:29:11Z
Events:
  Type    Reason        Age    From          Message
  ----    ------        ----   ----          -------
  Normal  GeneratedKey  2m44s  cert-manager  Generated a new private key
  Normal  Requested     2m43s  cert-manager  Created new CertificateRequest resource "example-tls-2800673269"
  Normal  Issued        29s    cert-manager  Certificate issued successfully

Eventsの部分にIssuedが表示されたら発行完了してます。

発行された証明書を確認してみます。

$ kubectl get secret 

apiVersion: v1
data:
  ca.crt: null
  tls.crt: ...
  tls.key: ...
kind: Secret
metadata:
  annotations:
    cert-manager.io/alt-names: '*.example.com'
    cert-manager.io/certificate-name: example-tls
    cert-manager.io/common-name: '*.example.com'
    cert-manager.io/ip-sans: ""
    cert-manager.io/issuer-kind: ClusterIssuer
    cert-manager.io/issuer-name: example-issuer
  creationTimestamp: "2019-10-03T06:26:57Z"
  name: example-tls
  namespace: default
  resourceVersion: "2949"
  selfLink: /api/v1/namespaces/default/secrets/example-tls
  uid: cd15196e-e5a6-11e9-a60d-9ca3ba2833af
type: kubernetes.io/tls

data.tls配下にBASE64エンコードされた証明書データが格納されているはずです。

これでワイルドカード証明書を発行することができました。

さくらのクラウド対応版cert-managerの利用上の注意

さくらのクラウド対応版のcert-managerはオリジナルのcert-manager v0.11系以降のみに対応予定です。
それ以前のバージョンには対応しませんのでご注意ください。

終わりに

さくらのクラウド対応版cert-managerを利用することで、さくらのクラウドDNSを用いてワイルドカード証明書の発行が行えます。
さくらのクラウド上でKubernetesを利用する場合などに便利だと思います。 ぜひご利用ください。

以上です。

Terraformerで既存のさくらのクラウド環境からリバースTerraformする

UPDATE: 2022-06 コメントでご指摘いただいたtypoを修正(from: resource= to resources=)

既に存在するリソースの情報からTerraformのコード(tfファイル + tfstateファイル)を生成できるterraformerというツールがあります。

github.com

このTerraformerをフォークしてさくらのクラウド対応を行ったものをリリースしました。

github.com

これを使えばさくらのクラウド上に存在するサーバやディスクなどのリソースからTerraformのコードを生成できます。

Terraformerとは

Terraformerとは前述の通り既存のリソースからTerraformのコードを生成してくれるツールです。
様々なプラットフォームに対応しており、現時点での最新版(0.7.9)では以下のようなものに対応しています。

• Google Cloud
• AWS
• OpenStack
• Kubernetes
• Github
• Datadog
• Cloudflare
• Logzio
• NewRelic

Terraformerの大まかな処理の流れは次の通りです。

• 1) 対象プラットフォームのAPIを呼ぶなどして実リソースの情報を取得
• 2) 取得したリソース毎にTerraformプロバイダーのRefresh(terraform refreshコマンド相当の処理)を実行
• 3) 得られたtfstateの情報からtfファイルを生成

1)と3)がTerraformer側で実装されており、2)はgRPCなどでTerraformプロバイダーの実行ファイルを利用する形になっています。 また、1)は対象プラットフォーム毎にプロバイダーという仕組み(インターフェース)で拡張できるようになっており、さくらのクラウド対応はこれを実装して行いました。

さくらのクラウド対応版Terraformer

さくらのクラウド対応版Terraformerを利用するには

• ローカルマシンにインストールする方法
• Dockerを利用する方法(推奨)

の2つの方法があります。

ローカルマシンにインストールする場合

terraformerコマンドとTerraform/Terraformプロバイダーそれぞれの実行ファイルをローカルマシンにダウンロードしておく必要があります。

それぞれバージョンに注意してダウンロードしてください。

• さくらのクラウド版terraformerコマンド: GitHubのリリースページからダウンロード
• Terraform: v0.11.12以降、かつ非v0.12以上
• さくらのクラウドTerraformプロバイダー: v1.16.4以降をダウンロードし~/.terraform.d/plugins/{darwin,linux}_amd64/に配置

なおterraformerの次のバージョンからTerraform v0.12対応される見込みです。 それまではTerraform v0.11系を利用しておくのが無難です(使えないこともないがエラーが出る箇所がいくつかある)。

バージョンに気をつけてダウンロードするのはなかなか大変なので次のDockerを利用する方法が推奨です。

Dockerを利用する場合(推奨)

さくらのクラウド対応版terraformerとTerraform/TerraformプロバイダーをセットにしたDockerイメージを公開しています。

https://hub.docker.com/r/sacloud/terraformer

以下のように利用します。

$ docker run -it --rm -v $PWD:/work sacloud/terraformer

さくらのクラウドAPIキーの指定

APIキーはコマンドラインオプション、または環境変数で指定します。

コマンドラインオプションで指定する場合は--token/--secretでAPIトークン/シークレットを指定します。

$ terraformer import sakuracloud --token=APIトークン --secret=APIシークレット --resources=server,disk,icon

環境変数の場合はSAKURACLOUD_ACCESS_TOKEN/SAKURACLOUD_ACCESS_TOKEN_SECRETを指定します。
(UsacloudやTerraformなどと同じ環境変数です)

$ export SAKURACLOUD_ACCESS_TOKEN=APIトークン
$ export SAKURACLOUD_ACCESS_TOKEN_SECRET=APIシークレット
$ terraformer import sakuracloud --resources=server,disk,icon

Dockerの場合は以下のような感じで指定します。

$ docker run -it --rm -v $PWD:/work -e SAKURACLOUD_ACCESS_TOKEN=APIトークン -e SAKURACLOUD_ACCESS_TOKEN_SECRET=APIシークレット sacloud/terraformer

使い方

基本的な使い方

対象となるリソースの種別を指定してterraformerコマンドを実行します。
例えばサーバを対象とする場合以下のように--resourcesオプション(または-r)を指定して実行します。

$ terraformer import sakuracloud --resources=server 

複数のリソース種別を対象にする場合は以下のように--resourcesオプションにカンマ区切りで指定します。

# サーバとディスクを対象にする場合
$ terraformer import sakuracloud --resources=server,disk

指定できるリソース種別はGitHubのREADME.mdを参照してください。

https://github.com/sacloud/terraformer#サポートしているリソース

またデフォルトではカレントディレクトリ配下にgenerated/sakuracloud/{リソース種別}/というディレクトリがリソース種別毎に作成され、その中にtfファイル/tfstateファイルが生成されます。(オプションで変更可能)

例として、シンプル監視を対象にコード生成した場合、以下のようなコードが生成されます。

# シンプル監視を対象にコード生成
$ terraformer import sakuracloud --resources=simpleMonitor

# 生成されたコードを確認
$ cat generated/sakuracloud/simpleMonitor/simple_monitor.tf
resource "sakuracloud_simple_monitor" "simpleMonitor-000-example" {
  description = "example"
  enabled     = true

  health_check {
    delay_loop     = "1800"
    host_header    = "example.usacloud.jp"
    path           = "/status"
    protocol       = "https"
    status         = "200"
  }

  notify_email_enabled = false
  notify_email_html    = false
  notify_slack_enabled = true
  notify_slack_webhook = "https://hooks.slack.com/services/xxx/xxxx/xxxx"
  target               = "example.usacloud.jp"
}

対象リソースを限定する場合

現在は対象リソースをIDで指定することでコード生成の対象リソースを限定できます。
--filterオプションにTerraformでのリソース種別+リソースのIDをコロン区切りで指定するようになっています。

# IDがid1,id2,id4のリソースのみを対象とする場合
$ terraformer import sakuracloud --resources=server --filter=sakuracloud_server=id1:id2:id4

利用上の注意

残念ながら一部の項目は入力専用となっており、Terraformerから生成できません。例えばサーバの管理者パスワードなどです。
このため、これらの項目については生成されたコードを手作業で修正する必要があります。

出力されない項目はこちらに一覧がありますのでこれを参考に修正してください。

https://github.com/sacloud/terraformer#サポートしない項目

これ以外にもいくつか注意事項がありますのでREADME.mdの利用上の注意を読んだ上でご利用ください。

https://github.com/sacloud/terraformer#利用上の注意

運用上の注意

前述の利用上の注意の通り、出力されない項目がいくつかある問題があるため、DNSレコードの管理やVPCルータの設定を管理するといったシンプルな用途以外は出力されたコードをそのまま実運用するのはなかなか難しいと思います。

出力されたコードは参考程度と割り切って利用するというのも手だと思います。 1からtfファイルを手作業で記載するよりは楽だと思いますのであくまでも道具の一つとしての利用がオススメです。

まとめ

既存のリソースからTerraformのコード生成を行えるTerraformerのさくらのクラウド対応版を紹介しました。
バージョンの縛りがあるためDockerから利用するのがオススメです。

また、いくつか出力されない項目があるなど利用上の注意点が結構あり、出力されたコードをそのまま実運用するというのは難しいです。
とはいえ1からtfファイルを書くより楽になると思いますので利用できる場面では便利にご利用いただけると思います。

ぜひ使ってみてください！

以上です。