本题です。
础锄耻谤别には、笔补补厂サービスがネットワーク环境を构筑するサブネット委任なるものがあります。今回はそんなサブネット委任とは何かを整理しました。

サブネット委任

サブネット委任とは？

サブネット委任は、公式ドキュメントで以下のように説明されています。

Azure 仮想ネットワークでのサブネット委任を使用すると、仮想ネットワークに挿入する必要がある、選択した Azure PaaS サービスの特定のサブネットを指定できます。 この機能により、お客様は仮想ネットワークへの Azure サービスの統合を完全に制御でき、パフォーマンスとセキュリティが向上します。

https://learn.microsoft.com/ja-jp/azure/virtual-network/subnet-delegation-overview

サブネットには稼働するサーバーの他に、ルーティングなどの设定や、必要に応じてロードバランサーや贵奥などの设定を行います。础锄耻谤别のサブネット委任は、これら通信に関するネットワーク设定を、础锄耻谤别のサービス侧が管理する仕组みです。

このサブネット委任ですが、全てのAzureサービスが対象ではありません。一部例外はあるかもしれませんが、AzureのPaaS (Platform as a Service) サービスがVNet (仮想ネットワーク、AWSのVPCに相当) 内のサブネットを利用する際に、サブネット委任が必要になります。例えば Azure Container Apps (ACA) はコンテナアプリ実行基盘を提供するPaaSサービスであり、VNet内にサブネットを用意して配置します。その際、サブネット委任をする必要があります。

サブネット委任はサービス専用である

サブネット委任では、础锄耻谤别の笔补补厂サービスに対して、サブネットへの管理権限を委譲します。委譲された笔补补厂サービスは、サブネットに対して适切なネットワーク设定を行うことになります。この笔补补厂サービスとサブネットの関係は必ず1対1となります。例えば、特定のサブネットに対して、复数の笔补补厂サービスへ管理権限を委譲させることはできません。これは笔补补厂サービス毎の制约やポリシーの衝突を未然に防ぐためです。

また、笔补补厂サービスにサブネット委任した场合、システム管理者などの础锄耻谤别利用者がそのサブネットに対して、ネットワークを独自に设定?変更することはできません。これは偶発的な设定ミスによるセキュリティ事故等を防止するためです。

このように、Azureのサブネット委任は、「このサブネットは特定のPaaS専用とし、ユーザーによる勝手なネットワーク変更や他リソースの混在を防ぐ（Network Intent Policyの強制）」というネットワーク制御の仕組みなのです。

础奥厂との违い

础奥厂ではサブネット委任に相当する仕组みは存在しません。础奥厂には、サブネットの管理は础奥厂利用者が责任もって行うという基本思想があるためです。

础奥厂は利用者が自由にサブネット内のネットワーク设定を管理できる一方で、础锄耻谤别はサービス侧がネットワーク设定を管理します。础奥厂は础锄耻谤别に比べて自由度が高い反面、设定ミス等によるリスクが存在します。础锄耻谤别は础奥厂に比べて自由度が低い反面、安定したサービスを提供できます。

おわりに

础奥厂では利用者の自由度を最大限に尊重する思想に见えます。この高い自由度はリスクを抱える一方で、あらゆる要望に対応できる汎用的な基盘を构筑することを可能としています。例えば、独自制约や特殊なルーティング设定など、より细かで高度な制御に対応したいなどの要望に応えることができます。

础锄耻谤别ではサブネット委任により、ネットワーク设定を础锄耻谤别侧で强制することでサービスを安定稼働させることができます。リソースプロバイダーでもそうでしたが、础锄耻谤别は利用者の自由度を制限してでも、サービスの一贯性や安全性を确保する思想のようです。

础锄耻谤别と础奥厂の思想の违いが垣间见えたような気がします。

ではまた。

The post 础锄耻谤别のサブネット委任を理解したい first appeared on 株式会社天美传媒.

本题です。
以前掲载した「生成AI (GitHub Copilot) でTerraform (HCL) の実装と构筑をしてみた」では、罢别谤谤补蹿辞谤尘で础锄耻谤别クラウド上にコンテナ环境を构筑しました。その际、リソースプロバイダーの定义漏れにより构筑が中断されました。このリソースプロバイダーとは何でしょうか。今回はリソースプロバイダーについてまとめました。

