Tame your Microservices with Helm and Software Release Trains

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Tame your Microservices with Helm and Software Release Trains Dimitris Kapanidis Harbur Cloud Solutions

Slide 3

Slide 3 text

About Me Founder at Harbur Cloud Solutions Member: - Docker Captains - Google Developer Experts Co-organizer: - Docker Barcelona Meetup - Kubernetes Barcelona Meetup 3

Slide 4

Slide 4 text

Harbur Cloud Solutions We are a cloud native consulting ● DevOps Consulting Services ● Cloud Native Solutions ● Courses & Workshops About Us 4

Slide 5

Slide 5 text

About Us 5

Slide 6

Slide 6 text

Tame your Microservices > Content 6 Microservice Architecture Why GitOps? CI/CD with Helm Repository Patterns (& Software Release Trains with Helm) Development Styles Demo! (with GKE + GitHub actions)

Slide 7

Slide 7 text

Software Release Trains 7 App1 v1.0.0 App2 v1.5.0 App3 v2.0.0 App4 v1.1.4 SRT v1.0.0

Slide 8

Slide 8 text

8 Software Release Trains SRT v1.0.0 PRO TEST DEV PRE

Slide 9

Slide 9 text

Everything is connected Git Cloud Native Containers Microservices Helm DevOps 9

Slide 10

Slide 10 text

Microservice Architecture > Monolith 10 Traﬃc Data Center 1 Data Center 2 Monolith Monolith Monolith Monolith

Slide 11

Slide 11 text

Microservice Architecture > Microservices 11 Traﬃc Cluster 2 Cluster 1 Data Center 1a Data Center 1b Data Center 2a Data Center 2b API Gateway SMS Payment API Gateway SMS 2 3

Slide 12

Slide 12 text

Infrastructure > Now with Microservices 12 Storage One per instance Multi-Instances Scaling Upgrade Graceful Shutdown Discovery Session Management Quorum Data Recovery Stateful Service MariaDB ElasticSearch Kafka Prometheus Multi-Instances Scaling Upgrade Graceful Shutdown Stateless Service API Gateway Rest API Frontend Auth Stateless Stateful Microservice Architecture > Stateful & Stateless

Slide 13

Slide 13 text

13 Microservice Architecture > Kubernetes Overview Images Registry Charts Registry

Slide 14

Slide 14 text

14 “Turn Right” “Take me Home” GitOps > Declarative vs Imperative Imperative Declarative

Slide 15

Slide 15 text

15 GitOps > Infrastructure as Code Pull Requests Code GitOps Kubernetes Clusters

Slide 16

Slide 16 text

16 CI / CD > Deploy with Helm Your CI / CD only needs three actions: ● Push Images ● Push Charts ● Deploy

Slide 17

Slide 17 text

17 CI / CD > Deploy with Helm We Need: ● An App Image ● An App Chart ● An App Environment setup (values.yaml) e.g: $ helm install stable/ghost -f values.yaml

Slide 18

Slide 18 text

18 CI / CD > App Image Creation Images Registry Developer git checkout docker build docker push Code Repository

Slide 19

Slide 19 text

19 CI / CD > App Chart Creation Developer git checkout Charts Registry Chart Repository helm dep build helm push

Slide 20

Slide 20 text

20 CI / CD > Env Deployment with Helm git checkout Kubernetes Cluster Images Registry Charts Registry Developer helm repo up docker pull helm install Env Repository

Slide 21

Slide 21 text

21 CI / CD > Workflow Kubernetes Cluster Images Registry helm repo up docker pull helm install Env Repository Chart Repository Charts Registry Code Repository helm push docker push

Slide 22

Slide 22 text

22 CI / CD > Workflow Kubernetes Cluster Images Registry helm repo up docker pull helm install Env Repository Chart Repository Charts Registry Code Repository helm push docker push

Slide 23

Slide 23 text

23 Repository Patterns > Code Structure Project Repository Project Monolith Mono Repo Multi Repo App1 Repository App2 Repository ... App1 App2 Project Repository App3 Code Code

