O slideshow foi denunciado.

New Ways To Production - Stress-Free Evolution Of Your Cloud Applications

0

Compartilhar

Carregando em…3
×
1 de 22
1 de 22

New Ways To Production - Stress-Free Evolution Of Your Cloud Applications

0

Compartilhar

Baixar para ler offline

Neue Versionen der eigenen Cloud-Anwendungen geordnet, stabil und somit ohne Stress und risikofrei in die Produktionsumgebung zu deployen, sollte das Ziel eines jeden Entwicklerteams sein. Erfolgt das zusammen mit den passenden Teststrategien, ohne Downtime und voll automatisiert, ist die Basis für hochfrequente Releasewechsel geschaffen. Ein Service-Mesh-Tool wie beispielsweise Istio bietet für verschiedene Deployment-Strategien – Canary, A/B Testing (HTTP Headers Routing), Blue/Green (Traffic Mirroring) – die notwendige Unterstützung. Kombiniert man das mit einem progressive Delivery Operator wie Flagger, wird die Automatisierung noch weiter gesteigert. Hotfixes und hektische Release-Rollbacks gehören damit der Vergangenheit an. In dieser Session werden die unterschiedlichen Release- und Teststrategien genauer vorgestellt. Darüber hinaus wird gezeigt, wie die Integration von Istio und Flagger erfolgen kann und welche Benefits sich daraus ergeben.

Neue Versionen der eigenen Cloud-Anwendungen geordnet, stabil und somit ohne Stress und risikofrei in die Produktionsumgebung zu deployen, sollte das Ziel eines jeden Entwicklerteams sein. Erfolgt das zusammen mit den passenden Teststrategien, ohne Downtime und voll automatisiert, ist die Basis für hochfrequente Releasewechsel geschaffen. Ein Service-Mesh-Tool wie beispielsweise Istio bietet für verschiedene Deployment-Strategien – Canary, A/B Testing (HTTP Headers Routing), Blue/Green (Traffic Mirroring) – die notwendige Unterstützung. Kombiniert man das mit einem progressive Delivery Operator wie Flagger, wird die Automatisierung noch weiter gesteigert. Hotfixes und hektische Release-Rollbacks gehören damit der Vergangenheit an. In dieser Session werden die unterschiedlichen Release- und Teststrategien genauer vorgestellt. Darüber hinaus wird gezeigt, wie die Integration von Istio und Flagger erfolgen kann und welche Benefits sich daraus ergeben.

Mais Conteúdo rRelacionado

Livros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

Audiolivros relacionados

Gratuito durante 30 dias do Scribd

Ver tudo