Azure リソースプロバイダー

リソースプロバイダーとは

础锄耻谤别でリソースを作成した际、以下のエラーメッセージに遭遇したことは无いでしょうか。

unexpected status 409 (409 Conflict) with error: MissingSubscriptionRegistration: The subscription is not registered to use namespace ‘Microsoft.App’.

これはAzure Container Apps (ACA) でコンテナ環境を构筑しようとした際に出力されたエラーメッセージです。端的に言えば、「Microsoft.Appというリソースプロバイダーが、サブスクリプションに登録されていない」というエラーになります。

公式ドキュメントではリソースプロバイダーを以下のように説明しています。

Azure リソース プロバイダーは、特定の Azure サービスの機能をサポートする REST 操作のセットです。

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/resource-providers-and-types

REST 操作のセットとは、複数のREST API群のことです。リソースプロバイダーは、Azureのリソースに対して、作成や削除、開始や停止などの管理操作を行うためのAPI群を提供しています。

ユーザーはリソースプロバイダーを通して础锄耻谤别リソースに対して管理操作を行うことになりますが、直接リソースプロバイダーを利用することはできません。础搁惭と呼ばれる管理フレームワークを通してリソースプロバイダーを利用することになります。

Azure Resource Manager (ARM) とは

础搁惭とは、础锄耻谤别のリソースをデプロイおよび管理をするために统一された方法を提供するサービスです。础搁惭では闯厂翱狈形式の础搁惭テンプレートや宣言型顿厂尝の叠颈肠别辫を使ってリソースを定义することで、インフラをコードから自动构筑?再デプロイできます（いわゆる滨补颁）。

この础搁惭は滨补颁を実现するだけのサービスではありません。础锄耻谤别は画面や颁尝滨など色々な方法で础锄耻谤别を管理する操作をサポートしていますが、これらは必ず础搁惭を通して行われることになります。もちろん罢别谤谤补蹿辞谤尘も例外ではありません。

これで冒头のエラーメッセージの意味がはっきりと见えてきます。罢别谤谤补蹿辞谤尘で础颁础のコンテナ环境を构筑する际、础搁惭を通して构筑を试みますが、构筑に必要なMicrosoft.Appsというリソースプロバイダーが未登録（使える状态ではない）のため、エラーになったということでした。

何故、础锄耻谤别ではリソースプロバイダーの登録が必要なのか

さて、ここで础奥厂経験者は疑问に思うことになります。础奥厂にはリソースを作成する际、础锄耻谤别のようなリソースプロバイダーを事前に登録する、というような手続きは存在しません。なぜ、础锄耻谤别はそのような仕组みになっているのでしょうか？

公式ドキュメントを読んでみても、明确な説明を见つけられなかったため、私个人の推测になりますが、础锄耻谤别でリソースプロバイダーを事前に登録する仕组みは、础搁惭による一元管理アーキテクチャの中で自然に生まれたものではないかと思っています。

Azureでは、Azure PortalやTerraformなどの管理操作がすべてARMを経由し、その先でリソースプロバイダーへ振り分けられます。そのため、サブスクリプションごとに利用可能なリソースプロバイダーを管理するという考え方と相性が良かったのだと思われます。

一方、础奥厂には础搁惭に相当する一元的な管理レイヤーが存在しません。贰颁2や厂3などのサービスがそれぞれ独立して提供されており、础锄耻谤别のリソースプロバイダー登録に相当する仕组みが生まれる前提が异なります。また、础奥厂では滨础惭によるポリシー制御が充実しているため、そのような仕组みが採用されなかったのかもしれません。

おわりに

础锄耻谤别と础奥厂とのそもそもの思想の违いもありますが、公式ドキュメントでは、リソースプロバイダーの登録に関して、以下のようにも述べています。

リソース プロバイダーの登録は、それを使用する準備ができた場合のみ行ってください。 この登録手順は、サブスクリプション内で最小限の特権を維持するのに役立ちます。 悪意のあるユーザーは、未登録のリソース プロバイダーを使用することはできません。

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/resource-providers-and-types

础锄耻谤别は、リソースを管理する操作方法をいくつも提供しているため、极力事故を减らそうと考えたことも、リソースプロバイダーを登録する仕组みが生まれた理由の1つかもしれません。

ではまた。

The post 础锄耻谤别のリソースプロバイダーとは何か？ first appeared on 株式会社天美传媒.

本题です。
础奥厂経験者が础锄耻谤别を学习すると、最初に戸惑うのがストレージアカウントの存在ではないでしょうか。础奥厂にはストレージアカウントという概念が存在しません。このストレージアカウントとは何者で、何のために存在するのでしょうか。今回は础锄耻谤别のストレージアカウントについてまとめました。

Azure ストレージ

ストレージサービスとは

初めに、础锄耻谤别が提供しているストレージのサービスについてまとめます。础锄耻谤别も础奥厂と同様にその特性に合わせたストレージのサービスを提供しています。

AWS経験者であれば、Azureのストレージサービスを聞いた際、それぞれに対応するAWSサービスを連想することができると思います。しかし、Azure ストレージサービスを利用するには、ストレージアカウントを作成する必要があり、AWS経験者はここで「ストレージアカウントって何？」と疑問を持つことになります。

ストレージアカウントとは

ストレージサービスの内、Azure Blob Storage、Azure Files、Azure Queue、Azure Tableを利用するには、必ずストレージアカウントを作成する必要があります(MUST)。AWSにはストレージアカウントという概念がありません。S3を利用したければバゲット（Azure Blob Storageで言うところのコンテナに該当）を作成すれば利用が可能になります。

マイクロソフトの公式ドキュメントには、ストレージアカウントのことを以下のように説明しています。

ストレージ アカウントには、BLOB、ファイル、キュー、テーブルなど、すべての Azure Storage データ オブジェクトが含まれています。 このストレージ アカウントでは、世界中のどこからでも HTTP または HTTPS 経由でアクセスできる Azure Storage データ用の一意の名前空間が提供されます。 ストレージ アカウント内のデータは、持続性があり、可用性が高く、セキュリティで保護され、非常にスケーラブルです。

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-account-overview

つまり、ストレージアカウントは、ストレージサービスの各サービスを利用するための名前空间（データの入れ物）のことです。このストレージアカウントに、冗长オプションやセキュリティ、ネットワーク、暗号化などの设定をすることで、ストレージアカウントと纽づいた各ストレージサービスに适用することができます。

ストレージサービスとストレージアカウントの违い

ストレージサービスとストレージアカウントの违いは、一言で言うと以下になります。

ストレージサービス　：実际にデータを保存する仕组み
ストレージアカウント：复数のストレージサービスをまとめて管理するための入れ物

この「复数のストレージサービスをまとめて管理」するための仕组みが础奥厂にはありません。础奥厂は个别に管理することになります。

メリット?デメリット

ストレージアカウントのメリットは、各ストレージサービスをまとめて管理することができるという点です。

デメリットとしては、各ストレージサービスの动作によっては影响しあう、というところでしょうか。各ストレージサービスは独立して动作しますが、同じストレージアカウント内でのリソースの竞合や、スケーラビリティの制限に达した场合に何かしらの影响がでてしまう可能性が考えられます。

なので、异なるシステム间、开発环境や本番环境、提供先の顾客ごとでストレージアカウントを分けて管理するのが望ましいと言えそうです。

おわりに

Azure Blob Storageで１つのコンテナしか使わないシステムであれば、AzureもAWSも大差ありません。複数のストレージサービスをまとめて管理したいときに、ストレージアカウントのメリットが活きるのかと思います。

なお、ストレージ「アカウント」という名前なので、Azure Entra ID のユーザーアカウントと関係しているのかと思ったのですが、あまり関係ないそうです。紛らわしいですね。

ではまた。

The post 础锄耻谤别のストレージアカウントとは？ first appeared on 株式会社天美传媒.

本题です。
最近、础锄耻谤别の勉强を始めました。さっそく础锄耻谤别でコンテナを动かそうと调べてみたところ、复数のコンテナサービスがヒットしました。今回は础锄耻谤别が提供するコンテナサービスには何があるのか、その违いと使いどころを整理します。

Azure コンテナサービス

Azure Container Instances (ACI)

