Skip to content

Blog

Azure Container Registry: Artifact Cache

Azure Container Registry is a managed, private Docker registry service provided by Microsoft. It allows you to build, store, and manage container images and artifacts in a secure environment.

What is Artifact Caching?

Artifact Cache is a feature in Azure Container Registry that allows users to cache container images in a private container registry. It is available in Basic, Standard, and Premium service tiers.

Benefits of Artifact Cache

  • Reliable pull operations: Faster pulls of container images are achievable by caching the container images in ACR.
  • Private networks: Cached registries are available on private networks.
  • Ensuring upstream content is delivered: Artifact Cache allows users to pull images from the local ACR instead of the upstream registry.

Limitations

Cache will only occur after at least one image pull is complete on the available container image

How to Use Artifact Cache in Azure Container Registry without credential?

Let's take a look at how you can implement artifact caching in Azure Container Registry.

Step 1: Create a Cache Rule

The first step is to create a cache rule in your Azure Container Registry. This rule specifies the source image that should be cached and the target image that will be stored in the cache.

az acr cache create -r MyRegistry -n MyRule -s docker.io/library/ubuntu -t ubuntu

Check the cache rule:

az acr cache show -r MyRegistry -n MyRule

Step 2: Pull the Image

Next, you need to pull the image from the source registry to the cache. This will download the image and store it in the cache for future use.

docker pull myregistry.azurecr.io/hello-world:latest

Step 3: Clean up the resources

Finally, you can clean up the resources by deleting the cache rule.

az acr cache delete -r MyRegistry -n MyRule

If you need to check other rules, you can use the following command:

az acr cache list -r MyRegistry

Conclusion

Azure Container Registry's Artifact Cache feature provides a convenient way to cache container images in a private registry, improving pull performance and reducing network traffic. By following the steps outlined in this article, you can easily set up and use artifact caching in your Azure Container Registry.

If you need to use the cache with authentication, you can use the following article: Enable Artifact Cache with authentication.

For more detailed information, please visit the official tutorial on the Microsoft Azure website.

References

Repository Strategy: Branching Strategy

Once we have decided that we will use branches, it is time to define a strategy, so that all developers can work in a coordinated way.

Some of the best known strategies are:

  • Gitflow: It is a branching model designed around the project release. It is a strict branching model that assigns very specific roles to different branches.
  • Feature Branch: It is a strategy where each feature is developed in a separate branch. This strategy is simple and easy to understand.
  • Trunk-Based Development: It is a strategy where all developers work on a single branch. This strategy is simple and easy to understand.
  • GitHub Flow: It is a strategy where all developers work on a single branch. This strategy is simple and easy to understand.
  • GitLab Flow: It is a strategy where all developers work on a single branch. This strategy is simple and easy to understand.
  • Microsoft Flow: It is a strategy where all developers work on a single branch. This strategy is simple and easy to understand.

Gitflow

Gitflow is a branching model designed around the project release. It is a strict branching model that assigns very specific roles to different branches.

The Gitflow strategy is based on the following branches:

  • main: It is the main branch of the project. It contains the code that is in production.
  • develop: It is the branch where the code is integrated before being released to production.

The Gitflow strategy is based on the following types of branches:

  • feature: It is the branch where the code for a new feature is developed.
  • release: It is the branch where the code is prepared for release.
  • hotfix: It is the branch where the code is developed to fix a bug in production.

The Gitflow strategy is based on the following rules:

  • Feature branches are created from the develop branch.
  • Feature branches are merged into the develop branch.
  • Release branches are created from the develop branch.
  • Release branches are merged into the main and develop branches.
  • Hotfix branches are created from the main branch.
  • Hotfix branches are merged into the main and develop branches.

The Gitflow strategy is based on the following workflow:

  1. Developers create a feature branch from the develop branch.
  2. Developers develop the code for the new feature in the feature branch.
  3. Developers merge the feature branch into the develop branch.
  4. Developers create a release branch from the develop branch.
  5. Developers prepare the code for release in the release branch.
  6. Developers merge the release branch into the main and develop branches.
  7. Developers create a hotfix branch from the main branch.
  8. Developers fix the bug in the hotfix branch.
  9. Developers merge the hotfix branch into the main and develop branches.
gitGraph:
options
{
    "nodeSpacing": 150,
    "nodeRadius": 10
}
end
commit
branch develop
checkout develop
commit
commit
branch feature_branch
checkout feature_branch
commit
commit
checkout develop
merge feature_branch
commit
branch release_branch
checkout release_branch
commit
commit
checkout develop
merge release_branch
checkout main
merge release_branch
commit
branch hotfix_branch
checkout hotfix_branch
commit
commit
checkout develop
merge hotfix_branch
checkout main
merge hotfix_branch

