作業メモ: TeamCity on さくらのクラウド+エンハンスドロードバランサ

JetBrainsのTeamCityをさくらのクラウド上に構築した時のメモです。

www.jetbrains.com

概要

構成

f:id:febc_yamamoto:20191218174908p:plain:w500

  • サーバ1台(パケットフィルタ込み)
  • エンハンスドロードバランサ(100cps プラン)
    • SSL終端
    • Let's Encryptでの証明書取得/更新
  • TeamCityはDockerで起動

サーバ上で直接証明書取得 & SSL終端してもよかったのですが、環境構築がめんどくさかったのでエンハンスドロードバランサを利用します。
また、サーバへのアクセスはエンハンスドロードバランサに限定するためにパケットフィルタも合わせて利用します。

構築手順

  • サーバ作成/Dockerインストール
  • エンハンスドロードバランサ作成
  • エンハンスドロードバランサで発行されたVIP or FQDNDNS登録(A or CNAMEレコード)
  • エンハンスドロードバランサの設定(待ち受けポート/実サーバ/Let's Encryptなど)
  • パケットフィルタ作成 & サーバにアタッチ
  • TeamCityをDocker上で起動
  • TeamCityのエージェントをDocker上で起動

各手順の詳細

サーバ作成/Dockerインストール

まずはサーバを作成します。今回は2CPU/4GBメモリ/共有セグメントに接続、というスペックで作成しました。
サーバ作成後はDockerがインストールされていない場合はインストールしておきます。

エンハンスドロードバランサ作成

次にエンハンスドロードバランサを作成します。
VIPフェイルオーバを有効にする/しないでこの後作成するDNSレコードの種別が変わりますのでご注意ください。

f:id:febc_yamamoto:20191218180325p:plain:w800

エンハンスドロードバランサで発行されたVIP or FQDNDNS登録(A or CNAMEレコード)

エンハンスドロードバランサを作成したらFQDN or VIPが払い出されます。この値をDNS登録しておきます。
前述の通りVIPフェイルオーバの有効/無効に応じて登録するDNSレコード種別が変わります。

VIPフェイルオーバを有効にした場合

FQDNが発行されますのでCNAMEレコードを登録します。

f:id:febc_yamamoto:20191218181219p:plain

VIPフェイルオーバを無効にした場合:

VIP(Virtual IP Address)が発行されますのでAレコードを登録します。

f:id:febc_yamamoto:20191218194905p:plain

エンハンスドロードバランサの設定

次にエンハンスドロードバランサの設定を行います。

待ち受けポート

以下のように2つ登録します。

f:id:febc_yamamoto:20191218181817p:plain:w800

(1) HTTP
  • プロキシ方式: http
  • 待受ポート番号: 80
  • httpsへのリダイレクト: 有効
(2) HTTPS
  • プロキシ方式: https
  • 待受ポート番号: 443
  • HTTP/2のサポート: 無効

実サーバ

IPアドレスに先ほど作成したサーバのIPを入力して登録します。
ポート番号は8111、サーバグループは空のままとします。

f:id:febc_yamamoto:20191218182449p:plain:w800

Let's Encryptの設定

次に右上のSSH証明書の設定 -> Let's Encryptの設定に進み、Let's Encryptでの証明書自動取得/更新を有効化します。

f:id:febc_yamamoto:20191218182754p:plain:w800

先ほどCNAMEレコードまたはAレコードを登録したFQDNを指定してください。 (エンハンスドロードバランサから払い出されたFQDNではありません)

パケットフィルタ作成 & サーバにアタッチ

次にサーバへのアクセスをエンハンスドロードバランサからだけに絞るためにパケットフィルタを作成してサーバにアタッチします。

まず、エンハンスドロードバランサが実サーバにアクセスする際のアクセス元IPレンジをメモしておきます。
エンハンスドロードバランサの詳細画面のプロキシ元ネットワークという項目です。

f:id:febc_yamamoto:20191218183630p:plain:w800

次にパケットフィルタを作成し、エンハンスドロードバランサからのアクセスだけ許可、以外は拒否するルールを設定します。
(この例では管理用にtcp/10022ポートの許可を追加してます)

f:id:febc_yamamoto:20191218183827p:plain:w800

作成したらサーバの詳細画面からNICに対してパケットフィルタを接続(アタッチ)しておきましょう。サーバを起動したままでアタッチ可能です。

TeamCityをDocker上で起動

ようやくTeamCityのインストールです。 以下のマニュアルからDockerでのインストール周りへと辿ります。

pleiades.io

余談ですが、日本語版マニュアルが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の画面が開くはずです。

f:id:febc_yamamoto:20191218191231p:plain:w800

あとは画面の指示/マニュアルを参考に進めていけばOKなはずです。

終わりに

今回はバックアップなど運用面をあまり気にしてませんので実運用の際はオプションの精査などをしっかり行ってください。

以上です。

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

f:id:febc_yamamoto:20191118145250p:plain

はじめに

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)

RancherによるKubernetes活用完全ガイド (Think IT Books)

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

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

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

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クラウドイメージの準備

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

gihyo.jp

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

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

qemu-imgコマンドについてはyum install qemu-imgapt 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 ModeLocalに変更する

最初に: やりたいこと

このために、リポジトリ上で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_TOKENGOOGLE_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からplanapplyを実行することで実際の処理をリモートのインフラ上で行える仕組みで、現在はTerraform Cloudでのみサポートされています。

www.terraform.io

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

対応

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

f:id:febc_yamamoto:20191010204044p:plain

まとめ

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

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

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

以上です。

さくらのクラウド対応版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版となっており、今後細かな仕様変更などがあるかもしれない点には留意ください。

発行までの手順

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

準備しておくもの

最後のさくらのクラウド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からさくらのクラウドDNSAPIを通じて操作する際に利用する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.commonNamespec.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を利用する場合などに便利だと思います。 ぜひご利用ください。

以上です。