GitOps è un nuovo metodo di CD che utilizza Git come unica fonte di verità per le applicazioni e per l'infrastruttura (declarative infrastructure/infrastructure as code), fornendo sia il controllo delle revisioni che il controllo delle modifiche. In questo talk vedremo come implementare workflow di CI/CD Gitops basati su Kubernetes, dalla teoria alla pratica passando in rassegna i principali strumenti oggi a disposizione come ArgoCD, Flux (aka Gitops engine) e JenkinsX
5. WHAT IS GIT?
THE BASICS: GIT
The most widely used modern
version control system in the world
today.
More one GIT: https://www.atlassian.com/git/tutorials/what-is-git
6. CI: Continuous
Integration
● A software development practice where all developers merge
code changes in a central repository (Git).
● Each change in code (commit) triggers an automated
build-and-test stage for the given repo and provides feedback
to the developer(s) who made the change.
● Automates the build and unit test process of new code
changes
THE BASICS: CICD
7. CD: Continuous
Delivery
THE BASICS: CICD
More one CONTINUOUS DELIVERY: https://en.wikipedia.org/wiki/Continuous_delivery
A software engineering approach in which
teams produce software in short cycles,
ensuring that the software can be reliably
released at any time and, when releasing
the software, doing so manually.
8. CD: Continuous
Deployments
THE BASICS: CICD
More one CONTINUOUS DEPLOYMENTS: https://en.wikipedia.org/wiki/Continuous_deployment
A software engineering approach in which
software functionalities are delivered
frequently through automated deployments.
10. KUBERNETES
THE BASICS: KUBERNETES
Kubernetes is a portable, extensible,
open-source platform for managing
containerized workloads and services, that
facilitates both declarative configuration
and automation.
More one KUBERNETES: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
11. Imperative model
You describe a sequence of instructions to
manipulate the state of the system to reach your
desired state
THE BASICS: DECLARATIVE MODEL
Declarative model
You describe what you want to be achieved, as
opposed to how to get there
12. An Imperative vs. Declarative Remote Control
https://livebook.manning.com/book/gitops-and-kubernetes/chapter-1/v-6/163
13. KUBERNETES
Controllers
DECLARATIVE MODEL AND K8S CONTROLLERS
Controllers are control loops that watch the
state of your cluster, then make or request
changes where needed.
Each controller tries to move the current
cluster state closer to the desired state.
The desired state is what is described
declaratively in the resource’s manifest.
More one K8S CONTROLLERS: https://kubernetes.io/docs/concepts/architecture/controller/
15. What is
GitOps?
GITOPS
More one GITOPS: https://www.gitops.tech/
Is a way of implementing Continuous
Deployment / Delivery for cloud
native applications.
It focuses on a developer-centric
experience when operating
infrastructure, by using tools
developers are already familiar with,
including Git and Continuous
Deployment tools.
16. GITOPS
“Gitops is a distillation of best practices for managing
the deployment of containerized applications as well
as the cluster infrastructure upon which they run”
https://aws.amazon.com/it/blogs/containers/help-us-write-a-new-chapter-for-gitops-kubernetes-and-open-source-collaboration/
20. GITOPS PRINCIPLES
System is
described
declaratively
It allows to describe the entire system
(services and applications) as configuration
code.
Kubernetes, given its declarative nature and
the controller pattern, is a perfect tool to do
GitOps.
22. GITOPS PRINCIPLES
● Git as the single source of truth of the system
● Git as the single place where we operate (create,
change and destroy) all environments
24. GITOPS PRINCIPLES
Changes can be
automatically
applied
Responsible of the automation is a GitOps
Operator.
It’s a Kubernetes operator, a server-side
controller, that read the desired state of a
system (i.e. the manifests in a git repo) and
continually tries to make the actual state of
the system match those manifests.
29. ● Flux is an open source project that was originally
developed by Weave Works, the same company that
coined the term GitOps
● FluxCD is a declarative deployment automation tool
which is controlled by means of its CLI, fluxctl
● Is a CNCF sandbox project since august 2019
● The new version of Flux (Flux V2) is in actual
development and almost production ready (roadmap)
and is based on the GitOps Toolkit
Flux CD
GITOPS IN PRACTICE
https://fluxcd.io/
30. ● Argo CD is a declarative GitOps continuous delivery
tool for Kubernetes and one of the 4 Argo Projects (a
set of Kubernetes-native tools for deploying and
running jobs and applications).
● includes a command line tool and an excellent
graphical user interface
● Developed by Intuit (a large a large American business
and financial software company), is a CNCF incubator
project since april 2020
● Focused on enterprise use-cases (security, RBAC,
SSO, centralized multi-tenancy multi-cluster
management)
Argo CD
GITOPS IN PRACTICE
https://argoproj.github.io/projects/argo-cd
31. ● Jenkins X is a CI/CD solution for modern cloud
applications on Kubernetes, an open source
opinionated way to do continuous delivery with
Kubernetes, natively
● Is a free open source tool with enterprise support
offered by Cloudbees
● it can handle all parts of the GitOps process, it’s an
all-in-one solution
Jenkins-x
GITOPS IN PRACTICE
https://www.cloudbees.com/jenkins-x/what-is-jenkins-x
32. ● Gitlab 13.4 (september 2020) integrated the
Kubernetes Agent (as premium only feature)
● It’s the first attempt to integrate GitOps CD in Gitlab CI,
implemented as a Kubernetes operator running inside
the cluster
● It’s based on Argo GitOps Engine
GitLab EE
GITOPS IN PRACTICE
https://docs.gitlab.com/ee/user/clusters/agent/
34. CICD PIPELINE AND GITOPS
A tipical Kubernetes CI/CD pipeline (the push model)
Jenkins CircleCI Travis CI GitLab GitHub Actions
Application
Repository
Image
registry
Build Pipeline
Trigger
Push
images
on
registry
Deploy Environment
CI CDDevelopers
35. CICD PIPELINE AND GITOPS
A tipical Kubernetes CI/CD pipeline (the push model)
Jenkins CircleCI Travis CI GitLab GitHub Actions
Application
Repository
Image
registry
Build Pipeline
Trigger
Push
images
on
registry
Deploy Environment
CI CDDevelopers
CI TOOL PUSH
CHANGES IN
PRODUCTION
36. CICD PIPELINE AND GITOPS
https://www.gitops.tech/#pull-based-deployments
The GitOps pull-based model for CD
CI CD
37. CICD PIPELINE AND GITOPS
https://www.gitops.tech/#pull-based-deployments
The GitOps pull-based model for CD
CI CD
38. CICD PIPELINE AND GITOPS
https://www.gitops.tech/#pull-based-deployments
The GitOps pull-based model for CD
CI CD
39. CICD PIPELINE AND GITOPS
https://www.gitops.tech/#pull-based-deployments
The GitOps pull-based model for CD
CI CD
40. GITOPS BENEFITS
GitOps benefits
● Improve system observability: allow running state and desired state to be
observable
● Improve security: no need to expone to internet K8s API server or to give access
to developers to the application cluster.
● Simpler disaster recovery and rollback procedure which is consistent with the
normal deployment experience (git revert commit)
● Increased Productivity: what can be described can be automated - continuous
deployment automation with an integrated feedback control loop via the operator
41. GITOPS THE BAD
GitOps: the bad and the ugly
● You need to structure the environment repo and your pipelines to prevent
concurrent push on the same repo (since remote may be out of sync): multiple
CI processes can end up writing to the same GitOps repo, causing conflicts or
errors. This is may happen for example if you have configured a single repository
environment to describe describe all applications deployed in a given cluster
(Flux CD V1 for example supported only one env repo)
● Doesn’t give you an opinionated way to deal with secret management (Git
repositories are not great places to store secrets, as you have to encrypt and
decrypt them)
https://blog.container-solutions.com/gitops-limitations
https://www.reddit.com/r/kubernetes/comments/imgqoj/gitops_the_bad_and_the_ugly/
42. GITOPS : Some suggestions?
GitOps - Suggestions?
● Use two repos: one for app source code, another for manifests.
● Never store secrets or keys in manifests repo as plain text and yes, base64 is
plain text! (plan how to manage secrets)