The Gitflow strategy have the following advantages:

  • Isolation: Each feature is developed in a separate branch, isolating it from other features.
  • Collaboration: Developers can work on different features at the same time without affecting each other.
  • Stability: The main branch contains the code that is in production, ensuring that it is stable and reliable.

The Gitflow strategy is based on the following disadvantages:

  • Complexity: The Gitflow strategy is complex and can be difficult to understand for new developers.
  • Overhead: The Gitflow strategy requires developers to create and manage multiple branches, which can be time-consuming.

Feature Branch Workflow

Feature Branch is a strategy where each feature is developed in a separate branch. This strategy is simple and easy to understand.

The Feature Branch strategy is based on the following rules:

  • Developers create a feature branch from the main branch.
  • Developers develop the code for the new feature in the feature branch.
  • Developers merge the feature branch into the main branch.

The Feature Branch strategy is based on the following workflow:

  1. Developers create a feature branch from the main branch.
  2. Developers develop the code for the new feature in the feature branch.
  3. Developers merge the feature branch into the main branch.
gitGraph:
options
{
    "nodeSpacing": 150,
    "nodeRadius": 10
}
end
commit
checkout main
commit
commit
branch feature_branch
checkout feature_branch
commit
commit
checkout main
merge feature_branch

The Feature Branch strategy is based on the following advantages:

  • Simplicity: The Feature Branch strategy is simple and easy to understand.
  • Flexibility: Developers can work on different features at the same time without affecting each other.
  • Visibility: Changes made in feature branches are visible to other developers, making it easier to review and merge changes.

The Feature Branch strategy is based on the following disadvantages:

  • Conflicts: Multiple developers working on the same feature can lead to conflicts and merge issues.
  • Complexity: Managing multiple feature branches can be challenging, especially in large projects.

Trunk-Based Development

The Trunk-Based Development strategy is based on the following rules:

  • Developers work on a single branch.
  • Developers create feature flags to hide unfinished features.
  • Developers merge the code into the main branch when it is ready.

The Trunk-Based Development strategy is based on the following workflow:

  1. Developers work on a single branch.
  2. Developers create feature flags to hide unfinished features.
  3. Developers merge the code into the main branch when it is ready.
gitGraph:
options
{
    "nodeSpacing": 150,
    "nodeRadius": 10
}
end
commit
checkout main
commit
commit tag:"v1.0.0"
commit
commit
commit tag:"v2.0.0"

The Trunk-Based Development strategy is based on the following advantages:

  • Simplicity: The Trunk-Based Development strategy is simple and easy to understand.
  • Flexibility: Developers can work on different features at the same time without affecting each other.
  • Visibility: Changes made in the main branch are visible to other developers, making it easier to review and merge changes.

The Trunk-Based Development strategy is based on the following disadvantages:

  • Conflicts: Multiple developers working on the same codebase can lead to conflicts and merge issues.
  • Complexity: Managing feature flags can be challenging, especially in large projects.

GitHub Flow

GitHub Flow is a strategy where all developers work on a single branch. This strategy is simple and easy to understand.

The GitHub Flow strategy is based on the following rules:

  • Developers work on a single branch.
  • Developers create feature branches to work on new features.
  • Developers merge the feature branches into the main branch when they are ready.

The GitHub Flow strategy is based on the following workflow:

  1. Developers work on a single branch.
  2. Developers create a feature branch from the main branch.
  3. Developers develop the code for the new feature in the feature branch.
  4. Developers merge the feature branch into the main branch.
gitGraph:
options
{
    "nodeSpacing": 150,
    "nodeRadius": 10
}
end
commit
checkout main
commit
commit
branch feature_branch
checkout feature_branch
commit
commit
checkout main
merge feature_branch

GitLab Flow

GitLab Flow is a strategy where all developers work on a single branch. This strategy is simple and easy to understand. GitLab Flow is often used with release branches.

The GitLab Flow strategy is based on the following rules:

  • Developers work on a single branch.
  • Developers create feature branches to work on new features.
  • Developers merge the feature branches into the main branch when they are ready.
  • Developers create a pre-production branch to make bug fixes before merging changes back to the main branch.
  • Developers merge the pre-production branch into the main branch before going to production.
  • Developers can add as many pre-production branches as needed.
  • Developers can maintain different versions of the production branch.

