Tech

Google Domains が事業売却されるという話から約半年、重い腰をあげてついに我が家のドメインも Cloudflare に移行対応しました。 半年も経てば Cloudflare への移行手順は多くの記事で紹介されているので、今回は Cloudflare 移行に伴って発生した自宅ラボで使っている cert-manager の移行対応を記録しておきます。 なぜドメイン移行先を Cloudflare にしたのか このブログでも使っている nnstt1.dev というドメインは Google Domains で購入していましたが、ネームサーバーを設定してレコードの管理自体は Azure DNS でおこなっていました。 Azure DNS で管理しているなら Azure 自体でドメインを購入すればいいじゃないかと思ったのですが、Azure でドメインを購入するサービスの App Service ドメインでは com、net、co.uk、org、nl、in、biz、org.uk、co.in のトップレベルドメイン (TLD) しか対応していなかったため、.dev ドメインは別のサービスを利用するしかありませんでした。 （そもそも Google Domains にしたのも Azure が .dev に対応してなかったからなのに、今回も移行できないか確認してしまったという…） というわけで他のドメインサービスを探すことになったのですが、おネームドットコムは論外ということ以外は特にこだわりはありませんでした。 半年前でもそうでしたが、やっぱり Cloudflare が移行先として人気のようで、右にならえで自分も Cloudflare に移行することにしました。 移行自体はすんなり完了したのと、レコード自体の管理も Terraform を使うようにしました。 cert-manager の対応 自宅ラボの Kubernetes クラスタでは証明書管理のための cert-manager を使っています。 クラスタで（自宅内に閉じて）公開しているサービスの証明書を Let’s Encrypt で発行していますが、そのためにはドメインの検証が必要になります。 検証の方法は 2 つあって、Let’s Encrypt から対象ドメインを使っているサービスにアクセスする HTTP Validation と、DNS に指定の TXT レコードを作成する DNS Validation があります。 ...

普段プライベートでは Terraform Cloud は Azure のリソース（このブログの Static Apps や自宅ラボと連携しているサービス）を管理するために使ってます。 最近 Terraform Cloud を触る、というかドキュメントを読み漁る機会があって、この機会に Terraform Cloud Operator for Kubernetes を自宅ラボに入れてみるかぁ、となったのでやってみました。 ちなみに最近アップデートされた v2 のほうです。 HCP Terraform Operator for Kubernetes overview | Terraform | HashiCorp Developer The HCP Terraform Operator for Kubernetes allows you to provision infrastructure directly from the Kubernetes control plane. developer.hashicorp.com Terraform Cloud Operator for Kubernetes は長すぎるので、以降 TFC Operator と記載します。 TFC Operator は何ができるの？ TFC Operator はカスタムリソースを使って Terarform Cloud のワークスペースやモジュール、そしてエージェントプールを Kubernetes のリソースとして管理することができます。 ...

おうち K8s クラスタで HashiCorp Vault を動かしているのですが、Pod が再起動すると Vault が Seal 状態となってしまうので都度 Unseal Key を入力しています。 そろそろ煩わしさが限界なので Azure Key Vault と連携して Vault の Auto Unseal 機能を使ってみます。 Auto Unseal 設定 Auto Unseal を使うためには以下の設定が必要になります。 Entra ID サービスプリンシパル Azure Key Vault Vault Config サービスプリンシパル Microsoft Entra ID に Vault の Auto Unseal で使用するサービスプリンシパルを作成します。 私の環境では Dynamic Secrets 用の Vault サービスプリンシパルを作成済みなので今回はこちらを流用します。 Vault サービスプリンシパルのシークレットは Vault がローテーションしてくれるのですが、Auto Uneal は Vault の設定ファイルに直接サービスプリンシパルのシークレットを記述する形式です。 そのため、サービスプリンシパルにもローテーションされない（有効期限を設定している）シークレットを作成します。 もしかしたら Auto Unseal 用のサービスプリンシパルを別途作成するのが安牌かもしれません。 Azure Key Vault Azure Key Vault を用意して Auto Unseal 時に使用されるキー（今回は generated-key という名前）を作成します。 そして、Vault サービスプリンシパルがシークレットを参照できるように組み込みロール Key Vault Secrets User を設定します。 ...

