Azure

ふと思い立って、2024 年の 1 年間にどれくらい四国の Azure 導入事例などが出ているか調べてみた。 調べたと言っても Google で「2024/01/01-2024/12/31」の期間で検索しただけなので漏れがあるかもしれない。 事例の詳しい内容はリンク先の記事を見てもらいたい。 今治造船株式会社（愛媛県） 愛媛が誇る造船会社「今治造船（いまぞう）」の Azure 導入事例。 2024年3月14日に公開された。 オンプレミスの基幹系システムを Azure に移行、オーバースペック回避で TCO を大幅に削減し、バックアップ/バッチ処理時間の短縮も実現 | Microsoft Customer Stories グループ全体で 10 か所の建造拠点を保有し、新造船建造量が国内トップとなっている今治造船株式会社。ここではオンプレミスの仮想化基盤上で運用されてきた基幹系システムが、Microsoft Azure ネイティブの IaaS へと「リフト」されています。これにより、オンプレミス システムにありがちな「オーバースペック」を回避し、TCO を大幅に削減。データ バックアップやバッチの処理時間短縮も実現しています。またこの移行にあたっては、Azure Migrate による必要リソースのアセスメントや、Azure Migrate ＆ Modernize による各種支援、Azure への移行でさらに 3 年間無償でセキュリティ更新プログラムを受けられる Windows Server 2012 の拡張セキュリティ更新プログラムなども活用。FastTrack for Azure もプロジェクトに参画し、テスト フェーズで発生した問題のスピーディな解決などで、大きな貢献を果たしています。 www.microsoft.com 事例記事によると、VMware で構築されたオンプレの基盤を Azure にリフトして IaaS を使っているらしい。 ぜひ苦労話をコミュニティでお話ししてもらいたいものだ。 なお、今治造船には「いまぞう君」というゆるキャラが存在する。 株式会社 石垣（香川県） 「株式会社 石垣」は香川県坂出市に工場や開発センターを持つ水インフラ関連の企業（本社は東京）。 2024年5月17日に Azure Machine Learning の導入事例が公開された。 環境機器の IoT データ プラットフォーム「miyoru」、Azure ML による予測モデルの実装で新たなフェーズへ | Microsoft Customer Stories IoT で収集したデータの可視化や分析をサービスとして提供する「ISHIGAKI Cyber Platform “miyoru”」を Microsoft Azure 上で実現し、2022 年 8 月にリリースした株式会社 石垣。現在はこの miyoru に AI 機能を搭載する取り組みが進められています。その AI エンジンとして採用されているのが、Microsoft Azure Machine Learning です。既に Azure 上で構築されていた IoT 基盤と、AI エンジンをダイレクトに連携させることで、学習のためのデータ パイプラインを完全に自動化。これによってスピーディかつ人手に頼らない学習を可能にしたのです。2023 年 8 月には、AI を搭載した miyoru のコンセプト展示も実施。今後は Microsoft Azure OpenAI Service とも連携させ、プラットフォームとしての強みをさらに強化していく計画です。 www.microsoft.com パートナーは株式会社ナレッジコミュニケーションズ。 同社会社情報によると、いくつかの「Specialization」や「Microsoft Mixed Reality パートナー プログラム認定パートナー」を取得されており、かつ「Microsoft Japan Partner of the Year 2023 (AI Partner Award)」を受賞されているらしい。 ...

