Skip to content
This repository was archived by the owner on Oct 12, 2023. It is now read-only.

Commit 927e52f

Browse files
bennagebennage
authored
Minimal viable documentation for vnext (#125)
* initial commit of minimal viable docs * update on design principles * update to principles * adding quickstart * corrections * added instructions for teardown * draft of readme * update lab readme * link to release notes * ready for review * broken link * cleanup * corrections * more feedback
1 parent f0b3944 commit 927e52f

File tree

5 files changed

+317
-14
lines changed

5 files changed

+317
-14
lines changed

Diff for: ‎Docs/Release/2019-09.md

+36
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,36 @@
1+
# September 2019 2.0 (Preview Release)
2+
_Azure Virtual Datacenter Toolkit_
3+
4+
The **September 2019** preview release represents a major change for the toolkit.
5+
There are numerous breaking changes and hence we incrementing the major version to 2.
6+
7+
We have revisited our core [design princilpes]() and this lead to significant architectural changes.
8+
9+
At a high level, these include:
10+
11+
- Using [Azure DevOps]() as the default for orchestrating a deployment using [YAML pipelines][]
12+
- Reducing the use of custom code and constructs
13+
- [Modules][] can now be deployed without any custom code
14+
- Promoting [_Landing Zone_]() as a core pattern
15+
- Improving auditability of deployments
16+
17+
NOTE:
18+
The toolkit is in _preview_.
19+
The approach of the toolkit is based on work with our customers, but the specific implementation of this release is not production-ready.
20+
21+
## General changes
22+
23+
* The toolkit now uses [PowerShell Core 6.2][] with [Az PowerShell][] modules.
24+
* There is _no longer any Python scripts_ beginning with this release
25+
* [Modules][] are deployment engine agnostic.
26+
- You don't have to use anything proprietary to deploy a module.
27+
- Modules consist of templates and parameters that can be deployed just like any other Azure Resource Manager template.
28+
29+
## Known Issues
30+
31+
* Lack of documentation
32+
33+
[Modules]: ../../Modules
34+
[YAML pipelines]: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/stages?view=azure-devops&tabs=yaml
35+
[PowerShell Core 6.2]: https://docs.microsoft.com/en-us/powershell/scripting/whats-new/what-s-new-in-powershell-core-62?view=powershell-6
36+
[Az PowerShell]: https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-2.5.0

Diff for: ‎Docs/design-principles.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
# Design Principles
2+
3+
These design principles drive the decisions around the toolkit's features and architecture.
4+
Understanding the design principles is helpful for understanding the intended usage of the toolkit.
5+
6+
Contributors should be familar with these principles before submiting a pull request or recommending a new feature.
7+
8+
There are some instances where the current implementation is not consistent with the stated design principles.
9+
However, the intent to always improve consistency.
10+
11+
## Everything-as-Code, Declarative, and Automated
12+
13+
The toolkit is following the common [principles of DevOps](https://docs.microsoft.com/azure/architecture/checklist/dev-ops).
14+
15+
We place an emphasis on [infrastructure-as-code (IaC)](https://en.wikipedia.org/wiki/Infrastructure_as_code) following a [declarative approach](https://en.wikipedia.org/wiki/Declarative_programming). This principle is extended to policy and process (i.e., gated release process).
16+
**Anything that can be managed through code, should be managed in code.** This is what is meant by _everything-as-code_.
17+
18+
The declarative model means that the code describes a _desired state_ and that some run-time is responsbile for interpreting the code and establishing the desire state. A declarative approach is contrasted against an imperative or procedural approach. An imperative approach provides a set of steps to execute and a desired state can only be infer (at best) from the steps. Azure Resource Manager templates and Azure Policy are declarative.
19+
20+
Automation is a third pillar along with everything-as-code and the declarative approach.
21+
Any change of state should be intiated as a change to source code. The change in source code triggers an automated process, that includes validation and safety checks. This allows for more predictable outcomes and reduces the risk of human error.
22+
**Anything that can be automated, should be automated.**
23+
24+
## Don't abstract the platform
25+
26+
The toolkit should avoid introducing abstractions that encapsulate the native platform.
27+
Instead, it should leverage native features and existing technologies as much as possible.
28+
29+
Any custom code included in the toolkit should be use to compose (or "glue together") native features.
30+
31+
## Open technology choices
32+
33+
A core purpose for the toolkit is to provide end-to-end reference implementations for core enterprise control plane scenarios. The reference implementations are concrete implementations and we have to choose specific technologies. While we have chosen native Azure technologies for our reference implementations, we recognize that customers may have other technology preferences.
34+
35+
The toolkit should avoid designs that introduce [tight coupling](https://en.wikipedia.org/wiki/Loose_coupling) between different functions. For example, the technology used to orchestrate a deployment (i.e., Azure DevOps, Jenkins) should not restrict the technology used to define the deployment (i.e., Azure Resource Manager templates, Terraform).
36+
37+
## Common tools for automation and manual process
38+
39+
Any automatation should follow the same steps and use the same tools that a developer would use manually.
40+
For example, a CI/CD pipeline in Azure DevOps should invoke the same commands that a human being would use when deploying manually.
41+
By having common tools and prodcedures, outcomes are more predictable.

Diff for: ‎Docs/quickstart.md

+200
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,200 @@
1+
# Toolkit Quickstart Guide
2+
3+
This guide will walk you through deploying one of the example archetypes provided in the toolkit.
4+
Specifically, we will deploy a [shared services](../Environments/SharedServices) that does not depend on an on-premises environment.
5+
6+
## Prerequisites
7+
8+
At a minimum you will need to follow this quickstart:
9+
* [Docker](https://www.docker.com/get-started)
10+
* [Git](https://git-scm.com/downloads)
11+
12+
We recommended [Visual Studio Code](https://code.visualstudio.com/) as well, though any text editor will suffice.
13+
14+
You can install these on your local machine, or you can the lab VM provided in the toolkit.
15+
See these instructions for [setting up the lab VM](../LabVM/README.md).
16+
17+
After these prerequisties are installed, we will [clone the reposistory on GitHub](https://help.github.com/en/articles/cloning-a-repository-from-github) and [build a Docker image](https://docs.docker.com/glossary/?term=build).
18+
This quickstart assumes that you will be interacting with the toolkit through the Docker image.
19+
20+
### Clone the repository
21+
22+
These steps assume that the `git` command is on your path.
23+
24+
1. Open a terminal window
25+
1. Navigate to a folder where you want to store the source for the toolkit. If you are using the labVM, you can use the default `c:\Users\vdcadmin` folder.
26+
1. Run `git clone https://github.com/Azure/vdc.git`. This will clone the GitHub repository in a folder named `vdc`.
27+
1. Run `cd vdc` to change directory in the source folder.
28+
1. Run `git checkout master` to switch to the branch with the current in-development version of the toolkit.
29+
30+
### Build the Docker image
31+
32+
1. Ensure that the [Docker daemon](https://docs.docker.com/config/daemon/) is running. If you are new to Docker, the easiest way to do this is to install [Docker Desktop](https://www.docker.com/products/docker-desktop).
33+
1. Open a terminal window
34+
1. Navigate to the folder where you cloned the repository. _The rest of the quickstart assumes that this path is `C:\Users\vdcadmin\vdc\`_
35+
1. Run `docker build . -t vdc:latest` to build the image.
36+
37+
### Run the toolkit container
38+
After the image finishing building, you can run it using:
39+
40+
`docker run -it --rm -v C:\Users\vdcadmin\vdc\Config:/usr/src/app/Config -v C:\Users\vdcadmin\vdc\Environments:/usr/src/app/Environments -v C:\Users\vdcadmin\vdc\Modules:/usr/src/app/Modules vdc:latest`
41+
42+
A few things to note:
43+
- You don't need to build the image every time you want to run the container. You'll only need to rebuild it if there are changes to the source (primarily changes in the `Orchestration` folder).
44+
- The `docker run` command above will map volumes in the container to volumes on the host machine. This will allow you to directly modify files in these directories (`Config`,`Environments`, and `Modules`).
45+
46+
When the container starts, you will see the prompt
47+
`PS /usr/src/app>`
48+
49+
## Configure the toolkit
50+
51+
To configure the toolkit for this quickstart, we will need to collect the following information.
52+
53+
You'll need:
54+
- A subscription for the toolkit to use for logging and tracking deployment.
55+
- A subscription that we'll deploy a shared services environment into.
56+
- The associated tenant id of the Azure Active Directory associated with those subscriptions.
57+
- The object id of the user account that you'll use to run the deployment.
58+
- The object id of a [service principal](https://docs.microsoft.com/azure/active-directory/develop/howto-create-service-principal-portal) that Azure DevOps can use for deployment.
59+
- An organizatgion name for generating a prefix for naming resources. This can be something fictious like "contoso".
60+
- The desired username and password for the Active Directory domain admin that will be created.
61+
- The [public ssh key](https://docs.microsoft.com/azure/virtual-machines/linux/mac-create-ssh-keys) for accessing the Linux jumpbox.
62+
- The desired password of the Windows jumpbox.
63+
64+
Note: You can use a single subscription. You'll just need to provide the same subscription id in multiple locations in the configuration.
65+
66+
### Collecting user object id and tentant id
67+
68+
You can get your user object id and tenant id in the portal or by using command line utitilies.
69+
70+
Using Azure PowerShell:
71+
1. Run `Connect-AzAccount` to login and set an Azure context.
72+
1. Run `Get-AzContext | % { Get-AzADUser -UserPrincipalName $($_.Account.Id) } | select Id` to get the user object id.
73+
1. Run `Get-AzContext | select Tenant` to get the tenant id.
74+
75+
Additional details on these cmdlets are here:
76+
- [Connect-AzAccount](https://docs.microsoft.com/powershell/module/az.accounts/connect-azaccount?view=azps-2.6.0)
77+
- [Get-AzContext](https://docs.microsoft.com/powershell/module/az.accounts/get-azcontext?view=azps-2.6.0)
78+
- [Get-AzADUser](https://docs.microsoft.com/powershell/module/az.resources/get-azaduser?view=azps-2.6.0)
79+
- [select](https://docs.microsoft.com/powershell/module/microsoft.powershell.utility/select-object?view=powershell-6)
80+
81+
### Azure DevOps service principal
82+
83+
Strictly speaking, you do not need a service principal for the purpose of this quickstart.
84+
You can reuse your user object id in place of the service principal object id.
85+
However, if you want to deploy using Azure DevOps will need to create the service principal.
86+
87+
Follow [thse instructions](https://docs.microsoft.com/azure/active-directory/develop/howto-create-service-principal-portal) for creating the service principal and note the object id during creation. The service principal will require owner permissions.
88+
89+
### Setting the configuration
90+
91+
To deploy the shared services environment, you will need to modify two configuration files and set several environmental variables.
92+
93+
#### [`Config\toolkit.subscription.json`](../Config/toolkit.subscription.json)
94+
95+
This file is for toolkit configuration in general.
96+
97+
- Set `Subscription.TenantId` to the tenant id note above.
98+
- Set `Subscription.SubscriptionId` to the id of the subscription used for logging and deployment state tracking noted above.
99+
100+
#### [`Environments\_Common\subscriptions.json`](../Environments/_Common/subscriptions.json)
101+
102+
This file is for the deployment enviroments configuration. In the quickstart, we are only interested in the `SharedServices`.
103+
104+
- Set `SharedServices.TenantId` to the tenant id note above.
105+
- Set `SharedServices.SubscriptionId` to the id of the target subscription for the deployment noted above.
106+
107+
#### Environmental variables
108+
109+
The toolkit uses environmental variables instead of configuration files to help avoid the accidental inclusion of secrets into your source control. In the context of a CI/CD pipeline, these values would be retrieved from a key vault.
110+
111+
You can set these environmental variables by substituting the actual values in the script below.
112+
You can then copy and paste this script into PowerShell to execute it.
113+
114+
Note: The first two variables are set with the content of the configuration files we just modified. The path will not resolve correctly unless you are in `/usr/src/app` directory.
115+
116+
```PowerShell
117+
$ENV:VDC_SUBSCRIPTIONS = (Get-Content .\Environments\_Common\subscriptions.json -Raw)
118+
$ENV:VDC_TOOLKIT_SUBSCRIPTION = (Get-Content .\Config\toolkit.subscription.json -Raw)
119+
120+
$ENV:ORGANIZATION_NAME = "contoso"
121+
$ENV:TENANT_ID = "00000000-0000-0000-0000-000000000000"
122+
123+
$ENV:KEYVAULT_MANAGEMENT_USER_ID = "00000000-0000-0000-0000-000000000000"
124+
$ENV:DEVOPS_SERVICE_PRINCIPAL_USER_ID = "00000000-0000-0000-0000-000000000000"
125+
126+
$ENV:DOMAIN_ADMIN_USERNAME = "xxx"
127+
$ENV:DOMAIN_ADMIN_USER_PWD = "yyy"
128+
129+
$ENV:ADMIN_USER_PWD = "zzz"
130+
131+
$ENV:ADMIN_USER_SSH = "ssh-rsa ... [email protected]"
132+
```
133+
134+
To use the above script:
135+
136+
1. Return to the running Docker container from earlier in the quickstart.
137+
1. Confirm that you are in the `/usr/src/app` directory.
138+
1. Make a copy of the above script and replace the necessary values.
139+
1. Copy the script into the clipboard and paste it in the terminal.
140+
1. Verify that the enviromental variables are set by running `env` to view the current values.
141+
142+
## Deploying the shared services environment
143+
144+
1. Return to the running Docker container from earlier in the quickstart.
145+
1. If you have not already done so, run `Connect-AzAccount` to login and set an Azure context.
146+
1. To deply the entire shared services environment, you can run a single command:
147+
148+
``` PowerShell
149+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json
150+
```
151+
152+
The toolkit will begin deploying the constituent modules and the status will be sent to the terminal.
153+
Open the [Azure portal](https://portal.azure.com) and you can check the status of the invididual deployments.
154+
155+
## Deploying individual moduels
156+
157+
If you prefer you can deploy the constituent modules for shared services individually.
158+
The following is the series of commands to execute.
159+
160+
``` PowerShell
161+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "DiagnosticStorageAccount"
162+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "LogAnalytics"
163+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "AutomationAccounts"
164+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "LinkLogAnalyticsWithAutomationAccount"
165+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "JumpboxASG"
166+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "DomainControllerASG"
167+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "SharedServicesNSG"
168+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "DMZNSG"
169+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "SharedServicesRouteTable"
170+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "VirtualNetwork"
171+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "EnableServiceEndpointOnDiagnosticStorageAccount"
172+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "VirtualNetworkGateway"
173+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "LocalVirtualNetworkGatewayConnection"
174+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "RemoteVirtualNetworkGatewayConnection"
175+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "AzureFirewall"
176+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "KeyVault"
177+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -DefinitionPath ./Environments/SharedServices/definition.json -ModuleConfigurationName "ArtifactsStorageAccount"
178+
```
179+
180+
### Teardown the environment
181+
182+
You can easily tear down the shared services environment by running this command:
183+
184+
``` PowerShell
185+
./Orchestration/OrchestrationService/ModuleConfigurationDeployment.ps1 -TearDownEnvironment -DefinitionPath ./Environments/SharedServices/definition.json
186+
```
187+
188+
> Note: This is the same command you used to deploy expect that you include ` -TearDownEnvironment`.
189+
> It uses the same configuration, so if you change the configuration the tear down may not execute as expected.
190+
191+
For safety reasons, the key vault will not be deleted. Instead, it will be set to a _removed_ state. This means that the name is still considered in use. To fully delete the key vault, use:
192+
193+
``` PowerShell
194+
Get-AzKeyVault -InRemovedState | ? { Write-Host "Removing vault: $($_.VaultName)"; Remove-AzKeyVault -InRemovedState -VaultName $_.VaultName -Location $_.Location -Force }
195+
```
196+
197+
### Next steps
198+
199+
Congratulations! You've deployed your first environment with the VDC Toolkit.
200+
Please be sure to [report any issues](https://github.com/Azure/vdc/issues) you might encounter.

Diff for: ‎LabVM/README.md

+20-10
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,31 @@
1-
# Azure Virtual Datacenter Admin Workstation
2-
This one click deployment will build a VDC Admin & Development box in Azure. All of the tools required to build and admin a VDC are installed.
1+
# Azure Virtual Datacenter lab workstation
2+
3+
This one click deployment will build the toolkit development box in Azure.
4+
All of the dependencies required to use the toolkit are installed.
35

46
<a href="https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fvdc%2Fvnext%2FLabVM%2Fazure-deploy.json" target="_blank">
57
<img src="http://azuredeploy.net/deploybutton.png"/>
68
</a>
79

8-
**Software included on the VM**
10+
> NOTE This can take 30 minutes to set up. Please be aware that if you login too early, the software won't be ready.
11+
12+
## Software included on the VM
913

1014
1. Docker for Windows Community Edition
1115
1. Git for Windows (bash)
1216
1. Visual Studio Code with Extentions: Azure ARM Tools, Azure CLI, Python Linting, Docker, PowerShell
1317

14-
**Creds**
15-
1. User: vdcadmin
16-
1. Password: Password.1!!
18+
See the [`auzre-deploy.json` file for credentials](azure-deploy.json#L16-L17).
19+
20+
> NOTE Storing credentials in source code is a very bad practice.
21+
> You should change these credentials as soon as you log into the VM.
22+
23+
## Starting Docker
24+
- Once the VM is deployed use the Azure portal to connect.
25+
- Double click the Docker for Windows shortcut on the desktop.
26+
- It will take a few minutes for Docker to start the first time.
27+
- You may need to sign out and sign back in for Docker to work.
28+
1729

18-
**Starting Docker**
19-
1. Once the VM is deployed use the Azure portal to connect.
20-
1. Double click the Docker for Windows shortcut on the desktop.
21-
1. It will take a few minutes for Docker to start the first time.
30+
## Next steps
31+
Checkout the [quick start guide](../Docs/quickstart.md).

0 commit comments

Comments
 (0)