作業メモ: TeamCity on さくらのクラウド+エンハンスドロードバランサ
JetBrainsのTeamCityをさくらのクラウド上に構築した時のメモです。
概要
構成
- サーバ1台(パケットフィルタ込み)
- エンハンスドロードバランサ(100cps プラン)
- SSL終端
- Let's Encryptでの証明書取得/更新
- TeamCityはDockerで起動
サーバ上で直接証明書取得 & SSL終端してもよかったのですが、環境構築がめんどくさかったのでエンハンスドロードバランサを利用します。
また、サーバへのアクセスはエンハンスドロードバランサに限定するためにパケットフィルタも合わせて利用します。
構築手順
- サーバ作成/Dockerインストール
- エンハンスドロードバランサ作成
- エンハンスドロードバランサで発行されたVIP or FQDNをDNS登録(A or CNAMEレコード)
- エンハンスドロードバランサの設定(待ち受けポート/実サーバ/Let's Encryptなど)
- パケットフィルタ作成 & サーバにアタッチ
- TeamCityをDocker上で起動
- TeamCityのエージェントをDocker上で起動
各手順の詳細
サーバ作成/Dockerインストール
まずはサーバを作成します。今回は2CPU/4GBメモリ/共有セグメントに接続、というスペックで作成しました。
サーバ作成後はDockerがインストールされていない場合はインストールしておきます。
エンハンスドロードバランサ作成
次にエンハンスドロードバランサを作成します。
VIPフェイルオーバ
を有効にする/しないでこの後作成するDNSレコードの種別が変わりますのでご注意ください。
エンハンスドロードバランサで発行されたVIP or FQDNをDNS登録(A or CNAMEレコード)
エンハンスドロードバランサを作成したらFQDN or VIPが払い出されます。この値をDNS登録しておきます。
前述の通りVIPフェイルオーバ
の有効/無効に応じて登録するDNSレコード種別が変わります。
VIPフェイルオーバを有効にした場合
FQDNが発行されますのでCNAMEレコードを登録します。
VIPフェイルオーバを無効にした場合:
VIP(Virtual IP Address)が発行されますのでAレコードを登録します。
エンハンスドロードバランサの設定
次にエンハンスドロードバランサの設定を行います。
待ち受けポート
以下のように2つ登録します。
(1) HTTP
- プロキシ方式:
http
- 待受ポート番号:
80
- httpsへのリダイレクト:
有効
(2) HTTPS
- プロキシ方式:
https
- 待受ポート番号:
443
- HTTP/2のサポート:
無効
実サーバ
IPアドレスに先ほど作成したサーバのIPを入力して登録します。
ポート番号は8111
、サーバグループは空のままとします。
Let's Encryptの設定
次に右上のSSH証明書の設定
-> Let's Encryptの設定
に進み、Let's Encryptでの証明書自動取得/更新を有効化します。
先ほどCNAMEレコードまたはAレコードを登録したFQDNを指定してください。 (エンハンスドロードバランサから払い出されたFQDNではありません)
パケットフィルタ作成 & サーバにアタッチ
次にサーバへのアクセスをエンハンスドロードバランサからだけに絞るためにパケットフィルタを作成してサーバにアタッチします。
まず、エンハンスドロードバランサが実サーバにアクセスする際のアクセス元IPレンジをメモしておきます。
エンハンスドロードバランサの詳細画面のプロキシ元ネットワーク
という項目です。
次にパケットフィルタを作成し、エンハンスドロードバランサからのアクセスだけ許可、以外は拒否するルールを設定します。
(この例では管理用にtcp/10022
ポートの許可を追加してます)
作成したらサーバの詳細画面からNICに対してパケットフィルタを接続(アタッチ)しておきましょう。サーバを起動したままでアタッチ可能です。
TeamCityをDocker上で起動
ようやくTeamCityのインストールです。 以下のマニュアルからDockerでのインストール周りへと辿ります。
余談ですが、日本語版マニュアルが
jetbrains.com
じゃなくてpleiades.io
なのが気になって調べたら↓↓が出てきました。
https://blog.jetbrains.com/jp/2018/10/18/1355
Pleiadesは昔大変お世話になりました。
今回は以下のように起動しました。
# bridgeネットワークを作成しておく $ docker network create teamcity # TeamCityサーバ起動 $ docker run -d --name teamcity-server-instance \ -v teamcity-data:/data/teamcity_server/datadir \ -v teamcity-log:/opt/teamcity/logs \ -p 8111:8111 \ --network teamcity \ jetbrains/teamcity-server
面倒だったのでDocker ComposeやKubernetesを使わずにDockerコマンドを直接使ってます。
TeamCityのエージェントをDocker上で起動
次にTeamCityのエージェントをDocker上で起動します。 (リスクのある方法ですので以下のドキュメントをちゃんと読んでおきましょう)
https://hub.docker.com/r/jetbrains/teamcity-agent/
今回は以下のように起動しました。
$ docker run -d --name teamcity-agent-01 \ -e SERVER_URL="http://teamcity-server-instance:8111" \ -e AGENT_NAME="agent-01" \ -v teamcity-agent-data:/data/teamcity_agent/conf \ --network teamcity \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /opt/buildagent/work:/opt/buildagent/work \ -v /opt/buildagent/temp:/opt/buildagent/temp \ -v /opt/buildagent/tools:/opt/buildagent/tools \ -v /opt/buildagent/plugins:/opt/buildagent/plugins \ -v /opt/buildagent/system:/opt/buildagent/system \ jetbrains/teamcity-agent
アクセスしてみる
ブラウザでAレコード or CNAMEレコードを登録したFQDNにアクセスするとTeamCityの画面が開くはずです。
あとは画面の指示/マニュアルを参考に進めていけばOKなはずです。
終わりに
今回はバックアップなど運用面をあまり気にしてませんので実運用の際はオプションの精査などをしっかり行ってください。
以上です。
TerraformのRKEプロバイダーをRancher Labsに移管しました
はじめに
Rancher Labsが提供するRKE(Rancher Kubernetes Engine)をTerraformから扱えるようにするRKEプロバイダーを私の個人リポジトリからRancher Labs配下へ移管しました。
移管によりこれまで以上にRKE本体との連携も進むでしょうし、今後はより一層安定してご利用いただけるようになりそうです。
TerraformのRKEプロバイダーって何?
こちらで紹介しています。
どんな人がRKEプロバイダーを使ってるの?
国外での利用が多いです。AWS(EC2)やAzure、OpenStack、vSphere、DigitalOceanとの組み合わせあたりでご利用いただくケースが多いです。
Rancher Labsが公開しているブログやYouTubeチャンネルなどで紹介されたこともあります。
以下のようなところで紹介されました。
Rancher Labsブログ
RanchCast(YouTube)
www.youtube.com (32:50秒あたりから)
Medium
使ってみた系記事: medium.com
RKEプロバイダーを組み込んだtk8というツール blog.kubernauts.io
これからRKEプロバイダーはどうなるの?
私は開発から一歩引き、今後はRancher Labs主導で開発が進められます。
Rancher LabsにはすでにRancher2プロバイダーがあり、一見RKEプロバイダーと機能的に重複して見えますが 利用シーンが異なるためある程度コードベースの統合はあってもプロバイダー自体は独立して開発が続くのではないかと思っています。
ちょうどそろそろRKEもv1.0に到達しようとしています。
(2019/11/18現在はv1.0.0-rc5までリリースされています)
これに追随してRKEプロバイダーもバージョンアップしていくのではないかと期待しています。
終わりに
Rancher Labs主導で開発が行われることでより安心して利用できるようになると思います。
ぜひご利用ください!
RancherによるKubernetes活用完全ガイド (Think IT Books)
- 作者: 市川豊,藤原涼馬,西脇雄基
- 出版社/メーカー: インプレス
- 発売日: 2019/07/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Terraformからウェブアクセラレータの証明書を管理する
Terraformからウェブアクセラレータを参照/一部の操作ができるように
Terraformのさくらのクラウドプロバイダー v1.18.1からウェブアクセラレータ向けのリソースが追加されました。
sakuracloud_webaccel
: サイト情報を参照するためのデータソースsakuracloud_webaccel_certificate
: サイトに登録する証明書リソース
sakuracloud_webaccel
データソース
サイト情報を参照するためのものです。
名前 or ドメインを指定して対象サイトの情報を参照できます。
以下のようなtfファイルで利用します。
data sakuracloud_webaccel "example" { domain = "www.example.com" # または # name = "example" }
以下のような情報が参照可能です。
$ terraform show data "sakuracloud_webaccel" "example" { cname_record_value = "xxxxxx.user.webaccel.jp." domain = "www.example.com" domain_type = "own_domain" has_certificate = true id = "xxx" name = "example" origin = "192.0.2.1" site_id = "xxx" status = "enabled" subdomain = "xxxxx.user.webaccel.jp" txt_record_value = "webaccel=xxxxx.user.webaccel.jp" }
利用例: サイト有効化に必要なDNSレコードの登録
ウェブアクセラレータでは独自ドメイン利用時にCNAMEまたはTXTレコードの設定が必要になります。
このデータソースはそのための値を持っており、以下のようにすることでレコードの登録が簡単に行えます。
data sakuracloud_webaccel "example" { domain = "www.example.com" } data sakuracloud_dns "zone" { name_selectors = ["example.com"] } # webaccelデータソースの値を参照してDNSレコード登録 resource "sakuracloud_dns_record" "webaccel" { dns_id = sakuracloud_dns.zone.id name = "www" type = "CNAME" value = data.sakuracloud_webaccel.example.cname_record_value }
証明書の登録/更新が行えるsakuracloud_webaccel_certificate
リソース
以下のようなコードで証明書の登録/更新が行えるようになりました。
data sakuracloud_webaccel "site" { name = "example" } resource sakuracloud_webaccel_certificate "example" { site_id = data.sakuracloud_webaccel.site.id certificate_chain = file("crt") private_key = file("key") }
応用例: TerraformのACMEプロバイダーと組み合わせる
ウェブアクセラレータに登録する証明書をTerraformのACMEプロバイダーを用いてLet's Encryptで取得してみます。
今回はDNSを用いて取得します。ACMEプロバイダーではDNSプロバイダーとしてさくらのクラウドDNSがサポートされていますのでこちらを利用します。
コードは以下のようになります。
data sakuracloud_webaccel "site" { name = "example" } resource sakuracloud_webaccel_certificate "foobar" { site_id = data.sakuracloud_webaccel.site.id certificate_chain = "${acme_certificate.cert.certificate_pem}${acme_certificate.cert.issuer_pem}" private_key = acme_certificate.cert.private_key_pem } provider "acme" { # レートリミットに注意 server_url = "https://acme-v02.api.letsencrypt.org/directory" } resource "tls_private_key" "private_key" { algorithm = "RSA" } resource "acme_registration" "reg" { account_key_pem = "${tls_private_key.private_key.private_key_pem}" email_address = "nobody@example.com" #自分のメールアドレスに置き換える } resource "acme_certificate" "cert" { account_key_pem = "${acme_registration.reg.account_key_pem}" common_name = "www.example.com" # 任意のドメインに変更 subject_alternative_names = ["www2.example.com"] # 任意のドメインに変更 dns_challenge { provider = "sakuracloud" config = { # APIキーを環境変数から指定する場合は以下2つの指定は不要 # SAKURACLOUD_ACCESS_TOKEN = "APIトークン" # SAKURACLOUD_ACCESS_TOKEN_SECRET = "APIシークレット" SAKURACLOUD_PROPAGATION_TIMEOUT = "300" } } }
あとは定期的にterraform apply
するようにすれば良いでしょう。
終わりに
ぜひご利用ください!
さくらのクラウドでUbuntuのクラウドイメージ+cloud-initを利用する
はじめに
さくらのクラウド上でUbuntuの「クラウドイメージ」を利用する機会がありましたので方法をまとめておきます。
手順
順番にみていきます。
Ubuntuのクラウドイメージの準備
cloud-initが構築済みの「クラウドイメージ」というものがUbuntuで提供されています。
今回はこれを利用します。ただし、さくらのクラウドは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でのみサポートされています。
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のでこの辺も理解した上で利用しましょう。
以上です。
さくらのクラウド対応版Terraformerがv0.8系になりました
先月リリースしたさくらのクラウド対応版Terraformerが本家のバージョンアップに追随してv0.8系になりました。
sacloud/v0.8.1のリリースページ:
以前のsacloud/terraformerについての記事:
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をフォークしてさくらのクラウド対応版をリリースしました。
これを利用することでさくらのクラウドDNSを利用して証明書の発行/更新が行えるようになります。
今回はこのさくらのクラウド対応版cert-managerを利用して証明書を発行する方法をご紹介します。
なお今回は現時点(2019/10/3)の最新版のv0.11.0-alpha.0
を利用します。
v0.11系はまだalpha版となっており、今後細かな仕様変更などがあるかもしれない点には留意ください。
発行までの手順
以下のような流れとなります。
- さくらのクラウド対応版cert-managerのインストール
- さくらのクラウドAPIキーを
Secret
に格納 Issuer
orClusterIssuer
の作成Certificate
リソースを作成して証明書を発行
準備しておくもの
最後のさくらのクラウドDNSヘのゾーン登録ですが、証明書を発行したいドメインをさくらのクラウドDNSへあらかじめ登録しておくということです。
(レコードは登録しておかなくても構いません)
ゾーン登録後に表示されるDNSサーバに対して権限移譲を行うところまでは済ませておいてください。
さくらのクラウド対応版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を利用する場合などに便利だと思います。
ぜひご利用ください。
以上です。