The document discusses how containerized GitLab CI pipelines can help streamline infrastructure deployments. It recommends containerizing pipeline jobs so that each runs in a dedicated container with isolated dependencies. This avoids issues with dependency conflicts and allows scaling pipelines. The GitLab Runner Kubernetes executor can integrate pipelines with Kubernetes to create pods for each job based on a defined container image. Containerizing builds with Kaniko also avoids issues with Docker-in-Docker. Examples show containerized pipelines for building images, deploying to AKS, and provisioning infrastructure with Terraform.

1. 1#GitLabCommit
How Containerized GitLab CI
Pipelines Can Help You Streamline
Your Infrastructure Deployments

2. 2#GitLabCommit
Senior Consultant @ panagenda.
Blogger, speaker.
IBM Cloud Champion & Docker Community Leader.
Loves K8s, containers & automation. His desk is a ping pong table.
Nico Meisenzahl
@nmeisenzahl
https://meisenzahl.org
nico@meisenzahl.org
https://panagenda.com/modernization
nico.meisenzahl@panagenda.com

3. 3#GitLabCommit
● Infrastructure-as-Code recap
● where containerized pipelines can help
● how to get started
Agenda

4. 4#GitLabCommit
● everything is code
● Git as single source of truth
● reproducible & declarable
● version controlled and testable
● fully automated
Infrastructure-as-Code principles

5. 5#GitLabCommit
● immutable infrastructure
● no snowflake servers
● no configuration drift
● no fragile infrastructure
● everything is documented (by itself)
Infrastructure-as-Code pros

6. 6#GitLabCommit
● you shouldn’t build everything on your own
○ you’ll need tools that support you
● you shouldn’t run everything manually on your own machine
○ you’ll be the constraint that slows everything down
○ you’ll have tons of dependencies on your local machine
● automation is key!
○ prevent “Automation Fear” 😱
Infrastructure-as-Code pitfalls

7. 7#GitLabCommit
● for the same reasons why you should use containers
○ isolation
○ dependencies
○ scalability
○ immutability
● example: Your new project needs Terraform 0.12, others only run with 0.11
○ can cause dependency issues on build server and local machine
○ makes everything a lot more complex
● this example works with every tool 😉
○ kubectl, Helm, Ansible... you name it
Why should you containerize your pipeline?

8. 8#GitLabCommit
● every pipeline job runs in a container
○ based on an image with all requirements for this single job
● GitLab Runner Kubernetes executor
○ integrates your CI/CD with Kubernetes
○ creates a pod per job based on the defined image
○ allows you to share your resources and scale your pipelines
● image builds in containers? Do I need Docker-in-Docker for that?!
○ Kaniko fixes this issue!
How does it work?

9. 9#GitLabCommit
● contains everything a single pipeline job needs
○ binaries, libraries, ...
● use a pipeline to build/rebuild it (security fixes!)
● you should define fix versions for your dependencies
Pipeline job images

10. 10#GitLabCommit
Containerized pipeline example

11. 11#GitLabCommit
● runs itself in a pod
● needs to be installed in your Kubernetes Cluster
○ automatable Helm deployment
● schedules job pods
● build steps of a pipeline job
○ prepare → creates pod with build and service containers
○ pre-build → clones repo, restore cache, download artifacts
○ build → user build steps
○ post-build → creates caches and upload artifacts
GitLab Runner Kubernetes executor

12. 12#GitLabCommit
GitLab Runner Kubernetes executor

13. 13#GitLabCommit
● Docker-in-Docker has security issues
○ exposing Docker daemon
○ mounting /var/lib/docker
○ privileged mode
● is part of “Knative build”
● image builds without the need of any
privileges or dependencies
● runs in a container
○ http://gcr.io/kaniko-project/executor
● speed up your pipeline with build caching
Kaniko - containerized image builds

14. 14#GitLabCommit
Kaniko pipeline example

15. 15#GitLabCommit
Kaniko pipeline example

16. 16#GitLabCommit
● pipeline will provision/update an Azure Kubernetes Cluster (AKS) with all dependencies
○ Terraform is used to provision/update the cluster
○ kubectl is used to apply resources (namespaces, RBAC, pod security policy, …)
● pipeline steps
○ validate Terraform code
○ validate Kubernetes resources
○ provision/update cluster
○ apply/update Kubernetes resources
Containerized Infrastructure pipeline example

17. 17#GitLabCommit
Containerized Infrastructure pipeline example

18. 18#GitLabCommit
Containerized Infrastructure pipeline example

19. 19#GitLabCommit
Containerized Infrastructure pipeline example

20. 20#GitLabCommit
Containerized Infrastructure pipeline example

21. 21#GitLabCommit
Containerized Infrastructure pipeline example

22. 22#GitLabCommit
Containerized Infrastructure pipeline example

23. 23#GitLabCommit
● slides → https://www.slideshare.net/nmeisenzahl
● demo projects → https://gitlab.com/gitlab-commit-demo
○ build-job-images → job images pipeline using Kaniko
○ deploy-aks → AKS IaC project with Terraform and kubectl
○ deploy-aks-with-runner → used to setup the demo env (optional)
Questions?
Nico Meisenzahl
Senior Consultant, panagenda
@nmeisenzahl
https://meisenzahl.org
nico@meisenzahl.org
https://panagenda.com/modernization
nico.meisenzahl@panagenda.com