Azure DevTest Labs に関する FAQAzure DevTest Labs FAQ

Azure DevTest Labs について特に多く寄せられる質問にお答えします。Get answers to some of the most common questions about Azure DevTest Labs.

ブログ記事Blog post

DevTest Labs チームのブログは 2019 年 3 月 20 日時点で廃止されました。Our DevTest Labs Team blog has been retired as of 20 March 2019. 

今後の機能更新はどこで追跡できるのでしょうか。Where can I track feature updates from now on?

今後、Azure ブログと Azure の更新情報で、機能更新や情報ブログ記事を投稿していきます。From now on, we'll be posting feature updates and informative blog posts on the Azure blog and Azure updates. これらのブログ記事は、必要に応じて、Microsoft のドキュメントにもリンクされます。These blog posts will also link to our documentation wherever required.

DevTest Labs Azure ブログDevTest Labs Azure の更新情報をご覧になり、DevTest Labs の新機能に関する情報を入手するようにしてください。Subscribe to the DevTest Labs Azure Blog and DevTest Labs Azure updates to stay informed about new features in DevTest Labs.

既存のブログ記事はどうなりますか。What happens to the existing blog posts?

現在、既存のブログ記事 (障害更新情報を除く) の DevTest Labs ドキュメントへの移行を進めています。We're currently working on migrating existing blog posts (excluding outage updates) to our DevTest Labs documentation. MSDN ブログが非推奨になると、DevTest Labs のドキュメントの概要にリダイレクトされます。When the MSDN blog is deprecated, it will be redirected to the documentation overview for DevTest Labs. リダイレクトされたら、タイトルの 'フィルター条件' で探している記事を検索できます。Once redirected, you can search for the article you're looking for in the 'Filter by' title. まだすべての記事を移行していませんが、今月末までに完了するはずです。We haven't migrated all posts yet, but should be done by end of this month. 

障害更新情報はどこで確認できますか。Where do I see outage updates?

今後、Twitter ハンドルを使用して、障害更新情報を投稿する予定です。We'll be posting outage updates using our Twitter handle from now onwards. Twitter でフォローして、障害と既知のバグに関する最新の更新情報を取得してください。Follow us on Twitter to get latest updates on outages and known bugs.

TwitterTwitter

Twitter ハンドル: @azlabservicesOur Twitter handle: @azlabservices

全般General

ここに質問の答えがない場合はどうすればいいですか。What if my question isn't answered here?

ご自分の質問がここに表示されていない場合はご連絡ください。答えを見つけるお手伝いをします。If your question isn't listed here, let us know, so we can help you find an answer.

  • この FAQ の末尾で質問を投稿してください。Post a question at the end of this FAQ. この記事について、Azure Cache チームや他のコミュニティ メンバーと情報交換できます。Engage with the Azure Cache team and other community members about this article.
  • さらに多くの人々と交流するには、Azure DevTest Labs MSDN フォーラムに質問を投稿してください。To reach a wider audience, post a question on the Azure DevTest Labs MSDN forum. Azure DevTest Labs チームや他のコミュニティ メンバーと情報交換できます。Engage with the Azure DevTest Labs team and other members of the community.
  • 機能を要求する場合は、要求とアイデアを Azure DevTest Labs のユーザーの声に送信してください。For feature requests, submit your requests and ideas to Azure DevTest Labs User Voice.

Microsoft アカウントとは何ですか。What is a Microsoft account?

Microsoft アカウントは、Microsoft のデバイスとサービスで実行するほぼすべての操作に使用するアカウントです。A Microsoft account is an account you use for almost everything you do with Microsoft devices and services. Skype、Outlook.com、OneDrive、Windows Phone、Azure、Xbox Live へのサインインに使用する電子メール アドレスとパスワードです。It’s an email address and password that you use to sign into Skype, Outlook.com, OneDrive, Windows phone, Azure, and Xbox Live. 1 つのアカウントで、どのデバイスからでもファイル、写真、連絡先、設定を利用できます。A single account means that your files, photos, contacts, and settings can follow you on any device.

注意

Microsoft アカウントは、以前は Windows Live ID と呼ばれていました。A Microsoft account used to be called a Windows Live ID.

なぜ Azure DevTest Labs を使用する必要があるのですか。Why should I use Azure DevTest Labs?

Azure DevTest Labs を使用すると、チームの時間と費用を節約できます。Azure DevTest Labs can save your team time and money. 開発者は、複数の異なるベースを使用して独自の環境を作成できます。Developers can create their own environments by using several different bases. また、アーティファクトを使用してアプリケーションを速やかにデプロイし、構成することもできます。They also can use artifacts to quickly deploy and configure applications. カスタム イメージと数式を使用して、仮想マシン (VM) をテンプレートとして保存し、チームで簡単に再現できます。By using custom images and formulas, you can save virtual machines (VMs) as templates, and easily reproduce them across the team. さらに、DevTest Labs には複数の構成可能なポリシーも用意されています。ラボ管理者は、これらのポリシーを使用して無駄を削減し、チームの環境を管理できます。DevTest Labs also offers several configurable policies that lab administrators can use to reduce waste and manage a team's environments. これらのポリシーには、自動シャットダウン、コストのしきい値、ユーザーごとの最大 VM 数、最大 VM サイズなどが含まれます。These policies include auto-shutdown, cost threshold, maximum VMs per user, and maximum VM size. DevTest Labs の詳細については、概要を確認するか、入門ビデオをご覧ください。For a more in-depth explanation of DevTest Labs, see the overview or the introductory video.

"心配無用のセルフ サービス" とはどういう意味ですか。What does "worry-free self-service" mean?

"心配無用のセルフ サービス" とは、開発者とテスト担当者が、必要に応じて独自の環境を作成することを意味します。Worry-free self-service means that developers and testers create their own environments as needed. 管理者は、DevTest Labs を使用することで、適切なアクセスを設定したり、無駄を最小限に抑えたり、コストを管理したりできるという安心感が得られます。Administrators have the security of knowing that DevTest Labs can help set the appropriate access, minimize waste and control costs. 管理者は、許可される VM のサイズ、VM の最大数、VM の起動およびシャットダウン時間を指定できます。Administrators can specify which VM sizes are allowed, the maximum number of VMs, and when VMs are started and shut down. また、DevTest Labs では、ラボ リソースの使用状況を常に把握できるように、コストの監視とアラートの設定も簡単に行うことできます。DevTest Labs also makes it easy to monitor costs and set alerts, to help you stay aware of how lab resources are being used.

DevTest Labs を使用するにはどうすればよいですか。How can I use DevTest Labs?

DevTest Labs は、開発環境やテスト環境が必要であり、これらを迅速に再現したり、コスト節約ポリシーを使用して管理したりする場合に常に役立ちます。DevTest Labs is useful anytime you require dev or test environments, and want to reproduce them quickly, or manage them by using cost-saving policies. お客様は、次のようなシナリオで DevTest Labs を使用しています。Here are some scenarios that our customers use DevTest Labs for:

  • 開発環境とテスト環境を 1 か所で管理する。Manage dev and test environments in one place. ポリシーを使用してコストを削減し、カスタム イメージを作成してチーム全体でビルドを共有する。Use policies to reduce costs and create custom images to share builds across the team.
  • 開発段階全体にわたってディスクの状態を保存するために、カスタム イメージを使用してアプリケーションを開発する。Develop an application by using custom images to save the disk state throughout the development stages.
  • 進行状況に関連してコストを追跡する。Track cost in relation to progress.
  • 品質保証テスト用の大容量テスト環境を作成する。Create mass test environments for quality assurance testing.
  • アーティファクトと数式を使用して、さまざまな環境でアプリケーションを簡単に構成し、再現する。Use artifacts and formulas to easily configure and reproduce an application in various environments.
  • ハッカソン (共同開発またはテスト作業) 用の VM を配布し、イベントの終了時に簡単にプロビジョニング解除する。Distribute VMs for hackathons (collaborative dev or test work), and then easily deprovision them when the event ends.