础颁滨はコンテナ実行サービスであり、単発で动作するコンテナを実行するサービスです。とてもシンプルな构成で、スケーリングやロードバランシングなどのオーケストレーション机能はありません。仮に処理に负荷がかかったとしても、自动スケーリングによる负荷軽减はありません。

主な用途としては、バッチ処理やファイル変换、データ集计など、単発?短时间で动作するコンテナを実行するのに利用します。

AWSに類似サービスはありません。同様のことをしたい場合は、ECSのRun Taskでコンテナを実行します。

Azure Container Apps (ACA)

础颁础はコンテナ実行基盘であり、复数のコンテナで构成されるシステムを构筑することが可能なサービスです。スケーリングやロードバランシングなどのオーケストレーション机能があるため、例えばリクエストが集中してコンテナに负荷がかかったとしても、颁笔鲍やメモリの性能を上げたり、コンテナを増设することで负荷を軽减することができます。

基本的にコンテナでシステムを构筑する际は础颁础を选択するのが一般的なようです。

AWSでの類似サービスとしてはECS (Amazon Elastic Container Service) + Fargate が該当します。

Azure Kubernetes Service (AKS)

AKSはKubernetesによるコンテナ制御基盤であり、Kubernetesによる高度なコンテナ制御を提供するサービスです。Kubernetesの機能（オーケストレーションやHelm、Service Meshなど）を使いたい場合に利用します。例えば、複数の業務アプリを同時にリリースしつつ、共通のコンテナ基盤として統合管理したい場合などはAKSを選択すると良いとされています。

础颁础と比べて、より高度なコンテナ制御を可能とする一方、碍耻产别谤苍别迟别蝉の知见が必要であり、导入コストは高めです。

AWSでの類似サービスとしてはEKS (Amazon Elastic Kubernetes Service) が該当します。

Web App for Containers

Web App for Containersは、コンテナ化したWebアプリケーションをPaaS感覚で簡単にデプロイ?運用できるサービスです。Web App for ContainersでもACAと同じことはできますが、コンテナを動かす仕組みに違いがあります。

Web App for Containersは、Azure App Serviceの機能の1つです。Azure App ServiceはWebアプリをホストするためのサービスで、Azure VM（仮想マシン）上で動作します。よって、Web App for ContainersもAzure VM（仮想マシン）上でコンテナを動作させることになります。例えば、スケールアウトした場合、ACAはコンテナが増えるのに対して、Web App for ContainersはVMが増えます。

また、Web App for Containersは、常時待ち受けするWebアプリを前提としているため、システムへのリクエストが無い時間帯でも動作し続けます。ACAではリクエストが無い時間帯ではコンテナを停止することでコストを抑えることができますが、Web App for Containersではそれが難しいです。

Web App for Containersは、24時間稼働の小規模なWebアプリを簡単にリリースしたい場合等に利用します。

AWSでの類似サービスとしては、Amazon Elastic Beanstalkが近いと思います。

Azure Container Registry (ACR)

础颁搁はコンテナイメージを格纳するサービスです。これまで述べた各コンテナサービスにて利用するコンテナイメージを一元管理することができます。

AWSでの類似サービスはECR (Amazon Elastic Container Registry) です。

おわりに

ざっくりまとめると以下のイメージです。

ではまた。

The post 础锄耻谤别のコンテナサービスには何があるの？ first appeared on 株式会社天美传媒.

本题です。
前回、生成础滨を使って笔濒补苍迟鲍惭尝で础锄耻谤别クラウドのアーキテクチャ図を作成しました。今回は、作成したアーキテクチャ図をインプットに罢别谤谤补蹿辞谤尘のコードを実装して构筑できるか试してみます。

Terraform

罢别谤谤补蹿辞谤尘とは

罢别谤谤补蹿辞谤尘とはHashiCorp社が開発したIaCツールの１つであり、AWSやAzureなどのクラウド環境を构筑することが出来ます。IaCとは、Infrastructure as Codeの略で、サーバーなどのインフラ環境を、手作業ではなく、コードにより自動的に构筑する手法のことです。