はじめに 今年の夏も酷暑続きでしたねー。 仕事が忙しくて自宅ラボに触る時間もなかったり、マシンの熱が心配なのもあって夏の間は自宅ラボの電源を落としてたり、ということもあり前回の投稿から 4 ヶ月も空いてしまいました。 忙しさのピークも一段落して季節も秋に変わってきたので、また自宅ラボという名の盆栽いじりを再開してます。 前回の投稿では、cert-manager を使って Ingress 用の証明書を発行するようにしました。 Let’s Encrypt の ACME DNS-01 チャレンジ用に cert-manager が Azure DNS に TXT レコードを作成してくれます。 このとき、cert-manager は Microsoft Entra ID のサービスプリンシパルを使います。 サービスプリンシパルのクライアントシークレットは有効期限が最大でも 2 年間 (24 ヶ月) なので、HashiCorp Vault と Vault Secrets Operator を使ってクライアントシークレットを動的に生成して、クライアントシークレットの有効期限を意識せずにサービスプリンシパルを使えるようにします。 自宅ラボ用途なので 2 年間でもいいっちゃいいんですがね。 全体像 今回は色々なサービスが連携していて流れが分かりづらいため、最初に全体像を把握します。 シーケンス図のほうが分かりやすかったかも？ サービスプリンシバルを含め、Secret リソース以外は事前に作成しておきます。 今回の投稿でメインになってくるのは Vault と Vault Secrets Operator (VSO) です。 サービスプリンシバル あらかじめ Vault 用と cert-manager 用のサービスプリンシバルを作成しておきます。 cert-manager サービスプリンシバルは前回作成したものを使います。 Vault サービスプリンシバルも同様に作成したあと、他のサービスプリンシバルを操作するためのアクセス許可を設定します。 必要なものは以下の 2 つです。 ...

はじめに 久しぶりの個人ブログへの投稿です。 4月に転職してから会社ブログのほうに投稿する機会ができた結果、個人ブログのほうが疎かになってしまいました。 仕事でもプライベートでもやってること大体同じなんで投稿ネタがなくなるよね……。 というわけで、しばらく個人ブログのほうは自宅ラボという盆栽のお手入れ内容をメインに扱っていきます。 身の上話はここらへんにしておいて、今回は kube-vip というツールを使って、盆栽（おうち K8s クラスタ）用に構築していたロードバランサを削除した話です。 どうしてロードバランサを無くしたいの？ 我が家の K8s クラスタは、Proxmox VE を使った仮想基盤上の VM で動いていました。 物理は NUC と DeskMini の2台構成です。 かつてラズパイを使った Ceph クラスタを Rook から使っていましたが、不安定極まりないためラズパイをコントロールプレーンとして転生させました。 この時点で以下のような構成でしたが、VM を使わずに K8s クラスタを作りたいという思いを捨てきれず、現在は3台目のマシンをお迎えして絶賛移行中です。 用途 種別 台数 コントロールプレーン ラズパイ 3 ワーカー VM 3 ロードバランサ VM 2 ロードバランサは kube-apiserver 用に作成したものです。 kubeadm の高可用性クラスタを作る際のドキュメントにも記載があります。 DNS に Keepalived 用の VIP を A レコードとして登録して、クラスタ外からアクセスするのに使っています。 K8s クラスタを物理だけで動かそうとしたとき、このロードバランサがネックになりました。 手持ちのラズパイ3台はすでにコントロールプレーンとして使ってますし、ワーカー用の筐体もやっと3台揃えたところです。 ロードバランサとして使える余剰筐体は我が家にはありません。 高可用性である必要があるの？と思われるかもしれませんが、それはアレですよ、“ロマン” ですよ。 というわけで、今の手持ちで物理 K8s クラスタを作るためにも、以下の要件を満たす方法を検討しました。 ロードバランサ用のマシンは使わない 高可用性は維持する kube-vip を使ってみる 元々ロードバランサ@VM は RHEL に Keepalived と HAProxy を入れてアクティブ/スタンバイの構成としていました。 ロードバランサを無くすに当たって、最初はコントロールプレーンに直接 Keepalived を入れようとしましたが、うまくサービスが上がってこず原因調査で時間を溶かしていました。 ...

