英語で読む

次の方法で共有

Azure DevTest Labs のエンタープライズ デプロイに関する概念実証を提供する

  • [アーティクル]

俊敏性、柔軟性、経済性を含むメリットを理由に、企業はクラウドを迅速に採用しています。 最初の手順は、多くの場合、開発とテストのワークロードです。 Azure DevTest Labs は、企業にとってメリットとなる機能を提供し、主要な開発/テスト シナリオをサポートします。

この記事では、企業が Azure DevTest Labs のデプロイに関する概念実証またはパイロットを成功させる方法について説明します。 概念実証では、単一のチームが集中的な作業を行って、組織の価値を確立します。

Azure DevTest Labs を組織に導入するための要件は、企業ごとに異なります。 概念実証は、エンド ツー エンドのデプロイを成功させるための最初のステップです。

概念実証を成功させるには、次のようにします。

  1. 1 つまたは 2 つのチームを選択します。
  2. チームのシナリオを特定します (開発者仮想マシン (VM) やテスト環境など)。
  3. 現在のユース ケースを文書化します。
  4. チームのシナリオとユース ケースを実現するために DevTest Labs をデプロイする。
  5. 成功と習得した教訓を評価します。

主要な DevTest Labs シナリオには、クラウド開発、テスト、トレーニング環境が含まれます。 次のようなユース ケースがあります。

  • 開発者デスクトップの作成。
  • テスト環境の構成。
  • VM と Azure リソースへのアクセスの有効化。
  • 学習と実験のためのサンドボックスの設定。
  • 企業の規制に準拠したラボ ポリシーとコスト管理の構成。

前提条件

DevTest Labs の概念実証を成功させるには、次の前提条件を満たす必要があります。

基本を学ぶ

次のリソースを使用して、Azure と DevTest Labs について学習します。

エンタープライズ フォーカス領域を理解する

ワークロードをクラウドに移行する企業にとっての一般的な懸念事項は、次のとおりです。

Azure サブスクリプションを取得する

Microsoft Entra ID ですべてのユーザーを登録する

ユーザーの追加やラボ所有者の追加などの管理を行うには、すべてのラボ ユーザーが、パイロットに使用する Azure サブスクリプションの Microsoft Entra ID テナントに属している必要があります。 多くの企業は、ユーザーがクラウドでオンプレミスの ID を使用できるようにハイブリッド ID を設定します。 DevTest Labs の概念実証には、ハイブリッド ID は必要ありません。

概念実証の範囲を設定する

パイロットで重点を置く必要があるのは、Azure DevTest Labs が自社に適しているかどうかを判断できる必要最小限のワークロードと依存関係を使用することです。 迅速でクリーンな成功を確実にするために、依存関係が最も少ない最も単純なワークロードを選択します。 または、潜在的な複雑さが表面化する最も典型的なワークロードを選択して、スケールアウト フェーズでパイロットの成功を再現できるようにします。

実装を開始する前に、概念実証を慎重に計画します。 パイロット リソースが無限に存在し続けることはないため、ユーザーに過度の期待を抱かせないようにします。

パイロットの範囲を設定するには、次の作業を行います。

  • 目標と成功基準を定義する。
  • パイロットの対象となるワークロードまたはシナリオの小さなセットの一覧を作成する。
  • カスタム イメージや Marketplace のイメージなど、ラボで利用可能にする必要のあるリソースを決定する。
  • ネットワーク トポロジとラボ ポリシーを決定する。
  • パイロットに参加するユーザーとチーム、および結果を検証するユーザーとチームを選択する。
  • パイロット期間 (2 週間、1 か月など) を決定する。
  • パイロット終了時にパイロット リソースを破棄する方法を決定する。

パイロットを完璧にしようとする傾向があるため、DevTest Labs のロールアウト後に最終的な状態がミラー化されます。 ただし、概念実証を完璧にしようとすると、パイロットを開始する前に多大な労力を費やすことになります。 パイロットの目的は、最終的なサービスのスケールアップとロールアウトに関して適切な意思決定を行うことです。

計画と設計に関するその他の決定を行う

完全な DevTest Labs ソリューションには、計画と設計に関するいくつかの重要な決定が含まれます。 概念実証は、これらの決定を行うのに役立ちます。 その他の考慮事項としては、次のようなものがあります。

サブスクリプションのトポロジ

Azure のリソースに関するエンタープライズ レベルの要件が、1 つのサブスクリプションで利用可能なクォータを超えることがあります。 複数の Azure サブスクリプションが必要な場合や、初期のサブスクリプション制限を増やすためにサービス要求を行うことが必要な場合があります。 詳細については、「スケーラビリティに関する考慮事項」を参照してください。

後でリソースを別のサブスクリプションに移動することは難しいため、最終的なフルスケールのロールアウトを行う前に、サブスクリプション間でリソースを分散する方法を決定することが重要です。 たとえば、ラボを作成後に別のサブスクリプションに移動することはできません。 「サブスクリプション決定ガイド」は、計画に有用なリソースです。

ネットワーク トポロジ

DevTest Labs によって自動的に作成される既定のネットワーク インフラストラクチャでは、エンタープライズ ユーザーの要件や制約が十分に満たされない可能性があります。 たとえば、多くの場合、企業は次のネットワークを使用します。