New Ways To Production - Stress-Free Evolution Of Your Cloud Applications

  1. 1. New Ways To Production: Stress-Free Evolution Of Your Cloud Applications Michael Hofmann Hofmann IT-Consulting info@hofmann-itconsulting.de https://hofmann-itconsulting.de
  2. 2. Traditional Process of Releasing ● Release frequency: 3 month, monthly, daily (?), hourly (?) ● Test upfront (minimize risk of failure) ● Setup pre-production: copy of production (?) ● Release Rollback – Restore old version: big-bang (?) – Restore process tested (?) cv
  3. 3. Risks of Traditional Process ● Load/Performance Test before releasing (?) – Too expensive: time consuming, staging costs – Just a guess: load scenarios, stage equivalent to production ● Results do not correlate with real world
  4. 4. Canary Release ● Canary (cole mines) ● Martin Fowler: “... technique to reduce the risk of introducing a new software … by slowly rolling … to a small subset of users before … making it available to everybody.” ● “… gain more confidence in the new version...routing more users to it” ● “… benefit ... capacity testing … in a production environment with a safe rollback strategy … slowly ramping up the load ... monitor and capture metrics …” https://martinfowler.com/bliki/CanaryRelease.html
  5. 5. Blue Green Deployment ● Martin Fowler: “... two production environments, as identical as possible. … blue for the example, is live. … new release … final … testing in the green environment. ...software is working in the green environment, … switch ... all incoming requests go to the green environment - the blue one is now idle.” ● “... rapid way to rollback ... switch … back to … blue environment.” https://martinfowler.com/bliki/BlueGreenDeployment.html
  6. 6. A/B Testing ● Is NOT Blue Green Deployment! – Blue Green: Releasing strategy – Release new software and safely rollback ● A/B Testing: Testing strategy – Test for new features (switch, feature toggle, …) – Often combined: blue green deployment BUT access only for dedicated users to new release – Canary: weighted random routing NOT dedicated users
  7. 7. Benefits of new strategies ● Canary Release – Controlled load/performance test ● No additional stage (only additional workload deployment) ● No guess of load scenarios – Rollback is an intrinsic part of canary ● A/B Testing – After successful test: releasing by deleting feature toggle/switch: no new deployment ● A/B Testing and Canary Release can converge to Blue Green Deployment ● Blue Green Deployment – Disaster Recovery (hot-standby) is part of releasing
  8. 8. Istio
  9. 9. Istio Blue Green Deployment apiVersion: networking.istio.io/v1beta1 kind: VirtualService ... spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 apiVersion: networking.istio.io/v1beta1 kind: DestinationRule ... spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 apiVersion: networking.istio.io/v1beta1 kind: VirtualService ... http: - route: - destination: host: reviews subset: v2
  10. 10. Istio Canary Release apiVersion: networking.istio.io/v1beta1 kind: VirtualService ... spec: hosts: - reviews http: - retries: attempts: 3 perTryTimeout: 1s route: - destination: host: reviews subset: v1 weight: 90 - destination: host: reviews subset: v2 weight: 10
  11. 11. Istio A/B Testing (2 Ways) apiVersion: networking.istio.io/v1beta1 kind: VirtualService ... spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 100 mirror: host: reviews subset: v2 mirrorPercentage: value: 100.0 apiVersion: networking.istio.io/v1beta1 kind: VirtualService ... spec: hosts: - reviews http: - match: - headers: end-user: exact: jason route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1
  12. 12. Flagger ● Progressive Delivery Operator for Kubernetes (CNCF) – Standalone or part for Flux (Weaveworks) – gradually shifting traffic to the new version – dynamically advises service mesh tool or ingress controller – metrics, webooks for running tests, notifications ● Canary Release – Progressive traffic shifting ● A/B Testing – HTTP headers and cookies for traffic routing and traffic mirroring ● Blue/Green Deployment – traffic switching https://flagger.app
  13. 13. Flagger
  14. 14. Flagger Canary Release
  15. 15. Flagger Canary CRD apiVersion: flagger.app/v1beta1 kind: Canary … spec: targetRef: # deployment reference ... progressDeadlineSeconds: 60 # max time of progress for canary before rollback autoscalerRef: # HPA reference (optional) ... service: ... gateways: # Istio gateways (optional) ... hosts: # Istio virtual service host names (optional) ... trafficPolicy: # Istio traffic policy (optional) ... retries: # Istio retry policy (optional) ...
  16. 16. Flagger Canary CRD (cont.) analysis: interval: 1m # schedule interval (default 60s) threshold: 5 # max number of failed metric checks before rollback maxWeight: 50 # max traffic percentage routed to canary stepWeight: 25 # canary increment step metrics: - name: request-success-rate # minimum req success rate (non 5xx responses) thresholdRange: min: 99 interval: 1m - name: request-duration # maximum req duration P99 in milliseconds thresholdRange: max: 500 interval: 30s ...
  17. 17. Flagger Canary CRD (cont.) ... webhooks: # testing (optional) is part of analysis section - name: acceptance-test type: pre-rollout url: http://flagger-loadtester.test/ timeout: 30s metadata: type: bash cmd: "curl -sd 'test' http://podinfo-canary:9898/token | grep token" - name: load-test url: http://flagger-loadtester.test/ timeout: 5s metadata: cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"
  18. 18. Demo
  19. 19. GitOps (Weaveworks) ● Git as single source of truth ● Git as source for declarative infrastructure (e.g. Kubernetes) and applications ● Pipeline (e.g. Flux, JenkinsX, ArgoCD, ...) reacts on Git pull requests and steers operations task and deployments
  20. 20. Flagger and GitOps ● Canary deployment is triggered by changes of: – Deployment Pod specification part: container image, command, ports, env, resources, etc) – ConfigMaps mounted as volumes or mapped to environment variables – Secrets mounted as volumes or mapped to environment variables ● Workflow: – define release process in Flagger (Canary CRD) – let pipeline change one of these objects e.g. new version of container image – pipeline change triggers Flagger to start the predefined release process
  21. 21. Zero Downtime Deployments ● Deployment strategy “RollingUpdate” with “maxUnavailable” ● Live- and Readiness-Probes ● Graceful shutdown with preStop hook ● Autoscaling HPA with resource settings ● Retry settings for Service Mesh
  22. 22. Summary ● Easy and full automated process, also rollback ● A/B Testing, Canary Release, Blue Green Deployment ● Service mesh resources must be configured in Canary CRD ● GitOps integration possible ● Zero Downtime comes from Service Mesh and Kubernetes

×