はじめに 前回の投稿で Google Domains で購入したドメインを Azure DNS に委任しました。 今回は cert-manager というツールを使って、自宅ラボの Kubernetes クラスタで LAN に公開している Ingress 用の証明書を発行します。 証明書は Let’s Encrypt に署名してもらうのですが、Let’s Encrypt がドメインの所有をチェックするために Azure DNS を使って「DNS01 チャレンジ」を突破します。 ドメインの所有のチェック方法として「HTTP01 チャレンジ」もありますが、こちらはインターネットからアクセス可能なエンドポイントを用意する必要があるため、インターネットに非公開の自宅ラボでは使えません。 今までも cert-manager を使って nnstt1.home という独自ドメインの自己署名証明書を発行していたのですが、ブラウザの警告を回避するためのルート証明書の設定が面倒でした。 そこで、nnstt1.dev のサブドメイン home.nnstt1.dev に対して証明書を発行（署名）してもらって、自宅ラボでも警告なしで使えるようにします。 手順の流れは以下です。 Azure にサービスプリンシパル作成する Kubernetes クラスタに Issuer / Certificate リソースを作成して証明書を発行する Ingress で証明書を使ってサービスを公開する なお、前提として Kubernetes クラスタには既に cert-manager がインストールされているものとして手順を記載しています。 サービスプリンシパル作成 AKS では ID 管理がより楽な「マネージド ID」を使うことができますが、自宅クラスタなので「サービスプリンシパル」を使用します。 はじめに、サービスプリンシパル名などの変数を設定します。 $ AZURE_CERT_MANAGER_NEW_SP_NAME=home-lab-cert-manager $ AZURE_DNS_ZONE_RESOURCE_GROUP=home-lab $ AZURE_DNS_ZONE=nnstt1.dev サービスプリンシパルを作成して、アプリケーション ID などの情報を変数に格納します。 $ DNS_SP=$(az ad sp create-for-rbac --name $AZURE_CERT_MANAGER_NEW_SP_NAME --output json) $ AZURE_CERT_MANAGER_SP_APP_ID=$(echo $DNS_SP | jq -r '.appId') $ AZURE_CERT_MANAGER_SP_PASSWORD=$(echo $DNS_SP | jq -r '.password') $ AZURE_TENANT_ID=$(echo $DNS_SP | jq -r '.tenant') $ AZURE_SUBSCRIPTION_ID=$(az account show --output json | jq -r '.id') 作成したサービスプリンシパルは「共同作成者」のロールが割り当てられているので、セキュリティ向上のために「共同作成者」は削除して、代わりに「DNS ゾーン共同作成者」を割り当てます。 ...

はじめに 本ブログは Azure の Azure Static Web Apps という PaaS でホスティングしています。 今までは Azure Portal で画面ポチポチしながら設定変更していましたが、なにかあったときに備えてリソースを Terraform で管理するようにします。 いわゆる Infrastructure as Code です。 今回は Azure Static Web Apps の既存リソースを Terraform 構成ファイルに落とし込んで、Terraform 自体を Terraform Cloud に管理してもらう形にします。 どちらかと言うと Terraform Cloud を使う方便だったり。 Azure Static Web Apps 既存リソースの Terraform 化 まず、Azure Static Web Apps のリソースを Terraform で管理できるように構成ファイルを作成します。 事前にプロバイダの設定ファイルを作成してから terraform init しておきます。 terraform { required_version = ">= 0.12" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } provider "azurerm" { features {} } そして、staticsite.tf ファイルにリソースの箱だけ用意しておきます。 Azure Static Web Apps のリソースはサイト本体を管理する [azurerm_static_site] と、サイトアクセスに利用するカスタムドメインを管理する [azurerm_static_site_custom_domain] の2種類です。 ...

