Environments

Environments allow you to develop and test your DX Cloud project in separate places so that your project is thoroughly tested and production-ready without impacting the proper production environment itself.

Typically, you have three environments and by default, we offer the following.

Environment Description

dev

The dev, or development, environment is typically used for active development where developers build out the project.

This is typically the starting environment for your project.

dev environment overview

uat

The uat, or User Acceptance Testing, environment is often used to validate and test the software developed by the developers in the dev environment. Hence, the "acceptance" part of the name.

Typically, the environment flow moves from dev > uat > prod.

uat environment overview

prod

The prod, or production, environment is the actual live environment and is implemented after uat.

prod environment overview


Author and Public in environments

We recommend that you have both Public and Author instances within your different environments as this allows proper testing of the entire workflow through multiple environments. Check out the visual below for more details.

environments with architecture

Feature environments

If your DX Cloud project requires that you have different environments than the default 3 environments (dev, uat, prod), you can configure your .gitlab-ci.yml file to have whatever environments you like.

A typical use-case for this would be temporary feature environments where you work on a new feature or improvement that you want to see fully before it goes into uat and onto prod. You can do this by ensuring your .gitlab-ci.yml file is configured to reflect the name of those environments.

See Feature environments for steps on creating a temporary feature environment.
Once configured in the .gitlab-ci.yml file, you can easily view and manage your environments directly from the Cockpit.

The .gitlab-ci.yml file

It’s important that you configure the .gitlab-ci.yml file correctly so that your development changes are picked up and deployed. If you are using a different CI/CD pipeline, you can use this file as a blueprint.

Magnolia automatically picks up the changes when using this approach.
.gitlab-ci.yml
# Use the latest Maven version

stages:
  - build
  - push
  - deploy

variables:
  MAVEN_OPTS: "-Dhttps.protocols=TLSv1.2 -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"

# Build the Maven project.
build-magnolia: (1)
  image: maven:3.6-jdk-11-slim
  stage: build
  cache:
    key: "$CI_JOB_NAME"
    paths:
      - $CI_PROJECT_DIR/.m2/repository
  before_script:
    - mkdir -p $CI_PROJECT_DIR/.m2
  script:
    - mvn $MAVEN_CLI_OPTS package
    - ls -Fahl base-webapp/target
  artifacts:
    expire_in: 30 days
    paths:
      - base-webapp/target/*.war

# Build docker images based on artifacts from the build stage.
push-docker-image: (2)
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: push
  dependencies:
    - build-magnolia
  before_script:
    - export WEBAPP_IMAGE=${CI_REGISTRY_IMAGE}/magnolia-webapp
    - export GIT_TAG=$CI_COMMIT_SHORT_SHA (3)
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json (4)
  script:
    - cd base-webapp
    - /kaniko/executor --context . --dockerfile ./Dockerfile --destination "$WEBAPP_IMAGE:$GIT_TAG"

.deploy: (5)
  image: registry.gitlab.com/mironet/helm-kubectl-gomplate:v0.0.5
  stage: deploy
  before_script:
    - export GIT_TAG=$CI_COMMIT_SHORT_SHA
    - helm repo add mironet https://charts.mirohost.ch/
    - export HELM_CHART_VERSION=1.16.0
    - export KUBECONFIG=$KUBE_CONFIG (6)
    - chmod 600 $KUBE_CONFIG (6)

deploy-dev: (7)
  extends: .deploy
  script:
    - export DEPLOYMENT=dev
    - export LE_ENVIRONMENT=letsencrypt-prod
    - cat values.yml | gomplate > ${DEPLOYMENT}.yml
    - cat ${DEPLOYMENT}.yml
    - kubectl create namespace ${DEPLOYMENT} --dry-run=client -o yaml | kubectl annotate --local -f - field.cattle.io/projectId=`kubectl get namespace default --output="jsonpath={.metadata.annotations.field\.cattle\.io/projectId}"` -o yaml  | kubectl apply -f - (8)
    - |
      sleep 2
      until kubectl get namespace ${DEPLOYMENT}; do
        echo "Waiting for namespace ${DEPLOYMENT} to be created..."
        sleep 2
      done
    - helm upgrade -i ${DEPLOYMENT} mironet/magnolia-helm --version ${HELM_CHART_VERSION} -f ${DEPLOYMENT}.yml -n ${DEPLOYMENT} (9)
    - kubectl -n default get secret gitlab -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT}  -f - (10)
    - kubectl -n default get secret s3-backup-key -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT}  -f - (10)
  environment:
    name: dev (11)
  when: manual (12)

deploy-uat: (7)
  extends: .deploy
  script:
    - export DEPLOYMENT=uat
    - export LE_ENVIRONMENT=letsencrypt-prod
    - cat values.yml | gomplate > ${DEPLOYMENT}.yml
    - cat ${DEPLOYMENT}.yml
    - kubectl create namespace ${DEPLOYMENT} --dry-run=client -o yaml | kubectl annotate --local -f - field.cattle.io/projectId=`kubectl get namespace default --output="jsonpath={.metadata.annotations.field\.cattle\.io/projectId}"` -o yaml  | kubectl apply -f - (8)
    - |
      sleep 2
      until kubectl get namespace ${DEPLOYMENT}; do
        echo "Waiting for namespace ${DEPLOYMENT} to be created..."
        sleep 2
      done
    - helm upgrade -i ${DEPLOYMENT} mironet/magnolia-helm --version ${HELM_CHART_VERSION} -f ${DEPLOYMENT}.yml -n ${DEPLOYMENT} (9)
    - kubectl -n default get secret gitlab -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT}  -f - (10)
    - kubectl -n default get secret s3-backup-key -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT}  -f - (10)
  environment:
    name: dev (11)
  when: manual (12)
1 In the build-magnolia stage, the web app is built using maven, as with any Magnolia project. If using Magnolia 6.3, you need Java 17 under build-magnolia.image. 
build-magnolia:
  image: maven:3.8-openjdk-17-slim
2 In the push-docker-image stage, the Docker image is built and pushed to the Docker registry (in this case the GitLab registry), using the Dockerfile located in the webapp folder.
3 The GIT_TAG is used to set the tag for the created Docker image.
4 The environment variables are set automatically by GitLab if the GitLab registry is used for the project.

We recommend that you use GitLab.

env variables

  • $CI_REGISTRY_USER

  • $CI_REGISTRY_PASSWORD

  • $CI_REGISTRY
5 The general deployment stage defines the helm chart repo and the version of the Helm chart to be used in the actual deployments.
6 The KUBE_CONFIG CI/CD variable should be defined as type File and hold KubeConfig of the cluster the deployment should go to. The same variable can be defined in different environment scopes (see 11). The chmod command changes the access to the file to avoid warnings.
7 The actual deployment stages define the namespace and prefix for the deployment. These stages can be duplicated for different namespaces (so that deployments can run in parallel on the cluster) and for different clusters (see 11).
8 This commands creates a namespace for the deployment and adds to the Rancher default project. A loop is integrated to ensure that the namespace exists before continuing. If the namespace already exists, the command is executed without errors.
9 Helm is using the Mironet Helm Chart to deploy the Magnolia App and the corresponding databases using the provided values.yml file (see Helm Values) to the defined namespace.
10 The needed secrets are copied over from the default namespace to the newly created namespace.
11 The environment name corresponds to the environment scope (dev or prod) defined in the Deployments section. In different environments the same variable names can be used.
12 The deployment must be triggered manually.
Feedback

PaaS

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the Magnolia PaaS docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules