Updated docs and renamed/moved files

.github/workflows/README.md

@@ -2,26 +2,23 @@
 
 This folder contains all the GitHub action workflows used to deploy the different components of the AKS solution. The naming convention for the workflow yaml files is as follow:
 **[IaC|shared-servies|app]-[purpose].yml**.
-For example a GitHub workflow intended to provision all the Azure resources under the hub Resource Group using bicep will be called "IaC-bicep-rg-hub.yml".
+For example a GitHub workflow intended to provision all the Azure resources for AKS using bicep will be called "IaC-bicep-aks.yml".
 
 ## Reusable Workflows
 
 All of the samples provided in this repo are written for GitHub. Many can easily be adapted for other systems by extracting the script logic used.
 
-GitHub has a concept of [Reusable Workflows](https://docs.github.com/en/actions/learn-github-actions/reusing-workflows), which as the name suggests promotes effective reuse of the workflow logic. Most of the samples in this repo are authored as Reusable Workflows to accelerate using them in your Action Workflow.
+GitHub has a concept of [Reusable Workflows](https://docs.github.com/en/actions/learn-github-actions/reusing-workflows), which as the name suggests promotes effective reuse of the workflow logic. Some of the samples in this repo are authored as Reusable Workflows to accelerate using them in your Action Workflow.
 
 ## IaC Workflow Scenarios
 The following sample workflows are provided for IaC deployments:
-1. **IaC-bicep-AKS.yml** for the deployment of AKS and all the Azure infrastructure resources that AKS depends on using [bicep CARML modules](https://aka.ms/CARML).
-2. **IaC-terraform-AKS.yml** for the deployment of AKS and all the Azure infrastructure resources that AKS depends on using [CAF CAF modules](https://github.com/aztfmod/terraform-azurerm-caf). 
+1. [IaC-bicep-AKS.yml](../workflows/IaC-bicep-AKS.yml) for the deployment of AKS and all the Azure infrastructure resources that AKS depends on using [bicep CARML modules](https://aka.ms/CARML).
+2. [IaC-terraform-AKS.yml](../workflows/IaC-terraform-AKS.yml) for the deployment of AKS and all the Azure infrastructure resources that AKS depends on using [CAF terraform modules](https://github.com/aztfmod/terraform-azurerm-caf). 
+
+For more information, see [IaC README](../../IaC/README.md).
 ## Shared-Services Workflow Scenarios
-TODO
+  * **Shared-Services-HelmDeployNginx.yaml** used to demonstrate the deployment of shared services through GitHub Actions. In this case NGINX is deployed. Note that there is also an option to deploy the ingress controller **Traefik** using GitOps (see [Shared Services](../../shared-services/README.md)  
+
 ## Workloads Workflow Scenarios
 
-The following sample workflows are provided for the deployment of the [Azure Voting App](https://github.com/Azure-Samples/azure-voting-app-redis/). 
-Sample App | Scenario | Description | Tags
----------- | -------- | ----------- | ----
-App-AzureVote-HelmRunCmd.yml| [AKS Run Command](/docs/app-azurevote-helmruncmd.md) | This sample deploys an existing container image using native Kubernetes tooling, executed in AKS using the AKS Run Command. | `Aks Run Command` `Playwright web tests` `Helm`
-App-AzureVote-HelmRunCmd-LegacyAuth.yml| [AKS Run Command](/docs/app-azurevote-helmruncmd.md) | Same as the previous sample but the workflow is using legacy Service Principal and password to authenticate to Azure instead of Federated Identity| `Aks Run Command` `Playwright web tests` `Helm`
-App-AzureVote-BuildOnACRs.yml| [ACR Build](/docs/app-azurevote-acrbuild.md) | This sample leverages an Azure Container Registry to builds a container image from code. Deployment is done using the Azure Kubernetes GitHub actions. | `Azure Container Registry` `GitHub Actions`
-App-AzureVote-DockerBuild.yml| [Docker Build](/docs/app-azurevote-dockerbuildpush.md) | This sample builds a container image from code on the runner then pushes to a registry. Deployment is done using the Azure Kubernetes GitHub actions. | `Azure Container Registry` `GitHub Actions`
+Multiple sample workflows are provided to demonstrate different patterns for deploying applications. For more information, see [Workload README](../../workloads/README.md).

IaC/terraform/README.md

@@ -4,7 +4,7 @@ This folder contains the code to build the [AKS Baseline reference implementatio
 
 The following components will be deployed as part of this automation:
 
-![aks_enterprise_scale_lz](../../docs/.attachments/aks_enterprise_scale_lz2.png)
+![aks_enterprise_scale_lz](../../media/aks_enterprise_scale_lz2.png)
 
 | Components                                                                                              | Config files                                                 | Description|
 |-----------------------------------------------------------|------------------------------------------------------------|------------------------------------------------------------|
@@ -31,7 +31,7 @@ The following components will be deployed as part of this automation:
 
 ## Prerequisites
 
-Make sure these [prerequisites](../../docs/IaC-prerequisites.md) are in place before proceeding.
+Make sure these [prerequisites](../IaC-prerequisites.md) are in place before proceeding.
 
 ## Customize the Terraform templates
 
@@ -39,7 +39,7 @@ To customize the sample terraform templates provided based on your specific need
 
 1. Fork this repo so that you can customize it and run GitHub action workflows.
 2. Review the terraform templates provided under the IaC/terraform folder and customize these files based on your specific deployment requirements for each resource.
-3. Test the deployment of each Azure resource individually using these [manual](../../docs/terraform-manual-steps.md) commands.
+3. Test the deployment of each Azure resource individually using these [manual](./terraform-manual-steps.md) commands.
 4. Customize the GitHub repo settings for flux so that it picks up your customized yaml files when deploying the shared services for your cluster. You need to change these settings in the file [`flux.yaml`](../../IaC/terraform/configuration/workloads/flux.tfvars) to point to your forked GitHub repo.
 
 

README.md

@@ -30,7 +30,7 @@ Each team will be responsible for maintaining their own automation pipeline. The
 This section demonstrates the implementation of a CI/CD pipeline built using GitHub Actions to automate the deployments of AKS and other Azure resources that AKS depends on. This pipeline deploys the [AKS Baseline Reference Implementation](https://github.com/mspnp/aks-baseline) using either Biceps or Terraform modules.
 
 
-![Infrastructure-as-Code](./docs/.attachments/IaC.jpg)
+![Infrastructure-as-Code](./media/IaC.jpg)
 
 ### Deploy AKS using GitHub Actions and Bicep
 Under the IaC/bicep folder you will find the instructions and the code to deploy the [AKS Baseline Reference Implementation](https://github.com/mspnp/aks-baseline) through a GitHub Actions pipeline leveraging bicep CARML modules. The steps can be found [here](https://github.com/Azure/aks-baseline-automation/tree/main/IaC/bicep).
@@ -45,7 +45,7 @@ We also provide example of metrics of interest from these Shared-Services that c
 In this section we demonstrate two implementation options:
 
  * A GitOps solution using the AKS [Flux](https://fluxcd.io/) add-on. Refer to [Shared-Services](./shared-services/README.md) for instructions on how to set it up so that the Traefik ingress controller gets automatically deployed.
- * A CI/CD pipeline built using GitHub actions. Refer to [this article](./doc/../docs/shared-services-workflow.md) for an example of a workflow to deploy an NGINX ingress controller.
+ * A CI/CD pipeline built using GitHub actions. Refer to [this article](./shared-services/shared-services-workflow.md) for an example of a workflow to deploy an NGINX ingress controller.
 
 
 The GitOps solution features:
@@ -53,7 +53,7 @@ The GitOps solution features:
  * An opinionated [overlay structure](https://cloud.google.com/anthos-config-management/docs/how-to/use-repo-kustomize-helm) that shows separation of concern and asset structure/management of the components that are bootstrapping the cluster.
 * Safe deployment practices with GitOps
 
-![Shared-Services Deployment](./docs/.attachments/shared-services.jpg)
+![Shared-Services Deployment](./media/shared-services.jpg)
 
 Note: in a real world deployment you may want to have a dedicated GitHub repo and an ACR instance for Shared-Services to store artifacts (i.e. manifest files, helm charts and docker images), separating them from the ones used for IaC and the application workloads. For simplicity and convenience sake, we have placed all those artifacts within this same repo but in different folders.
 
@@ -63,19 +63,23 @@ This section demonstrates the deployment of an application composed of multiple
 
  * A GitOps solution using [Flux](https://fluxcd.io/). Note that a future version of this solution will showcase an alternate GitOps products, such as [ArgoCD](https://argoproj.github.io/cd/) (see issue https://github.com/Azure/aks-baseline-automation/issues/72). This intent is to demonstrate how an app team may chose to use a separate tool for their specific workload lifecycle concerns as opposed to using the same tool as what the cluster operators use for cluster management.
 
-The application [Flask App](./docs/app-docs/README.md) is used for this deployment as this application is quite simple, but yet demonstrates how to deploy an application composed of multiple containers. In this case the application is composed of a web-front-end written in Python.
+The application [Flask App](./workloads/docs/README.md) is used for this deployment as this application is quite simple, but yet demonstrates how to deploy an application composed of multiple containers. In this case the application is composed of a web-front-end written in Python.
 
 Blue/Green and Canary release strategies for this application will also be demonstrated. Note however that this feature has not been implemented yet, see issue https://github.com/Azure/aks-baseline-automation/issues/27.
 
-### Deploy sample applications using GitHub Actions and GitOps
-Multiple GitHub action workflows are used to demonstrate the deployment of sample applications through a CI/CD pipeline (push and pull methods). Please click on the links below for instructions on how to use these workflows.
+### Deploy sample applications using GitHub Actions (push method)
+Multiple GitHub action workflows are used to demonstrate the deployment of sample applications through a CI/CD pipeline (push method). Please click on the links below for instructions on how to use these workflows.
 
 Sample App | Scenario | Description | Tags
 ---------- | -------- | ----------- | ----
-Flask Hello World| [Docker Build](./docs/app-docs/README.md) | Builds a container image from code on the runner then pushes to ACR. Deployment is done via a push model and a pull model(GitOps) as described in Microsoft docs. Requires the use of self-hosted runners if you deployed a private ACR per the instructions in the [IaC](./IaC/README.md) section of this repo. To setup self-hosted runners, refer to the [Self-hosted GitHub Runners](#Self-hosted-GitHub-Runners) section.
-Azure Vote | [AKS Run Command](./docs/app-docs/other-app-deploy-scenarios/app-azurevote-helmruncmd.md) |Sample of re-usable workflow called from the workflow [App-Test-All.yml](./.github/workflows/App-Test-All.yml). Deploys the app using a helm chart through the _AKS Command Invoke_. The focus here is to demonstrate how workloads in private clusters can still be managed through cloud hosted GitHub runners (no need to install self-hosted runners as in the other samples). It also shows how to test your application using Playwright.
-Azure Vote  | [ACR Build](./docs/app-docs/other-app-deploy-scenarios/app-azurevote-helmruncmd.md) |Another Sample of re-usable workflow called from the workflow [App-Test-All.yml](./.github/workflows/App-Test-All.yml). Builds a container image from code directly in Azure Container Registry (ACR). Deployment is done using the Azure Kubernetes GitHub actions. Requires the use of self-hosted runners if you deployed a private ACR per the instructions in the [IaC](./IaC/README.md) section of this repo. To setup self-hosted runners, refer to the [Self-hosted GitHub Runners](#Self-hosted-GitHub-Runners) section.
- 
+Flask Hello World| [Docker Build](./workloads/docs/app-flask-push-dockerbuild.md) | Builds a container image from code on the runner then pushes to ACR. Deployment is done via a push model. Requires the use of self-hosted runners if you deployed a private ACR per the instructions in the [IaC](./IaC/README.md) section of this repo. To setup self-hosted runners, refer to the [Self-hosted GitHub Runners](#Self-hosted-GitHub-Runners) section.
+Azure Vote | [AKS Run Command](./workloads/docs/other-app-scenarios/app-azurevote-helmruncmd.md) |Sample of re-usable workflow called from the workflow [App-Test-All.yml](./.github/workflows/App-Test-All.yml). Deploys the app using a helm chart through the _AKS Command Invoke_. The focus here is to demonstrate how workloads in private clusters can still be managed through cloud hosted GitHub runners (no need to install self-hosted runners as in the other samples). It also shows how to test your application using Playwright.
+Azure Vote  | [ACR Build](./workloads/docs/other-app-scenarios/app-azurevote-acrbuild.md) |Another Sample of re-usable workflow called from the workflow [App-Test-All.yml](./.github/workflows/App-Test-All.yml). Builds a container image from code directly in Azure Container Registry (ACR). Deployment is done using the Azure Kubernetes GitHub actions. Requires the use of self-hosted runners if you deployed a private ACR per the instructions in the [IaC](./IaC/README.md) section of this repo. To setup self-hosted runners, refer to the [Self-hosted GitHub Runners](#Self-hosted-GitHub-Runners) section.
+
+### Deploy sample applications using GitOps (pull method)
+You can use GitOps with flux or ArgoCD (pull method) as an alternative to GitHub action workflows to deploy your applications. 
+
+Refer to [these instructions](./workloads/docs/app-flask-pull-gitops.md) for how to setup your environment to deploy a sample application with GitOps using ArgoCD. 
 ## Lifecycle-Management
 Different components of an AKS solution are often owned by different teams and typically follow their own lifecycle management schedule and process, sometimes using different tools. In this section we will cover the following lifecycle management processes:
 
@@ -90,12 +94,12 @@ For better security and version control, all these lifecycle management processe
 Note that these features have not been implemented yet in this reference implementation. For the automation of the cluster lifecycle-management see issue https://github.com/Azure/aks-baseline-automation/issues/23.
 ## Secure DevOps
 A typical DevOps process for deploying containers to AKS can be depicted by the diagram below:
-![Typical DevOps](./docs/.attachments/secure-devOps-1.jpg)
+![Typical DevOps](./media/secure-devOps-1.jpg)
 
 
 The security team focus is to make sure that security is built into this automation pipeline and that security tasks are shifted to the left and automated as much as possible. They will need for example to work with the different automation teams to make sure that the following controls are in place within their pipelines:
 
-![Secure DevOps](./docs/.attachments/secure-devOps-2.jpg)
+![Secure DevOps](./media/secure-devOps-2.jpg)
 
 In addition to this oversight role, they will also have to build and maintain their own pipeline to automate the management of security related resources outside the clusters (Azure policies, firewall rules, NSGs, Azure RBAC, etc) as well as inside the cluster (Network Security Policies, Service Mesh Authentication and Authorization rules, Kubernetes RBAC, etc).
 
@@ -105,7 +109,7 @@ Incorporate security controls into the devOps pipeline is not implemented yet in
 
 This repository is organized as follow:
 
-![AKS Baseline Automation Repo Structure](./docs/.attachments/repo-structure.jpg)
+![AKS Baseline Automation Repo Structure](./media/repo-structure.jpg)
 
 
 ## Self-hosted GitHub Runners
@@ -117,7 +121,7 @@ For more information about the benefits of self-hosted runners, refer to [this a
 
    The diagram below depicts how a GitHub runner hosted in your Azure subscription uses a Managed Identity to connect securely to your Azure subscription and make changes to your Azure and Kubernetes resources:
    
-   ![GitHub Runners](./docs/.attachments/github-runners.jpg)
+   ![GitHub Runners](./media/github-runners.jpg)
 
 ## Contributing
 

workloads/README.md

@@ -1,7 +1,6 @@
 # Workloads
 This folder contains helm charts and other artifacts used to deploy sample applications.
 
-To deploy sample applications through a CI/CD pipeline using GitHub action workflows, refer to the following articles:
-* Start here: [Push and Pull models described in Microsoft docs with the Flask App](../docs/app-docs/README.md) (../docs/app-docs/README.md)
-* [AKS Run Command with the vote app](../docs/app-docs/other-app-deploy-scenarios/app-azurevote-helmruncmd.md)
-* [ACR Build with the vote app](../docs/app-docs/other-app-deploy-scenarios/app-azurevote-acrbuild.md)
+To deploy sample applications through a CI/CD pipeline using a GitHub action workflow (push method) or using GitOps (pull method), refer to the following article: [Push and Pull models for the deployment of the Flask app](./docs/README.md).
+
+Other sample apps can be found in the [other-app-scenarios](./docs/other-app-scenarios) folder.

workloads/docs/README.md

@@ -4,7 +4,7 @@ In the [**Automated build & deployment of container applications using DevOps &
 
 ### Option \#1 Push-based CI/CD Architecture and Dataflow
 
-![Figure 1 - Option 1 Push based Architecture with GitHub Actions for CI and CD](./pull-push-steps/media/5ef464b58b9ce8ab4499ed1c2aec882f.png)
+![Figure 1 - Option 1 Push based Architecture with GitHub Actions for CI and CD](./media/5ef464b58b9ce8ab4499ed1c2aec882f.png)
 
 This scenario covers a push-based DevOps pipeline for a web application with a front-end component. This pipeline uses GitHub Actions for build push and deployment. The data flows through the scenario as follows:
 
@@ -15,7 +15,7 @@ This scenario covers a push-based DevOps pipeline for a web application with a f
 
 ### Option \#2 Pull-based CI/CD Architecture and Dataflow
 
-![Figure 2 - Option 2 Pull based Architecture with GitHub Actions for CI and Argo CD for CD](./pull-push-steps/media/72be57feef5bb9b47658cfc16f3d779f.png)
+![Figure 2 - Option 2 Pull based Architecture with GitHub Actions for CI and Argo CD for CD](./media/72be57feef5bb9b47658cfc16f3d779f.png)
 
 This scenario covers a pull-based DevOps pipeline for a web application with a front-end component. This pipeline uses GitHub Actions for build and push it uses Argo CD a GitOps operator pull/sync for deployment. The data flows through the scenario as follows:
 
@@ -37,7 +37,7 @@ Before deploying the push or pull based end to end scenario you need to ensure y
 -   An ACR instance deployed
 -   An AKS cluster. It is highly recommended that you utilize one of the two options below:
     - Quick option: The [AKS Construction helper](https://azure.github.io/AKS-Construction/) to deploy your Azure Container Registry (ACR) and Azure Kubernetes Service (AKS) cluster. You can use this pre-configured link: [AKS Construction helper (pre-configured)](https://azure.github.io/AKS-Construction/?ops=managed&cluster.apisecurity=none&addons.ingress=none&addons.monitor=aci&addons.azurepolicy=none&addons.networkPolicy=none&addons.csisecret=none&deploy.location=EastUS2) to create a basic AKS cluster (not recommended for production) to use with this CI/CD scenario. This will create an ACR, and an AKS cluster that is AAD integrated and attached to the ACR
-    - Learn CI/CD for IaC first option: Deploy the cluster using the [infrastructure scenario](../../IaC) in this repo that walks you through the process of managing your infrastructure using automation
+    - The [IaC workflows](../../IaC/README.md) used in this repo, which walks you through the process of managing your infrastructure using automation with bicep or terraform.
 -   Argo CD installed on your AKS cluster (only required for pull option) ([Get Started with Argo CD](https://argo-cd.readthedocs.io/en/stable/getting_started/))
 -   A GitHub account ([Getting started with your GitHub account](https://docs.github.com/en/get-started/onboarding/getting-started-with-your-github-account))
 -   Fork the [AKS Baseline Automation repository](https://github.com/azure/aks-baseline-automation)
@@ -45,8 +45,8 @@ Before deploying the push or pull based end to end scenario you need to ensure y
 ### Next
 Pick one of the following options to deploy a workload using automation
 
-:arrow_forward: [Push option](./pull-push-steps/app-azurevote-push-dockerbuild.md)
+:arrow_forward: [Push option](./app-flask-push-dockerbuild.md)
 
-:arrow_forward: [Pull option](./pull-push-steps/app-azurevote-pull-gitops.md)
+:arrow_forward: [Pull option](./app-flask-pull-gitops.md)
 
-:arrow_forward: [Other app scenarios](./other-app-deploy-scenarios)
+:arrow_forward: [Other app scenarios](./other-app-scenarios)