DevTest Labs の課金方法を教えてください。How am I billed for DevTest Labs?

DevTest Labs は無料サービスです。DevTest Labs is a free service. DevTest Labs でのラボの作成や、ポリシー、テンプレート、アーティファクトの構成は無料です。Creating labs and configuring policies, templates, and artifacts in DevTest Labs is free. VM、ストレージ アカウント、仮想ネットワークなど、ラボ内で使用する Azure リソースに対してのみ課金されます。You pay only for the Azure resources used in your labs, such as VMs, storage accounts, and virtual networks. ラボ リソースのコストの詳細については、「Azure DevTest Labs の価格」をご覧ください。For more information about the cost of lab resources, see Azure DevTest Labs pricing.

セキュリティSecurity

DevTest Labs の各種セキュリティ レベルはどのようなものですか。What are the different security levels in DevTest Labs?

セキュリティ アクセスは、ロールベースのアクセス制御 (RBAC) によって決定されます。Security access is determined by Role-Based Access Control (RBAC). アクセスのしくみを理解するには、RBAC で定義されているアクセス許可、ロール、スコープの違いを理解することが有用です。To learn how access works, it helps to learn the differences between a permission, a role, and a scope, as defined by RBAC.

  • アクセス許可: アクセス許可とは、特定のアクションへのアクセスを定義したものです。Permission: A permission is a defined access to a specific action. たとえば、すべての VM への読み取りアクセス許可などがあります。For example, a permission can be read access to all VMs.
  • ロール: ロールとは、グループ化してユーザーに割り当てることができる一連のアクセス許可です。Role: A role is a set of permissions that can be grouped and assigned to a user. たとえば、サブスクリプション所有者ロールが割り当てられたユーザーは、サブスクリプション内のすべてのリソースにアクセスできます。For example, a user with a subscription owner role has access to all resources within a subscription.
  • [スコープ]: スコープとは、Azure リソースの階層内のレベルです。Scope: A scope is a level within the hierarchy of an Azure resource. たとえば、リソース グループ、単一のラボ、またはサブスクリプション全体をスコープとして指定できます。For example, a scope can be a resource group, a single lab, or the entire subscription.

DevTest Labs のスコープ内には、ユーザーのアクセス許可を定義する次の 2 種類のロールがあります。Within the scope of DevTest Labs, there are two types of roles that define user permissions:

  • ラボ所有者:ラボ所有者は、ラボ内のすべてのリソースにアクセスできます。Lab owner: A lab owner has access to all resources in the lab. ポリシーの変更、任意の VM に対する読み取りと書き込み、仮想ネットワークの変更などを行うことができます。A lab owner can modify policies, read and write to any VMs, change the virtual network, and so on.
  • ラボ ユーザー:ラボ ユーザーは、VM、ポリシー、仮想ネットワークなど、すべてのラボ リソースを表示できます。Lab user: A lab user can view all lab resources, such as VMs, policies, and virtual networks. ただし、ラボ ユーザーは他のユーザーが作成したポリシーや VM を変更することはできません。However, a lab user can't modify policies or any VMs that were created by other users.

DevTest Labs にカスタム ロールを作成することもできます。You also can create custom roles in DevTest Labs. DevTest Labs にカスタム ロールを作成する方法については、「特定のラボ ポリシーに対するアクセス許可をユーザーに付与する」をご覧ください。To learn how to create custom roles in DevTest Labs, see Grant user permissions to specific lab policies.

スコープは階層構造を持つため、特定のスコープでアクセス許可を持つユーザーには、そのスコープのすべての下位のスコープでそれらのアクセス許可が自動的に付与されます。Because scopes are hierarchical, when a user has permissions at a certain scope, the user is automatically granted those permissions at every lower-level scope in the scope. たとえば、ユーザーにサブスクリプション所有者のロールが割り当てられている場合、そのユーザーはサブスクリプションのすべてのリソースにアクセスできます。For instance, if a user is assigned the role of subscription owner, the user has access to all resources in a subscription. これには、VM、仮想ネットワークおよびラボが含まれます。These resources include VMs, virtual networks, and labs. サブスクリプション所有者は、ラボ所有者のロールを自動的に継承します。A subscription owner automatically inherits the role of lab owner. ただし、その逆は真ではありません。However, the opposite is not true. ラボ所有者はラボにアクセスできます。これはサブスクリプション レベルよりも下位のスコープです。A lab owner has access to a lab, which is a lower scope than the subscription level. そのため、ラボ所有者はラボの外部の VM、仮想ネットワーク、またはその他のリソースを表示できません。So, a lab owner can't see VMs, virtual networks, or any other resources that are outside the lab.

IT 部門が管理作業を行い開発者/テスト担当者がそれぞれの作業を行うことができるように、DevTest Labs 環境に対してロールベースのアクセス制御を定義するにはどうすればよいですか?How do I define role-based access control for my DevTest Labs environments to ensure that IT can govern while developers/test can do their work?

おおまかなパターンはありますが、詳細は組織によって異なります。There is a broad pattern, however the detail depends on your organization.

全社的 IT 部門は必要なもののみを所有し、プロジェクトおよびアプリケーション チームが必要なレベルの制御を行えるようにする必要があります。Central IT should own only what is necessary and enable the project and application teams to have the needed level of control. 一般にこれは、全社的 IT 部門はサブスクリプションを所有し、ネットワークの構成などの中核的 IT 機能を扱うことを意味します。Typically, it means that central IT owns the subscription and handles core IT functions such as networking configurations. サブスクリプションの所有者のセットは小規模にする必要があります。The set of owners for a subscription should be small. これらの所有者は、必要に応じて追加の所有者を指名したり、"パブリック IP なし" などのサブスクリプション レベルのポリシーを適用したりできます。These owners can nominate additional owners when there's a need, or apply subscription-level policies, for example “No Public IP”.

レベル 1 やレベル 2 のサポートなど、サブスクリプション全体へのアクセスを必要とするユーザーのサブセットが存在する場合があります。There may be a subset of users that require access across a subscription, such as Tier1 or Tier 2 support. その場合は、このようなユーザーに共同作成者のアクセス権を付与してリソースを管理できるようにしながら、ポリシーへのアクセスやその変更は許可しないことをお勧めします。In this case, we recommend that you give these users the contributor access so that they can manage the resources, but not provide user access or adjust policies.

DevTest Labs のリソースは、プロジェクト/アプリケーション チームの近くにいる所有者によって所有される必要があります。The DevTest Labs resource should be owned by owners who are close to the project/application team. それは、彼らがマシンおよび必須のソフトウェアの要件を理解しているためです。It's because they understand their requirements for machines, and required software. ほとんどの組織では、一般に、この DevTest Labs リソースの所有者はプロジェクト/開発リーダーです。In most organizations, the owner of this DevTest Labs resource is commonly the project/development lead. この所有者は、ラボ環境内のユーザーとポリシーを管理でき、DevTest Labs 環境にあるすべての VM を管理できます。This owner can manage users and policies within the lab environment and can manage all VMs in the DevTest Labs environment.