詳細については、「ネットワーク コンポーネント」を参照してください。

DevTest Labs では、新しい VM の作成に使用するために既存の仮想ネットワークをラボに追加する機能もサポートされています。 詳細については、「Azure DevTest Labs で仮想ネットワークを追加する」を参照してください。

仮想マシンへのリモート アクセス

エンタープライズ ユーザーが DevTest Labs VM にリモート アクセスするには、いくつかのオプションがあります。

  • 最も簡単で安全な方法は、Azure Bastion を介したブラウザー接続を使用することです。 VM でパブリック IP アドレスを使用する必要がありません。 詳細については、「Azure Bastion を使用して DevTest Labs VM へのブラウザー接続を有効にする」を参照してください。

  • もう 1 つのオプションは、パブリック IP または共有パブリック IP を使用し、リモート デスクトップ プロトコル (RDP) またはセキュア シェル (SSH) を経由して接続する方法です。

  • 上記のオプションで十分ではない場合、「DevTest Labs のエンタープライズ参照アーキテクチャ」で示しているように、リモート アクセス ゲートウェイを経由して接続することができます。 詳細については、リモート デスクトップ ゲートウェイを使用するようにラボを構成に関するページを参照してください。

  • 企業では、ExpressRoute またはサイト間 VPN を使用して、ラボをオンプレミスのネットワークに接続することもできます。 このオプションにより、プライベート IP アドレスをインターネットに公開することなく、それに基づいて VM に RDP または SSH で直接接続することができます。

ラボへのアクセスとアクセス許可

DevTest Labs の最終的なロールアウトの前に、ラボへの各レベルのアクセス権を与えるユーザーを大まかに決定しておくことが重要です。 DevTest Labs の 2 つの主要なアクセス許可レベルは、所有者と DevTest Labs ユーザーです。 一般的なモデルでは、チームリーダーなどの予算所有者をラボ所有者とし、チームメンバーをラボ ユーザーとします。 その後、予算の担当者は、ラボ ポリシーの設定を調整し、チームを予算内に収めることができます。

概念実証を完了する

定義されたシナリオに対応したら、パイロットを完了します。 ユーザーからフィードバックを収集し、パイロットが成功したかどうかを判断し、組織でエンタープライズ規模の DevTest Labs のロールアウトを進めるかどうかを決定します。 この後、スケーリングされたロールアウト全体の一貫性を確保するために、DevTest Labs と関連リソースのデプロイの自動化を検討します。

概念実証の計画例

次の例は、DevTest Labs の概念実証デプロイのスコープを設定するための計画を示しています。

概要

ある企業は、ベンダーが使用する新しい Azure DevTest Labs 環境の開発を計画しています。これは、企業ネットワークから分離されます。 ソリューションが要件を満たすかどうかを判断するために、組織は、エンド ツー エンドのシナリオを検証するための概念実証を開発しています。

目標

概念実証には、次の目標があります。

  • Microsoft Entra ゲスト アカウントを使用して分離された Azure 環境にアクセスするベンダー向けの実用的なエンド ツー エンド ソリューション。
  • ベンダーが生産性を発揮するために必要なすべてのリソースを備えた DevTest Labs 環境。
  • 障害となり、幅広い使用と導入に影響を与える潜在的な問題を特定し、理解する。
  • ソリューションの開発担当者がすべてのコードと関連資料について十分に理解する。
  • すべての参加者が幅広い導入に対して自信を持つ。

要件

ソリューションには、次の要件があります。

  • ベンダー チームが、Azure DevTest Labs で一連のラボを使用できる。
  • ベンダーは Microsoft Entra ID とロールの割り当てによってラボにアクセスできます。
  • ベンダーがリソースに正常に接続できる方法 (たとえば、パブリック IP アドレスを使用せずに VM にアクセスできるサイト間 VPN など) がある。
  • ラボは、要件をサポートするネットワーク インフラストラクチャに接続される。
  • DevTest Labs によって、ベンダーが VM で必要とする一連のソフトウェア成果物がインストールされる。

前提条件

  • プロジェクトに使用するサブスクリプション

  • Microsoft Entra テナントと、Microsoft Entra ID のヘルプとガイダンスを提供できるプラットフォーム エンジニア

  • プロジェクト メンバーが共同作業を行う方法。たとえば、次のようなものがあります。

    • ソース コードとスクリプト用の Azure Repos
    • ドキュメント用の Microsoft Teams または SharePoint
    • 対話用の Microsoft Teams
    • 作業項目用の Azure Boards

設定タスク

  • 概念実証に使用する Azure リージョンを決定する。
  • ラボ VM を Microsoft Entra ドメインに参加させるかどうか、および Microsoft Entra Domain Services または別の方法を使用するかどうかを決定する。
  • 概念実証環境を使用するベンダーを特定する。
  • ベンダーに必要なリソース (VM で使用可能なソフトウェアなど) を決定する。
  • ベンダーが DevTest Labs で使用できる Azure サービス (VM 以外) を決定する。
  • ラボを使用するためのベンダーのトレーニング方法を計画する。

次の手順