DRUPAL CI/CD FROM DEV TO PROD WITH GITLAB, KUBERNETES AND HELM

DRUPAL CI/CD
FROM DEV TO PROD WITH
GITLAB, KUBERNETES AND
HELM
Yevgen Nikitin @ EPAM Systems
CONFIDENTIAL | © 2019 EPAM Systems, Inc.
May 25, 2019

WHY WE ARE GOING TO USE KUBERNETES?

When we’ve started this project, the customer told us,
that he wants to use the Kubernetes cluster.
Customer’s reasons(non-functional requirements) are:
• Multiple projects to deploy
• Different dev teams
• Multiple environments
• Single stack to maintain
• Dynamic resources utilization
• Decrease maintenance costs
Constraints:
• AWS
• Drupal
• Kubernetes
3

KUBERNETES
https://kubernetes.io/

KUBERNETES (K8S) IS AN OPEN-SOURCE SYSTEM FOR
AUTOMATING DEPLOYMENT, SCALING, AND MANAGEMENT OF
CONTAINERIZED APPLICATIONS.
IT GROUPS CONTAINERS THAT MAKE UP AN APPLICATION INTO
LOGICAL UNITS FOR EASY MANAGEMENT AND DISCOVERY.
https://kubernetes.io/

What is Kubernetes
Kubernetes provides a container-centric management
environment. It orchestrates computing, networking,
and storage infrastructure on behalf of user
workloads. This provides much of the simplicity of
Platform as a Service (PaaS) with the flexibility of
Infrastructure as a Service (IaaS), and enables
portability across infrastructure providers.
WHY DO I NEED KUBERNETES
Kubernetes is not a traditional, all-inclusive PaaS
(Platform as a Service) system. Since Kubernetes
operates at the container level rather than at the
hardware level, it provides some generally applicable
features common to PaaS offerings, such as
deployment, scaling, load balancing, logging, and
monitoring. However, Kubernetes is not monolithic,
and these default solutions are optional and pluggable.
Kubernetes provides the building blocks for building
developer platforms, but preserves user choice and
flexibility where it is important.
WHAT KUBERNETES IS NOT
6

Kubernetes architecture
7
ARCHITECTURE
Master node consist of etcd, kube-apiserver, kube-
scheduler and kube-controller-manager.
Kubernetes nodes previously known as a minions. Each
node contains the services necessary to run pods and is
managed by the master components. The services on a
node include the container runtime, kubelet and kube-
proxy.
MAIN COMPONENTS

GITLAB
https://about.gitlab.com/

Gitlab configuration
• Integrate with Kubernetes cluster
• Install Helm/Tiller
• Install Ingress
• Install GitLab runners
• Assign DNS wildcard
• GitLab Registry for docker containers*
• Configure CI/CD
• GitLab Pages for Helm charts*
• Helm charts
STEPS
9

Integrate with Kubernetes cluster
10
ADD CLUSTER TO THE PROJECT
• AWS EKS
• Google GKE
• Microsoft AKS
• Self-hosted Kubernetes cluster
POSSIBLE OPTIONS

Install the applications
11
ENABLE THE APPLICATIONS
Initially it will be available only Helm Tiller. Need to
install it first, as other applications are installed with the
Helm/Tiller.
To correctly run Drupal applications we need to install
Ingress controller and GitLab Runner applications.
Cert-Manager is highly recommended to provide the
possibility of dynamic SSL certificates provisioning by
Let’s Encrypt.
Don’t forget to assign the DNS wildcard and/or single
domains to the Ingress controller endpoint.
APPLICATIONS

Kubernetes Persistent Volume types
• AWS EBS
• AzureDisk
• GCEPersistentDisk
READWRITEONCE
• AWS EFS
• AzureFile
• CephFS
• Glusterfs
• NFS
READWRITEMANY
13

K8s deployment strategies
1 RECREATE
2
3
4
5
BLUE/GREEN
RAMPED(ROLLING)
CANARY
A/B TESTING
14

K8s deployment strategies: recreate
15
RECREATE
A deployment defined with a strategy of
type Recreate will terminate all the running instances
then recreate them with the newer version.
Pros:
• application state entirely renewed
Cons:
• downtime that depends on both shutdown and boot
duration of the application
BEST FOR DEV ENVIRONMENT

