Slide 1

Slide 1 text

12:50 PM-1:05 PM

Slide 2

Slide 2 text

12:50 PM-1:05 PM AI アプリを支えるチームの 最適な開発環境を整備する Kodai Sakabe @koudaiii Tuesday, February 20 12:50 PM-1:05 PM

Slide 3

Slide 3 text

12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。

Slide 4

Slide 4 text

12:50 PM-1:05 PM Agenda  AI アプリの特徴  Developer Environment  Azure Developer  Appendix  OpenFeature  Radius

Slide 5

Slide 5 text

12:50 PM-1:05 PM AI アプリの特徴

Slide 6

Slide 6 text

12:50 PM-1:05 PM AI とアプリの境界点 データフローの分離 Baseline OpenAI end-to-end chat reference architecture https://learn.microsoft.com/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat

Slide 7

Slide 7 text

12:50 PM-1:05 PM 本番環境での変化(主に見直しされるポイント) SLO  AI とアプリでアーキテクチャ を疎結合  それぞれスケールできるアー キテクチャ  セキュリティとガバナンス対 策、ネットワークを準備  ミドルウェアや API 外部連 携による SLA の低下 Cost  新規ミドルウェア  外部連携  データ量  ネットワーク  モデル  セキュリティ End-to-end simulation  モデル調製  カテゴリ  評価  Side-by-side  プロンプト  OpenFeature CICD  新規デリバリー  ミドルウェアの CICD  A/B テスト  データによる意思決定

Slide 8

Slide 8 text

12:50 PM-1:05 PM Building for the future: The enterprise generative AI application lifecycle with Azure AI https://azure.microsoft.com/en-us/blog/building-for-the-future-the-enterprise-generative-ai-application-lifecycle-with-azure-ai/

Slide 9

Slide 9 text

12:50 PM-1:05 PM LLMOps process flow https://learn.microsoft.com/azure/machine-learning/prompt-flow/how-to-end-to-end-llmops-with-prompt-flow?view=azureml-api-2

Slide 10

Slide 10 text

12:50 PM-1:05 PM Achieve generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/

Slide 11

Slide 11 text

12:50 PM-1:05 PM Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化 Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み LLMOps におけるレベル別 Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/

Slide 12

Slide 12 text

12:50 PM-1:05 PM Developer Environment

Slide 13

Slide 13 text

12:50 PM-1:05 PM 組織のパフォーマンスに 影響ある Four keys metrics Deployment frequency デプロイの頻度 Change lead time コード変更からデプロイするまでの時間 Change failure rate デプロイによる障害率 Failed deployment recovery time デプロイ失敗から復旧にかかる時間 Accelerate State of DevOps 2023 P12 https://cloud.google.com/devops/state-of-devops

Slide 14

Slide 14 text

12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始  Developer experience Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備

Slide 15

Slide 15 text

12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion

Slide 16

Slide 16 text

12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion

Slide 17

Slide 17 text

12:50 PM-1:05 PM Azure Developer

Slide 18

Slide 18 text

12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion

Slide 19

Slide 19 text

12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM

Slide 20

Slide 20 text

12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM

Slide 21

Slide 21 text

12:50 PM-1:05 PM LLMOps process flow https://learn.microsoft.com/azure/machine-learning/prompt-flow/how-to-end-to-end-llmops-with-prompt-flow?view=azureml-api-2

Slide 22

Slide 22 text

12:50 PM-1:05 PM https://github.com/koudaiii/my-devcenter

Slide 23

Slide 23 text

12:50 PM-1:05 PM Deploy environments in CI/CD by using GitHub GitHub Actions で環境の構築 https://devportal.microsoft.com

Slide 24

Slide 24 text

12:50 PM-1:05 PM Cost 計算は AI に

Slide 25

Slide 25 text

12:50 PM-1:05 PM Dev Centers / Azure Deployment Environments  Dev Center からプロジェクトが作られ、配下にリソースグループ、サブスクリプシ ョン等が紐づけされる  Azure Deployment Environments は、 azd で作れる環境を Dev Center 配下に provisioning する  リソースグループに環境ができるため  リソースグループ単位でコスト管理ができる  リソースグループ単位で権限も管理ができる  Developer portal ができ、 Ops や Infra エンジニアによって IaC や Azure portal 上で厳密に管理された領域を触れずに利用できる  開発チーム単位または個人単位で Azure 全体を利用実現

Slide 26

Slide 26 text

12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング  Developer experience Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備

Slide 27

Slide 27 text

12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。

Slide 28