The GitLab Flow strategy is based on the following workflow:

  1. Developers work on a single branch.
  2. Developers create a feature branch from the main branch.
  3. Developers develop the code for the new feature in the feature branch.
  4. Developers merge the feature branch into the main branch.
  5. Developers create a pre-production branch from the main branch.
  6. Developers make bug fixes in the pre-production branch.
  7. Developers merge the pre-production branch into the main branch.
  8. Developers create a production branch from the main branch.
  9. Developers merge the production branch into the main branch.
gitGraph:
options
{
    "nodeSpacing": 150,
    "nodeRadius": 10
}
end
commit
checkout main
commit
commit
branch feature_branch
checkout feature_branch
commit
commit
checkout main
merge feature_branch
commit
branch pre-production
checkout pre-production
commit
commit
checkout main
merge pre-production
commit
branch production
checkout production
commit
commit
checkout main
merge production

Repository Strategy: Fork vs Branch

In this post, I will explain the different ways to contribute to a Git repository: Fork vs Branch.

Fork

A fork is a copy of a repository that you can make changes to without affecting the original repository. When you fork a repository, you create a new repository in your GitHub account that is a copy of the original repository.

The benefits of forking a repository include:

  • Isolation: You can work on your changes without affecting the original repository.
  • Collaboration: You can make changes to the forked repository and submit a pull request to the original repository to merge your changes.
  • Ownership: You have full control over the forked repository and can manage it as you see fit.

The challenges of forking a repository include:

  • Synchronization: Keeping the forked repository up to date with the original repository can be challenging.
  • Conflicts: Multiple contributors working on the same codebase can lead to conflicts and merge issues.
  • Visibility: Changes made to the forked repository are not visible in the original repository until they are merged.

Branch

A branch is a parallel version of a repository that allows you to work on changes without affecting the main codebase. When you create a branch, you can make changes to the code and submit a pull request to merge the changes back into the main branch.

The benefits of using branches include:

  • Flexibility: You can work on different features or bug fixes in separate branches without affecting each other.
  • Collaboration: You can work with other developers on the same codebase by creating branches and submitting pull requests.
  • Visibility: Changes made in branches are visible to other developers, making it easier to review and merge changes.

The challenges of using branches include:

  • Conflicts: Multiple developers working on the same branch can lead to conflicts and merge issues.
  • Complexity: Managing multiple branches can be challenging, especially in large projects.
  • Versioning: Branches are versioned separately, making it harder to track changes across the project.

Fork vs Branch

The decision to fork or branch a repository depends on the project's requirements and the collaboration model.

  • Fork: Use a fork when you want to work on changes independently of the original repository or when you want to contribute to a project that you do not have write access to.

  • Branch: Use a branch when you want to work on changes that will be merged back into the main codebase or when you want to collaborate with other developers on the same codebase.

For my IaC project with Terraform, I will use branches to work on different features and bug fixes and submit pull requests to merge the changes back into the main branch. This approach will allow me to collaborate with other developers and keep the codebase clean and organized.

Repository Strategy: Monorepo vs Multi-repo

In this post, I will explain the repository strategy that I will use for my Infrastructure as Code (IaC) project with Terraform.

Monorepo

A monorepo is a single repository that contains all the code for a project.

The benefits of using a monorepo include:

  • Simplicity: All the code is in one place, making it easier to manage and maintain.
  • Consistency: Developers can easily see all the code related to a project and ensure that it follows the same standards and conventions.
  • Reusability: Code can be shared across different parts of the project, reducing duplication and improving consistency.
  • Versioning: All the code is versioned together, making it easier to track changes and roll back if necessary.

The challenges of using a monorepo include:

  • Complexity: A monorepo can become large and complex, making it harder to navigate and understand.
  • Build times: Building and testing a monorepo can take longer than building and testing smaller repositories.
  • Conflicts: Multiple developers working on the same codebase can lead to conflicts and merge issues.

Multi-repo

A multi-repo is a set of separate repositories that contain the code for different parts of a project.

The benefits of using a multi-repo include:

  • Isolation: Each repository is independent, making it easier to manage and maintain.
  • Flexibility: Developers can work on different parts of the project without affecting each other.
  • Scalability: As the project grows, new repositories can be added to manage the code more effectively.

The challenges of using a multi-repo include:

  • Complexity: Managing multiple repositories can be more challenging than managing a single repository.
  • Consistency: Ensuring that all the repositories follow the same standards and conventions can be difficult.
  • Versioning: Each repository is versioned separately, making it harder to track changes across the project.

Conclusion

For my IaC project with Terraform, I will use a monorepo approach to manage all the Terraform modules and configurations for my project.

Terraform: Configuration Language

After deciding to use Terraform for my Infrastructure as Code (IaC) project, Terraform configuration language must be understanded to define the desired state of my infrastructure.