K8s deployment strategies: Blue/Green
16
BLUE/GREEN
The GREEN version of the application is deployed
alongside the BLUE version. After testing that the new
version meets the requirements, we update the
Kubernetes Service object that plays the role of load
balancer to send traffic to the new version by replacing
the version label in the selector field.
Pros:
• instant rollout/rollback
• avoid versioning issue, change the entire cluster
state in one go
Cons:
• requires double the resources
• proper test of the entire platform should be done
before releasing to production
• handling stateful applications can be hard
BEST TO AVOID API
VERSIONING ISSUES

Liveness / Readiness Probes
READINESS PROBE
Many applications running for long periods of time eventually
transition to broken states, and cannot recover except by being
restarted. Kubernetes provides liveness probes to detect and remedy
such situations.
LIVENESS PROBE
17
Sometimes, applications are temporarily unable to serve traffic. For
example, an application might need to load large data or
configuration files during startup, or depend on external services after
startup. In such cases, you don’t want to kill the application, but you
don’t want to send it requests either. Kubernetes provides readiness
probes to detect and mitigate these situations. A pod with containers
reporting that they are not ready does not receive traffic through
Kubernetes Services.

We know how to configure k8s deploy, which strategy
we are going to use, how we are going to store our data.
Now we need to define, what exactly we will deploy to the cluster.
18

Docker images to deploy
Nginx image is packed with the web(docroot) folder only, as we no
need to have a vendor folder on that layer.
NGINX
PHP-FPM image is packed with the whole Drupal installation, php
configuration and tools like Drush/Drupal console.
Also we need to ensure, that all necessary folders are created and
permissions assigned correctly.
PHP-FPM WITH THE DRUPAL
19

Okay, we know what and how to deploy.
But how to manage different instances(dev/stage/prod) or even
different projects?
As GitLab provides us Helm/Tiller during installation procedure –
let’s use it.
Alternatives are:
• Separate set of deployment files per instance/project
• Kubernetes operators
• Kustomize
• Draft
• Ksonnet
20

HELM
https://helm.sh/

HELM HELPS YOU MANAGE KUBERNETES APPLICATIONS —
HELM CHARTS HELP YOU DEFINE, INSTALL, AND UPGRADE EVEN
THE MOST COMPLEX KUBERNETES APPLICATION.
CHARTS ARE EASY TO CREATE, VERSION, SHARE, AND PUBLISH —
SO START USING HELM AND STOP THE COPY-AND-PASTE.
https://helm.sh/

Helm: brief architecture
23
COMPONENTS
The Helm Client is a command-line client for end users.
The client is responsible for the following domains:
• Local chart development
• Managing repositories
• Interacting with the Tiller server
The Tiller Server is an in-cluster server that interacts
with the Helm client, and interfaces with the Kubernetes
API server. The server is responsible for the following:
• Listening for incoming requests from the Helm client
• Combining a chart and configuration to build a
release
• Installing charts into Kubernetes, and then tracking
the subsequent release
• Upgrading and uninstalling charts by interacting with