Slide 28 text

12:50 PM-1:05 PM © Copyright Microsoft Corporation. All rights reserved.

Slide 29

Slide 29 text

12:50 PM-1:05 PM Appendix: OpenFeature

Slide 30

Slide 30 text

12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion

Slide 31

Slide 31 text

12:50 PM-1:05 PM OpenFeature What's a Feature Flag?  フィーチャーフラグは、ソースコード を変更することなく、製品やサー ビスの特定の機能やコードパス の動作を有効化、無効化、変 更することを可能にするソフト ウェア開発手法 What's OpenFeature?  OpenFeature は、コミュニティ 主導のフィーチャーフラグのAPIを 提供する CNCF Sandbox で あり、フラグ管理ツールと連動で きる Why standardize?  フィーチャーフラグを標準化するこ とで、ツールやベンダーを共通の インターフェイスで統一し、コード レベルでのベンダーロックインを 避けることができる。また、コミュ ニティ全体で共有できる拡張 機能や統合機能を構築するた めのフレームワークを提供する。 https://openfeature.dev/

Slide 32

Slide 32 text

12:50 PM-1:05 PM OpenFeature https://openfeature.dev/docs/reference/intro/ https://openfeature.dev/ecosystem/

Slide 33

Slide 33 text

12:50 PM-1:05 PM https://github.com/koudaiii/gostart

Slide 34

Slide 34 text