プロジェクトおよびアプリケーション チームのメンバーは、DevTest Labs ユーザー ロールに追加する必要があります。The project/application team members should be added to the DevTest Labs Users role. これらのユーザーは、仮想マシンを (ラボおよびサブスクリプション レベルのポリシーに従って) 作成できます。These users can create virtual machines (in-line with the lab and subscription-level policies). また、自分が所有する仮想マシンを管理することもできます。They can also manage their own virtual machines. 他のユーザーに属している仮想マシンを管理することはできません。They can't manage virtual machines that belong to other users.

詳細については、「Azure エンタープライズ スキャフォールディング:サブスクリプションの規範的なガバナンス」ドキュメントをご覧ください。For more information, see Azure enterprise scaffold – prescriptive subscription governance documentation.

特定の 1 つのタスクの実行をユーザーに許可するようにロールを作成するにはどうすればよいですか。How do I create a role to allow users to do a specific task?

カスタム ロールを作成し、ロールにアクセス許可を割り当てる方法の詳細については、「特定のラボ ポリシーに対するアクセス許可をユーザーに付与する」をご覧ください。For a comprehensive article about how to create custom roles and assign permissions to a role, see Grant user permissions to specific lab policies. ラボ内のすべての VM を起動および停止するアクセス許可を持つ DevTest Labs Advanced User ロールを作成するスクリプトの例を次に示します。Here's an example of a script that creates the role DevTest Labs Advanced User, which has permission to start and stop all VMs in the lab:

$policyRoleDef = Get-AzRoleDefinition "DevTest Labs User"
$policyRoleDef.Actions.Remove('Microsoft.DevTestLab/Environments/*')
$policyRoleDef.Id = $null
$policyRoleDef.Name = "DevTest Labs Advanced User"
$policyRoleDef.IsCustom = $true
$policyRoleDef.AssignableScopes.Clear()
$policyRoleDef.AssignableScopes.Add("subscriptions/<subscription Id>")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Start/action")
$policyRoleDef.Actions.Add("Microsoft.DevTestLab/labs/virtualMachines/Stop/action")
$policyRoleDef = New-AzRoleDefinition -Role $policyRoleDef  

組織で企業のセキュリティ ポリシーを適用するにはどうすればよいですか。How can an organization ensure corporate security policies are in place?

次の操作を実行することによって実現できます。An organization may achieve it by doing the following actions:

  • 包括的なセキュリティ ポリシーを開発して発行します。Developing and publishing a comprehensive security policy. ポリシーでは、クラウドの資産であるソフトウェアに関連付けられている許容される使用方法の規則を明確に示します。The policy articulates the rules of acceptable use associated with the using software, cloud assets. また、ポリシーに明らかに違反することも定義します。It also defines what clearly violates the policy.
  • カスタム イメージ、カスタム成果物、および Active Directory で定義されているセキュリティ領域内のオーケストレーションを可能にするデプロイ プロセスを開発します。Develop a custom image, custom artifacts, and a deployment process that allows for orchestration within the security realm that is defined with active directory. このアプローチにより、会社の境界が強制され、共通の環境コントロールのセットが設定されます。This approach enforces the corporate boundary and sets a common set of environmental controls. 開発者は、環境に対するこれらのコントロールを、全体的なプロセスの一部としてセキュリティ保護された開発ライフサイクルを開発して従うときに考慮できます。These controls against the environment a developer can consider as they develop and follow a secure development lifecycle as part of their overall process. また、開発の妨げになる可能性のある過剰な制限のない環境を提供しながら、妥当なコントロールのセットを提供するという目的もあります。The objective also is to provide an environment that isn't overly restrictive that may hinder development, but a reasonable set of controls. ラボの仮想マシンを含む組織単位 (OU) でのグループ ポリシーは、運用環境の全体的なグループ ポリシーのサブセットでもかまいません。The group policies at the organization unit (OU) that contains lab virtual machines could be a subset of the total group policies that are found in production. または、識別されたリスクを適切に軽減するための追加セットでもかまいません。Alternatively, they can be an additional set to properly mitigate any identified risks.

リモート開発者がコードを削除したり、マルウェアや未承認のソフトウェアを導入したりできないようにするデータ整合性を確保するにはどうすればよいですか。How can an organization ensure data integrity to ensure that remoting developers can't remove code or introduce malware or unapproved software?

DevTest Labs を使用してリモートで共同作業する外部のコンサルタント、請負業者、または従業員からの脅威を軽減するための複数のコントロール レイヤーがあります。There are several layers of control to mitigate the threat from external consultants, contractors, or employees that are remoting in to collaborate in DevTest Labs.

前に説明したように、最初のステップでは、ユーザーがポリシーに違反したときの影響が明確に説明されている許容される使用ポリシーを起草して定義する必要があります。As stated previously, the first step must have an acceptable use policy drafted and defined that clearly outlines the consequences when someone violates the policy.

リモート アクセスに対するコントロールの最初のレイヤーでは、ラボに直接接続されていない VPN 接続経由でリモート アクセス ポリシーを適用します。The first layer of controls for remote access is to apply a remote access policy through a VPN connection that isn't directly connected to the lab.

コントロールの第 2 のレイヤーでは、リモート デスクトップからのコピーと貼り付けを禁止するグループ ポリシー オブジェクトのセットを適用します。The second layer of controls is to apply a set of group policy objects that prevent copy and paste through remote desktop. 環境外の FTP や RDP サービスなど、環境からの送信サービスを許可しないネットワーク ポリシーを実装できます。A network policy could be implemented to not allow outbound services from the environment such as FTP and RDP services out of the environment. ユーザー定義のルーティングですべての Azure ネットワーク トラフィックをオンプレミスに強制的に戻すことはできますが、プロキシでコンテンツとセッションをスキャンして制御しない限り、データのアップロードを許可する可能性があるすべての URL をルーティングできません。User-defined routing could force all Azure network traffic back to on-premises, but the routing couldn't account for all URLs that might allow uploading of data unless controlled through a proxy to scan content and sessions. 外部ネットワーク リソースのブリッジを禁止するように、DevTest Labs をサポートする仮想ネットワーク内でパブリック IP アドレスを制限できます。Public IPs could be restricted within the virtual network supporting DevTest Labs to not allow bridging of an external network resource.

最終的には、同じ種類の制限を組織全体に適用する必要があります。コンテンツの送信を受け入れる可能性があるリムーバブル メディアまたは外部 URL のすべての可能な方法に対してもです。Ultimately, the same type of restrictions needs to be applied across the organization, which would account for all possible methods of removable media or external URLs that could accept a post of content. セキュリティ担当者とセキュリティ ポリシーを検討して実装してください。Consult with your security professional to review and implement a security policy. 詳しい推奨事項については、Microsoft のサイバー セキュリティに関するページをご覧ください。For more recommendations, see Microsoft Cyber Security.

ラボの構成Lab configuration

Resource Manager テンプレートからラボを作成するにはどうすればよいですか。How do I create a lab from a Resource Manager template?