Helm files structure
1 CHART.YAML
2
3
4
5
REQUIREMENTS.YAML
VALUES.YAML
CHARTS/_HELPERS.TPL
CHARTS/*.YAML
24

Helm configuration files
CHART.YAML REQUIREMENTS.YAML
25

Helm configuration files: values.yaml
One of the four built-in objects is Values. The built-in values always
begin with a capital letter. This is in keeping with Go’s naming
convention. Values passed into the template from the values.yaml file
and from user-supplied files. By default, Values is empty.
The values are available to any top-level template.
This object provides access to values passed into the chart. Its
contents come from four sources:
• The values.yaml file in the chart
• If this is a subchart, the values.yaml file of a parent chart
• A values file is passed into helm install or helm upgrade with the -f
flag (helm install -f myvals.yaml ./mychart)
• Individual parameters passed with --set (such as helm install --set
foo=bar ./mychart)
VALUES.YAML
26

Helm configuration files: _helpers.tpl
27
_HELPERS.TPL
These files are used to store partials and helpers.
The define action allows us to create a named template
inside of a template file.
When the template engine reads this file, it will store
away the reference to drupal.release_labels until
template “drupal.release_labels" is called. Then it will
render that template inline.

Okay, we have a templates, how to store them and build ?
We can store the templates in a separate GitLab Project with
GitLab Pages support enabled.
In this case we can run CI process to build and deploy our Helm
Charts to the GitLab Pages.
28

Helm: build and deploy
29
.GITLAB-CI.YML
In the .gitlab-ci.yml file we are building charts with the
domain, configured in the $CI_PAGES_URL environment
variable.
Right after successful built artefacts deployed to the
GitLab Pages.

DRUPAL
https://www.drupal.org/

Drupal: database configuration
31
SETTINGS.PHP
To configure DB credentials we are taking it from the env
variables. Also, based on env variables, we can configure
3rd party services like S3, Mailchimp, etc.

GITLAB-CI

Initially, to utilize all OOTB GitLab features, we’ve used
GitLab Auto DevOps and adopt configuration to our needs.
All parameters, like DB credentials, 3rd party services API
keys/tokens/ hosts are stored in the GitLab variables. All variables
prefixed with “K8S_SECRET_” will be available as environment
variables.
To handle this keys on the Drupal side we’ve used Key module.
For daily database backup scheduled job has been created, which
really helpful for the developers. Scheduled job is running
overnight or we can run it manually.
33

GitLab-CI stages
1 VALIDATE
2
3
4
5
BUILD
DEPLOY
OPERATIONS
PERFORMANCE
34
6 DATABASE BACKUP

GitLab-CI stages: Validate
35
.GITLAB-CI.YML
Validate stage are used for PhpCS code validation.
Special thanks to the Andriy Iun and Andriy Postnikov for
packing in the small image such amazing tool.

GitLab-CI stages: Build
36
.GITLAB-CI.YML
On the build stage we are running
composer install and push the images to
the GitLab Registry.

GitLab-CI stages: Build
37
.GITLAB-CI.YML
On the build stage we are running
composer install and push the images to
the GitLab Registry.

GitLab-CI stages: Deploy
38
.GITLAB-CI.YML
During deploy stage GitLab Auto DevOps
need to ensure, that K8S cluster is
available, Helm Tiller is up and running,
namespace is present in the cluster. After
that we are downloading our helm charts,
creating all necessary secrets and then
starting deployment procedure.

GitLab-CI stages: Deploy
39
.GITLAB-CI.YML
During deploy stage GitLab Auto DevOps
need to ensure, that K8S cluster is
available, Helm Tiller is up and running,
namespace is present in the cluster. After
that we are downloading our helm charts,
creating all necessary secrets and then
starting deployment procedure.

GitLab-CI stages: Operations
40
.GITLAB-CI.YML
To ensure, that right after deployment all
operations are executed.

GitLab-CI stages: Performance
41
.GITLAB-CI.YML
To ensure, that right after all operations
executed site works correctly at least on
some important pages like Home page,
Login page etc, we are going to run k6
tool, to measure the requests.

42
.GITLAB-CI.YML
Login page etc., we are going to run k6

43
.GITLAB-CI.YML
Login page etc., we are going to run k6

GitLab-CI stages: backup DB – scheduled job
44
.GITLAB-CI.YML
During backup procedure we are running
drush sql:dump and storing dump as
artifact in GitLab CI.

GitLab-CI stages: backup DB – scheduled job
45
.GITLAB-CI.YML
During backup procedure we are running
drush sql:dump and storing dump as
artifact in GitLab CI.

GitLab-CI stages: successful pipeline
46
.GITLAB-CI.YML
If everything went well we’ll see, that all
Jobs in the Pipeline are successful.

SATIS
https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md

Satis: configuration
48
.GITLAB-CI.YML
Satis should be created as a separate
project with .gitlab-ci.yaml to deploy the
Satis into k8s cluster. Configurations of the
repositories are stored in the satis.json
which could be stored in the Satis repo or
as a ConfigMap in the Helm chart.

QUESTIONS ARE WELCOME!

THANKS A LOT!
https://www.linkedin.com/in/yevgen-nikitin/
https://gitlab.com/lestat1/drupalcampkyiv19

DRUPAL CI/CD FROM DEV TO PROD WITH GITLAB, KUBERNETES AND HELM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DRUPAL CI/CD FROM DEV TO PROD WITH GITLAB, KUBERNETES AND HELM

Similar to DRUPAL CI/CD FROM DEV TO PROD WITH GITLAB, KUBERNETES AND HELM (20)

More from DrupalCamp Kyiv

More from DrupalCamp Kyiv (20)

Recently uploaded

Recently uploaded (20)

DRUPAL CI/CD FROM DEV TO PROD WITH GITLAB, KUBERNETES AND HELM