In the first part of this series, we explored the concept of a cloud landing zone and discussed the most common building blocks that are often involved. This part will focus mostly on the implementation itself, getting our hands dirty with everything we learned on theory.

在 本系列 的第一部分 中，我们探讨了云着陆区的概念，并讨论了经常涉及的最常见的构建基块。 这一部分将主要集中于实现本身，使我们不厌其烦地学习理论知识。

To sum the concept of a Landing Zone in a few words, something along the lines of “Reusable blueprint that provide a consistent foundation while increasing efficiency, security, and compliance” makes a lot of sense.

简而言之，着陆区的概念很有意义：“可重复使用的蓝图可提供一致的基础，同时提高效率，安全性和合规性”。

While the best description is a matter of taste and debate, I think it’s safe to assume that the purpose and functionalities are easier to agree on. The scope and implementation of a Landing Zone on the other hand is an area that may include some variation to the discussion.

尽管最好的描述是关于品味和辩论的问题，但我认为可以肯定地认为其目的和功能更容易达成共识。 另一方面，着陆区的范围和实施是一个可能包含一些讨论变化的领域。

A large part of this post is dedicated to creating a Landing Zone solution in practice. There is a considerable amount of Infrastructure as Code and tech buzz below, included with some explanations and reasoning on why we chose to pursue some tech choices. As described in the first part, this example is using Terraform for practical reasons. ARM templates would work just as well, and then you could take advantage of Azure Blueprints.

这篇文章的很大一部分致力于实践中的着陆区解决方案。 下面有大量的基础架构，如代码和技术嗡嗡声，其中包括一些解释和推理，说明了我们为什么选择追求某些技术选择。 如第一部分所述，出于实际原因，本示例使用Terraform。 ARM模板也可以正常工作，然后您可以利用Azure蓝图 。

If you want to jump straight to the reference materials and sample, they are hosted here

如果您想直接跳转到参考资料和示例，请在此处托管

输入CAF地形着陆区 (Enter CAF Terraform Landing Zones)

Within the last couple of years, the Microsoft Cloud Adoption Framework has gained a significant presence. Rightfully so, the CAF is a great foundation for any organization looking to move their workloads to Azure. During an assignment, I was tasked to build a Landing Zone for a multi-subscription organization. I was already pretty deep into planning to manage this with Azure Blueprints when my brother-in-arms Masi Malmi tipped me about the CAF-compliant modules and Landing Zone tools for Terraform!

在过去的几年中，Microsoft Cloud Adoption Framework获得了巨大的成功。 因此，对于希望将工作负载转移到Azure的任何组织来说，CAF都是一个很好的基础。 在分配任务期间，我的任务是为多订阅组织建立一个着陆区。 当我的兄弟Masi Malmi向我介绍了CAF兼容模块和Terraform的着陆区工具时，我已经非常计划使用Azure蓝图来管理此问题！

In this post, we are using the CAF Landing Zones and rover, since they offload so many tasks and steps that we would have to take into account if coming up with a complete custom approach. I strongly advise you to plan this ahead if you are embarking on a Landing Zone journey of your own. Creating a solution from scratch is arguably the best way to learn, but it comes with a steep learning curve.

在本文中，我们将使用CAF着陆区和流动站，因为它们会分担很多任务和步骤，因此如果要使用完整的自定义方法，则必须考虑这些任务和步骤。 如果您要自己着陆，我强烈建议您提前计划。 从头开始创建解决方案可以说是最好的学习方法，但是它具有陡峭的学习曲线。

The CAF Landing Zone setup includes a tool called rover — which includes a Terraform wrapper, among other beneficial tools in a container — which saved me countless hours of repetitive work and spending time on mechanisms that were available already. I have now used these tools for a couple of different projects and they have proven to be an efficient solution if you are working with Terraform and Azure.

CAF着陆区设置包括一个名为流动站的工具-包括一个Terraform包装器，以及一个位于容器中的其他有益工具-为我节省了无数小时的重复工作，并节省了已经可用的机制的时间。 现在，我已经将这些工具用于几个不同的项目，并且如果您正在使用Terraform和Azure，则它们被证明是一种有效的解决方案。