Podman Desktop がリリースされたので Windows にインストールしました。 インストールしただけです。 Podman Desktop とは Publickey さんの記事にすべて書かれてます。 GUIでDockerコンテナのビルドやPodsのKubernetesへの展開を可能にする「Podman Desktop」が登場。新たなDocker Desktop対抗となるか GUIでDockerコンテナやKubernetesの操作を可能にするオープンソースの「Podman Desktop」がリリースされたことをRed Hatが発表しました。Windows、Mac、Linuxに対応します。 Install, co... www.publickey1.jp インストール Podman Desktop 公式ページ に MacOS, Windows, Linux の各環境向けインストールマニュアルがあります。 今回は Windows 向けマニュアルを参照しました。 前提条件に「Hyper-V が有効化されていること」と「WSL2 がインストールされていること」とありますが、今回は両方ともインストール済みだったので省略します。 マニュアルによると Podman Desktop からそれぞれインストールできるようです。 Podman Desktop ダウンロードページ から .exe ファイルをダウンロードします。 バージョンは v0.9.1 でした。 ダウンロードした .exe を起動すると、匿名で情報収集してよいかと聞かれます。 任意ですがこころよく OK します。 Podman Desktop のダッシュボードが表示されますが、Podman が見つからないと表示されました。 この Windows には Podman 自体もインストールしていませんでした。 [Install] ボタンを押すと Podman をインストールするか聞かれます。 今回はバージョン v4.3.0 でした。 ...

前回の投稿で、Terraform を使って AKS で AGIC を動かす際のハマりポイントを紹介しました。 その際はマネージド ID の権限周りの設定がうまくできていなかったのですが、解決方法がわかったので改めて Terrafrom で AKS と AGW をデプロイする書き方を整理します。 デプロイパターン まず、AGIC から使う前提の AGW を Terraform でデプロイするパターンとしては以下の 2 つが考えられます。 AKS と AGW を個別にデプロイ AKS デプロイ時に AGW も作成 それぞれについて、Terraform の書き方とデメリットについて説明します。 前提条件として、以下のリソースは既に存在しているものとします。 リソースグループ VNet AKS 用 サブネット AGW 用 サブネット AKS と AGW を個別にデプロイ PIP AKS と AGW を個別にデプロイするパターンでは、Public IP も作成する必要があります。 resource "azurerm_public_ip" "pip" { name = local.pip_name resource_group_name = azurerm_resource_group.rg.name location = azurerm_resource_group.rg.location allocation_method = "Static" sku = "Standard" } AGW 次に、PIP に依存する形で AGW を作成します。 今回作成する AGW では、HTTP で受けたリクエストを HTTPS へリダイレクトさせます。 redirect_configuration ブロックでリダイレクト先の HTTPS リスナーを指定し、request_routing_rule ブロックの HTTP ルーティング規則 でリダイレクト設定を指定します。 ...

Terraform を使って Azure Kubernetes Service (AKS) で AGIC を動かす機会があったので、ハマりポイントを記録しておきます。 AGIC とは Application Gateway Ingress Controller (AGIC) は、Azure ネイティブの L7 ロードバランサ Application Gateway を利用した AKS で動作する Ingress Controller です。 AGIC を使うことで、AKS で Application Gateway の機能（URL ルーティングや TLS 終端）を使うことができます。 また、AKS クラスタ外の Application Gateway がオートスケールするため、トラフィックの増減に対してクラスタでのリソース消費がありません。 この機能を使うためには、Azure に AKS と Application Gateway、そして Public IP のリソースをデプロイする必要があります。 Terraform から Application Gateway を作成する方法として 2 パターンあります。 Application Gateway と Public IP のリソースタイプを指定する AKS のリソースタイプで Application Gateway を指定する ちなみに、利用した Terraform のバージョンは以下になります（バージョン古いと怒られていますね…）。 ...