19
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

【2019年6月版】Terraform+Spinnakerがよくね!? → もはや沼。

Posted at

GKE + Spinnaker のデプロイを Terraform で行ってみた。2か月ぶりに。

以前のこちらの記事「【2019年4月版】Terraform+Spinnakerがよくね!? → 闇が深い。」で作成した Terraform のスクリプトを2か月ぶりに実行してみたのですが・・・Terraformがバージョンアップしてたり**GKEのバージョンアップ?**などあったりして、まったく動かなくなっておりました。

特に、Spinnaker本家サイトの構築手順が現時点では構築できない手順になっておりましたので要注意です。

対象環境

  • OS : Ubuntu 18.04 LTS
  • Terraform : 0.12.2 !!
  • Terraform : 0.12.2 !!
  • Terraform : 0.12.2 !!
  • GCP Provider : 2.8
  • Kubernetes Provider : 1.6.1

Terraform が 0.11 から 0.12 に上がりました。0.x 系での破壊的更新はアリですけど!アリですけど!

・・・以下に修正箇所を上げます。

Terrform 0.11 から 0.12 へのマイグレーション

こちらの本家ページ「Upgrading to Terraform v0.12」にもありますが、以下のコマンドで設定ファイルをコンバートしてくれます。

$ terraform 0.12checklist

$ terraform 0.12upgrade

変数や式の書き方がだいぶわかりやすくなりましたね。というか、基本的に ${...} は書かなくてもOKになりましたね。

Google Kubernetes クラスタ から Kubernetes Provider への接続情報

以下のようになります。

data "google_client_config" "default" {}

provider "kubernetes" {
  host = google_container_cluster.gke.endpoint
  cluster_ca_certificate = base64decode(
    google_container_cluster.gke.master_auth[0].cluster_ca_certificate,
  )
  token   = data.google_client_config.default.access_token
  version = "~> 1.6.2"
}

前回のmaster_authを使った認証は全滅でした。全く接続できなくなっておりました。
google_client_config.default.access_tokenトークンでしか、アクセスできませんでした。

Connection リソースの host 指定が必須

Remote-exec Provider や File Provider で大活躍の Connection リソースですが、host の指定が必須になりました。そこ、自動でやってくれるから便利だったのにさ・・・

作成した vm インスタンスにsshでコマンド投げる場合は以下のようになります。

resource "google_compute_instance" "instance-1" {
    name         = "small-instance-1"
    machine_type = "g1-small"
    zone         = "us-cental1-a"
...
  provisioner "remote-exec" {
    inline = [
      "KUBECTL_LATEST=$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)",
      "curl -LO https://storage.googleapis.com/kubernetes-release/release/$KUBECTL_LATEST/bin/linux/amd64/kubectl",
      "chmod +x kubectl",
      "sudo mv kubectl /usr/local/bin/kubectl",
      ....
    ]
    connection {
      host        = self.network_interface.0.access_config.0.nat_ip
      type        = "ssh"
      user        = var.gcp_account_name
      private_key = file("path/to/rsa/private")
      timeout     = "5m"
    }
}

このように、GCE のインスタンスに接続する場合は self.network_interface.0.access_config.0.nat_ip を接続先とします。

ちなみに、この値は上記の terraform 0.12upgrade では補完してくれませんので自分でその都度、確認する必要あります。

kubenetes_secret.data がブロックからマップに変更

以前は以下のような書き方をしていたkubenetes_secret.dataプロパティですが・・・

resource "kubernetes_secret" "example" {
  metadata {
    name = "basic-auth"
  }

  data {
    username = "admin"
    password = "P4ssw0rd"
  }

  type = "kubernetes.io/basic-auth"
}

マップ になって以下のように = を挟むようになってます。

  data = {
    username = "admin"
    password = "P4ssw0rd"
  }

本家のリファレンスを見ても0.11までの書き方だし、エラーメッセージもよくわからないので、かなりハマりました。

他にもブロックからマップになったプロパティ、あるんじゃないだろうか・・・

Spinnaker のインストール手順がダメ

その1

上記にも上げました Spinnaker 公式サイトの以下の手順で・・・

$ GKE_CLUSTER_NAME={YOUR_GKE_CLUSTER_NAME}
$ GKE_CLUSTER_ZONE={YOUR_GKE_CLUSTER_ZONE}

$ gcloud config set container/use_client_certificate true

$ gcloud container clusters get-credentials $GKE_CLUSTER_NAME \
    --zone=$GKE_CLUSTER_ZONE

gcloud config set container/use_client_certificate trueやっちゃダメです

以下のように set container/use_client_certificate true を抜いた、

$ GKE_CLUSTER_NAME={YOUR_GKE_CLUSTER_NAME}
$ GKE_CLUSTER_ZONE={YOUR_GKE_CLUSTER_ZONE}

$ gcloud container clusters get-credentials $GKE_CLUSTER_NAME \
    --zone=$GKE_CLUSTER_ZONE

が正解です。

ちなみに、gcloud config set container/use_client_certificate true を実施すると・・・

$ gcloud config set container/use_client_certificate true

$ gcloud container clusters get-credentials $GKE_CLUSTER_NAME \
    --zone=$GKE_CLUSTER_ZONE
Fetching cluster endpoint and auth data.
ERROR: (gcloud.container.clusters.get-credentials) get-credentials requires edit permission on プロジェクト名

と素っ気ない返事が返ってきます。たとえオーナー権限を持つサービスアカウントを使ったとしてもこのエラーメッセージは揺るぎません。

その2

もはや些細なことですがhal deploy apply はエラーとなり、以下で動きます。

$ sudo hal deploy apply

はい、sudoが必要です。。。

以上!

19
16
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?