There is plenty of documentation in Github about the code architecture and organizing of the Landing Zones, included with example LZ’s to get anyone started. I have personally taken some liberties for the customer projects since we’ve worked with a more specific toolset.

Github上有很多关于代码架构和着陆区组织的文档，其中包括示例LZ以使任何人入门 。 由于我们使用了更具体的工具集，因此我个人对客户项目采取了一些自由措施。

As said, using Rover as a runtime allows us to offload state management for the most part, and it enables a working level-based approach for creating the Landing Zones. When working on a new subscription, the first thing is to deploy a Launchpad aka Level 0 Landing Zone, which creates the necessary storage for the remote state. Each and every LZ represents a certain “level” which relies on data and parameters that have been set on a previous stage.

如前所述，将Rover用作运行时可以使我们在很大程度上减轻状态管理的负担，并且可以基于工作级别的方法来创建着陆区。 在处理新订阅时，第一件事是部署启动板 (也称为0级着陆区)，该创建区为远程状态创建了必要的存储。 每个LZ都代表一个特定的“级别”，该级别取决于在上一级设置的数据和参数。

Each level is responsible for certain functionalities or parts of the infrastructure, beginning from the low-level basic functionalities, such as roles and policies.

从底层的基本功能(例如角色和策略)开始，每个级别都负责某些功能或基础结构的某些部分。

By design, each Landing Zone is responsible for its state even if Rover makes the management quite straightforward. Each Landing Zone can produce outputs that are then used by the next “levels” of the Landing Zone. This is a great way to pass data to other landing zones and supports the idea of setting certain variables once and using them throughout the lifecycle. Some elements such as tags, regions, and resource IDs can be set once those can be referred to later on as we’ve done with our example.

通过设计，即使Rover使管理非常简单，每个着陆区也要对其状态负责。 每个着陆区都可以产生输出，然后由着陆区的下一个“层”使用。 这是将数据传递到其他着陆区的一种好方法，并且支持一次性设置某些变量并在整个生命周期中使用它们的想法。 一旦我们在示例中完成引用，便可以设置诸如标签，区域和资源ID之类的某些元素。

One important takeaway from the picture above is that the target environment can have as many Landing Zone levels as you see fit. If you are working in an enterprise with a lot of requirements, it might make sense to spread the security and compliance Landing Zone to multiple parts. On the contrary, if you can manage with two or three layers that cater to all your needs as well as the application infrastructure, go ahead! If you look at the picture, you’ll notice that starting from Level 3 the configuration involves application configuration. This is likely something specific to your environment or subscription, so at that point, the Landing Zones will start to branch out from each other and they are no longer identical with each other. In an ideal situation, levels 1 and 2 change rarely, whereas levels 3+ may be redeployed multiple times a day because of ongoing development. If you look at the reference picture, levels 1 and 2 are the common baseline LZ’s that are deployed to each and every subscription, and from that point onwards each subscription may start to branch out separately if they are hosting different workloads.

上图的重要内容之一是目标环境可以具有您认为合适的任意多个着陆区级别。 如果您在有很多要求的企业中工作，则将安全性和合规性着陆区扩展到多个部分可能是有意义的。 相反，如果您可以管理两层或三层以满足您的所有需求以及应用程序基础架构，那就继续吧！ 如果看图片，您会注意到从级别3开始，配置涉及应用程序配置。 这可能是您的环境或订阅所特有的，因此在那时，着陆区将开始彼此分支，并且彼此不再相同。 在理想情况下，级别1和2很少更改，而级别3+可能由于不断发展而一天可能多次重新部署。 如果您查看参考图片，则级别1和2是部署到每个订阅的通用基准LZ，从那时起，如果每个订阅承载不同的工作负载，则它们可能会分别开始分支。

Splitting the Landing Zone to smaller levels provide:

将着陆区划分为较小的级别可提供：

• Least privilege approach — easier to control permissions最低特权方法-更容易控制权限
• Autonomy and modularity — easier to author changes and features自治性和模块化-易于编写更改和功能
• Controlled blast radius — Smaller units of configuration are easier to test爆炸半径受控-较小的配置单位更易于测试
• A consistent toolset that can be used for both development and deployment可以用于开发和部署的一致工具集