Microsoft では、そのままデプロイしたり、変更してラボ用のカスタム テンプレートを作成したりできる、ラボの Azure Resource Manager テンプレートの GitHub リポジトリを提供しています。We offer a GitHub repository of lab Azure Resource Manager templates that you can deploy as-is or modify to create custom templates for your labs. 各テンプレートには、ご自分の Azure サブスクリプションにラボをそのままデプロイできるリンクが含まれています。Each template has a link to deploy the lab as it's in your own Azure subscription. また、テンプレートをカスタマイズし、PowerShell または Azure CLI を使用してデプロイすることもできます。Or, you can customize the template and deploy by using PowerShell or Azure CLI.

仮想マシンをその仮想マシン独自のリソース グループにそれぞれ入れるのではなく、すべての仮想マシンを共有のリソース グループに入れて作成することはできますか。Can I have all virtual machines to be created in a common resource group instead having each machine in its own resource group?

はい。ラボの所有者であるあなたは、リソース グループの割り当てをあなたの代わりにラボに処理させることも、あなたが指定した共通のリソース グループにすべての仮想マシンを入れて作成することも可能です。Yes, as a lab owner, you can either let the lab handle resource group allocation for you or have all virtual machines created in a common resource group that you specify.

別のリソース グループのシナリオ:Separate resource group scenario:

  • DevTest Labs が、あなたが作成したすべてのパブリックおよびプライベート IP の仮想マシンに対し、新しいリソース グループを作成します。DevTest Labs creates a new resource group for every public/private IP virtual machine you spin up
  • DevTest Labs は、同じサイズの、IP を共有するマシンに対し、リソース グループを作成します。DevTest Labs creates a resource group for shared IP machines that belong to the same size.

共有のリソース グループのシナリオ:Common resource group scenario:

DevTest Labs 環境全体で名前付け規則を維持するにはどうすればよいですか?How do I maintain a naming convention across my DevTest Labs environment?

現在の社内の名前付け規則を Azure の運用環境にまで拡張し、DevTest Labs 環境全体で一貫性を持たせたいことがあります。You may want to extend current enterprise naming conventions to Azure operations and make them consistent across the DevTest Labs environment. DevTest Labs をデプロイするときは、開始時のポリシーを具体的に設けることをお勧めします。When deploying DevTest Labs, we recommend that you have specific starting policies. 一元化されたスクリプトと JSON テンプレートを使用してポリシーをデプロイすることで、一貫性を適用できます。You deploy these policies by a central script and JSON templates to enforce consistency. 名前付けポリシーは、サブスクリプション レベルで適用される Azure のポリシーによって実装できます。Naming policies can be implemented through Azure policies applied at the subscription level. Azure Policy の JSON サンプルについては、「Azure Policy のサンプル」をご覧ください。For JSON samples for Azure Policy, see Azure Policy samples.

同じサブスクリプションにラボをいくつ作成できますか。How many labs can I create under the same subscription?

サブスクリプションごとに作成できるラボの数に特定の制限はありません。There isn't a specific limit on the number of labs that can be created per subscription. ただし、サブスクリプションごとに使用できるリソースの量には制限があります。However, the amount of resources used per subscription is limited. Azure サブスクリプションの制限とクォータおよびこれらの制限を引き上げる方法に関する記事をご覧ください。You can read about the limits and quotas for Azure subscriptions and how to increase these limits.

ラボごとにいくつの VM を作成できますか。How many VMs can I create per lab?

ラボごとに作成できる VM の数に特定の制限はありません。There is no specific limit on the number of VMs that can be created per lab. ただし、使用できるリソース (VM コア、パブリック IP など) はサブスクリプションごとに制限されています。However, the resources (VM cores, public IP addresses, and so on) that are used are limited per subscription. Azure サブスクリプションの制限とクォータおよびこれらの制限を引き上げる方法に関する記事をご覧ください。You can read about the limits and quotas for Azure subscriptions and how to increase these limits.

ラボあたりのユーザー数と組織全体で必要なラボの総数の比率を決める方法はありますか。How do I determine the ratio of users per lab and the overall number of labs that are needed across an organization?

同じ開発プロジェクトに関連付けられている部署と開発グループは、同じラボに関連付けることをお勧めします。We recommend that business units and development groups that are associated with the same development project are associated with the same lab. 両方のグループに同じ種類のポリシー、イメージ、およびシャットダウン ポリシーを適用できます。It allows for same types of policies, images, and shutdown policies to be applied to both groups.

また、地理的境界を考慮することが必要な場合があります。You may also need to consider geographic boundaries. たとえば、米国 (US) 北東部の開発者は、米国東部 2 でプロビジョニングされたラボを使用できます。For example, developers in the North East United States (US) may use a lab provisioned in East US2. また、テキサス州ダラスおよびコロラド州デンバーの開発者は、米国中南部のリソースを使用できます。And, developers in Dallas, Texas, and Denver, Colorado may be directed to use a resource in US South Central. 外部のサード パーティと共同作業する場合は、社内開発者によって使用されていないラボに割り当てることができます。If there is a collaborative effort with an external third party, they could be assigned to a lab that is not used by internal developers.

また、Azure DevOps Projects 内の特定のプロジェクトのラボを使用することもできます。You may also use a lab for a specific project within Azure DevOps Projects. その後、指定された Azure Active Directory グループによってセキュリティを適用すると、両方のリソースのセットにアクセスできます。Then, you apply security through a specified Azure Active Directory group, which allows access to both set of resources. ラボに割り当てられた仮想ネットワークは、ユーザーを統合する別の境界になる場合があります。The virtual network assigned to the lab can be another boundary to consolidate users.

ラボ内のリソースの削除を防ぐにはどうすればよいですか?How can we prevent the deletion of resources within a lab?

ラボ レベルで適切なアクセス許可を設定し、承認されたユーザーのみがリソースを削除したりラボのポリシーを変更したりできるようにすることをお勧めします。We recommend that you set proper permissions at the lab level so that only authorized users can delete resources or change lab policies. 開発者は、DevTest Labs ユーザー グループ内に配置する必要があります。Developers should be placed within the DevTest Labs Users group. 開発リーダーまたはインフラストラクチャ リーダーが、DevTest Labs 所有者になる必要があります。The lead developer or the infrastructure lead should be the DevTest Labs Owner. ラボの所有者は 2 人のみにすることをお勧めします。We recommend you have only two lab owners. 破損を防ぐため、このポリシーをコード リポジトリに拡張します。This policy extends towards the code repository to avoid corruption. ラボのユーザーは、リソースを使用する権限はありますが、ラボのポリシーを更新することはできません。Lab users have rights to use resources but can't update lab policies. 各組み込みグループがラボ内で持っているロールと権限の一覧については、「Azure DevTest Labs での所有者とユーザーの追加」を参照してください。See the following article that lists the roles and rights that each built-in group has within a lab: Add owners and users in Azure DevTest Labs.

  1. Azure portal でラボに移動します。In the Azure portal, go to the lab.
  2. ブラウザーからラボの URL をコピーし、ラボ ユーザーと共有します。Copy the lab URL from your browser, and then share it with your lab users.

注意

ラボ ユーザーが Microsoft アカウントを持つ外部ユーザーであり、あなたの組織の Active Directory インスタンスのメンバーではない場合、そのユーザーが共有リンクにアクセスしようとすると、エラー メッセージが表示される場合があります。If a lab user is an external user who has a Microsoft account, but who is not a member of your organization's Active Directory instance, the user might see an error message when they try to access the shared link. 外部ユーザーにエラー メッセージが表示された場合は、そのユーザーに、Azure Portal の右上隅に表示されている自分の名前をまず選択してもらいます。If an external user sees an error message, ask the user to first select their name in the upper-right corner of the Azure portal. これで、ユーザーはメニューの [ディレクトリ] セクションで、ラボが存在するディレクトリを選択できるようになります。Then, in the Directory section of the menu, the user can select the directory where the lab exists.