12:50 PM-1:05 PM リアルタイムのフラグ管理 main.go func main() { // Use flagd as the OpenFeature provider openfeature.SetProvider(flagd.NewProvider()) // Initialize OpenFeature client client := openfeature.NewClient("GoStartApp") // Initialize Go Gin engine := gin.Default() // Setup a simple endpoint engine.GET("/hello", func(c *gin.Context) { // Evaluate welcome-message feature flag welcomeMessage, _ := client.BooleanValue( context.Background(), "welcome-message", false, openfeature.EvaluationContext{}, ) if welcomeMessage { c.JSON(http.StatusOK, gin.H{"message": newWelcomeMessage}) return } else { c.JSON(http.StatusOK, gin.H{"message": defaultMessage}) return } }) Client と Provider(flagd) 導入 Sample https://github.com/koudaiii/gostart

Slide 35

Slide 35 text

12:50 PM-1:05 PM flagd server https://github.com/open- feature/flagd OpenFeature 公式のフラグ管理 のプロバイダー。 json ファイルと docker run するだけ。 プロバイダー用 SDK があるため自 作可能。クライアント側でイベント 、フックが提供されているため、イ ベント駆動で処理を追加すること やプロバイダーのステータスからハン ドリング可能。 Flags.flagd.json { "flags": { "welcome-message": { "variants": { "on": true, "off": false }, "state": "ENABLED", "defaultVariant": "off" } } } “on” にファイル上書きで無停止切替

Slide 36

Slide 36 text

12:50 PM-1:05 PM 新しい機能をサービスに安全に追加するための9つのステップ 1. Create a new runtime configuration directive : 新しい機能のための config を作成し、 default は false に設定。 2. Release a new binary : 参照がない状態でリリース 3. Update the configuration file : config を更新して見えるようにする。ユーザーの導線なし。 4. Update the canary jobs : カナリージョブのみで config を有効にする 5. Update all jobs : 全部公開。この時点で新しい機能が有効。 6. Change the default flag value : flag を default で true になるように変更。 7. Update the configuration file again : config を更新して、 config 参照をなくします。 8. Edit the conditional code execution : 条件付きのコード実行を常に実行するように編集します。 9. Remove the now-unused code : 今は使われていないコードを削除します。 https://www.usenix.org/system/files/login/articles/login_1410_05_klein.pdf Daniel V. Klein、Dina M. Betser、Mathew G. Monroe

Slide 37

Slide 37 text

12:50 PM-1:05 PM OpenFeature  AI の機能を安全にリリースするためのフィーチャーフラグ  リアルタイムで制御可能な仕組み  その他 secrets や環境変数と分離できる  最適なモデル検証のため flag 利用  API on/off  プレビュー機能として実現 on/off

Slide 38

Slide 38 text

12:50 PM-1:05 PM Appendix: Radius

Slide 39

Slide 39 text

12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal (https://devportal.microsoft.com/) Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion

Slide 40

Slide 40 text

12:50 PM-1:05 PM Cloud-native application platform that works on any cloud https://radapp.io/

Slide 41

Slide 41 text

12:50 PM-1:05 PM Why is building and running microservice apps hard?  Complex architectures  Cross-platform portability Enforcing best-practices Troubleshooting experiences

Slide 42

Slide 42 text

12:50 PM-1:05 PM Standardized “app” layer across platforms On-premises

Slide 43

Slide 43 text

12:50 PM-1:05 PM

Slide 44

Slide 44 text

12:50 PM-1:05 PM Envrironment XXX_URL には、 接続可能であ れば、 Docker や AWS RDS や Azure SQL DB 利用可能であり 、 Application と Environment が切り離されている状態を radius が行っている。 func main() { ctx := context.Background() // cf. "sqlserver://sa:pa@localhost:1433?database=db" mssqldbURL := os.Getenv("MSSQL_SERVER_URL") // Open a MSSQL database. sqldb, err := sql.Open("sqlserver", mssqldbURL) if err != nil { panic(err) } ・・・ main.go

Slide 45

Slide 45 text

12:50 PM-1:05 PM https://github.com/koudaiii/first-app

Slide 46

Slide 46 text

12:50 PM-1:05 PM rad init Console on MacOS $ curl -fsSL "https://raw.githubusercontent.com/radius-project/radius/main/deploy/install.sh" | /bin/bash $ rad init Initializing Radius. This may take a minute or two... Install Radius v0.30.0 - Kubernetes cluster: minikube - Kubernetes namespace: radius-system Create new environment default - Kubernetes namespace: default - Recipe pack: local-dev Scaffold application first-app Update local configuration Initialization complete! Have a RAD time

Slide 47

Slide 47 text

12:50 PM-1:05 PM radius-system and recipes Console on MacOS $ kubectl get deployments -n radius-system NAME READY UP-TO-DATE AVAILABLE AGE applications-rp 1/1 1 1 2d21h bicep-de 1/1 1 1 2d21h contour-contour 1/1 1 1 2d21h controller 1/1 1 1 2d21h ucp 1/1 1 1 2d21h $ rad recipe list RECIPE TYPE TEMPLATE KIND TEMPLATE VERSION TEMPLATE default Applications.Datastores/redisCaches bicep ghcr.io/radius-project/recipes/local-dev/rediscaches:0.30 default Applications.Datastores/sqlDatabases bicep ghcr.io/radius-project/recipes/local-dev/sqldatabases:0.30 default Applications.Messaging/rabbitMQQueues bicep ghcr.io/radius-project/recipes/local-dev/rabbitmqqueues:0.30 default Applications.Dapr/pubSubBrokers bicep ghcr.io/radius-project/recipes/local-dev/pubsubbrokers:0.30 default Applications.Dapr/secretStores bicep ghcr.io/radius-project/recipes/local-dev/secretstores:0.30 default Applications.Dapr/stateStores bicep ghcr.io/radius-project/recipes/local-dev/statestores:0.30 default Applications.Datastores/mongoDatabases bicep ghcr.io/radius-project/recipes/local-dev/mongodatabases:0.30

Slide 48

Slide 48 text

12:50 PM-1:05 PM radius getting started guide app.bicep import radius as radius @description('The Radius Application ID. Injected automatically by the rad CLI.') param application string resource demo 'Applications.Core/containers@2023-10-01-preview' = { name: 'demo’ properties: { application: application container: { image: 'ghcr.io/radius-project/samples/demo:latest’ ports: { web: { containerPort: 3000 } } } } } https://docs.radapp.io/getting-started/

Slide 49

Slide 49 text

12:50 PM-1:05 PM connection rad run app.bicep $ rad run app.bicep Building app.bicep... Deploying template 'app.bicep' for application 'first-app' and environment 'default' from workspace 'default'... Deployment In Progress... Completed db Applications.Datastores/redisCaches . demo Applications.Core/containers Deployment Complete Resources: demo Applications.Core/containers db Applications.Datastores/redisCaches Starting log stream... + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis-monitor https://docs.radapp.io/getting-started/ https://github.com/koudaiii/first-app

Slide 50

Slide 50 text

12:50 PM-1:05 PM Radius on GitHub Codespaces

Slide 51

Slide 51 text

12:50 PM-1:05 PM Radius  マイクロサービスで複雑になったアーキテクチャをシンプルなプラットフォーム実現  軽量の Kubernetes を利用して GitHub Codespaces 上で実行可能  Kubernetes を利用した開発環境  Bicep を local に対して実行するため、 Bicep がよりインフラからアプリエンジニ アに対して利用しやすい  Application と Environment を分離、 Environment は rad switch コマン ドで環境切替