Environments
Environments allow you to develop and test your Magnolia PaaS 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 | ||
|---|---|---|---|
|
The
|
||
|
The
|
||
|
The
|
- 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.
Feature environments
If your Magnolia PaaS 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={helm-chart-version}
- export KUBECONFIG=$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
- helm upgrade -i ${DEPLOYMENT} mironet/magnolia-helm --version ${HELM_CHART_VERSION} -f ${DEPLOYMENT}.yml --create-namespace -n ${DEPLOYMENT}
- kubectl annotate --overwrite namespace ${DEPLOYMENT} field.cattle.io/projectId=\`kubectl get namespace default --output="jsonpath={.metadata.annotations.field\.cattle\.io/projectId}"` (8)
- kubectl -n default get secret activation-key -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT} -f - (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 - (9)
- 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 - (9)
environment:
name: dev (10)
when: manual (11)
deploy-uat: (7)
extends: .deploy
script:
- export DEPLOYMENT=uat
- export LE_ENVIRONMENT=letsencrypt-prod
- cat values.yml | gomplate > ${DEPLOYMENT}.yml
- cat ${DEPLOYMENT}.yml
- helm upgrade -i ${DEPLOYMENT} mironet/magnolia-helm --version ${HELM_CHART_VERSION} -f ${DEPLOYMENT}.yml --create-namespace -n ${DEPLOYMENT}
- kubectl annotate --overwrite namespace ${DEPLOYMENT} field.cattle.io/projectId=\`kubectl get namespace default --output="jsonpath={.metadata.annotations.field\.cattle\.io/projectId}"` (8)
- kubectl -n default get secret activation-key -o json | jq 'del(.metadata.annotations,.metadata.labels,.metadata.namespace,.metadata.resourceVersion,.metadata.uid,.metadata.namespace,.metadata.creationTimestamp)' | kubectl apply -n ${DEPLOYMENT} -f - (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 - (9)
- 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 - (9)
environment:
name: dev (10)
when: manual (11)| 1 | In the build-magnolia stage, the web app is built using maven, as with any Magnolia project. |
||
| 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.
|
||
| 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 10) |
||
| 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 10). |
||
| 8 | The newly created namespace is added to the Rancher default project. |
||
| 9 | The needed secrets are copied over from the default namespace to the newly created namespace. |
||
| 10 | 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. |
||
| 11 | The deployment must be triggered manually. |