diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 00000000..272cbd70
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
new file mode 100644
index 00000000..24473dee
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.
\ No newline at end of file
diff --git a/.github/workflows/.template.terraform.yml b/.github/workflows/.template.terraform.yml
index 02e58f50..8297fa0f 100644
--- a/.github/workflows/.template.terraform.yml
+++ b/.github/workflows/.template.terraform.yml
@@ -38,7 +38,7 @@ jobs:
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
- terraform_version: ${{ inputs.terraform_version }}
+ terraform_version: ${{ inputs.terraformVersion }}
# Log into Azure via OIDC
- uses: azure/login@v1
diff --git a/.gitignore b/.gitignore
index dbca554e..91f49915 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,7 +43,7 @@ override.tf.json
# Ignore CLI configuration files
.terraformrc
terraform.rc
-shared/agentsetup.ps1
+# shared/agentsetup.ps1
.vscode/tasks.json
.vscode/launch.json
.vscode/launch.json
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 18395837..7507bd32 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,6 +19,7 @@
---
## Contributing
+
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
@@ -30,6 +31,7 @@ The rest of this document outlines a few important notes/guidelines to help us t
## GitHub Operations, Conventions and other Standards
### GitHub Basics
+
The following guides provide basic knowledge for understanding Git command usage and the workflow of GitHub.
- [Introduction to version control with Git](https://docs.microsoft.com/learn/paths/intro-to-vc-git/)
@@ -37,12 +39,14 @@ The following guides provide basic knowledge for understanding Git command usage
- [GitHub Flow](https://guides.github.com/introduction/flow/)
### Folder Structure and Naming Conventions
+
- Github uses ASCII for ordering files and folders. For consistent ordering create all files and folders in **lowercase**. The only exception to this guideline is the *common supporting files* such as README.md, CONTRIBUTING.md etc files, that should be in the format **UPPERCASE.lowercase**. Remember that there are operating systems that handle files with different casing as distinct files, so we need to avoid these kind of conflicts.
- Avoid **camelCase** for files and folders consisting of two or more words. Use only lowercase and append words with dashes, i.e. **`folder-name-one`** and **not** `folderNameOne`
> NOTE: the aforementioned rules can be overridden, if any Language Coding Styles or Guidelines instruct the usage of different conventions
-Below you can see the selected folder structure for the project. The main folders and a brief description of their purpose is as follows:
+Below you can see the selected folder structure for the project. The main folders and a brief description of their purpose is as follows:
+
- **docs**
The *docs* folder contains two subfolders; **design-areas** and **media**.
- The **design-areas** subfolder contains the relevant documentation.
@@ -107,6 +111,7 @@ Unless you are working with multiple contributors on the same file, we ask that
- [Contributing to GitHub projects](https://guides.github.com/activities/forking/).
### Branch Naming Standards
+
For branches, use the following prefixes depending on which is most applicable to the work being done:
| Prefix | Purpose |
|-------------|-----------|
@@ -118,10 +123,11 @@ For branches, use the following prefixes depending on which is most applicable t
|test/|Any task pertaining to testing updates |
### Commit Standards (optional)
+
Prefixing the commits as described below, is **optional**, however is **highly encouraged**.
For commits, use the following prefixes depending on which is most applicable to the changes:
-| Prefix | Purpose |
-|-------------|-----------|
+| Prefix | Purpose |
+|-------------|-----------|
|fix:|Update to code base or bug|
|feat:|New feature added to code base|
|chore:|Basic task to update formatting or versions, etc.|
@@ -129,11 +135,13 @@ For commits, use the following prefixes depending on which is most applicable to
|ci:|New workflow or updates to workflow(s) |
|test:|New tests or updates to testing framework(s) |
-## Style Guide and coding conventions
-A guide outlining the coding conventions and style guidelines that should be followed when contributing code to the repository is outlined below:
+## Style Guide and coding conventions
+
+A guide outlining the coding conventions and style guidelines that should be followed when contributing code to the repository is outlined below:
### Bicep Best Practices and Conventions
-- The starting point for any deployment should be named **main.bicep**. This (usually) should be the main deployment file, scoped at *subscription* level, and it would call several sub-deployments, usually at the resource group scope.
+
+- The starting point for any deployment should be named **main.bicep**. This (usually) should be the main deployment file, scoped at *subscription* level, and it would call several sub-deployments, usually at the resource group scope.
- The **main.bicep** file should be accompanied with a parameter file named **main.parameters.jsonc**. The benefit of the `*.jsonc` file extension is that you can use inline comments (either `//` or `/* ... */`) in Visual Studio Code (otherwise you will get an error message saying "*Comments not permitted in JSON*"). [Bicep Parameter Files](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameter-files)
- Details of using the deployment should be given in the README.md file. However if we need extra scripts to either deploy the bicep files or other functionality use a naming conventions as the following
- deploy.main.sh: for bash-based script deploying the main.bicep
@@ -144,6 +152,7 @@ A guide outlining the coding conventions and style guidelines that should be fol
- Use strictly `camelCasing` for all elements like parameters, variables, resources, modules and outputs, and avoid prepending those elements in a [Hungarian Notation](https://en.wikipedia.org/wiki/Hungarian_notation) style.
**Bad practice examples that should be avoided:**
+
``` bicep
\\ BAD PRACTICE param EXAMPLES
param parVmSubnetAddressPrefix string
@@ -167,8 +176,10 @@ A guide outlining the coding conventions and style guidelines that should be fol
output acrId string = acr.id
```
- **Acceptable naming convention examples:**
+ **Acceptable naming convention examples:**
+
``` bicep
+
\\ GOOD PRACTICE param EXAMPLES
param vmSubnetAddressPrefix string
@@ -179,12 +190,12 @@ A guide outlining the coding conventions and style guidelines that should be fol
output acrId string = acr.id
```
-
-- For **parameters and outputs**, avoid using extreme abbreviations, and stick to well known (de-facto) Azure resource abbreviations. Examples:
+- For **parameters and outputs**, avoid using extreme abbreviations, and stick to well known (de-facto) Azure resource abbreviations. Examples:
- **expressRouteGwName** instead of *erGwName*
- **storageAccountName** instead of *stAccName*
-- Bicep is a declarative language, which means the elements can appear in any order. In reality you can put parameter declarations anywhere in the template file, and the same you can do for resources, variables and outputs. However it is highly recommended that any bicep template file to adhere to the following order `Parameters > Variables > Resources/Modules > Outputs` as shown in the code snippet.
+- Bicep is a declarative language, which means the elements can appear in any order. In reality you can put parameter declarations anywhere in the template file, and the same you can do for resources, variables and outputs. However it is highly recommended that any bicep template file to adhere to the following order `Parameters > Variables > Resources/Modules > Outputs` as shown in the code snippet.
+
``` bicep
targetScope = 'subscription'
// ================ //
@@ -254,11 +265,12 @@ A guide outlining the coding conventions and style guidelines that should be fol
- `app-marketCampaign-backEnd`
- `app-marketCampaign-frontEnd`
-- Consider sanitizing names of resources to avoid deployment errors. For example consider the name limitations for a storage account (all lowercase, less than 24 characters long, no dashes etc).
+- Consider sanitizing names of resources to avoid deployment errors. For example consider the name limitations for a storage account (all lowercase, less than 24 characters long, no dashes etc).
+
``` bicep
var maxStorageNameLength = 24
var storageName = length(name) > maxStorageNameLength ? toLower(substring(replace(name, '-', ''), 0, maxStorageNameLength)) : toLower(replace(name, '-', ''))
- ```
+ ```
- Use bicep **parameter** files for giving the end user the ability to paramterize the deployed resources. (i.e. to select CIDR network spaces, to select SKUs for given resources etc). As a rule of thumb, avoid using the parameter file for *naming recources*, unless there is a really good reason for that. Naming resources should be handled centrally (preferably with variables), following specific rules (as already described). Try not to overuse parameters in the template, because this creates a burden on your template users, since they need to understand the values to use for each resource, and the impact of setting each parameter. Consider using the [t-shirt sizing pattern](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/patterns-configuration-set#solution)
@@ -307,6 +319,7 @@ resource storage 'Microsoft.Storage/storageAccounts@2019-06-01' = {
- [Azure Resource Abbreviations](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations)
### Terraform Best Practices and Conventions
+
- Use modules: Terraform modules allow you to reuse and share code across different projects and teams. This helps to reduce duplication of effort and increases consistency
- Use Terraform variables: Use Terraform variables to provide input values and make your code more flexible and easier to maintain.
- Use Terraform outputs: Use Terraform outputs to extract information about your infrastructure for later use.
@@ -320,16 +333,10 @@ resource storage 'Microsoft.Storage/storageAccounts@2019-06-01' = {
- Declare all outputs in **outputs.tf**, including a description
- Modules must always include the following files, even if empty: **main.tf**, **variables.tf**, and **outputs.tf**
-
-
-
-
-
-
-
-
## Issue Tracker
+
> TODO: Instructions on how to use the issue tracker, including how to submit bugs and feature requests.
## Pull Request Process
+
> TODO: A description of the pull request process, including the criteria that pull requests will be reviewed against and the steps that will be taken to merge a pull request.
diff --git a/README.md b/README.md
index 8132f1b4..eda0dc87 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,29 @@
# App Service Landing Zone Accelerator
-This repository encompasses both enterprise architecture guidelines and a reference implementation for deploying Azure App Service solutions in multi-tenant and App Service Environment scenarios. It includes best practices, considerations and deployable artifacts for implementing a common reference architecture.
-
-[aka.ms/EnterpriseScale-AppService](https://aka.ms/EnterpriseScale-AppService)
+This repository provides both enterprise architecture guidelines and a reference implementation for deploying Azure App Service solutions in multi-tenant and App Service Environment scenarios. It includes best practices, considerations, and deployable artifacts for implementing a common reference architecture.
+45
+
+## Table of Contents
+
+- [App Service Landing Zone Accelerator](#app-service-landing-zone-accelerator)
+ - [Table of Contents](#table-of-contents)
+ - [Enterprise-Scale Architecture](#enterprise-scale-architecture)
+ - [Prerequisites](#prerequisites)
+ - [Getting Started](#getting-started)
+ - [Step 1. Reference implementations](#step-1-reference-implementations)
+ - [Step 2. Configure and test the deployment in your own environment](#step-2-configure-and-test-the-deployment-in-your-own-environment)
+ - [Deploy with Azure Portal (Bicep/ARM)](#deploy-with-azure-portal-biceparm)
+ - [Locally deploy with Bicep](#locally-deploy-with-bicep)
+ - [Locally deploy with Terraform](#locally-deploy-with-terraform)
+ - [Step 3. Configure GitHub Actions](#step-3-configure-github-actions)
+ - [App Patterns](#app-patterns)
+ - [Got a feedback](#got-a-feedback)
+ - [Data Collection](#data-collection)
+ - [Telemetry Configuration](#telemetry-configuration)
+ - [Contributing](#contributing)
+ - [Trademarks](#trademarks)
+
+Visit [EnterpriseScale-AppService](https://aka.ms/EnterpriseScale-AppService) for more information.
![image](/docs/Images/home-page.gif)
@@ -18,30 +39,95 @@ The enterprise architecture is broken down into six different design areas, wher
| Security, Governance, and Compliance|[Design Considerations](/docs/Design-Areas/security-governance-compliance.md#design-considerations)|[Design Recommendations](/docs/Design-Areas/security-governance-compliance.md#design-recommendations)|
| Application Automation and DevOps|[Design Considerations](/docs/Design-Areas/automation-devops.md#design-considerations)|[Design Recommendations](/docs/Design-Areas/automation-devops.md#design-recommendations)|
-## Enterprise-Scale Reference Implementation
+## Prerequisites
+
+Before you begin, ensure you have met the following requirements:
+
+- **Azure Subscription**: You need an Azure subscription to create resources in Azure. If you don't have one, you can create a [free account](https://azure.microsoft.com/free/).
+
+- **Azure CLI or Azure PowerShell**: You need either Azure CLI or Azure PowerShell installed and configured to interact with your Azure account. You can download them from [here](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) and [here](https://docs.microsoft.com/en-us/powershell/azure/install-az-ps) respectively.
+
+- **Terraform or Bicep**: Depending on your preference, you need either Terraform or Bicep installed to deploy the infrastructure. You can download Terraform from [here](https://www.terraform.io/downloads.html) and Bicep from [here](https://github.com/Azure/bicep#installing-bicep-cli).
+
+- **Knowledge of Azure App Service**: This project involves deploying and managing Azure App Service resources. Familiarity with Azure App Service and its concepts is recommended.
+
+Please replace the links and the software versions with the ones that are relevant to your project.
-In this repo you will find reference implementations with supporting Infrastructure as Code templates. More reference implementations will be added as they become available.
+## Getting Started
-## Next Steps to implement the Azure App Service Landing Zone Accelerator
+Follow the steps below to get started with the App Service Landing Zone Accelerator.
### Step 1. Reference implementations
-:arrow_forward: [App Service Secure Baseline](scenarios/secure-baseline-multitenant/README.md)
+In this project, we currently have the following reference implementations:
-For configuring the GitHub Actions pipelines, please refer to the [GitHub Actions](docs/github-actions.md) documentation.
+| Scenario | Description | Documentation | Pipeline Status |
+| -------- | ----------- | ------------- | --------------- |
+| :arrow_forward: [Scenario 1: App Service Secure Baseline Multi-Tenant](scenarios/secure-baseline-multitenant/README.md) | This scenario deploys a multi-tenant App Service environment with a Hub and Spoke network topology. | [README](scenarios/secure-baseline-multitenant/README.md) | [![Scenario 1: Terraform HUB Multi-tenant Secure Baseline](https://github.com/Azure/appservice-landing-zone-accelerator/actions/workflows/scenario1.terraform.hub.yml/badge.svg?branch=main)](https://github.com/Azure/appservice-landing-zone-accelerator/actions/workflows/scenario1.terraform.hub.yml) [![Scenario 1: Terraform SPOKE Multi-tenant Secure Baseline](https://github.com/Azure/appservice-landing-zone-accelerator/actions/workflows/scenario1.terraform.spoke.yml/badge.svg)](https://github.com/Azure/appservice-landing-zone-accelerator/actions/workflows/scenario1.terraform.spoke.yml) |
-### Step 2. Configure and test the deployment on your own environment
+> **Note**
+ Currently, the App Service Secure Baseline Multi-Tenant is the only reference implementation available. However, both the Terraform and Bicep configuration files have feature flags available to accommodate additional scenarios. More reference input files will be provided to accommodate additional reference implementations in the future.
+
+### Step 2. Configure and test the deployment in your own environment
With the selected reference implementation, you can now choose between `Bicep` or `Terraform` to deploy the scenario's infrastructure.
-#### Deploying Bicep
+#### Deploy with Azure Portal (Bicep/ARM)
+
+[![Deploy to Azure](https://aka.ms/deploytoazurebutton)](https://portal.azure.com/#view/Microsoft_Azure_CreateUIDef/CustomDeploymentBlade/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fazure%2Fappservice-landing-zone-accelerator%2Fmain%2Fscenarios%2Fsecure-baseline-multitenant%2Fazure-resource-manager%2Fmain.json/uiFormDefinitionUri/https%3A%2F%2Fraw.githubusercontent.com%2Fazure%2Fappservice-landing-zone-accelerator%2Fmain%2Fscenarios%2Fsecure-baseline-multitenant%2Fazure-resource-manager%2Fmain-portal-ux.json)
+
+#### Locally deploy with Bicep
+
+For additional information, view the Bicep README [here](scenarios/secure-baseline-multitenant/bicep/README.md).
+
+The Bicep configuration files are located in the [scenarios/secure-baseline-multitenant/bicep](scenarios/secure-baseline-multitenant/bicep/) directory.
+
+Before deploying the Bicep IaC artifacts, you need to review and customize the values of the parameters in the [main.parameters.jsonc](scenarios/secure-baseline-multitenant/bicep/main.parameters.jsonc) file.
-#### Deploying Terraform
+> **Note**
+ Azure Developer CLI (azd) is also supported as a deployment method. Since azd CLI does not support parameter files with *jsonc* extension, we provide a simple json parameter file (which does not contain inline comments)
+
+The expandable table below summarizes the available parameters and the possible values that can be set.
+
+
+Bicep Configuration Parameters Table
+
+| Name | Description | Example |
+|------|-------------|---------|
+|workloadName|A suffix that will be used to name the resources in a pattern similar to ` - ` . Must be up to 10 characters long, alphanumeric with dashes|app-svc-01|
+|location|Azure region where the resources will be deployed in|northeurope|
+|environment|Required. The name of the environment (e.g. "dev", "test", "prod", "preprod", "staging", "uat", "dr", "qa"). Up to 8 characters long.|dev|
+|deployAseV3|Optional, default is false. Set to true if you want to deploy ASE v3 instead of Multitenant App Service Plan.|false|
+|vnetHubResourceId|If empty, then a new hub will be created. If you select not to deploy a new Hub resource group, set the resource id of the Hub Virtual Network that you want to peer to. In that case, no new hub will be created and a peering will be created between the new spoke and and existing hub vnet|/subscriptions// resourceGroups//providers/ Microsoft.Network/virtualNetworks/|
+|firewallInternalIp|If you select to create a new Hub, the UDR for locking the egress traffic will be created as well, no matter what value you set to that variable. However, if you select to connect to an existing hub, then you need to provide the internal IP of the azure firewal so that the deployment can create the UDR for locking down egress traffic. If not given, no UDR will be created||
+|vnetHubAddressSpace|If you deploy a new hub, you need to set the appropriate CIDR of the newly created Hub virtual network|10.242.0.0/20|
+|subnetHubFirewallAddressSpace|CIDR of the subnet that will host the azure Firewall|10.242.0.0/26|
+|subnetHubBastionAddressSpace|CIDR of the subnet that will host the Bastion Service|10.242.0.64/26|
+|vnetSpokeAddressSpace|CIDR of the spoke vnet that will hold the app services plan and the rest supporting services (and their private endpoints)|10.240.0.0/20|
+|subnetSpokeAppSvcAddressSpace|CIDR of the subnet that will hold the app services plan. ATTENTION: If you deploy ASEv3 this CIDR should be x.x.x.x/24 |10.240.0.0/26 (*USE 10.240.0.0/24 if deployAseV3=true*)|
+|subnetSpokeDevOpsAddressSpace|CIDR of the subnet that will hold devOps agents etc|10.240.10.128/26|
+|subnetSpokePrivateEndpointAddressSpace|CIDR of the subnet that will hold the private endpoints of the supporting services|10.240.11.0/24|
+|webAppPlanSku|Defines the name, tier, size, family and capacity of the App Service Plan. Plans ending to _AZ, are deplying at least three instances in three Availability Zones. select one from: 'S1', 'S2', 'S3', 'P1V3', 'P2V3', 'P3V3', 'P1V3_AZ', 'P2V3_AZ', 'EP1', 'EP2', 'EP3', 'ASE_I1V2_AZ', 'ASE_I2V2_AZ', 'ASE_I3V2_AZ' ||
+|webAppBaseOs|The OS for the App service plan. Two options available: Windows or Linux||
+|resourceTags|Resource tags that we might need to add to all resources (i.e. Environment, Cost center, application name etc)|"resourceTags": {
"value": {
"deployment": "bicep",
"key1": "value1"
}
} |
+|enableEgressLockdown|Feature Flag: te (or not) a UDR for the App Service Subnet, to route all egress traffic through Hub Azure Firewall|
+|deployRedis|Feature Flag: Deploy (or not) a redis cache |
+|deployAzureSql|Feature Flag: Deploy (or not) an Azure SQL with default database|
+|deployAppConfig|Feature Flag: Deploy (or not) an Azure app configuration|
+|deployJumpHost|Feature Flag: Deploy (or not) an Azure virtual machine (to be used as jumphost)|
+|autoApproveAfdPrivateEndpoint|Default value: true. Set to true if you want to auto approve the Private Endpoint of the AFD Premium. See details [regarding approving the App Service private endpoint connection from Front Door](#approve-the-app-service-private-endpoint-connection-from-front-door-in-the-azure-portal) | false
+|sqlServerAdministrators|The Azure Active Directory (AAD) administrator group used for SQL Server authentication. The Azure AD group must be created before running deployment. This has three values that need to be filled, as shown below
**login**: the name of the AAD Group
**sid**: the object id of the AAD Group
**tenantId**: The tenantId of the AAD ||
+
+
+
+#### Locally deploy with Terraform
1. Ensure you are logged in to Azure CLI and have selected the correct subscription.
1. Navigate to the Terraform deployment directory (same directory as the `main.tf` file).
- [scenarios/secure-baseline-multitenant/terraform/hub](scenarios/secure-baseline-multitenant/terraform/hub/)
- [scenarios/secure-baseline-multitenant/terraform/spoke](scenarios/secure-baseline-multitenant/terraform/spoke/)
+ > **Note**
+ > The GitHub Action deployments for Terraform `hub` and `spoke` are currently separated due to the amount of time both components take to deploy. It is advised to use a self-hosted agent to ensure the deployment does not timeout.
1. Familiarize yourself with the deployment files:
- `main.tf` - Contains the Terraform provider configurations for the selected deployment/module. Note the `backend "azurerm" {}` block as this configures your [Terraform deployment's remote state](https://developer.hashicorp.com/terraform/language/settings/backends/azurerm). Also contains the resource group definitions to host the deployed resources.
- `_locals.tf` - Contains the local variable declarations as well as custom logic to support naming and tagging conventions across each module.
@@ -55,10 +141,14 @@ With the selected reference implementation, you can now choose between `Bicep` o
1. Run `terraform apply -var-file="Parameters/uat.tfvars"` to deploy the resources.
### Step 3. Configure GitHub Actions
+
+> **Note**
+ The GitHub Actions pipelines are currently configured to deploy the Terraform `hub` and `spoke` deployments. The Bicep pipelines are currently in development.
+
GitHub Actions pipelines are located in the [`.github/workflows`](.github/workflows/) directory with templates stored in the [`.github/actions`](.github/actions/) directory.i
1. Create an Azure AD Service Principal for OIDC Authentication
- - Reference the following documentation to configure your Azure AD Service Principal: [OIDC authentication to Azure](https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-enterprise-managed-user-oidc-provisioning-tutorial).
+ - Reference the following documentation to configure your Azure AD Service Principal: [OIDC authentication to Azure](https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/github-enterprise-managed-user-oidc-provisioning-tutorial).
1. Configure your GitHub Actions Secrets
- In your forked repository, navigate to `Settings > Secrets and variables > Actions`.
- Create the following secrets:
@@ -67,15 +157,17 @@ GitHub Actions pipelines are located in the [`.github/workflows`](.github/workfl
| `AZURE_CLIENT_ID` | GUID value for the Client ID of the service principal to authenticate with | `00000000-0000-0000-0000-000000000000` |
| `AZURE_SUBSCRIPTION_ID` | GUID value for the Subscription ID to deploy resources to | `00000000-0000-0000-0000-000000000000` |
| `AZURE_TENANT_ID` | GUID value for the Tenant ID of the service principal to authenticate with | `00000000-0000-0000-0000-000000000000` |
- | `AZURE_TF_STATE_RESOURCE_GROUP_NAME` | Optional override value to configure the remote state resource group name | `rg-terraform-state` |
- | `AZURE_TF_STATE_STORAGE_ACCOUNT_NAME` | Optional override value to configure the remote state storage account name | `tfstate` |
- | `AZURE_TF_STATE_STORAGE_CONTAINER_NAME` | Optional override value to configure the remote state storage container name | `tfstate` |
- | `ACCOUNT_NAME` | | `https://dev.azure.com/ORGNAME` OR `github.com/ORGUSERNAME` OR `none` |
- | `PAT` | Personal Access Token for the DevOps VM to leverage on provisioning the pipeline agent | `asdf1234567` |
+ | `AZURE_TF_STATE_RESOURCE_GROUP_NAME` | [**Optional**] For Terraform only: override value to configure the remote state resource group name | `rg-terraform-state` |
+ | `AZURE_TF_STATE_STORAGE_ACCOUNT_NAME` | [**Optional**] For Terraform only: override value to configure the remote state storage account name | `tfstate` |
+ | `AZURE_TF_STATE_STORAGE_CONTAINER_NAME` | [**Optional**] For Terraform only: override value to configure the remote state storage container name | `tfstate` |
+ | `ACCOUNT_NAME` | [**Optional**] The Azure DevOps organization URL or GitHub Actions account name (see Example Value column) to use when provisioning the pipeline agent on the self-hosted DevOps Agent VM | `https://dev.azure.com/ORGNAME` OR `github.com/ORGUSERNAME` OR `none` |
+ | `PAT` | [**Optional**] Personal Access Token for the DevOps VM to leverage on provisioning the pipeline agent on the self-hosted DevOps Agent VM | `asdf1234567` |
---
+
### App Patterns
-Looking for developer-focused reference implementation? Check out Reliable Web Patterns for App Service.
+
+Looking for developer-focused reference implementation? Check out Reliable Web Patterns for App Service.
:arrow_forward: [Reliable web app pattern for .NET](https://github.com/Azure/reliable-web-app-pattern-dotnet)
@@ -83,12 +175,13 @@ Looking for developer-focused reference implementation? Check out Reliable Web P
## Got a feedback
-Please leverage issues if you have any feedback or request on how we can improve on this repository.
+Please leverage [issues](https://github.com/Azure/appservice-landing-zone-accelerator/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) if you have any feedback or request on how we can improve on this repository.
---
+
## Data Collection
-The software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft's privacy statement. Our privacy statement is located at https://go.microsoft.com/fwlink/?LinkId=521839. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.
+The software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft's privacy statement. Our privacy statement is located at [https://go.microsoft.com/fwlink/?LinkId=521839](https://go.microsoft.com/fwlink/?LinkId=521839). You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.
### Telemetry Configuration
@@ -97,14 +190,14 @@ Telemetry collection is on by default.
To opt-out, set the variable enableTelemetry to `false` in Bicep/ARM file and disable_terraform_partner_id to `false` on Terraform files.
---
+
## Contributing
See more at [Contributing](CONTRIBUTING.md)
## Trademarks
-This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
-trademarks or logos is subject to and must follow
-[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
+This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
+
Any use of third-party trademarks or logos are subject to those third-party's policies.
diff --git a/scenarios/secure-baseline-multitenant/README.md b/scenarios/secure-baseline-multitenant/README.md
index 84b6f8ae..4312999a 100644
--- a/scenarios/secure-baseline-multitenant/README.md
+++ b/scenarios/secure-baseline-multitenant/README.md
@@ -3,6 +3,7 @@
This reference architecture shows how to run a web-app workload on Azure App Services in a secure configuration. This secure baseline follow [Defense in Depth](https://learn.microsoft.com/en-us/shows/azure-videos/defense-in-depth-security-in-azure) approach to protect AppService workload against cloud vulnerabilities along with additional [Well-Architected Framework](https://learn.microsoft.com/en-us/azure/architecture/framework/) pillars to enable a resilient solution.
## Quick deployment to Azure
+
You can deploy the current LZA directly in your azure subscription by hitting the button below or using Azure Dev CLI.
### Deploy to Azure via Portal
@@ -14,30 +15,31 @@ You can deploy the current LZA directly in your azure subscription by hitting th
- Visit [github.com/Azure/appservice-landing-zone-accelerator](https://github.com/Azure/appservice-landing-zone-accelerator)
- Click on the `Green Code` button.
- Navigate to the `CodeSpaces` tab and create a new code space.
-- Open the terminal by pressing Ctrl + `
.
+- Open the terminal by pressing ```Ctrl + ` ```.
- Navigate to the scenario folder using the command `cd /workspaces/appservice-landing-zone-accelerator/scenarios/secure-baseline-multitenant`.
- Login to Azure using the command `azd auth login`.
- Use the command `azd up` to deploy, provide environment name and subscription to deploy to.
- Finally, use the command `azd down` to clean up resources deployed.
# Architecture
-![image](/docs/Images/Multitenant/AppServiceLandingZoneArchitecture-multitenant.png)
+![image](/docs/Images/Multitenant/AppServiceLandingZoneArchitecture-multitenant.png)
## Core architecture components
-* The application's users are authenticated by [Azure Active Directory (Azure AD)](https://azure.microsoft.com/services/active-directory/) or [Azure AD B2C](https://azure.microsoft.com/services/active-directory/external-identities/b2c/). The browser performs DNS lookups to resolve addresses to Azure Front Door.
-* [Virtual Network](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works) enables Azure resources to securely communicate with each other, the internet, and on-premises networks by creating boundaries, isolation and segmentation of your workloads in the cloud, much like a physical network.
-* [Network Security Group](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview?toc=%2Fazure%2Fnetworking%2Ffundamentals%2Ftoc.json) is a set of security policies that Allow or Deny Inbound/Outbound traffic (Protocols/Ports).
-* [Azure Front Door](https://azure.microsoft.com/services/frontdoor/) is a public front-end for all internet requests, acting as a global HTTP reverse proxy and cache in front of several Azure services. Front Door also provides automatic protection from layer 3 and 4 DDoS attacks, and a range of other features including WAF (web application firewall), caching, and custom rules to enhance the security and performance of your application.
-* [Azure App Service (Premium)](https://azure.microsoft.com/services/app-service/) hosts the front-end API applications that are called by the app. Deployment slots are used to provide zero-downtime releases.
-* App Services use [Virtual Network (VNet) Integration](https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#regional-virtual-network-integration) to connect to backend Azure services over a private VNet.
-* [Azure Cache for Redis](https://azure.microsoft.com/services/cache/) provides a high-performance distributed cache for output, session, and general-purpose caching.
-* [Azure SQL DB](https://azure.microsoft.com/en-us/products/azure-sql/database/) provides a fully managed relational database service for back-end application services.
-* [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) provides REST API access to OpenAI's powerful language models including the GPT-4, GPT-3.5-Turbo, and Embeddings model series.
-* [Private Endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview) allow connections to Azure services from private VNets, and allow the public endpoints on these services to be disabled.
-* [Azure private DNS](https://learn.microsoft.com/en-us/azure/dns/private-dns-overview) automatically configures and updates the DNS records required by private endpoint services.
-* [Azure Key Vault](https://azure.microsoft.com/services/key-vault/) securely stores secrets and certificates to be accessed by Azure services.
-* [Azure Monitor](https://azure.microsoft.com/services/monitor/) and [Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview) collect service logs and application performance metrics for observability.
+
+- The application's users are authenticated by [Azure Active Directory (Azure AD)](https://azure.microsoft.com/services/active-directory/) or [Azure AD B2C](https://azure.microsoft.com/services/active-directory/external-identities/b2c/). The browser performs DNS lookups to resolve addresses to Azure Front Door.
+- [Virtual Network](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works) enables Azure resources to securely communicate with each other, the internet, and on-premises networks by creating boundaries, isolation and segmentation of your workloads in the cloud, much like a physical network.
+- [Network Security Group](https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview?toc=%2Fazure%2Fnetworking%2Ffundamentals%2Ftoc.json) is a set of security policies that Allow or Deny Inbound/Outbound traffic (Protocols/Ports).
+- [Azure Front Door](https://azure.microsoft.com/services/frontdoor/) is a public front-end for all internet requests, acting as a global HTTP reverse proxy and cache in front of several Azure services. Front Door also provides automatic protection from layer 3 and 4 DDoS attacks, and a range of other features including WAF (web application firewall), caching, and custom rules to enhance the security and performance of your application.
+- [Azure App Service (Premium)](https://azure.microsoft.com/services/app-service/) hosts the front-end API applications that are called by the app. Deployment slots are used to provide zero-downtime releases.
+- App Services use [Virtual Network (VNet) Integration](https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration#regional-virtual-network-integration) to connect to backend Azure services over a private VNet.
+- [Azure Cache for Redis](https://azure.microsoft.com/services/cache/) provides a high-performance distributed cache for output, session, and general-purpose caching.
+- [Azure SQL DB](https://azure.microsoft.com/en-us/products/azure-sql/database/) provides a fully managed relational database service for back-end application services.
+- [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) provides REST API access to OpenAI's powerful language models including the GPT-4, GPT-3.5-Turbo, and Embeddings model series.
+- [Private Endpoints](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview) allow connections to Azure services from private VNets, and allow the public endpoints on these services to be disabled.
+- [Azure private DNS](https://learn.microsoft.com/en-us/azure/dns/private-dns-overview) automatically configures and updates the DNS records required by private endpoint services.
+- [Azure Key Vault](https://azure.microsoft.com/services/key-vault/) securely stores secrets and certificates to be accessed by Azure services.
+- [Azure Monitor](https://azure.microsoft.com/services/monitor/) and [Application Insights](https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview) collect service logs and application performance metrics for observability.
## Networking
@@ -52,69 +54,79 @@ Azure services that don't require access from the public internet have private e
For network and subnet topology details, see the [Azure sample template](https://github.com/Azure-Samples/highly-available-zone-redundant-webapp) for this architecture.
## Alternatives
-* Either Azure AD or Azure AD B2C can be used as an identity provider in this scenario. Azure AD is designed for internal applications and business-to-business (B2B) scenarios, while Azure AD B2C is designed for business-to-consumer (B2C) scenarios.
-* You can choose to bring your own DNS provider or use Azure-managed DNS, which is recommended.
-* Azure Application Gateway can be used solely instead of Azure Front Door when most users are located close to the Azure region that hosts your workload, and when content caching isn't required. Azure DDoS Network Protection is recommended for protecting internet-facing Application Gateway services.
+
+- Either Azure AD or Azure AD B2C can be used as an identity provider in this scenario. Azure AD is designed for internal applications and business-to-business (B2B) scenarios, while Azure AD B2C is designed for business-to-consumer (B2C) scenarios.
+- You can choose to bring your own DNS provider or use Azure-managed DNS, which is recommended.
+- Azure Application Gateway can be used solely instead of Azure Front Door when most users are located close to the Azure region that hosts your workload, and when content caching isn't required. Azure DDoS Network Protection is recommended for protecting internet-facing Application Gateway services.
## Scenario details
+
The scenario describes a secure baseline that allows you to have a protect environment and a good starting point for designing your solution.
Defense in depth is a security strategy that involves implementing multiple layers of defense at different points within a network or system. The idea is that if one layer of defense is breached, the next layer will be able to prevent an attacker from gaining access to sensitive information or critical systems.
This approach is a key point that drives the architecture decisions ->
-* Use isolated network layers for the different components.
-* Use protected AD based access via Managed Identity (where possible).
-* Use private endpoints for Azure services.
-* Use Network Security Groups to control inbound and outbound traffic in the subnet level.
-* Enable Standard DDoS Protection for the SPOKE VNET.
+
+- Use isolated network layers for the different components.
+- Use protected AD based access via Managed Identity (where possible).
+- Use private endpoints for Azure services.
+- Use Network Security Groups to control inbound and outbound traffic in the subnet level.
+- Enable Standard DDoS Protection for the SPOKE VNET.
## Potential use cases
-* Public website hosting
-* Intranet portal
-* Mobile app hosting
-* E-commerce
-* Media streaming
-* Machine learning workloads
-
-# Recommendations
-* Private endpoints are mostly available on Premium Azure service SKUs. Private endpoints incur hourly and bandwidth (data) charges. For more information, see [Private Link pricing](https://azure.microsoft.com/en-us/pricing/details/private-link/).
-* Govern your access and follow [Role Based Access Control](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) to have a fine-grained access management to Azure resources.
-* Review your data classification and determine the protection level you have to enforce in terms of Encryption, Protection, Access and Detection.
-
-## Front Door
+
+- Public website hosting
+- Intranet portal
+- Mobile app hosting
+- E-commerce
+- Media streaming
+- Machine learning workloads
+
+## Recommendations
+
+- Private endpoints are mostly available on Premium Azure service SKUs. Private endpoints incur hourly and bandwidth (data) charges. For more information, see [Private Link pricing](https://azure.microsoft.com/en-us/pricing/details/private-link/).
+- Govern your access and follow [Role Based Access Control](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) to have a fine-grained access management to Azure resources.
+- Review your data classification and determine the protection level you have to enforce in terms of Encryption, Protection, Access and Detection.
+
+### Front Door
Azure Front Door is a global service, always available across all Azure geographies and resilient to zone-wide outages and region-wide outages.
-* Use [Azure managed certificates](https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-configure-https-custom-domain#azure-managed-certificates) on all front ends to prevent certificate mis-configuration and expiration issues.
-* Enable [caching](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-caching?pivots=front-door-standard-premium) on routes where appropriate to improve availability. Front Door's cache distributes your content to the Azure PoP (point of presence) edge nodes. In addition to improving your performance, caching reduces the load on your origin servers.
-* Deploy Azure Front Door Premium and configure a [WAF policy](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview) with a Microsoft-managed ruleset. Apply the policy to all custom domains. Use Prevention mode to mitigate web attacks that might cause an origin service to become unavailable.
-* Deployments with higher security requirements could also use [Private Link in Azure Front Door Premium](https://learn.microsoft.com/en-us/azure/frontdoor/private-link) to secure connectivity to Azure App Service.
+- Use [Azure managed certificates](https://learn.microsoft.com/en-us/azure/frontdoor/standard-premium/how-to-configure-https-custom-domain#azure-managed-certificates) on all front ends to prevent certificate mis-configuration and expiration issues.
+- Enable [caching](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-caching?pivots=front-door-standard-premium) on routes where appropriate to improve availability. Front Door's cache distributes your content to the Azure PoP (point of presence) edge nodes. In addition to improving your performance, caching reduces the load on your origin servers.
+- Deploy Azure Front Door Premium and configure a [WAF policy](https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview) with a Microsoft-managed ruleset. Apply the policy to all custom domains. Use Prevention mode to mitigate web attacks that might cause an origin service to become unavailable.
+- Deployments with higher security requirements could also use [Private Link in Azure Front Door Premium](https://learn.microsoft.com/en-us/azure/frontdoor/private-link) to secure connectivity to Azure App Service.
For more recommendations and information, see [Best practices for Front Door](https://learn.microsoft.com/en-us/azure/frontdoor/best-practices).
-## App Service
-* Access restrictions on Azure App Service should be configured to only allow Front Door traffic. Access restrictions ensure that requests aren't able to bypass the Azure Front Door WAF, see [App Service access restrictions](https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions#restrict-access-to-a-specific-azure-front-door-instance).
-* All service-to-service communication in Azure is TLS (transport layer security) encrypted by default. Azure Front Door and Azure App Services should be configured to accept HTTPS traffic only, and the minimum TLS version set.
-* Managed identities are used for authenticating Azure service-to-service communication, where available. For more information about managed identities, see [What are managed identities for Azure resources?](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
+
+### App Service
+
+- Access restrictions on Azure App Service should be configured to only allow Front Door traffic. Access restrictions ensure that requests aren't able to bypass the Azure Front Door WAF, see [App Service access restrictions](https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions#restrict-access-to-a-specific-azure-front-door-instance).
+- All service-to-service communication in Azure is TLS (transport layer security) encrypted by default. Azure Front Door and Azure App Services should be configured to accept HTTPS traffic only, and the minimum TLS version set.
+- Managed identities are used for authenticating Azure service-to-service communication, where available. For more information about managed identities, see [What are managed identities for Azure resources?](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
Check out [Defender for App Service](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-app-service-introduction) for secure and detect operations to protect your Azure App Service web apps and APIs.
-## SQL Database
-* Get to know the risks and [Common SQL threats](https://learn.microsoft.com/en-us/sql/relational-databases/security/sql-server-security-best-practices?view=sql-server-ver16#common-sql-threats) and plan how to [Protect](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/sql-database-security-baseline?toc=%2Fazure%2Fazure-sql%2Ftoc.json&view=azuresql).
-* Define your encryption policy - you either use a Microsoft managed key or [BYOK](https://learn.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview?view=azuresql).
-* Verify your needs to protect and [detect](https://learn.microsoft.com/en-us/azure/azure-sql/database/threat-detection-configure?view=azuresql) any malfunction activity within your environment
-* Check out [Defender for Azure SQL](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-sql-introduction) to improve your vulnerabilities assessment and threat protection processes.
+### SQL Database
+
+- Get to know the risks and [Common SQL threats](https://learn.microsoft.com/en-us/sql/relational-databases/security/sql-server-security-best-practices?view=sql-server-ver16#common-sql-threats) and plan how to [Protect](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/sql-database-security-baseline?toc=%2Fazure%2Fazure-sql%2Ftoc.json&view=azuresql).
+- Define your encryption policy - you either use a Microsoft managed key or [BYOK](https://learn.microsoft.com/en-us/azure/azure-sql/database/transparent-data-encryption-byok-overview?view=azuresql).
+- Verify your needs to protect and [detect](https://learn.microsoft.com/en-us/azure/azure-sql/database/threat-detection-configure?view=azuresql) any malfunction activity within your environment
+- Check out [Defender for Azure SQL](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-sql-introduction) to improve your vulnerabilities assessment and threat protection processes.
For more recommendations and information, see [Azure SQL Security Baseline](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/sql-database-security-baseline?toc=%2Fazure%2Fazure-sql%2Ftoc.json&view=azuresql)
-## Cache for Redis
-* Set the publicNetworkAccess flag to Disabled to disable the public endpoint.
-* To connect to a clustered cache, there can only be one private endpoint connection.
+### Cache for Redis
+
+- Set the publicNetworkAccess flag to Disabled to disable the public endpoint.
+- To connect to a clustered cache, there can only be one private endpoint connection.
For more recommendations and information, see [Azure Redis Cache Security Baseline](https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-cache-for-redis-security-baseline)
-# Deploy this scenario
+
+## Deploy this scenario
+
Deploy this reference architecture using this [Azure sample on GitHub](/scenarios/secure-baseline-multitenant/README.md).
- Azure AD, Azure AD B2C, and Azure DNS aren't deployed by this sample.
- Custom domain names and TLS/SSL certificates aren't created and configured. Default frontend DNS names are used instead.
- The scripts are modular so you if you already have an existing environment, you can pick and choose the relevant section or adjust the relevant pieces according to your needs (deploy only SPOKE, replace SQL DB with PostgreSQL and etc.).
-
## Considerations for Azure Government cloud
Azure Front Door Premium is not available in Azure Government cloud. The reference implementation will deploy an Azure Application Gateway instead.
diff --git a/shared/agentsetup.ps1 b/shared/agentsetup.ps1
deleted file mode 100644
index 5fcdfd30..00000000
--- a/shared/agentsetup.ps1
+++ /dev/null
@@ -1,149 +0,0 @@
-param (
- [string]$URL,
- [string]$PAT,
- [string]$POOL,
- [string]$AGENT,
- [string]$AGENTTYPE
-)
-
-
-function setupazdevops{
- param(
- [string]$URL,
- [string]$PAT,
- [string]$POOL,
- [string]$AGENT
- )
-
- Write-Host "About to setup Azure DevOps Agent"
- Start-Transcript
- Write-Host "start"
-
- $azagentdir="c:\agent"
-
- #test if an old installation exists, if so, delete the folder
- if (test-path $azagentdir)
- {
- set-location $azagentdir
- $servicename=(Get-Content .service)
- Stop-Service $servicename -ErrorAction SilentlyContinue
- set-location 'c:\'
- Remove-Item -Path $azagentdir -Force -Confirm:$false -Recurse
- }
-
- #create a new folder
- new-item -ItemType Directory -Force -Path $azagentdir
- set-location $azagentdir
- $global:ProgressPreference = 'SilentlyContinue'
- $env:VSTS_AGENT_HTTPTRACE = $true
-
- #github requires tls 1.2
- [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
-
- $ProgressPreference = 'SilentlyContinue'
- #get the latest build agent version
- $wr = Invoke-WebRequest https://api.github.com/repos/Microsoft/azure-pipelines-agent/releases/latest -UseBasicParsing
- $tag = ($wr | ConvertFrom-Json)[0].tag_name
- $tag = $tag.Substring(1)
-
- write-host "$tag is the latest version"
- #build the url
- $download = "https://vstsagentpackage.azureedge.net/agent/$tag/vsts-agent-win-x64-$tag.zip"
-
- #download the agent
- Invoke-WebRequest $download -Out agent.zip
-
- #expand the zip
- Expand-Archive -Path agent.zip -DestinationPath $PWD
-
- Write-Output "--unattended --url $URL --auth pat --token "$PAT" --pool $POOL --agent $AGENT --acceptTeeEula --runAsService"
- #run the config script of the build agent
- .\config.cmd --unattended --url $URL --auth pat --token "$PAT" --pool $POOL --agent $AGENT --acceptTeeEula --runAsService --replace
-
- #exit
- Stop-Transcript
- exit 0
-}
-
-function setupghrunner {
- param(
-
- [string]$URL,
- [string]$PAT,
- [string]$POOL,
- [string]$AGENT
- )
-
- Start-Transcript
-
- Write-Host "About to setup GitHub Runner"
- $ghrunnerdirectory="c:\actions-runner"
-
-
-#test if an old installation exists, if so, delete the folder
-if (test-path $ghrunnerdirectory)
-{
- set-location $ghrunnerdirectory
- $servicename=(Get-Content .service)
- Stop-Service $servicename -ErrorAction SilentlyContinue
- set-location 'c:\'
- Remove-Item -Path $ghrunnerdirectory -Force -Confirm:$false -Recurse
-}
-
-#create a new folder
-new-item -ItemType Directory -Force -Path $ghrunnerdirectory
-set-location $ghrunnerdirectory
-$global:ProgressPreference = 'SilentlyContinue'
-$env:VSTS_AGENT_HTTPTRACE = $true
-
-#github requires tls 1.2
-[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
-
-$ProgressPreference = 'SilentlyContinue'
-#get the latest build agent version
-$wr = Invoke-WebRequest https://api.github.com/repos/actions/runner/releases/latest -UseBasicParsing
-$tag = ($wr | ConvertFrom-Json)[0].tag_name
-$tag = $tag.Substring(1)
-
-write-host "$tag is the latest version"
-#build the url
-
-$download = "https://github.com/actions/runner/releases/download/v$tag/actions-runner-win-x64-$tag.zip"
-
-#download the agent
-Invoke-WebRequest $download -Out ghactionsrunner.zip
-
-#expand the zip
-Expand-Archive -Path ghactionsrunner.zip -DestinationPath $PWD
-
-
-#run the config script of the build agent
-set-location $ghrunnerdirectory
-.\config.cmd --unattended --url $URL --token "$PAT" --runnergroup $POOL --replace --runasservice --replace
-
-
-
-#exit
-Stop-Transcript
-exit 0
-
-}
-
-
-
-Write-Output $URL
-Write-Output $PAT
-Write-Output $POOL
-Write-Output $AGENT
-Write-Output $AGENTTYPE
-
-if ($AGENTTYPE.ToLower() -eq "azuredevops")
-{
- setupazdevops -URL $URL -PAT $PAT -POOL $POOL -AGENT $AGENT
-}
-
-else
- {
- setupghrunner -URL $URL -PAT $PAT -POOL $POOL -AGENT $AGENT
-}
-