仮想マシンVirtual machines

DevTest Labs で表示されている VM が [仮想マシン] ページに表示されないのはなぜですか。Why can't I see VMs on the Virtual Machines page that I see in DevTest Labs?

DevTest Labs で VM を作成すると、その VM にアクセスするためのアクセス許可が付与されます。When you create a VM in DevTest Labs, you're given permission to access that VM. この VM は、Labs ページと [仮想マシン] ページの両方に表示されます。You can view the VM both on the labs page and on the Virtual Machines page. DevTest ラボの所有者ロールが割り当てられているユーザーは、ラボの [すべての仮想マシン] ページで、ラボで作成されたすべての VM を確認できます。Users assigned to the DevTest Labs Owner role can see all VMs that were created in the lab on the lab's All Virtual Machines page. ただし、DevTest ラボの所有者ロールが割り当てられているユーザーには、他のユーザーが作成した VM リソースへの読み取りアクセス権は自動的に付与されません。However, users who have the DevTest Labs User role are not automatically granted read access to VM resources that other users have created. そのため、これらの VM は [仮想マシン] ページには表示されません。So, those VMs are not displayed on the Virtual Machines page.

同じテンプレートから複数の VM を一度に作成するにはどうすればよいですか。How do I create multiple VMs from the same template at once?

同じテンプレートから複数の VM を一度に作成する場合、次の 2 つのオプションがあります。You have two options for simultaneously creating multiple VMs from the same template:

既存の Azure VM を DevTest Labs ラボに移動するにはどうすればよいですか。How do I move my existing Azure VMs into my DevTest Labs lab?

既存の VM を DevTest Labs にコピーするには、次の手順に従います。To copy your existing VMs to DevTest Labs:

  1. Windows PowerShell スクリプトを使用して、既存の VM の VHD ファイルをコピーします。Copy the VHD file of your existing VM by using a Windows PowerShell script.
  2. ご自分の DevTest Labs ラボ内にカスタム イメージを作成します。Create the custom image inside your DevTest Labs lab.
  3. カスタム イメージからラボ内に VM を作成します。Create a VM in the lab from your custom image.

複数のディスクを VM に接続できますか。Can I attach multiple disks to my VMs?

はい。複数のディスクを VM に接続できます。Yes, you can attach multiple disks to your VMs.

テストに Windows OS イメージを使用する場合、MSDN サブスクリプションを購入する必要はありますか。If I want to use a Windows OS image for my testing, do I have to purchase an MSDN subscription?

Azure でのご自分の開発またはテストに Windows クライアント OS イメージ (Windows 7 以降) を使用するには、次のいずれかの手順を実行します。To use Windows client OS images (Windows 7 or a later version) for your development or testing in Azure, take one of the following steps:

各 MSDN サービスの Azure クレジットの詳細については、「Visual Studio サブスクライバー向けの月単位の Azure クレジット」を参照してください。For more information about the Azure credits for each MSDN offering, see Monthly Azure credit for Visual Studio subscribers.

ラボ内の VM をすべて削除するプロセスを自動化するにはどうすればよいですか。How do I automate the process of deleting all the VMs in my lab?

ラボの所有者として、Azure portal のお使いのラボから VM を削除できます。As a lab owner, you can delete VMs from your lab in the Azure portal. また、PowerShell スクリプトを使用して、ラボ内の VM をすべて削除することもできます。You also can delete all the VMs in your lab by using a PowerShell script. 次の例では、values to change コメントの下のパラメーター値を変更します。In the following example, under the values to change comment, modify the parameter values. Azure portal でラボ ウィンドウから、subscriptionId、labResourceGroup、および labName 値を取得できます。You can retrieve the subscriptionId, labResourceGroup, and labName values from the lab pane in the Azure portal.

# Delete all the VMs in a lab.

# Values to change:
$subscriptionId = "<Enter Azure subscription ID here>"
$labResourceGroup = "<Enter lab's resource group here>"
$labName = "<Enter lab name here>"

# Sign in to your Azure account.
Connect-AzAccount

# Select the Azure subscription that has the lab. This step is optional
# if you have only one subscription.
Select-AzSubscription -SubscriptionId $subscriptionId

# Get the lab that has the VMs that you want to delete.
$lab = Get-AzResource -ResourceId ('subscriptions/' + $subscriptionId + '/resourceGroups/' + $labResourceGroup + '/providers/Microsoft.DevTestLab/labs/' + $labName)

# Get the VMs from that lab.
$labVMs = Get-AzResource | Where-Object {
          $_.ResourceType -eq 'microsoft.devtestlab/labs/virtualmachines' -and
          $_.Name -like "$($lab.Name)/*"}

# Delete the VMs.
foreach($labVM in $labVMs)
{
    Remove-AzResource -ResourceId $labVM.ResourceId -Force
}

環境Environments

DevTest Labs 環境で Resource Manager テンプレートを使用するにはどうすればよいですか。How can I use Resource Manager templates in my DevTest Labs Environment?

DevTest Labs での環境機能に関する記事で説明されている手順を使用して、DevTest Labs 環境にご自分の Resource Manager テンプレートをデプロイします。You deploy your Resource Manager templates into a DevTest Labs environment by using steps mentioned in the Environments feature in DevTest Labs article. 基本的には、Resource Manager テンプレートを Git リポジトリ (Azure Repos または GitHub) にチェックインし、テンプレート用のプライベート リポジトリをラボに追加します。Basically, you check your Resource Manager templates into a Git Repository (either Azure Repos or GitHub), and add a private repository for your templates to the lab. このシナリオは、開発マシンのホストに DevTest Labs を使用している場合には役立たないことがありますが、運用環境の典型であるステージング環境を構築している場合には役立つことがあります。This scenario may not be useful if you're using DevTest Labs to host development machines but may be useful if you're building a staging environment, which is representative of production.

また、ラボごとまたはユーザー オプションごとの仮想マシン数は、ラボ自体にネイティブに作成されるマシンの数のみを制限し、任意の環境 (Resource Manager テンプレート) によって作成されるマシンの数は制限しないこと注意することも重要です。It's also worth noting that the number of virtual machines per lab or per user option only limits the number of machines natively created in the lab itself, and not by any environments (Resource Manager templates).

カスタム イメージCustom Images

カスタム組織イメージを DevTest Labs 環境に展開する簡単に反復可能なプロセスをセットアップするにはどうすればよいですか。How can I set up an easily repeatable process to bring my custom organizational images into a DevTest Labs environment?

次のイメージ ファクトリ パターンに関するビデオをご覧ください。See this video on Image Factory pattern. これは高度なシナリオであり、提供されているスクリプトはサンプル スクリプトのみです。This scenario is an advanced scenario, and the scripts provided are sample scripts only. 何らかの変更が必要な場合は、環境で使用されるスクリプトを自分で管理および保守する必要があります。If any changes are required, you need to manage and maintain the scripts used in your environment.

イメージ ファクトリの作成の詳細については、「Azure DevTest Labs でカスタム イメージ ファクトリを作成する」を参照してください。For detailed information on creating an image factory, see Create a custom image factory in Azure DevTest Labs.