Info

I will update this post with more information about Terraform configuration language in the future.

Terraform uses a declarative configuration language to define the desired state of your infrastructure. This configuration language is designed to be human-readable and easy to understand, making it accessible to both developers and operations teams.

Declarative vs. Imperative

Terraform's configuration language is declarative, meaning that you define the desired state of your infrastructure without specifying the exact steps needed to achieve that state. This is in contrast to imperative languages, where you specify the exact sequence of steps needed to achieve a desired outcome.

For example, in an imperative language, you might write a script that creates a virtual machine by executing a series of commands to provision the necessary resources. In a declarative language like Terraform, you would simply define the desired state of the virtual machine (e.g., its size, image, and network configuration) and let Terraform figure out the steps needed to achieve that state.

Configuration Blocks

Terraform uses configuration blocks to define different aspects of your infrastructure. Each block has a specific purpose and contains configuration settings that define how that aspect of your infrastructure should be provisioned.

For example, you might use a provider block to define the cloud provider you want to use, a resource block to define a specific resource (e.g., a virtual machine or storage account), or a variable block to define input variables that can be passed to your configuration.

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "East US"
}

variable "location" {
  type    = string
  default = "East US"
}

Variables

Terraform allows you to define variables that can be used to parameterize your configuration. Variables can be used to pass values into your configuration, making it easier to reuse and customize your infrastructure definitions.

variable "location" {
  type    = string
  default = "East US"
}

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = var.location
}

locals

Terraform allows you to define local values that can be used within your configuration. Locals are similar to variables but are only available within the current module or configuration block.

variable "location" {
  type    = string
  default = "East US"
}

locals {
  resource_group_name = "example-resources"
}

resource "azurerm_resource_group" "example" {
  name     = local.resource_group_name
  location = var.location
}

Data Sources

Terraform allows you to define data sources that can be used to query external resources and retrieve information that can be used in your configuration. Data sources are read-only and can be used to fetch information about existing resources, such as virtual networks, storage accounts, or database instances.

data "azurerm_resource_group" "example" {
  name = "example-resources"
}

resource "azurerm_virtual_network" "example" {
  name                = "example-network"
  location            = data.azurerm_resource_group.example.location
  resource_group_name = data.azurerm_resource_group.example.name
}

Functions

try

The try function allows you to provide a default value in case an expression returns an error. This can be useful when working with optional values that may or may not be present.

variable "optional_value" {
  type    = string
  default = null
}

locals {
  value = try(var.optional_value, "default_value")
}

Debugging Terraform

You can use the TF_LOG environment variable to enable debug logging in Terraform. This can be useful when troubleshooting issues with your infrastructure or understanding how Terraform is executing your configuration.

export TF_LOG=DEBUG
terraform plan

TOu can use the following decreasing verbosity levels log: TRACE, DEBUG, INFO, WARN or ERROR

To persist logged output logs in a file:

export TF_LOG_PATH="terraform.log"

To separare logs for Terraform and provider, you can use the following environment variables TF_LOG_CORE and TF_LOG_PROVIDER respectively. For example, to enable debug logging for both Terraform and the Azure provider, you can use the following environment variables:

export TF_LOG_CORE=DEBUG
export TF_LOG_PATH="terraform.log"

or

export TF_LOG_PROVIDER=DEBUG
export TF_LOG_PATH="provider.log"

To disable debug logging, you can unset the TF_LOG environment variable:

unset TF_LOG

References

Terraform: Set your local environment developer

I wil use Ubuntu in WSL v2 as my local environment for my IaC project with Terraform. I will install the following tools:

  • vscode
  • Trunk
  • tenv
  • az cli

az cli

I will use the Azure CLI to interact with Azure resources from the command line. I will install the Azure CLI using the following commands:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

vscode

I will use Visual Studio Code as my code editor for my IaC project with Terraform. I will install the following extensions:

  • Terraform
  • Azure Terraform
  • Azure Account
  • Trunk

tenv

tenv is a tool that allows you to manage multiple Terraform environments with ease. It provides a simple way to switch between different environments, such as development, staging, and production, by managing environment variables and state files for each environment.

Installation

You can install tenv using go get:

