Download as PDF, PPTX
Uploaded byNico Meisenzahl
Gitlab Commit: How Containerized GitLab CI Pipelines Can Help You Streamline Your Infrastructure Deployments
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.
Gitlab Commit: How Containerized GitLab CI Pipelines Can Help You Streamline Your Infrastructure Deployments
- 1. 1#GitLabCommit How Containerized GitLabCI 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 iscode ● 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’tbuild 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 thesame 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 pipelinejob 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 everythinga 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.
- 11. 11#GitLabCommit ● runs itselfin 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.
- 13. 13#GitLabCommit ● Docker-in-Docker hassecurity 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.
- 15.
- 16. 16#GitLabCommit ● pipeline willprovision/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.
- 18.
- 19.
- 20.
- 21.
- 22.
- 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