Cloud Native Story CA #1 by Julian Mazzitelli @BioBox

Transcript

1. You Got GitOps In My Development Environment! Unifying Operations and Development with ArgoCD Julian Mazzitelli, CIO BioBox Analytics Inc. May 12, 2020
2. BioBox.io
3. 1. What is GitOps, how does ArgoCD work 2. Problem: disparity between development environment and production environment 3. Solution: ArgoCD per developer 4. DX: Developer Experience 5. Effect on organizational structure: team topologies
4. GitOps https://www.weave.works/blog/automate-kubernetes-with-gitops https://www.weave.works/technologies/gitops/
5. How ArgoCD Performs the GitOps Loop Template in git - Helm - Jsonnet - Kustomize - Plain yaml - Custom - etc.
6. How ArgoCD Performs the GitOps Loop Application CRD - source.repoURL - source.path - source.targetRevision - source.<template-specific-params>
7. How ArgoCD Performs the GitOps Loop
8. How ArgoCD Performs the GitOps Loop
9. How ArgoCD Performs the GitOps Loop
10. How ArgoCD Performs the GitOps Loop
11. How ArgoCD Performs the GitOps Loop “Deployments” repository to hold Application CRDs, or use separate folders within one repository, or deployment repo per app, or ...
12. Development Environment Options Local machine, un-containerized Docker Compose (current) Kubernetes (desired) Docker images ❌ ✅ ✅ Prod-like Networking ❌ ❌ / ~ (with effort) ✅ Prod-like observability ❌ ❌ ✅ Prod resemblance ~40% ~60-70% ~90% ❌: not at all, or with lots of duplicated effort
13. Ops is doing it already, can Dev too? - Operations team is already using Kubernetes to deploy application - Operations team is already using ArgoCD - => ArgoCD templates already exist for platform (API gateway, observability) and application - Want to reuse and share knowledge between Ops and Dev but.. - Kubernetes on its own (kubectl apply) is too complicated, lots of potential for error (drift!) - Solution: Ops team prepares personal ArgoCD per developer - Can use GitOps deployment repo, web UI, or kubectl to deploy stack - Development environment is near exact copy of prod
14. Personal ArgoCD Architecture
15. Personal ArgoCD Architecture
16. Personal ArgoCD Architecture
17. Personal ArgoCD Architecture
18. Developer Perspective 1. Copy/paste app-ticket.application.yaml into personal deployments repo and push, or use ArgoCD UI, or kubectl apply 2. Ksync (volume sync between local machine and pod) local checkout and pods in stack as desired a. See also Telepresence / Ambassador Edge Stack “service preview” (network proxies b/w local and Pod) 3. Use kubectl logs (or ELK!) for reading logs, Grafana/Prometheus for metrics a. Developers get practice using observability tooling on a day-to-day basis 4. If templates need to change, modify targetRevision of Application to point to a feature branch on developer’s personal templates repo, make edits to template, PR these back to upstream org templates when complete 5. Developer pulls in upstream master whenever PRs merged on organization templates
19. A Black Frame, Not a Box - ArgoCD is a black box that can be “peeked into” - If developer does need to edit templates, they can do so autonomously (or with help of Ops) as opposed to waiting on a ticket - Slowly introduce some ops concepts to developer at a pace they can feel comfortable with - BioBox uses custom JavaScript (language our devs are familiar with) templates (instead of Helm/Jsonnet etc) to further lower the barrier to entry
20. - Expose developer to templates (YAML, helm, kustomize, jsonnet, etc.) for application as well as platform configuration - Easy to set up, but not a black box and they can inspect further as they feel comfortable - Aiming for somewhere in between Type 1 and Type 2 team topology: https://web.devopstopologies.com/
21. BioBox is hiring! Email julian@biobox.io