LATEST_VERSION=$(curl --silent https://api.github.com/repos/tofuutils/tenv/releases/latest | jq -r .tag_name)
curl -O -L "https://github.com/tofuutils/tenv/releases/latest/download/tenv_${LATEST_VERSION}_amd64.deb"
sudo dpkg -i "tenv_${LATEST_VERSION}_amd64.deb"

Usage

To create a new environment, you can use the tenv create command:

# to install the latest version of Terraform
tenv tf install 

References

Starting my IaC project with terraform

This is not my first IaC project but I want to share with you some key considerations that I have in mind to start a personal IaC project with Terraform based on post What you need to think about when starting an IaC project ?

1. Define Your Goals

These are my goals:

  • Automate the provisioning of infrastructure
  • Improve consistency and repeatability
  • Reduce manual effort
  • Enable faster deployments

2. Select the Right Tools

For my project I will use Terraform because I am familiar with it and I like its declarative configuration language.

3. Design Your Infrastructure

In my project, I will use a modular design that separates my infrastructure into different modules, such as networking, compute, and storage. This will allow me to reuse code across different projects and make my infrastructure more maintainable.

4. Version Control Your Code

I will use Git for version control and follow best practices for version control, such as using descriptive commit messages and branching strategies.

5. Automate Testing

Like appear in Implement compliance testing with Terraform and Azure, I'd like to implement:

  • Compliance testing
  • End-to-end testing
  • Integration testing

6. Implement Continuous Integration/Continuous Deployment (CI/CD)

I set up my CI/CD pipelines with Github Actions.

7. Monitor and Maintain Your Infrastructure

I will use Azure Monitor to monitor my infrastructure and set up alerts to notify me of any issues. I will also regularly review and update my infrastructure code to ensure that it remains up to date and secure.

Of course I don't have all the answers yet, but I will keep you updated on my progress and share my learnings along the way. Stay tuned for more updates on my IaC project with Terraform!

What you need to think about when starting an IaC project ?

Infrastructure as Code (IaC) is a key practice in modern software development that allows you to manage your infrastructure in a declarative manner. With IaC, you can define your infrastructure using code, which can be version-controlled, tested, and deployed automatically. This approach brings several benefits, such as increased consistency, repeatability, and scalability.

When starting an IaC project, there are several key considerations you need to keep in mind to ensure its success. In this article, we will discuss some of the key things you should think about when embarking on an IaC project.

1. Define Your Goals

Before you start writing any code, it's essential to define your goals for the IaC project. What are you trying to achieve with IaC? Are you looking to automate the provisioning of infrastructure, improve consistency, or increase scalability? By clearly defining your goals, you can ensure that your IaC project is aligned with your organization's objectives.

Some examples:

  • Automate the provisioning of infrastructure
  • Improve consistency and repeatability
  • Increase scalability and reduce manual effort
  • Enhance security and compliance
  • Enable faster development and deployment cycles

2. Select the Right Tools

Choosing the right tools is crucial for the success of your IaC project. There are several IaC tools available, such as Terraform, Ansible, and AWS CloudFormation, each with its strengths and weaknesses. Consider factors such as ease of use, scalability, and integration with your existing tools when selecting an IaC tool.

Some examples:

  • Terraform: A popular IaC tool that allows you to define your infrastructure using a declarative configuration language.
  • Ansible: A configuration management tool that can also be used for IaC.
  • AWS CloudFormation: A service provided by AWS that allows you to define your infrastructure using JSON or YAML templates.
  • Azure Resource Manager (ARM) templates: A service provided by Azure that allows you to define your infrastructure using JSON templates.
  • Bicep: A domain-specific language for defining Azure resources that compiles to ARM templates.
  • Pulumi: A tool that allows you to define your infrastructure using familiar programming languages such as Python, JavaScript, and Go.
  • Chef: A configuration management tool that can also be used for IaC.

3. Design Your Infrastructure

When designing your infrastructure, think about how you want to structure your code. Consider using modular designs that allow you to reuse code across different projects. Define your infrastructure in a way that is easy to understand and maintain, and follow best practices for code organization.

4. Version Control Your Code

Version control is a fundamental practice in software development, and it is equally important for IaC projects. By using version control systems such as Git, you can track changes to your infrastructure code, collaborate with team members, and roll back changes if needed. Make sure to follow best practices for version control, such as using descriptive commit messages and branching strategies.

Some examples:

  • Use Git for version control
  • Use branching strategies like Microsoft Flow or GitHub Flow to manage your codebase
  • Use pull requests for code reviews
  • Automate your CI/CD pipelines to run tests and deploy changes
  • Use tags to mark releases or milestones

5. Automate Testing

Testing is an essential part of any software development project, and IaC is no exception. Automating your tests can help you catch errors early in the development process and ensure that your infrastructure code is working as expected. Consider using tools such as Terraform's built-in testing framework or third-party testing tools to automate your tests.

Some examples:

  • Use Terraform's built-in testing framework to write unit tests for your infrastructure code
  • Use tools like Terratest or Kitchen-Terraform to write integration tests for your infrastructure code
  • Use static code analysis tools to check for common errors and best practices in your infrastructure code, like Terraform's terraform validate command, or tools like tfsec or checkov.
  • Use linting tools to enforce coding standards and style guidelines in your infrastructure code, like Terraform's terraform fmt command, or tools like tflint or checkov.
  • Use security scanning tools to identify potential security vulnerabilities in your infrastructure code.

6. Implement Continuous Integration/Continuous Deployment (CI/CD)

CI/CD pipelines are a key component of modern software development practices, and they are equally important for IaC projects. By implementing CI/CD pipelines, you can automate the testing, building, and deployment of your infrastructure code, reducing the risk of errors and speeding up the development process. Consider using tools such as Github or Azure DevOps to set up your CI/CD pipelines.

Use tools like Terraform Cloud, Azure DevOps, or Github Actions to automate your CI/CD pipelines.

7. Monitor and Maintain Your Infrastructure

Once your IaC project is up and running, it's essential to monitor and maintain your infrastructure. Implement monitoring solutions that allow you to track the health and performance of your infrastructure, and set up alerts to notify you of any issues. Regularly review and update your infrastructure code to ensure that it remains up-to-date and secure.

By keeping these key considerations in mind when starting an IaC project, you can set yourself up for success and ensure that your infrastructure is managed efficiently and effectively. IaC is a powerful practice that can help you automate and scale your infrastructure, and by following best practices, you can maximize the benefits of this approach.

How to create a Management Group diagram with draw.io

I nedd to create a diagram of the Management Groups in Azure, and I remembered a project that did something similar but with PowerShell: https://github.com/PowerShellToday/new-mgmgroupdiagram.

Export your Management Group structure from Azure Portal or ask for it

If you can access the Azure Portal, you can export the Management Group structure to a CSV file. To do this, follow these steps:

  1. Go to the Azure portal.
  2. Navigate to Management groups.
  3. Click on Export.
  4. Save the CSV file to your local machine.

If you don't have access to the Azure Portal, you can ask your Azure administrator to export the Management Group structure for you.

The file has the following columns:

  • id: The unique identifier of the Management Group or subscription.
  • displayName: The name of the Management Group or subscription.
  • itemType: The type of the item (Management Group or subscription).
  • path: The path to the management or subscription group, its parent.
  • accessLevel: Your access level.
  • childSubscriptionCount: The number of child subscriptions at this level.
  • totalSubscriptionCount: The total number of subscriptions.

Create a CSV to be imported into draw.io

  1. Import the CSV file to excel, rename the sheet to "Export_Portal"
  2. Create a second sheet with the following columns:
    • id: reference to the id in the first sheet
    • displayName: reference to the displayName in the first sheet
    • itemType: reference to the itemType in the first sheet
    • ParentId: Use the following formula to get the parent of the current item:
      =IF(ISERROR(FIND(","; Export_Portal!D2)); Export_Portal!D2; TRIM(RIGHT(SUBSTITUTE(Export_Portal!D2; ","; REPT(" "; LEN(Export_Portal!D2))); LEN(Export_Portal!D2))))
      
  3. Export the second sheet to a CSV file.

Import the CSV file into draw.io

  1. Go to draw.io and create a new diagram.
  2. Click on Arrange > Insert > Advanced > CSV.
  3. Insert the header for the columns: id, displayName, itemType, Parent:

        #label: %displayName%
        #stylename: itemType
        #styles: {"Management Group": "label;image=img/lib/azure2/general/Management_Groups.svg;whiteSpace=wrap;html=1;rounded=1; fillColor=%fill%;strokeColor=#6c8ebf;fillColor=#dae8fc;points=[[0.5,0,0,0,0],[0.5,1,0,0,0]];",\
        #"Subscription": "label;image=img/lib/azure2/general/Subscriptions.svg;whiteSpace=wrap;html=1;rounded=1; fillColor=%fill%;strokeColor=#d6b656;fillColor=#fff2cc;points=[[0.5,0,0,0,0],[0.5,1,0,0,0]];imageWidth=26;"}
        #
        #
        #namespace: csvimport-
        #
        #connect: {"from": "ParentId", "to": "displayName", "invert": true, "style": "curved=1;endArrow=blockThin;endFill=1;fontSize=11;edgeStyle=orthogonalEdgeStyle;"}
        #
        ## Node width and height, and padding for autosize
        #width: auto
        #height: auto
        #padding: -12
        #
        ## ignore: id,image,fill,stroke,refs,manager
        #
        ## Column to be renamed to link attribute (used as link).
        ## link: url
        #
        ## Spacing between nodes, heirarchical levels and parallel connections.
        #nodespacing: 40
        #levelspacing: 100
        #edgespacing: 40
        #
        ## layout: auto
        #layout: verticaltree
        #
        ## ---- CSV below this line. First line are column names. ----
    
    4. Paste the content of the CSV file and click on Import.

You should see a diagram with the Management Groups and Subscriptions.

For example:

This is the common structure for the Management Groups in the Enterprise Scale Landing Zone, now Accelerator Landing Zone:

    graph TD
        A[Root Management Group] --> B[Intermediary-Management-Group]
        B --> C[Decommissioned]
        B --> D[Landing Zones]
        B --> E[Platform]
        B --> F[Sandboxes]
        D --> G[Corp]
        D --> H[Online]
        E --> I[Connectivity]
        E --> J[Identity]
        E --> K[Management]        

And this is the CSV file to import into draw.io:

#label: %displayName%
#stylename: itemType
#styles: {"Management Group": "label;image=img/lib/azure2/general/Management_Groups.svg;whiteSpace=wrap;html=1;rounded=1; fillColor=%fill%;strokeColor=#6c8ebf;fillColor=#dae8fc;points=[[0.5,0,0,0,0],[0.5,1,0,0,0]];",\
#"Subscription": "label;image=img/lib/azure2/general/Subscriptions.svg;whiteSpace=wrap;html=1;rounded=1; fillColor=%fill%;strokeColor=#d6b656;fillColor=#fff2cc;points=[[0.5,0,0,0,0],[0.5,1,0,0,0]];imageWidth=26;"}
#
#
#namespace: csvimport-
#
#connect: {"from": "ParentId", "to": "displayName", "invert": true, "style": "curved=1;endArrow=blockThin;endFill=1;fontSize=11;edgeStyle=orthogonalEdgeStyle;"}
#
## Node width and height, and padding for autosize
#width: auto
#height: auto
#padding: -12
#
## ignore: id,image,fill,stroke,refs,manager
#
## Column to be renamed to link attribute (used as link).
## link: url
#
## Spacing between nodes, heirarchical levels and parallel connections.
#nodespacing: 40
#levelspacing: 100
#edgespacing: 40
#
## layout: auto
#layout: verticaltree
#
## ---- CSV below this line. First line are column names. ----
id,displayName,itemType,ParentId
1,Tenant Root Group,Management Group,
2,Intermediary Management Group,Management Group,Tenant Root Group
3,Decommissioned,Management Group,Intermediary Management Group
4,Landing Zones,Management Group,Intermediary Management Group
5,Platform,Management Group,Intermediary Management Group
6,Sandboxes,Management Group,Landing Zones
7,Corp,Management Group,Landing Zones
8,Online,Management Group,Landing Zones
9,Connectivity,Management Group,Platform
10,Identity,Management Group,Platform
11,Management,Management Group,Platform
12,subcr-1,Subscription,Decommissioned
13,subcr-2,Subscription,Sandboxes
14,subcr-3,Subscription,Corp
15,subcr-4,Subscription,Online
16,subcr-5,Subscription,Connectivity
17,subcr-6,Subscription,Identity
18,subcr-7,Subscription,Management

Make your diagram animated and interactive

You can make your diagram animated and interactive by following these steps:

  1. File > Export as > URL
  2. Add p=ex& after the first ? in the URL.

For example, the URL should look like this:

https://viewer.diagrams.net/?p=ex&tags=%7B%7D&highlight=0000ff&layers=1&nav=1&title=MGs.drawio#R7Zxbc5s4FMc%2FjR%2BbAQkEPK7dJHWn3XbW6exMX3ZkkLFakDxCvvXTr7jFxrZi1k0Wg5lxYnR0QfqfHxqOBB7AUbx5FHgx%2F8wDEg2AEWwG8P0AAGAgQ32llm1uMU0X5pZQ0KCw7QwT%2BosUxqJiuKQBSSoFJeeRpIuq0eeMEV9WbFgIvq4Wm%2FGoetYFDsmRYeLj6Nj6Nw3kvBwG8nYZHwgN58WpXeDkGTEuCxcjSeY44Os9E7wfwJHgXOZH8WZEolS9Upe83oMm97ljgjB5osK3hIgv0x%2BpJsCI8FQ5Jis0AHZAk0WEt3%2FimKhU3k7Z7HBLxq7x42mcwOHy%2B0dn9PCRvIOFz%2FYrZqWfCMMsPcFf6TCA8Sj4clE0KEn8tF0UBT9jpoSKCTso9TXr%2Fjgo%2B5YNKcI%2BmStHEbHvvKoMidyWLioGN6Rx7ksah0qFiE7Vf%2FxrKUgqSkgYEVjVfNh15Z%2BsI8ldsgpV9fVcdXmyUOdWbawVzso2l3Eqm6kOVVEWkKBIpSjRKBrxiIusF3aaTNWEw0QK%2FpPssiDyXTKdqZxqFRhg4s58ZV9wymQ2VnuoPsadcsrIqPzZqsLoOc88zFOftFOpfCsiJNloIdnX8pHwmEixVUWKCpYD7goituU1nCfXO%2FqB4ea2%2BR74dmHDhc%2FC57Z3TKqDwoFlco%2FS16fW0lA7ZpKImAQUZ0PXsXkJwS9cED3WDWINnQOsTegec%2B20g2tbw%2FV74vM4pklCOVMuvRjimtdHD3RzQJezcjlJ2%2BiIZtNrB81IQ%2FMnzALKFCLGd4Vz0uPcYZyhZ57nuSWzs6Ph%2BWuE5YyLuAe5wyB7rn0eZKsdILsakCdqYp7yze9MySfn9p7bBu8nAKxwCx3rmFvUDm49DbcjLn4jsuuRvTJkLWieRxa0AlnL0CD7hUWUkR7azkBre955aGE7oDW182y2FE9XVG4vR7d6u9wz2xyzjuN05d7AAhpmx4ESo%2Be1E7wexmBtnmN1G2%2F7TPbEtp1Y00Q1wq92rH9Zul23ZDn1xTvzFK%2BT5TTxBV1IytkpUk9tbLwxr%2FtdentWAzRFNjpmdTabAf8VWc0GXz7HANAr3dPWmG5bEofpdtZydsEl7B6slvXYXgu2wKrOuZYHWsutbg8t5xZewu1utaxH9lqQPVzyajOyum2yHFnrEmT3V8t6aK8FWmRYnYFWtyWWQ2tfAu3xalmP7rWg63hOZ9DV7Yrl6KJL0K0umvXYXgu2nmd0BVtbtzOWY%2Btcgu3h2lkP7rWAa5qu2yS5Ry9ZnGayGNcKR0tSog2qjPhLsXp2IGHBH%2BmrKCo5jbj%2F82lOWW5%2BSB2ZF5pxJovXX8ysUhCSSdEgF3LOQ85wdL%2BzFoKn5V6WW3WML4VPXhhS%2BYKHxCIk8qWC1mkHChJhdQ9T7cl%2FcEZN5UH3lLfqKm83qjy8YeVRo8pbN6y806jydveUR3WVdxtVHt2w8l6jyju3q3z%2BFF5jyrvdU96pq7wmLPiflPduWHnQpPLlrwPcpPKwUeU7GMPadZVvNIZFHYxh3brKNxrDog7GsF5d5RuNYVH3YtjylY3zyjcaw6LuxbDlewfnlW80hkXdi2HLp%2BfPK99oDIu6F8Naddfn7TeKYVVy90tVWd7eD37B%2B38B#%7B%22pageId%22%3A%22UGUHswWqf16rUITyRAQM%22%7D

You can check it here

References

Moving Management Groups and Subscriptions

Managing your Azure resources efficiently often involves moving management groups and subscriptions. Here's a brief guide on how to do it:

Moving Management Groups

To move a management group, you need to have the necessary permissions. You must be an owner of the target parent management group and have Management Group Contributor role at the group you want to move.

Here's the step-by-step process:

  1. Navigate to the Azure portal.
  2. Go to Management groups.
  3. Select the management group you want to move.
  4. Click Details.
  5. Under Parent group, click Change.
  6. Choose the new parent group from the list and click Save.

Remember, moving a management group will also move all its child resources including other management groups and subscriptions.

Moving Subscriptions

You can move a subscription from one management group to another or within the same management group. To do this, you must have the Owner or Contributor role at the target management group and Owner role at the subscription level.

Follow these steps:

  1. Go to the Azure portal.
  2. Navigate to Management groups.
  3. Select the management group where the subscription currently resides.
  4. Click on Subscriptions.
  5. Find the subscription you want to move and select ..." (More options).
  6. Click Change parent.
  7. In the pop-up window, select the new parent management group and click Save.

Note

Moving subscriptions could affect the resources if there are policies or permissions applied at the management group level. It's important to understand the implications before making the move. Also, keep in mind that you cannot move the Root management group or rename it.

In conclusion, moving management groups and subscriptions allows for better organization and management of your Azure resources. However, it should be done carefully considering the impact on resources and compliance with assigned policies.