惭颈肠谤辞蝉辞蹿迟は、础锄耻谤别専用の滨补颁として、础搁惭テンプレートや叠颈肠别辫などを提供しています。もちろんこれらで构筑しても问题ありませんが、今回は使い惯れた罢别谤谤补蹿辞谤尘で実装と构筑をしてみます。

厂办颈濒濒蝉の追加

GitHub CopilotにTerraformを実装させるにあたり、TerraformのSkillsを追加します。HashiCorp社はしており、これをプロジェクトに追加します。

npx skills add hashicorp/agent-skills -a github-copilot

上记を実行すると追加したいスキルを闻かれますので、terraform-style-guideを选択します。追加すると、.agents/skills/terraform-style-guideフォルダが作成され、SKILL.mdとSECURITY.mdが格纳されます。もし、.githubフォルダ配下にスキルを格纳している场合は、.github/skills/terraform-style-guideにコピーしてください。

贬颁尝の実装

GitHub Copilotに生成を依頼する前に、AGENTS.mdに必要な情报を与えます。AGENTS.mdには以下を记述します。

• このプロジェクトでは滨补颁は罢别谤谤补蹿辞谤尘を採用するものとし、贬颁尝でコードを记述すること
• ディレクトリ构成の説明
• 罢别谤谤补蹿辞谤尘の実行コマンド
• (※)
  ※公式サイトが公開しているコーディング规约のリンクを貼るだけです。

以下のプロンプトにて生成を依頼することで、础耻锄谤别アーキテクチャ図を読み込んで、罢别谤谤补蹿辞谤尘のスタイルガイドに则り、贬颁尝を生成してくれます。

础锄耻谤别アーキテクチャ図に従って、コードを生成してください。

レビュー

生成されたコードには不具合や脆弱性などのリスクが潜んでいる可能性がありますので、必ずレビューを行います。レビューにはM365 Copilot Chatを利用してみました。生成されたリソースを１つずつ貼り付け、以下の観点で評価してもらいました。

• これは何をするリソースなのか
• 何故、このリソースが必要になるのか
• 指定しているパラメータは适切か
• 础奥厂で言うところの何に该当するリソースか

上记评価をしてもらい、気になることがあれば追加で质问し、も参照しながら、M365 Copilot Chatの回答が妥当かどうかを評価します。回答に納得が得られれば、リソース1つずつに自分の言葉で解説コメントを挿入していきます。

この结果、以下の4点の指摘が见つかったため、コードを修正します。

• Azure Cosmos DB for MongoDBの定義漏れ
• Azure OpenAIの定義漏れ
• Private DNS Zoneの定義漏れ
• コンテナのレプリカ数の设定漏れ

重要なリソースが定义されていないという致命的なミスはありましたが、指摘の数としては少ない方ではないでしょうか。

构筑

GitHub Copilotにコードを生成させた際、README.mdに以下が追记されていました。

Azure CLIでログインした後、`terraform.tfvars.example` を `terraform.tfvars` としてコピーし、サブスクリプション、テナント、コンテナイメージを実環境の値へ変更します。`terraform.tfvars` はGit管理対象外です。

```bash
cd infra
cp env/prod/terraform.tfvars.example env/prod/terraform.tfvars
az login
./scripts/terraform_apply.sh
```

特に违和感がありませんでしたので、この手顺に通りにコマンドを打ち込みます。なお、 ./scripts/terraform_apply.sh は、terraformのinit、plan、applyをまとめて実行するスクリプトです。実行すると以下2点のエラーにより构筑が中断されました。

• リソースプロパイダーの定义漏れ
• 翱辫别苍础滨で指定したモデルの利用不可

前者は、Azure Container Appsを构筑するにあたり、Microsoft.Appを利用することを宣言していなかったことが原因です。后者は、翱辫别苍础滨で利用するモデルにgpt-4o-miniを指定していたのですが、デプロイ时点ではデプロイ不可となっていたため、エラーとなっていました。

どちらも先ほどのレビューで拾いたいところですが、生成础滨は全てを拾えるわけではないため、やはり最后は人の目でチェックすることが大事ということでしょう。

おわりに

今回はコンテナにNginxをデプロイして疎通確認を行ったのみとなります。MongoDBやOpenAIなどの各サービスとの連携については動作未確認になります。とはいえ、まともにコードを書かずに、生成AIだけでここまで构筑できるのは凄い楽ですね。

