Deploy Magnolia PaaS
When Magnolia PaaS is set up with GitLab, changes in your project automatically trigger your pipeline via what is configured in your .gitlab-ci.yml
file.
This way, changes are picked up automatically and you don’t have to worry about it. However, the final deployment step is sometimes manual and you’ll need to make a deploy action to finish the process. This is typically done by clicking a button manually in GitLab.
For a full view into deploying your webapp with Magnolia PaaS, check out the Webapp deployment page under the "Hello PaaS" getting started section. |
.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.3
stage: deploy
before_script:
- export GIT_TAG=$CI_COMMIT_SHORT_SHA
- helm repo add mironet https://charts.mirohost.ch/
- export HELM_CHART_VERSION=1.5.7
when: manual
deploy-dev: (6)
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}
environment:
name: dev (7)
when: manual (8)
deploy-uat: (6)
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}
environment:
name: dev (7)
when: manual (8)
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 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 7 ). |
||
7 | The environment name corresponds to the environment scope defined when the Kubernetes clusters were added to GitLab. | ||
8 | The deployment must be triggered manually. |