こちらは Microsoft Azure Advent Calendar 2024 の 6 日目の記事です。 AKS の API サーバーアドレスの謎 Azure ポータルでいろいろな AKS クラスタの状態を眺めていたところ、AKS の概要ページにある 「API サーバーアドレス」に表示されている内容がクラスタによって異なることに気づきました。 当然クラスタごとに一意となる文字列は異なるのですが、ドメイン部分が大きく異なります。 以下は状況を再現したクラスタのスクショです。 表示されている API サーバーアドレスには hcp.<location>.azmk8s.io と 00000000-0000-0000-0000-000000000000.privatelink.<location>.azmk8s.io の 2 種類あります。 クラスタ A の API サーバーアドレス aks-public-aks-public-fqdn-c209fd-mytdol9d.hcp.japaneast.azmk8s.io クラスタ B の API サーバーアドレス aks-public-aks-public-fqdn-c209fd-rzz0g24p.a47e9794-80a7-4088-9a92-3706e050f9cc.privatelink.japaneast.azmk8s.io 両クラスタともプライベート AKS クラスタとして構築しています。 パブリックアクセスはできないので、VPN などを使っていない端末では Azure ポータルからクラスタのリソースを見ようとしてもエラーになってしまいます。 同じプライベート AKS クラスタなのにどうして差が生まれてしまうのでしょうか？ 結論から AKS の「パブリック FQDN enablePrivateClusterPublicFqdn」という設定によって API サーバーアドレスに表示される内容が変わります。 プライベート Azure Kubernetes Service (AKS) クラスターを作成する - Azure Kubernetes Service プライベート Azure Kubernetes Service (AKS) クラスターの作成方法について説明します。 learn.microsoft.com Azure CLI では --disable-public-fqdn オプションをつけて新規クラスタを作成、または既存クラスタを更新することで「パブリック FQDN」を無効化できます。 つまりデフォルトは有効状態です。 ...

こちらは エーピーコミュニケーションズ Advent Calendar 2024 の 1 日目の記事です。 Ephemeral values の登場 先日リリースされた Terraform v1.10.0 で Ephemeral values という新しい機能が登場しました。 Terraform 1.10 improves handling secrets in state with ephemeral values Terraform 1.10 is generally available, and it includes ephemeral values along with improvements to plan and apply performances. www.hashicorp.com Ephemeral values は次の要素で構成されています。 Ephemeral input variables / Ephemeral output variables Ephemeral resources Write-only attribute (v1.11 で追加予定) この中でも今回は Ephemeral resources に焦点を当ててみます。 ...

おうち K8s クラスタで HashiCorp Vault を動かしているのですが、Pod が再起動すると Vault が Seal 状態となってしまうので都度 Unseal Key を入力しています。 そろそろ煩わしさが限界なので Azure Key Vault と連携して Vault の Auto Unseal 機能を使ってみます。 Auto-unseal Vault using Azure Key Vault | Vault | HashiCorp Developer Enable auto-unseal with Azure Key Vault. developer.hashicorp.com Auto Unseal 設定 Auto Unseal を使うためには以下の設定が必要になります。 Entra ID サービスプリンシパル Azure Key Vault Vault Config サービスプリンシパル Microsoft Entra ID に Vault の Auto Unseal で使用するサービスプリンシパルを作成します。 ...

はじめに 今年の夏も酷暑続きでしたねー。 仕事が忙しくて自宅ラボに触る時間もなかったり、マシンの熱が心配なのもあって夏の間は自宅ラボの電源を落としてたり、ということもあり前回の投稿から 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 つです。 ...

はじめに 前回の投稿で 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 ゾーン共同作成者」を割り当てます。 ...

はじめに Google Domains で nnstt1.dev というドメインを購入しているのですが、最近 Azure を使うことが増えてきたので、ドメイン管理も Azure DNS に委任しました。 以下のドキュメントを参照しています。 チュートリアル:Azure DNS でドメインをホストする | Microsoft Learn ドキュメント内では Azure Portal を使って Azure DNS を操作していますが、今回は Azure CLI を使って作業しました。 DNS ゾーンの作成 はじめに、移管先となる DNS ゾーンを作成します。 $ az network dns zone create \ --name nnstt1.dev \ --resource-group $RG_NAME 作成できたか確認します。 $ az network dns zone list -o table ZoneName ResourceGroup RecordSets MaxRecordSets ------------- ------------------ -------------- ------------------- nnstt1.dev home-lab 2 10000 DNS ゾーンが作成されていることを確認できました。 次に、割り当てられたネームサーバを確認します。 $ az network dns record-set ns list \ --resource-group $RG_NAME \ --zone-name nnstt1.dev \ --out tsv --query '[].nsRecords[]' ns1-09.azure-dns.com. ns2-09.azure-dns.net. ns3-09.azure-dns.org. ns4-09.azure-dns.info. 4 つのネームサーバが登録されていることが確認できました。 ...

はじめに 本ブログは 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種類です。 ...

前回の投稿で、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 を作成します。 ...

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 のバージョンは以下になります（バージョン古いと怒られていますね…）。 ...