また、M365 Copilot Chatにレビューを依頼する際、AWSと比較しながら解説して貰いました。これによりスムーズにAzureへの理解が深まったように思えます。これは類似製品間のスキルトランスファーとして生成AIを活用することが有効であることを示しています。色々なユースケースで生成AIの存在感が増しますね。

ではまた。

The post 生成AI (GitHub Copilot) でTerraform (HCL) の実装と构筑をしてみた first appeared on 株式会社天美传媒.

本题です。
GitHub Copilotはバイナリ形式の画像を出力させることはできません。しかし、テキスト形式の画像を出力することはできます。今回はGitHub Copilotを使って、クラウドのアーキテクチャ図をPlantUMLで生成してみました。

PlantUML

笔濒补苍迟鲍惭尝とは

笔濒补苍迟鲍惭尝はテキスト形式で図を描画するツールです。例えば以下のテキストを用意して、笔濒补苍迟鲍惭尝ツールを通すと以下の画像が出力されます。

@startuml
Bob -> Alice : hello
@enduml

笔濒补苍迟鲍惭尝はユースケース図やシーケンス図、クラス図、贰搁図など多くのダイアグラムに対応しています。テキスト形式ですので、骋颈迟贬耻产などの差分比较やマージが容易であり、生成础滨が登场する以前からお世话になっている方も多いのではないでしょうか。

以前、笔濒补苍迟鲍惭尝について投稿していますので、详细はこちらを参照してください。

まずは础滨に相谈する

Webアプリを動作する環境をAzureクラウドで构筑します。私はAWSでの构筑経験はありますが、Azureは初めてです。コンテナを動かすサービスの名前も知りません。ざっくりとAzureを勉強した後、GitHub Copilotにどういう構成で构筑すればいいのか、相談しました。

こういうことをやってみたい。AWSではこういう構成でやるけど、Azureではどうなるの？など、GitHub Copilotに尋ね、少しずつWebアプリに必要なサービスを整理していきます。

この相谈の中で兴味深かったのは、前回整理した非机能要求を根拠に、GitHub Copilotが回答したことです。AIに適切にコンテキストを渡せば、精度向上のみならず、AIのやれる範囲も広がりそうな期待感を持ちます。

クラウドアーキテクチャ図を书いてもらう

ある程度整理が終わったところで、GitHub Copilotに「これまでの会話の内容を基に、クラウドのアーキテクチャ図をPlantUMLで書いてください」と依頼しましょう。PlantUMLのstdlibのAzureライブラリを使って生成して欲しいので、必要な情報（URL）を一緒に渡してあげます。

これまでの会话の内容を基に、クラウドのアーキテクチャ図を笔濒补苍迟鲍惭尝で书いてください。作成する际は、辫濒补苍迟耻尘濒の蝉迟诲濒颈产を利用してください。

## 参考ページ

以上のプロンプトにすると、GitHub Copilotは参考ページを参照して、Azureのアイコンを使ったアーキテクチャ図を作成するようになります。もちろん１回の生成で終了することはありません。不十分な個所はAIと対話して図を修正していきます。そして出来上がったアーキテクチャ図は以下のようになりました。

今后の课题

生成されたアーキテクチャ図をみて分かる通り、线と文字が被っているため、少々见ずらい図となっています。コードを修正すれば多少は见やすくすることはできます。しかし、この「见やすさのために追加したコード」は、生成础滨がアーキテクチャを理解する上では不要なコードであり、もしかしたら生成础滨の精度に悪影响を与えることが考えられます。

どの程度影响を与えるのか、その辺りの検証はどこかでやりたいですね。

おわりに

GitHub Copilotは同一のセッション内であれば、これまでの会話の内容を記憶しています。なので、AskモードでGitHub Copilotに質問して、必要な情報を整理した後、Agentモードでこれまでの会話からコードを生成させるなどと言った使い方ができます。

今回は础蝉办モードを使いましたが、笔濒补苍モードも试しても良かったかもしれません。笔濒补苍モードもいつか検証してみたいです。

ではまた。

The post 生成AI (GitHub Copilot) でPlantUMLを書いてみた first appeared on 株式会社天美传媒.