カスタム イメージと数式の違いは何ですか。What is the difference between a custom image and a formula?

カスタム イメージは、マネージド イメージです。A custom image is a managed image. 数式は、追加設定で構成し、保存して再現できるイメージです。A formula is an image that you can configure with additional settings, and then save and reproduce. 同じ基本的な不変イメージを使用して複数の環境をすばやく作成する場合は、カスタム イメージをお勧めします。A custom image might be preferable if you want to quickly create several environments by using the same basic, immutable image. 数式は、最新のビットで、仮想ネットワークまたはサブネットの一部として、または特定のサイズの VM として、VM の構成を再現する場合に適しています。A formula might be better if you want to reproduce the configuration of your VM with the latest bits, as part of a virtual network or subnet, or as a VM of a specific size. 詳細については、「DevTest ラボのカスタム イメージと数式の比較」をご覧ください。For a more in-depth explanation, see Comparing custom images and formulas in DevTest Labs.

定型イメージとカスタム イメージをどのように使い分ける必要がありますか。When should I use a formula vs. custom image?

通常、このシナリオでの決定要因はコストと再利用です。Typically, the deciding factor in this scenario is cost and reuse. 基本イメージに多くのソフトウェアが追加されたイメージを多くのユーザーおよびラボが必要とするシナリオでは、カスタム イメージを作成してコストを減らすことができます。If you have a scenario where many users/labs require an image with a lot of software on top of the base image, then you could reduce costs by creating a custom image. つまり、イメージを 1 回だけ作成します。It means that the image is created once. 仮想マシンのセットアップ時間が短縮され、セットアップ時に仮想マシンの実行が原因で発生するコストが減ります。It reduces the setup time of the virtual machine and the cost incurred due to the virtual machine running when setup occurs.

ただし、注意する必要のあるもう 1 つの要素は、ソフトウェア パッケージに対する変更の頻度です。However, an additional factor to note is the frequency of changes to your software package. ビルドを毎日実行し、ソフトウェアをユーザーの仮想マシンに展開する必要がある場合は、カスタム イメージではなく定型イメージの使用を検討してください。If you run daily builds and require that software to be on your users’ virtual machines, consider using a formula instead of a custom image.

詳細な説明については、「DevTest Labs のカスタム イメージと数式の比較」をご覧ください。For a more in-depth explanation, see Comparing custom images and formulas in DevTest Labs.

カスタム イメージを作成するために VHD ファイルをアップロードするプロセスを自動化するにはどうすればよいですか。How do I automate the process of uploading VHD files to create custom images?

カスタム イメージを作成するために VHD ファイルのアップロードを自動化する場合、次の 2 つのオプションがあります。To automate uploading VHD files to create custom images, you have two options:

  • AzCopy を使用して、ラボに関連付けられているストレージ アカウントに VHD ファイルをコピーまたはアップロードします。Use AzCopy to copy or upload VHD files to the storage account that's associated with the lab.
  • Azure ストレージ エクスプローラーを使用します。Use Azure Storage Explorer. ストレージ エクスプローラーは、Windows、OS X、Linux で動作するスタンドアロン アプリです。Storage Explorer is a standalone app that runs on Windows, OS X, and Linux.

ラボに関連付けられているコピー先ストレージ アカウントを検索するには、次の手順に従います。To find the destination storage account that's associated with your lab:

  1. Azure Portal にサインインします。Sign in to the Azure portal.
  2. 左側のメニューの [リソース グループ] を選択します。On the left menu, select Resource Groups.
  3. ラボに関連付けられているリソース グループを見つけて選択します。Find and select the resource group that's associated with your lab.
  4. [概要] で、いずれかのストレージ アカウントを選択します。Under Overview, select one of the storage accounts.
  5. [BLOB] を選択します。Select Blobs.
  6. 一覧内でアップロードを検索します。Look for uploads in the list. 存在しない場合は、手順 4. に戻り、別のストレージ アカウントを試します。If none exists, return to step 4 and try another storage account.
  7. AzCopy コマンドで、コピー先として URL を使用します。Use the URL as the destination in your AzCopy command.

Azure Marketplace イメージと組織独自のカスタム イメージをどのように使い分ける必要がありますか。When should I use an Azure Marketplace image vs. my own custom organizational image?

Azure Marketplace イメージと組織独自のカスタム イメージをどのように使い分ける必要がありますか。When should I use an Azure Marketplace image vs. my own custom organizational image?

特定の問題または組織の要件がない限り、Azure Marketplace を既定で使用する必要があります。Azure Marketplace should be used by default unless you have specific concerns or organizational requirements. 問題や要件とは、たとえば次のようなものです。Some common examples include;

  • 基本イメージの一部としてアプリケーションを含める必要がある複雑なソフトウェアのセットアップ。Complex software setup that requires an application to be included as part of the base image.
  • アプリケーションのインストールとセットアップに多くの時間がかかる場合。これは、Azure Marketplace イメージに追加される計算時間を効率的に使用していないことになります。Installation and setup of an application could take many hours, which aren't an efficient use of compute time to be added on an Azure Marketplace image.
  • 開発者やテスト担当者が迅速に仮想マシンにアクセスする必要があり、新しい仮想マシンのセットアップ時間を最小限にしたい場合。Developers and testers require access to a virtual machine quickly, and want to minimize the setup time of a new virtual machine.
  • コンプライアンスまたは法規制の条件 (たとえば、セキュリティ ポリシー) をすべてのマシンに適用する必要がある場合。Compliance or regulatory conditions (for example, security policies) that must be in place for all machines.
  • カスタム イメージの使用を軽々しく考えてはいけません。Using custom images shouldn't be considered lightly. 基になっている基本イメージの VHD ファイルを管理する必要が生じるため、複雑さが増します。They introduce extra complexity, as you now must manage VHD files for those underlying base images. また、基本イメージにソフトウェア更新プログラムを定期的に適用する必要があります。You also need to routinely patch those base images with software updates. これらの更新プログラムには、新しいオペレーティング システム (OS) の更新と、ソフトウェア パッケージ自体に必要なすべての更新または構成変更が含まれます。These updates include new operating system (OS) updates, and any updates or configuration changes needed for the software package itself.

アーティファクトArtifacts

アーティファクトとは何ですか。What are artifacts?

アーティファクトは、最新のビットまたは開発用ツールを VM にデプロイするために使用できるカスタマイズ可能な要素です。Artifacts are customizable elements that you can use to deploy your latest bits or deploy your dev tools to a VM. VM の作成時に、アーティファクトを VM に接続します。Attach artifacts to your VM when you create the VM. VM がプロビジョニングされると、アーティファクトによって VM がデプロイされ、構成されます。After the VM is provisioned, the artifacts deploy and configure your VM. パブリック GitHub リポジトリで、さまざまな既存のアーティファクトを利用できます。Various pre-existing artifacts are available in our public GitHub repository. また、独自のアーティファクトを作成することもできます。You can also author your own artifacts.

VM の作成時にアーティファクトでエラーが発生しました。My artifact failed during VM creation. どのようにトラブルシューティングすればよいですか。How do I troubleshoot it?

失敗したアーティファクトのログを取得する方法については、DevTest Labs でアーティファクトの失敗を診断する方法に関する記事をご覧ください。To learn how to get logs for your failed artifact, see How to diagnose artifact failures in DevTest Labs.