Individual Landing Zones and the amount of them depend on your environment and complexity.

各个着陆区及其数量取决于您的环境和复杂性。

Rover also integrates directly with VSCode and the Remote Development extension. This way you can use VSCode to create your Terraform configurations and deploy them directly from your workstation with Rover to ensure they function as expected. This extends the development capabilities so that you can use the same runtime as you would use from a CD pipeline.

Rover还直接与VSCode和Remote Development扩展集成。 这样，您可以使用VSCode创建Terraform配置，并直接使用Rover从工作站部署它们，以确保它们按预期运行。 这扩展了开发功能，因此您可以使用与CD管道中相同的运行时。

Please take a look at the CAF landing zones and rover if you are interested in learning more about them. We are using a fairly simple example in this post which doesn’t even begin to take advantage of all the cool features available. That is to keep this blog from becoming a three-part series.

如果您想了解更多有关CAF着陆区和流动站的信息，请查看它们。 我们在这篇文章中使用的是一个非常简单的示例，它甚至没有开始利用所有可用的出色功能。 这是为了防止该博客成为三部分组成的系列。

动手：Contoso公司简介 (Hands-On: Introducing Contoso Corporation)

Picture this; It’s your first day working in the IT Ops team for Contoso Corporation. Somebody is asking if you could help to create a repeatable, secure, and well-optimized infrastructure template that could be used for all future Azure deployments. Sure thing!

想象一下； 这是您在Contoso Corporation的IT Ops团队工作的第一天。 有人问您是否可以帮助创建可重复，安全且经过优化的基础结构模板，该模板可用于将来的所有Azure部署。 当然可以！

To get things started, we quickly map out the requirements we need to include in our Minimum Viable Product. As I explained in the first part of the series, start from the very basic requirements and work your way from there. Every fine little detail may not be in place from day one. This is as much of software development as any, so define the capabilities and features accordingly. Use agile. Use sprints. Use whatever methods and tools you feel comfortable with to keep the development moving on continuously.

为了让事情开始，我们快速制定了最低可行产品中需要包含的要求。 正如我在系列的第一部分中解释的那样，从最基本的要求开始，然后从那里开始。 从第一天开始，每个细节都可能不到位。 这与软件开发一样多，因此请相应地定义功能。 使用敏捷。 使用冲刺。 使用您认为合适的任何方法和工具来保持开发的持续进行。

Based on an internal brainstorming session we conclude that version 0.1 should deploy the following for each subscription:

根据内部头脑风暴会议，我们得出结论，版本0.1应该为每个订阅部署以下内容：

• Deployment of Log Analytics (configured with Activity Logs for preserving audit data)部署日志分析(配置有活动日志以保留审核数据)
• Deployment of an Azure Policy that enforces certain Azure regions部署强制某些Azure区域的Azure策略的部署
• Deployment of an Azure Policy that denies VMs to use any public IPs部署拒绝虚拟机使用任何公共IP的Azure策略
• Configuration of RBAC with designated Azure AD security groups使用指定的Azure AD安全组配置RBAC
• All resource groups tagged with predefined key:value pairs.所有标有预定义的key：value对的资源组。

To make things a bit easier to maintain later, each deployment must supply some unique input that will be used, such as values for tags, contact information for Azure Security Center, and a short friendly name for the subscription, which will be used in the naming conventions for all resources.

