GitOps - Speaker Deck

Slide 1

Slide 1 text

GitOps

Slide 2

Slide 2 text

2 … @me Marcos Nils Lilljedahl (@marcosnils) Head of Infra @ iúnigo, OS Developer, consultant & trainer - Ing. en sistemas / MoIT - OSS & Golang - Docker Captain - Container junkie - Active projects: Jedis, Vault, Goblin, dynamodb-filters, play-with-docker (and probably more) - crossfit, asado, mate, sailing, drinks & food.

Slide 3

Slide 3 text

3 La mejor aseguradora de la Argentina https://www.meetup.com/es-ES/10x-Buenos-Aires/

Slide 4

Slide 4 text

Slide 5

Slide 5 text

5 … Qué y por qué? “GitOps - Operations by Pull Request” Git is the source of truth. And it also means you get code reviews, comments in the configuration files, and links to any issues in commit messages and PRs. All of this makes the system (and the reasons behind it!) discoverable and easier to operate, recover, and observe. ● Infrastructure as code ● Mecanismo de convergencia ● Uso de CI como fuente de verdad ● Pull vs Push ● Developers y operaciones (git) ● Atomic updates

Slide 6

Slide 6 text

6 … Manual Provisioning ● Proceso manual, con downtime y muy propenso a errores ● Se esperaba tener una cantidad de features X para poder deployar ● El estado del servicio y producción eran desconocidos ● Configuración manual y desconocimiento del entorno

Slide 7

Slide 7 text

7 … Generating impact ● Poder desplegar features nuevos rápido ● Reducir el tiempo para arreglar bugs ● Generar el sentimiento de control y empoderamiento. Confidencia y control ● 20 deploys por día ● 80% en ahorro del tiempo para arreglar errores en producción

Slide 8

Slide 8 text

8 … Entering GitOps GitOps promueve la práctica de DevOps + git como una única fuente de verdad Objetivos: ● Todo debe encontrarse versionado en una única fuente de verdad de la cual sea posible recuperarse ● Monitoreo y observabilidad son necesarios ● Tener un pipeline completamente automatizado

Slide 9

Slide 9 text

9 … History https://www.linkedin.com/pulse/what-does-devops-look-like-2017-helen-beal/

Slide 10

Slide 10 text

10 … Declarative { "cpu": 1000, "memory": 128, "env": { "DB_TIMEOUT": "2000" }, "replicas": 2 } { "swagger": "2.0", "host": "*.iunigo.com", "paths": { "/gizmo/delay": { "get": { "tags": [ "Sample" ], "summary": "Generates a delay in the response", "parameters": [ { "in": "query", "name": "duration", "description": "Golang duration of the delay (1s|1m|1h)", "type": "string" } ], "responses": { "200": { "description": "" } } } } } }

Slide 11

Slide 11 text

11 … GitOps @ iúnigo ● Utilizamos herramientas para infraestructura declarativa como Nomad + Consul, Docker, Terraform ● Todo nuestro sistema incluyendo código, configuraciones, reglas de monitoreo, y dashboards se encuentra versionado en GitHub ● Tenemos herramientas que disparan alertas si el estado de producción difiere del estado en Git. (Kubediff, Terradiff, Nomadiff, Whaleprint?) ● Los cambios en ops deben viajar por Pull Request

Slide 12

Slide 12 text

12 … GitOps @ iúnigo

Slide 13

Slide 13 text

13 … Outcome ● Todos los devs usan Github ● Cualquier dev pueden unirse al team y ser productivo rápidamente ● Todos los cambios pueden ser ejecutados, guardados y validados en Git

Slide 14

Slide 14 text

14 … Secrets ● Private key en el cluster y public key hacia los developers para encriptar los secretos en GIT

Slide 15

Slide 15 text

15 … Pillars Pipelines Observability Control

Slide 16

Slide 16 text

16 … Pipeline example https://www.weave.works/blog/category/gitops/

Slide 17

Slide 17 text