DevTest Labs でのパブリック成果物リポジトリとプライベート成果物リポジトリはどのように使い分ける必要がありますか。When should an organization use a public artifact repository vs. private artifact repository in DevTest Labs?

パブリック成果物リポジトリでは、最もよく使用されるソフトウェア パッケージの初期セットが提供されます。The public artifact repository provides an initial set of software packages that are most commonly used. 共通の開発ツールとアドインの再生成に時間をかける必要がなく、すばやくデプロイするのに役立ちます。独自のプライベート リポジトリのデプロイを選択できます。It helps with rapid deployment without having to invest time to reproduce common developer tools and add-ins. You can choose to deploy their own private repository. パブリック リポジトリとプライベート リポジトリを並列で使用できます。You can use a public and a private repository in parallel. パブリック リポジトリを無効にすることもできます。You may also choose to disable the public repository. プライベート リポジトリをデプロイする条件は、以下の質問と考慮事項を基に決定する必要があります。The criteria to deploy a private repository should be driven by the following questions and considerations:

  • 組織には、DevTest Labs オファリングの一部として企業でライセンスされたソフトウェアを使用する要件がありますか。Does the organization have a requirement to have corporate licensed software as part of their DevTest Labs offering? 答えが "はい" の場合は、プライベート リポジトリを作成する必要があります。If the answer is yes, then a private repository should be created.
  • 組織は特定の操作を提供するカスタム ソフトウェアを開発しており、それは全体的なプロビジョニング プロセスの一部として必要ですか。Does the organization develop custom software that provides a specific operation, which is required as part of the overall provisioning process? 答えが "はい" の場合は、プライベート リポジトリをデプロイする必要があります。If the answer is yes, then a private repository should be deployed.
  • 組織のガバナンス ポリシーで分離が必要であり、外部リポジトリの構成を組織が直接管理できない場合は、プライベートの成果物リポジトリをデプロイする必要があります。If organization's governance policy requires isolation, and external repositories aren't under direct configuration management by the organization, a private artifact repository should be deployed. このプロセスの一環として、パブリック リポジトリの初期コピーをコピーし、プライベート リポジトリと統合できます。As part of this process, an initial copy of the public repository can be copied and integrated with the private repository. その後、パブリック リポジトリを無効にして、組織内のだれもそれ以上アクセスできないようにすることができます。Then, the public repository can be disabled so that no one within the organization can access it anymore. この方法では、組織内のすべてのユーザーに対して、組織によって承認された単一のリポジトリのみを使用することが強制され、構成のずれが最小限になります。This approach forces all users within the organization to have only a single repository that is approved by the organization and minimize configuration drift.

組織では単一のリポジトリを計画する必要がありますか、または複数のリポジトリでもかまいませんか。Should an organization plan for a single repository or allow multiple repositories?

組織の全体的なガバナンスと構成管理戦略の一環として、集中管理されたリポジトリを使用することをお勧めします。As part of your organization's overall governance and configuration management strategy, we recommend that you use a centralized repository. 複数のリポジトリを使用すると、時間の経過と共に管理されていないソフトウェアのサイロになる可能性があります。When you use multiple repositories, they may become silos of unmanaged software over the time. 中央リポジトリでは、複数のチームがプロジェクト用にこのリポジトリから成果物を使用できます。With a central repository, multiple teams can consume artifacts from this repository for their projects. それにより、標準化とセキュリティが強制され、管理しやすく、作業の重複がなくなります。It enforces standardization, security, ease of management, and eliminates the duplication of efforts. 一元化の一環として、長期的な管理と持続性のために以下の操作が推奨されます。As part of the centralization, the following actions are recommended practices for long-term management and sustainability:

  • Azure Repos と、Azure サブスクリプションで認証と承認に使用されているものと同じ Azure Active Directory テナントを関連付けます。Associate the Azure Repos with the same Azure Active Directory tenant that the Azure subscription is using for authentication and authorization.
  • 一元管理する All DevTest Labs Developers という名前のグループを Azure Active Directory に作成します。Create a group named All DevTest Labs Developers in Azure Active Directory that is centrally managed. 成果物の開発に関与するすべての開発者を、このグループに入れる必要があります。Any developer who contributes to artifact development should be placed in this group.
  • 同じ Azure Active Directory グループを使用して、Azure Repos リポジトリおよびラボへのアクセスを提供できます。The same Azure Active Directory group can be used to provide access to the Azure Repos repository and to the lab.
  • Azure Repos でブランチまたはフォークを使用して、開発中のリポジトリとプライマリ運用リポジトリを分離する必要があります。In Azure Repos, branching or forking should be used to a separate an in-development repository from the primary production repository. コンテンツは、適切なコード レビュー後に pull request でマスター ブランチのみに追加されます。Content is only added to the master branch with a pull request after a proper code review. コード レビューで変更が承認されたら、マスター ブランチのメンテナンスを担当する開発リーダーが、更新されたコードをマージします。Once the code reviewer approves the change, a lead developer, who is responsible for maintenance of the master branch, merges the updated code.

CI/CD の統合CI/CD integration

DevTest Labs は、CI/CD ツールチェーンと統合されますか。Does DevTest Labs integrate with my CI/CD toolchain?

Azure DevOps を使用している場合は、DevTest Labs Tasks の拡張機能を使用して、DevTest Labs でのご自分のリリース パイプラインを自動化できます。If you're using Azure DevOps, you can use a DevTest Labs Tasks extension to automate your release pipeline in DevTest Labs. この拡張機能を使用して実行できるタスクの一部を次に示します。Some of the tasks that you can do with this extension include:

  • VM を自動的に作成してデプロイします。Create and deploy a VM automatically. Azure ファイル コピーまたは PowerShell の Azure DevOps Services タスクを使用して、最新のビルドで VM を構成することもできます。You also can configure the VM with the latest build by using Azure File Copy or PowerShell Azure DevOps Services tasks.
  • テストの終了後、詳しい調査を目的として同じ VM 上でバグを再現するために、VM の状態を自動的にキャプチャします。Automatically capture the state of a VM after testing to reproduce a bug on the same VM for further investigation.
  • VM が不要になったら、リリース パイプラインの最後で VM を削除します。Delete the VM at the end of the release pipeline, when it's no longer needed.

次のブログ記事では、Azure DevOps Services 拡張機能の使用方法に関するガイダンスと情報を提供しています。The following blog posts offer guidance and information about using the Azure DevOps Services extension:

他の継続的インテグレーション (CI)/継続的デリバリー (CD) ツールチェーンの場合、Azure PowerShell コマンドレット.NET SDK を使用して Azure Resource Manager テンプレートをデプロイすることによって、同じシナリオを実現できます。For other continuous integration (CI)/continuous delivery (CD) toolchains, you can achieve the same scenarios by deploying Azure Resource Manager templates by using Azure PowerShell cmdlets and .NET SDKs. DevTest Labs 用 REST API を使用して、お使いのツールチェーンと統合することもできます。You also can use REST APIs for DevTest Labs to integrate with your toolchain.

ネットワークNetworking

どのような場合に DevTest ラボ環境用の新しい仮想ネットワークを作成する必要があり、どのような場合に既存の仮想ネットワークを使用できますか。When should I create a new virtual network for my DevTest Labs environment vs. using an existing virtual network?