为了使事情在以后易于维护，每个部署必须提供一些将要使用的唯一输入，例如标签的值，Azure安全中心的联系信息以及订阅的简短易记名称(将在所有资源的命名约定。

Now, if you are just starting with the CAF Landing Zones, I suggest using the starter examples and learning from them. Clone the repository, try things out and study the docs. They are a great reference and include a lot of good use cases on how to use the ready-made modules and blueprints in conjunction. However, we want to keep this example fairly short and straightforward so we’ll create our own Landing Zone. We are using the Level 0 (“Launchpad”) that is provided out of the box, to get a head start, but other than that we’ve taken some liberties. Don’t take the examples too literally, they are here to merely prove a point.

现在，如果您只是从CAF着陆区开始，我建议使用入门示例并从中学习。 克隆存储库，尝试一下并研究文档。 它们是很好的参考，其中包含许多有关如何结合使用现成的模块和蓝图的良好用例。 但是，我们希望此示例简短明了，因此我们将创建自己的着陆区。 我们使用开箱即用的0级(“ Launchpad”)来获得领先，但是除此之外，我们还获得了一些自由。 不要从字面上拿出这些例子，它们只是在证明一个观点。

弄脏我们的手 (Getting our hands dirty)

Now, for our experiments let’s use a repository with the original starter LZs as well as the ones we use for this post. Let’s start by cloning the existing CAF repository and start building our fresh Level 1 LZ to a new directory. The last line invokes VSCode so if you prefer to use another IDE, disregard that (although I strongly suggest you use VSCode):

现在，对于我们的实验，让我们使用一个包含原始入门级LZ以及本文中使用的存储库的存储库。 让我们首先克隆现有的CAF存储库，然后开始将新的Level 1 LZ构建到新目录中。 最后一行调用了VSCode，因此，如果您更喜欢使用另一个IDE，则可以忽略它(尽管我强烈建议您使用VSCode)：

git clone https://github.com/anttipo/caf-landingzone-example.gitcode caf-landingzone-example/

If you have the Remote Development -extension installed in your VSCode, you should get a prompt asking if you want to reopen the folder inside a container. Clicking ‘Yes’ will reopen the workspace in the rover container, which makes it easy to run interactive commands directly. If you are using the VSCode and Remote Development combo, you’ll first need to log in with rover:

如果您在VSCode中安装了Remote Development -extension，则应提示您是否要重新打开容器内的文件夹。 单击“是”将重新打开流动站容器中的工作区，这使直接运行交互式命令变得容易。 如果使用VSCode和Remote Development组合，则首先需要使用流动站登录：

# log in similar to azure clirover login# after logging in choose the proper subscription if neededaz account set --subscription <subscription_id>

This will invoke the normal device login process that you are likely used to with AzCLI. Next up we’ll deploy the Level 0 Landing Zone, also known as Launchpad. For this we are using a pre-existing launchpad, that is included in the repository.

这将调用您可能会使用AzCLI的正常设备登录过程。 接下来，我们将部署0级着陆区，也称为启动板。 为此，我们使用存储库中包含的预先存在的启动板。

rover -lz /tf/caf/landingzones/launchpad/ -a apply -launchpad -env sandpit

rover is pretty verbose and will instruct you accordingly if you mistype something important. Having the environment is optional, and it will automatically default to sandpit if nothing is provided. It’s best to learn the habit of including the environment right from the start.

流动站非常冗长，如果您输错重要内容，则会相应地指示您。 具有环境是可选的，如果不提供任何内容，它将自动默认为sandpit。 最好从一开始就学习包括环境在内的习惯。

If everything went as expected, you have some new resources deployed in your Azure subscription! These follow a certain, predefined naming convention with a random prefix, as well as descriptive names of what the resource groups are used for. You can find more information from the Terraform CAF GitHub that describes what these resources are for, but basically, they prepare your subscription and set the stage to deploy more Landing Zones, by creating a Key Vault and storage for the Terraform state.

如果一切都按预期进行，则您的Azure订阅中已部署了一些新资源！ 这些遵循带有随机前缀的特定预定义命名约定，以及资源组的用途的描述性名称。 您可以从Terraform CAF GitHub中找到更多信息，这些信息描述了这些资源的用途，但基本上，它们通过为Terraform状态创建密钥保管库和存储来准备您的订阅并为部署更多着陆区打下基础。

To follow clear and practical conventions, we’ll structure our LZ’s around modules.

为了遵循明确而实用的约定，我们将构建LZ的around模块。

We begin with making a simple module for the Log Analytics part, while taking advantage of the CAF provider, along with some existing modules:

我们首先为Log Analytics部分创建一个简单的模块，同时利用CAF提供程序以及一些现有模块：

We have a separate variables.tf -file which introduces the variables used by the module. Let’s do a similar convention for providing some ready-made RBAC assignments. In our example, we want the LZ to always create three predefined AAD security groups and assign them to appropriate roles. Note that for this module to function you will need to have the appropriate AAD permissions to create security groups:

我们有一个单独的variables.tf -file，它介绍了模块使用的变量。 让我们做一个类似的约定来提供一些现成的RBAC分配。 在我们的示例中，我们希望LZ始终创建三个预定义的AAD安全组并将它们分配给适当的角色。 请注意，要使该模块正常运行，您将需要具有适当的AAD权限才能创建安全组：

Once more for the road, so let’s also create a module for Azure Policy that we want to include with the LZ:

再次上路，让我们也为我们要包含在LZ中的Azure策略创建一个模块：

Then, we call this module from the main.tf -file in our LZ root:

然后，我们从LZ根目录下的main.tf -file调用此模块：

Notice the data “terraform_remote_state” “level0_launchpad” we configured? That is used to pull any outputs that might be necessary from the previous LZ level. We don’t take advantage of it in our Level 1 LZ here but the example in GitHub contains a Level 2 LZ as well which does use this feature for its benefit. Even if you might not need it, it’s good to keep the remote state reference in place for future compatibility.

注意我们配置的数据“ terraform_remote_state”“ level0_launchpad”吗？ 这用于从先前的LZ级别提取任何可能需要的输出。 我们不在这里的Level 1 LZ中利用它，但是GitHub中的示例也包含Level 2 LZ，它确实利用了此功能。 即使您可能不需要它，也最好将远程状态引用保留在适当的位置，以备将来兼容。

We are using the null data source subscription_prefix to form the friendly name that is incorporated in most of the resource names around our landing zone. The subscription_prefix is one of the things we want to provide as an output, so further landing zones can take advantage of it!

我们使用空数据源subscription_prefix来形成友好名称，该友好名称并入我们着陆区周围的大多数资源名称中。 subscription_prefix是我们要提供的输出内容之一，因此更多的着陆区都可以利用它！

OK, we have a very simple yet supposedly functional Landing Zone at our hands. Let’s see how it works with sandbox values that I provide to it as variables in the tfvars file:

好的，我们手边有一个非常简单但功能正常的着陆区。 让我们看看它如何与我作为tfvars文件中的变量提供给它的沙箱值一起工作：

rover -lz /tf/caf/landingzones/landingzone_contoso_level_1 -a plan --var-file /tf/caf/landingzones/landingzone_contoso_level_1/sandpit.tfvars

Time to sit back and observe Rover do its thing, which is basically running terraform plan for the Landing Zone we just provided. If everything goes as planned, the outcome should be a properly evaluated plan of actions that Terraform will take. If no errors are detected, run the same command but instead with apply instead of plan:

是时候坐下来观察罗孚(Rover)做事了，这基本上是我们刚刚提供的着陆区的地形计划 。 如果一切按计划进行，则结果应该是Terraform将采取的适当评估的行动计划。 如果未检测到错误，请运行相同的命令，但使用apply而不是plan ：

rover -lz /tf/caf/landingzones/landingzone_contoso_level_1 -a apply --var-file /tf/caf/landingzones/landingzone_contoso_level_1/sandpit.tfvars

After rover and Terraform are finished, we should have a few new resource groups, one of which includes a Log Analytics workspace.

在流动站和Terraform完成之后，我们应该有几个新的资源组，其中一个包括Log Analytics工作区。

This is already a working yet a very small PoC of a Landing Zone. To scale this to multiple subscriptions or environments you should rely on specifying the values for Terraform variables and apply the same configuration at scale. We’ll use GitHub Actions to deploy this automatically to our sandbox environment. The entire solution with other components of the Landing Zone is available in.

这已经是一个有效的着陆区很小的PoC。 要将其扩展到多个订阅或环境，您应该依靠为Terraform变量指定值并按比例应用相同的配置。 我们将使用GitHub Actions将其自动部署到我们的沙盒环境中。 提供着陆区其他组件的完整解决方案。

OK, so far from the Terraform perspective all this is fairly straightforward. Nothing extraordinary here. What the layered approach brings to the table, is that now we create outputs to represent the important resources. Later levels will be able to import this data from the remote state and reuse the same parameters instead of setting them all again — keeping our code a bit more DRY.

好的，到目前为止，从Terraform角度来看，所有这些都非常简单。 这里没什么特别的。 分层方法带来的好处是，现在我们创建代表重要资源的输出。 更高级别的用户将能够从远程状态导入此数据，并重复使用相同的参数，而无需再次设置所有参数-使我们的代码更加干燥。

For example, this short example shows how a Level 2 Landing Zone can import the data for resource location and tags:

例如，以下简短示例显示了2级着陆区如何导入资源位置和标签的数据：

See? We import the previous state, pull the interesting outputs to local values, and reuse them with all our resources wherever applicable. Convenient!

看到？ 我们导入先前的状态，将有趣的输出拉到局部值，并在适用的情况下将其与我们的所有资源一起重复使用。 方便！

而已？ 接下来是什么？ (That’s it? What next?)

The example used here is an overly straightforward and simple implementation. It is not a direct fit for an enterprise, but rather proves a point and demonstrates a proof of concept on how Landing Zones can be built.

这里使用的示例是一个过于直接和简单的实现。 它不是直接适合企业，而是证明了一个观点并证明了如何构建着陆区的概念证明。

Here are a few more pointers to get you forward:

这里有一些其他的指针可以使您前进：

• Modify the Launchpad (Level 0) according to your needs or create an entirely new version of it. The existing Launchpad creates some resources — such as networking — that you may want to change.根据您的需要修改启动板(级别0)或为其创建一个全新的版本。 现有的启动板会创建一些您可能想要更改的资源(例如网络)。

• Focus on developing a baseline and rely on core controls. By definition, that’s what Landing Zone is about. Don’t incorporate services and controls that are useless for your development teams. You can include such functions as optional layers applied later on.

  专注于制定基准并依靠核心控制 。 根据定义，这就是着陆区。 不要合并对您的开发团队无用的服务和控件。 您可以包含诸如稍后应用的可选图层之类的功能。

• Rely on Terraform best practices and use modules whenever possible, to keep your code DRY.依靠Terraform最佳实践并尽可能使用模块，以使代码保持干燥。

• Don’t spend too much time on irrelevant details. For example, a diagnostic configuration can be called just vnetDiagnostics or something similar because it doesn’t overlap with anything.

  不要在无关紧要的细节上花太多时间。 例如，诊断配置可以称为vnetDiagnostics或类似的名称，因为它不与任何东西重叠。

自动化概念和CI / CD (Automation concepts and CI/CD)

Ok, we’ve spent a good while on learning the ropes of creating and maintaining the configurations. However, especially in large environments, deploying individual Landing Zones manually becomes a burden very quickly.

好的，我们花了很多时间来学习创建和维护配置的绳索。 但是，尤其是在大型环境中，手动部署各个着陆区很快成为一种负担。

One working approach is to provide each environment or subscription a dedicated tfvars -file, which includes the variable values unique to the environment. This way, the Landing Zone configuration stays intact and can be deployed at scale, while the environment-specific values may change whenever necessary. This keeps each deployment pretty much identical to each other, which streamlines the deployment event further. Depending on your CI/CD solution, this kind of approach may require separate deployment pipelines for each subscription or something resembling the Azure DevOps’s variable groups, so you could use the same pipeline but rotate the variables per deployment or environment.

一种可行的方法是为每个环境或订阅提供专用的tfvars -file，该文件包括该环境唯一的变量值。 这样，着陆区配置保持不变，可以大规模部署，而特定于环境的值可以在必要时更改。 这样可以使每个部署几乎完全相同，从而进一步简化了部署事件。 根据您的CI / CD解决方案，这种方法可能需要为每个订阅使用单独的部署管道或类似于Azure DevOps变量组的部署管道，因此您可以使用相同的管道，但是根据部署或环境旋转变量。

We are gonna harness our LZ to GitHub Actions, which we mimicked from the CAF Terraform repos, and do a simple deployment consisting of:

我们将把我们的LZ运用到GitHub Actions(我们从CAF Terraform仓库中模仿)，并进行以下简单部署：

• Deploy Launchpad/Level 0 if not present部署启动板/级别0(如果不存在)
• Plan & Apply Level 1计划和申请第1级
• Plan & Apply Level 2计划和申请第2级
• Destroy Level 2摧毁2级
• Destroy Level 1摧毁1级
• Destroy Launchpad/Level 0摧毁发射台/等级0

So as you can see we basically want to deploy all our current LZs and then get rid of them in an automated fashion. While we cannot use the resources since they are instantly removed, we’ll get the verification that individual levels work with each other and there are no errors in the pipeline. I suggest incorporating this sort of build for testing purposes, so that whenever someone files a change, the setup can be deployed once to a sandbox environment to verify that everything remains intact and functional.

因此，正如您所看到的，我们基本上想部署所有当前的LZ，然后以自动化的方式消除它们。 虽然由于资源被立即删除而无法使用这些资源，但我们将获得验证，证明各个级别可以相互配合并且管道中没有错误。 我建议出于测试目的而合并这种构建，以便每当有人提出更改时，都可以将安装程序一次部署到沙盒环境中，以验证所有内容是否完好无损。

First up, you’ll need a service principal that the workflow will use to log in to your subscription.

首先，您需要一个服务主体，工作流将使用该服务主体来登录到您的订阅。

# create a new service principal with azure cliSPNAME="<yourServicePrincipalName>"az ad sp create-for-rbac --name $SPNAME

Once you have create the service principal, note down the following parameters and add them as individual secrets on GitHub:

创建服务主体后，记下以下参数并将它们作为单独的秘密添加到GitHub：

In order to properly use the example LZ, you will need to provide the subscription owner role, as well as the necessary AAD permissions for this principal. After that, create a new yaml file to describe your build workflow or clone the one used in this example and modify it according to your needs. Save the file as /.github/workflows/deploy.yml

为了正确使用示例LZ，您将需要提供订阅所有者角色，以及为此主体提供必要的AAD权限。 之后，创建一个新的yaml文件来描述您的构建工作流程，或克隆本示例中使用的文件并根据您的需要进行修改。 将文件另存为/.github/workflows/deploy.yml

The entire example is hosted here

整个示例在此处托管

If everything goes as planned (and why wouldn’t it) you can observe your GitHub Actions Workflow kick in and deploy the Landing Zone once in its entirety, and then destroy the LZ as well at the end. Obviously this isn’t much good if you want to actually deploy the resources, in which case you should remove the pipeline steps that destroy the LZs.

如果一切都按计划进行(为什么不这样做)，您可以观察到GitHub Actions工作流的启动，并一次完整地部署着陆区，然后最后也销毁LZ。 显然，如果您想实际部署资源，这不是很好，在这种情况下，您应该删除破坏LZ的流水线步骤。

结论 (Conclusion)

Throughout the two posts, we’ve explored concepts, methods and the common patterns of creating a Landing Zone. Due to the tools and on-demand nature of the public cloud platforms, LZ is a logical choice there but is by no means limited to only the public offering. Similar orchestration can be achieved with a private cloud as well, even if the toolkit may look a bit different.

在这两篇文章中，我们探讨了创建着陆区的概念，方法和常见模式。 由于公共云平台的工具和按需性质，LZ在那是合乎逻辑的选择，但绝不仅限于公共产品。 即使工具包看起来有些不同，也可以使用私有云实现类似的编排。

If you find yourself or your organization in demand of a repeatable and modular way to bootstrap cloud subscriptions or accounts, investing time for Landing Zones is likely worth the effort. If your cloud journey takes place in Azure, the Cloud Adoption Framework will serve as an endless source of guidance and practices for your migration.

如果您发现自己或您的组织需要可重复且模块化的方式来引导云订阅或帐户，那么为登陆区域投入时间可能是值得的。 如果您的云计算之旅是在Azure上进行的，则Cloud Adoption Framework将为您的迁移提供无穷的指导和实践。