17 … Observability ● Monitoring ● Logging ● Tracing & Visualization ● Ver el impacto en el sistema temprano para tomar acciones rápidamente ● E2E testing & canary deployments ● Dashboards unificados (metrics.iunigo.com)

Slide 18

Slide 18 text

18 … Control ● Control == Convergencia ● CD Operators ● Usar tools de diff & sync ● Hacer cambios via Git y no tooling (kubectl, nomad-cli, docker service, etc)

Slide 19

Slide 19 text

19 … Repo structure ● Usar el mismo repo o un repo distinto por aplicación / servicio (deployment) ● Usar un branch por entorno (se puede mapear a un namespace o cluster en k8s / nomad / swarm) ● Subir los cambios como los nombre de imagen, health checks a branches primero ● Hacer un deploy a producción implica sólo un merge. (git merge -s ours )

Slide 20

Slide 20 text

20 … Env structure https://www.infoq.com/presentations/testing-software-production

Slide 21

Slide 21 text

21 … Env structure I'm more and more convinced that staging environments are like mocks - at best a pale imitation of the genuine article and the worst form of confirmation bias. It's still better than having nothing - but "works in staging" is only one step better than "works on my machine". — @copyconstruct

Slide 22

Slide 22 text

22 … Env structure ● Cluster size ● Config options ● Networking optimizations ● Monitoring in staging ● Env parity

Slide 23

Slide 23 text

23 … Env structure I’d argue that being able to successfully and safely test in production requires a significant amount of automation, a firm understanding of the best-practices as well as designing the systems from the ground up to lend themselves well toward this form of testing.

Slide 24

Slide 24 text

24 … Env structure

Slide 25

Slide 25 text

25 … Deploying code Feature Merge commit

Slide 26

Slide 26 text

26 … Deploying code Feature Merge commit P P A A A Feature A + B P Release P P Canary Canary

Slide 27

Slide 27 text

27 … Deploying code Auth + Audit + RL { “domain”: “api.iunigo.com”} *.iunigo.com/policies *.iunigo.com/accounts api.iunigo.com policies accounts api.iunigo.com/ accounts/1234

Slide 28

Slide 28 text

28 … Deploying code Auth + Audit + RL { “domain”: “edge.iunigo.com”} edge.iunigo.com/policies edge.iunigo.com/accounts *.iunigo.com/policies *.iunigo.com/accounts traffic % || edge.iunigo.com policies accounts E E api.iunigo.com/ accounts/1234 E E

Slide 29

Slide 29 text

29 … GitOps lifecycle https://www.weave.works/blog/gi tops-part-3-observability

Slide 30

Slide 30 text

30 … Wrap up ● GitOps se centra en la idea de que debemos manejar nuestro cluster comparando el estado deseado a través de herramientas declarativas con el estado observado del sistema ● Nunca podemos saber realmente el estado actual. A través de monitoreo. Existe un estado actual, lo que creemos y el estado deseado versionado en git. ● GitOps es una iteración simple de DevOps e infra as code, orquestación y observabilidad ● Evitar darle al CI la incorrecta responsabilidad de administrar el cluster. (GitOPs != CIOps)

Slide 31

Slide 31 text

31 … GitOps != CIOps https://images.contentstack.io/v3/assets/blt300387d93dabf50e/blta7990af54f3c2434/5b50 dadc277066700b7c555c/download

Slide 32

Slide 32 text

32 … GitOps != CIOps https://images.contentstack.io/v3/assets/blt300387d93dabf50e/blt45da455528f4ff83/5b50d aedd873a86d0baef1ef/download

Slide 33

Slide 33 text

33 … Future: Declarative apps? Lo que importa: - Nuevos features - Releases rápidos - Uptime perfecto El enfoque: - Aprender - Construir - Explicar - Monitorear - Repetir Solución: Herramientas - Compiladores - Depuradores - Unit testing - IDE

Slide 34

Slide 34 text

34 … Future: Declarative apps? DS Tools: - Helm (helm.sh) - Draft (draft.sh) - Telepresence (telepresence.io) - Jenkins X - Spinnaker Language Features: - synchronized - async/await - GC - Single thread - Channels