お使いの VM が既存のインフラストラクチャと通信する必要がある場合は、お使いの DevTest Labs 環境内の既存の仮想ネットワークを使用することを検討してください。If your VMs need to interact with existing infrastructure, then consider using an existing virtual network inside your DevTest Labs environment. ExpressRoute を使用している場合は、サブスクリプションで使用が割り当てられているお使いの IP アドレス空間がフラグメント化されないように、VNet およびサブネットの量を最小限に抑えることが必要な場合があります。If you use ExpressRoute, you may want to minimize the amount of VNets / Subnets so that you don’t fragment your IP address space that gets assigned for use in the subscriptions.

また、ここでは (ハブ - スポーク モデル)、VNET ピアリング パターンの使用も検討してください。Consider using the VNet peering pattern here (Hub-Spoke model) too. このアプローチでは、サブスクリプション間で vnet およびサブネットでの通信が可能になります。This approach enables vnet/subnet communication across subscriptions. それ以外の場合は、各 DevTest Labs 環境で専用の仮想ネットワークを使用できます。Otherwise, each DevTest Labs environment could have its own virtual network.

サブスクリプションあたりの仮想ネットワークの数には制限があります。There are limits on the number of virtual networks per subscription. 既定の数は 50 ですが、この制限は 100 まで増やすことができます。The default amount is 50, though this limit can be raised to 100.

共有 IP アドレス、パブリック IP アドレス、プライベート IP アドレスはどのように使い分ける必要がありますか。When should I use a shared IP vs. public IP vs. private IP?

サイト間 VPN または ExpressRoute を使用する場合は、マシンが内部ネットワーク経由ではアクセスできてもパブリック インターネット経由ではアクセスできないように、プライベート IP アドレスの使用を検討します。If you use a site-to-site VPN or Express Route, consider using private IPs so that your machines are accessible via your internal network, and inaccessible over public internet.

注意

ラボの所有者は、このサブネット ポリシーを変更して、ユーザーが各自の VM に誤ってパブリック IP アドレスを作成できないようにすることができます。Lab owners can change this subnet policy to ensure that no one accidentally creates public IP addresses for their VMs. サブスクリプションの所有者は、パブリック IP アドレスが作成されるのを防ぐサブスクリプション ポリシーを作成する必要があります。The subscription owner should create a subscription policy preventing public IPs from being created.

共有パブリック IP アドレスを使用すると、ラボ内の仮想マシンはパブリック IP アドレスを共有します。When using shared public IPs, the virtual machines in a lab share a public IP address. この方法は、特定のサブスクリプションに対するパブリック IP アドレスの制限が違反されるのを防ぐのに役立ちます。This approach can be helpful when you need to avoid breaching the limits on public IP addresses for a given subscription.

はい。Yes. 受信トラフィックと送信トラフィックの 2 つの側面を考慮する必要があります。There are two aspects to consider – inbound and outbound traffic.

  • 受信トラフィック: 仮想マシンがパブリック IP アドレスを持っていない場合、その仮想マシンにはインターネットから到達できません。Inbound traffic – If the virtual machine doesn't have a public IP address, then it cannot be reached by the internet. ユーザーがパブリック IP アドレスを作成できないように、サブスクリプション レベルのポリシーを設定するのが、一般的なアプローチです。A common approach is to ensure that a subscription-level policy is set, such that no user can create a public IP address.
  • 送信トラフィック: 仮想マシンがパブリック インターネットに直接アクセスできないようにし、企業のファイアウォールをトラフィックが通過するよう強制するには、強制ルーティングを使用して、オンプレミスのトラフィックを ExpressRoute または VPN 経由でルーティングします。Outbound traffic – If you want to prevent virtual machines accessing public internet directly and force traffic through a corporate firewall, then you can route traffic on-premises via express route or VPN, by using forced routing.

注意

プロキシ設定のないトラフィックをブロックするプロキシ サーバーがある場合は、ラボの成果物ストレージ アカウントに対する例外を追加することを忘れないでください。If you have a proxy server that blocks traffic without proxy settings, do not forget to add exceptions to the lab’s artifact storage account.

仮想マシンまたはサブネットに対してネットワーク セキュリティ グループを使用することもできます。You could also use network security groups for virtual machines or subnets. このステップにより、トラフィックを許可/ブロックする保護レイヤーが追加されます。This step adds an additional layer of protection to allow / block traffic.

トラブルシューティングTroubleshooting

既存の仮想ネットワークが正しく保存されないのはなぜですか。Why isn't my existing virtual network saving properly?

仮想ネットワーク名にピリオドが含まれていることが原因となっている可能性があります。One possibility is that your virtual network name contains periods. その場合は、ピリオドを削除するか、ハイフンに置き換えてみます。If so, try removing the periods or replacing them with hyphens. その後、仮想ネットワークをもう一度保存してみてください。Then, try again to save the virtual network.

PowerShell から VM をプロビジョニングしたときに、"親リソースが見つからない" ことを示すエラーが発生するのはなぜですか。Why do I get a "Parent resource not found" error when I provision a VM from PowerShell?

リソースが別のリソースの親である場合、子リソースを作成するには、親リソースが存在している必要があります。When one resource is a parent to another resource, the parent resource must exist before you create the child resource. 親リソースが存在しない場合、ParentResourceNotFound メッセージが表示されます。If the parent resource doesn't exist, you see a ParentResourceNotFound message. 親リソースに依存関係を指定していない場合、子リソースは親の前にデプロイされる可能性があります。If you don't specify a dependency on the parent resource, the child resource might be deployed before the parent.

VM は、リソース グループ内のラボの下の子リソースです。VMs are child resources under a lab in a resource group. PowerShell で Resource Manager テンプレートを使用して VM をデプロイした場合、PowerShell スクリプトで指定されたリソース グループ名がラボのリソース グループ名になります。When you use Resource Manager templates to deploy VMs by using PowerShell, the resource group name provided in the PowerShell script should be the resource group name of the lab. 詳細については、Azure へのデプロイで発生する一般的なエラーのトラブルシューティングに関する記事をご覧ください。For more information, see Troubleshoot common Azure deployment errors.

VM のデプロイが失敗した場合、さらに詳しいエラー情報はどこで確認できますか。Where can I find more error information if a VM deployment fails?

VM のデプロイ エラーは、アクティビティ ログに記録されます。VM deployment errors are captured in activity logs. ラボの VM のアクティビティ ログは、ラボの VM ページにあるリソース メニューの [監査ログ] または [仮想マシンの診断] で確認できます (VM ページは、[自分の仮想マシン] の一覧から VM を選択すると表示されます)。You can find lab VM activity logs under Audit logs or Virtual machine diagnostics on the resource menu on the lab's VM page (the page appears after you select the VM from the My virtual machines list).

VM のデプロイが開始される前に、デプロイ エラーが発生する場合もあります。Sometimes, the deployment error occurs before VM deployment begins. たとえば、VM で作成されたリソースのサブスクリプションの制限を超えた場合です。An example is when the subscription limit for a resource that was created with the VM is exceeded. この場合、ラボ レベルのアクティビティ ログにエラーの詳細が記録されます。In this case, the error details are captured in the lab-level activity logs. アクティビティ ログは、[Configuration and policies](構成とポリシー) 設定の下部にあります。Activity logs are located at the bottom of the Configuration and policies settings. Azure でのアクティビティ ログ使用の詳細については、「リソースのアクションを監査するアクティビティ ログの表示」を参照してください。For more information about using activity logs in Azure, see View activity logs to audit actions on resources.