Slide 24

Slide 24 text

24 App1 Repository App3 Repository App4 Repository App2 Repository Repository Patterns > Code Structure Code Code Code Code ALICE TEAM BOB TEAM

Slide 25

Slide 25 text

25 Mono Repo Multi Repo App1 Repository App2 Repository ... App1 App2 App3 Charts Repository Chart Chart Repository Patterns > Charts Structure helm/charts e.g.

Slide 26

Slide 26 text

26 App1 Repository Repository Patterns > Charts Structure Code Chart App2 Repository Code Chart App3 Repository Code Chart App4 Repository Chart Code

Slide 27

Slide 27 text

27 Repository Patterns > Envs Structure Mono Repo Multi Repo Pre Environment Pro Environment ... Envs Repository dev pre pro pre pro : One helm release per namespace

Slide 28

Slide 28 text

28 Repository Patterns > Envs Structure App1 Repository Code Chart App2 Repository Code Chart App3 Repository Code Chart App4 Repository Code Chart Pre Environment Pro Environment Tst Environment Tst Pre Pro

Slide 29

Slide 29 text

Repository Patterns > Software Release Trains Tst Environment Tst Release App1 App2 App3 App4 Pre Environment Pre Release App1 App2 App3 App4 29 Pro Environment Pro Release App1 App2 App3 App4 requirement s values.yaml values.yaml values.yaml requirements requirement s

Slide 30

Slide 30 text

Development Styles > Git Flow 30 develop feature branches release branches master Tag: 0.1 Tag: 1.0 Tag: 2.0 v1 v2 Tag: 2.1

Slide 31

Slide 31 text

Development Styles > Trunk Based 31 master feature branches release branches Tag: 1.0 Tag: 2.0 v1 v2 Tag: 2.1

Slide 32

Slide 32 text

32 CI / CD > Workflow Kubernetes Cluster Images Registry helm repo up docker pull helm install Env Repository Chart Repository Charts Registry Code Repository helm push docker push

Slide 33

Slide 33 text

33 Development Styles > Docker Image Versioning Each branch/tag is a potential deployment On each push, images are built and pushed to Registry. Image versioning should be immutable (if possible) ● Tag name is immutable ● Branch name is not immutable! (Immutability is important for declarative deployments) Two alternatives for branches deployment: ● Versioning should include a suffix of CI BUILD number (e.g. “master-1”) ● Configure Pods to redeploy always on helm upgrade (for development environments only): ○ Pod Annotation: helm.sh/deploy-date: "{{ .Release.Time.Seconds }}" ○ Pod container: imagePullPolicy: Always ○ Configure Registry to allow redeploys of same version

Slide 34

Slide 34 text

34 Development Styles > Versioning per Environment ● Production Deployments ○ by tags ○ continuously by “master” ● Staging Deployments ○ by “release” branches ○ continuously by “master” ○ continuously by “staging” ● Develop Deployments ○ by “develop” branch ○ by “feature” branches

Slide 35

Slide 35 text

35 Development Styles > Environments ● Production Environments ○ by cluster (AZ, DC) ○ by namespace (client) ● Staging Environments ○ for load testing ○ for security testing ○ for regression testing ● Develop Environments ○ by team ○ by developer ○ by feature branch

Slide 36

Slide 36 text

36 Development Styles > Centralized vs Decentralized Centralized Decentralized vs - Least Privilege Principle - Role Based Access Control - Self Service - Cluster-wide Privileges - Promoting silos culture

Slide 37

Slide 37 text

37 Demo Time!

Slide 38

Slide 38 text

38 DevOps Culture Automation - CI/CD - GitOps - ChatOps - Metrics - Alerts - Dashboards Feedback - Retrospectives - Transparency - Blameless post-mortems - Evidence based experiments Shared Responsibility - Objectives - KPIs - Organization Culture Autonomous Teams - Self-service - Build & Deploy Agile - Move fast - React quickly - Accept Failure - Fail fast - Fail once

Slide 39

Slide 39 text

Thank You! Innovating Container Delivery