When you work with CloudOps for Azure and deploy multiple types of Elastic Path Commerce environments, it is best practice to have one hub Azure Kubernetes Service (AKS) cluster. This AKS cluster is dedicated to building and deploying code. Create additional, separate AKS clusters dedicated to hosting Elastic Path Commerce environments. By running in this way, the Jenkins and Nexus containers inside the hub AKS cluster do not compete for resources with the Elastic Path Commerce deployment in a production environment.
The preceding diagram is an example of a CloudOps for Azure deployment with development, staging, and production Elastic Path Commerce environments running in their own AKS clusters. These clusters are in the same Resource Group and are managed by the Jenkins server in
Hub AKS Cluster. The
Hub AKS Cluster is the cluster bootstrap creates in
setup mode. The additional clusters are created by manually running bootstrap in
create-new-cluster mode or running the Jenkins job
For more information on the
create-new-cluster bootstrap mode, see:
For more information on the Jenkins job
Bootstrapping Separate Jenkins Clusters
A greater degree of isolation can be achieved by utilizing separate Jenkins clusters for each type of Elastic Path Commerce environment. This is done by running bootstrap in
setup mode for each environment.
When running the bootstrap container, the
docker-compose.yml must have different
baseName values. This ensures that separate Resource Groups are created for each environment. A separate Service Principal must also be created for each environment.
In the following diagram, the development and production environments have their own Resource Group and their own dedicated Jenkins. The Elastic Path stacks of the environments are deployed into their own AKS cluster instead of in the same cluster as the Jenkins server.
Note: This approach results in having separate Azure Container Registry (ACR) Docker registries in each Resource Group. By default, an environment can only access the registry in its own Resource Group. If the separate environments are for development, staging, and production, Docker images built in the dev environment will only be pushed into the registry in the dev Resource Group. To make images available in the other environments, without having to rebuild the Docker images, manually pull, tag, and push of images into the staging and production registries when required.
Different Configurations for Multiple AKS Clusters
Depending on the needs of the user and the desired degree of separation between deployments, there can be deployments of CloudOps for Azure with multiple AKS clusters with any of the following:
- Shared resource group
- Multiple resource groups
- Multiple subscriptions