Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

1

Share

Download to read offline

Gitops Hands On

Download to read offline

These are the slides for a talk/workshop delivered to the Cloud Native Wales user group (@CloudNativeWal) on 2019-01-10.

In these slides, we go over some principles of gitops and a hands on session to apply these to manage a microservice.

You can find out more about GitOps online https://www.weave.works/technologies/gitops/

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Gitops Hands On

  1. 1. Hands on Gitops January 2019 – Cloud Native Wales Brice Fernandes – @fractallambda – brice@weave.works 1
  2. 2. 2 I’m Brice I work for Weaveworks. You can find Weaveworks at https://www.weave.works or @weaveworks Team at Weaveworks is behind the GitOps model You can find me online at @fractallambda
  3. 3. 3 Login to your cluster – Weave Cloud & C9 1. Go to tinyurl.com/cnw-gitops-2019 2. Add your name and email 3. You can log into your cluster using the username and password
  4. 4. Q: Why this talk? 4
  5. 5. Q: Why this talk? 5 A: New ideas. Inspire change.
  6. 6. What’s this Gitops business anyway? 6
  7. 7. 7 GitOps is...
  8. 8. 8 GitOps is... An operation model
  9. 9. 9 GitOps is... An operation model Derived from CS and operation knowledge
  10. 10. 10 GitOps is... An operation model Derived from CS and operation knowledge Technology agnostic (name notwithstanding)
  11. 11. 11 GitOps is... An operation model Derived from CS and operation knowledge Technology agnostic (name notwithstanding) A set of principles (Why instead of How)
  12. 12. 12 GitOps is... An operation model Derived from CS and operation knowledge Technology agnostic (name notwithstanding) A set of principles (Why instead of How) Although Weaveworks can help with how
  13. 13. 13 GitOps is... An operation model Derived from CS and operation knowledge Technology agnostic (name notwithstanding) A set of principles (Why instead of How) A way to speed up your team
  14. 14. Principles of GitOps 14
  15. 15. 15 1 The entire system is described declaratively.
  16. 16. 16 1 The entire system is described declaratively. Beyond code, data ⇒ Implementation independent Easy to abstract in simple ways Easy to validate for correctness Easy to generate & manipulate from code
  17. 17. 17 1 The entire system is described declaratively. Beyond code, data ⇒ Implementation independent Easy to abstract in simple ways Easy to validate for correctness Easy to generate & manipulate from code
  18. 18. 18 How is that different from Infrastructure as code?
  19. 19. 19 How is that different from Infrastructure as code? It’s about consistency in the failure case.
  20. 20. 20 It’s about consistency in the failure case. When imperative systems fail, the system ends up in an unknown, inconsistent state.
  21. 21. 21 fail, the system ends up in an unknown, inconsistent state. Declarative changes let you think of changes as transactions.
  22. 22. 22 Declarative changes let you think of changes as transactions. This is a very good thing.
  23. 23. 23 The canonical desired system state is versioned (with Git) 2
  24. 24. 24 The canonical desired system state is versioned (with Git) Canonical Source of Truth (DRY) With declarative definition, trivialises rollbacks Excellent security guarantees for auditing Sophisticated approval processes (& existing workflows) Great Software ↔ Human collaboration point 2
  25. 25. 25 Changes to the desired state are automatically applied to the system 3
  26. 26. 26 Changes to the desired state are automatically applied to the system Significant velocity gains Privileged operators don’t cross security boundaries Separates What and How. 3
  27. 27. 27 Software agents ensure correctness and alert on divergence 4
  28. 28. 28 Software agents ensure correctness and alert on divergence 4 Continuously checking that desired state is met System can self heal Recovers from errors without intervention (PEBKAC) It’s the control loop for your operations
  29. 29. 29 1 The entire system is described declaratively. 2 The canonical desired system state is versioned (with Git) 3 Changes to the desired state are automatically applied to the system 4 Software agents ensure correctness and alert on divergence
  30. 30. Gitops is Functional Reactive Programming… ...for your infrastructure. Like React, but for servers and applications.
  31. 31. What should be GitOps’ed? 31
  32. 32. What should be GitOps’ed? 32 I’m o r so y
  33. 33. 33 Canonical source of truth People Software Agents Software Agents
  34. 34. 34 ?
  35. 35. Dashboards Alerts Playbook Kubernetes Manifests Application configuration Provisioning scripts 35 Application checklists Recording Rules Sealed Secrets
  36. 36. 36
  37. 37. Getting started with your environment 37
  38. 38. 38 Login to your cluster – Weave Cloud & C9 1. Go to tinyurl.com/cnw-gitops-2019 2. Add your name and email 3. You can log into your cluster using the username and password
  39. 39. 39
  40. 40. 40 Application code
  41. 41. 41 Cluster shell
  42. 42. Your Cluster 42 pod Icon by Freepik from www.flaticon.com
  43. 43. Your Cluster 43 pod Cloud Source Repositories Container Builder Cloud Registry
  44. 44. GitOps hands-on 1/10Kick the tires on your cluster 💻 1. Start with a simple command: ➤ kubectl version 2. Look at what’s running on the cluster with Weave Cloud Explore
  45. 45. “DevOps Console” Tooling for deployment, visualisation and observability Weave Cloud 45
  46. 46. 46 Weave Cloud Explore
  47. 47. 47 Weave Cloud Monitor
  48. 48. GitOps hands-on 1/10 Ask Kubernetes what’s running on the cluster: ➤ kubectl get pods --all-namespaces Query Kubernetes 💻
  49. 49. Gitops in practice 49
  50. 50. GitOps hands-on 4/10 [Only do this step if you didn’t do it in your cluster earlier] Create the namespace we will use for this exercise: kubectl create namespace dev Shortly, the Deploy agent will notice this change, and sync the Deployment and Service files. Watch for this happening in Weave Cloud or via: watch kubectl -n dev get all Gitops Hands On 1/12 💻
  51. 51. GitOps hands-on 5/10 We’re going to make a code change and see it flow through CI, then deploy that change. Call the version endpoint on the service to see what is running: curl podinfo.dev:9898/version Gitops Hands On 2/12 💻
  52. 52. GitOps hands-on 7/10 In the editor, open podinfo/pkg/version/version.go, increment the version number and save: var VERSION = "0.3.1" Commit your changes and push to master: cd /workspace/podinfo git pull git add pkg/version/version.go git commit -m "release v0.3.1 to dev" git push Gitops Hands On 3/12 💻
  53. 53. GitOps hands-on 2/10 The CI pipeline will create an image tagged the same as the git commit Git said something like [master 89b8396]; the tag will be like master-89b8396 Check by listing image tags (replace user with your username): gcloud container images list-tags gcr.io/dx-training/USER-podinfo USER should be of the form “training-user-<number>”. Gitops Hands On 4/12 💻
  54. 54. GitOps hands-on 3/10 Navigate in the editor to workspace/cluster/un-workshop/dev and open podinfo-dep.yaml. Where it says image: replace quay.io/stefanprodan/podinfo with gcr.io/dx-training/USER-podinfo replace the tag 0.3.0 with your tag master-TAG Save the file and commit your changes and push to master: cd /workspace/cluster/un-workshop/dev git add podinfo-dep.yaml git commit -m "my first deploy" git push Gitops Hands On 5/12 💻 NO : Her co g u w ar n
  55. 55. GitOps hands-on 5/10 Call the version endpoint on the service to see if it changed: curl podinfo.dev:9898/version Gitops Hands On 6/12 💻
  56. 56. Editing the YAML file was tedious. Let’s automate it! 56
  57. 57. GitOps hands-on 6/10 Let’s automate by adding an annotation to your deployment file: annotations: flux.weave.works/automated: 'true' flux.weave.works/tag.podinfo: glob:* Create a commit (In the control repository) and push it up to the remote to trigger automation: cd /worskpace/cluster/un-workshop/dev/ git add podinfo-dep.yaml git commit -m "automate releases of podinfo" git push Gitops Hands On 7/12 💻
  58. 58. GitOps hands-on 7/10 Open podinfo/pkg/version/version.go, increment the version number again, and save: var VERSION = "0.3.2" Commit your changes and push to master: cd /workspace/podinfo git add pkg/version.version.go git commit -m "release v0.3.2" git push Gitops Hands On 8/12 💻
  59. 59. GitOps hands-on 8/10 Watch for the CI/CD to upgrade the app to 0.3.2: watch curl podinfo.dev:9898/version Gitops Hands On 9/12 💻
  60. 60. GitOps hands-on 8/10 Suppose we don’t like the latest version: we want to roll back. 1. Deautomate by reverting your automate commit git revert <sha of automation commit> 2. Set the version back to the previous version 3. Check again which version is running: watch curl podinfo.dev:9898/version Gitops Hands On 10/12 💻
  61. 61. GitOps hands-on 7/10 We can flow the version number through the pipeline with a git tag, to show more meaningful versions Create and push a git tag: cd /workspace/podinfo git tag 0.3.2 git push origin 0.3.2 This will trigger another CI build, and when that is finished you should have an image tagged 0.3.2 Gitops Hands On 11/12 💻
  62. 62. GitOps hands-on 7/10 All done :) Gitops Hands On 12/12 💻
  63. 63. 63 ● Having separate pipelines for CI and CD enables better security ● It’s also easier to deal with if a deployment goes wrong ● We built a few versions of a simple app, using a demo CI pipeline ● Deployed those versions to Kubernetes using Weave Cloud ● Automated the deployment ● Deployments, rollback and lock are all done via git ● Git is our single source of truth. Recap: GitOps CI/CD
  64. 64. 64 Git v a We v o
  65. 65. Where to find out more 65 Search for “Weaveworks GitOps” in your favourite search engine Take a look at our opensource work on https://github.com/weaveworks Questions? Weaveworks @weaveworks https://weave.works Brice Fernandes @fractallambda brice@weave.works
  66. 66. Supplemental slides 66
  67. 67. 67 Declare Implement Monitor / Observe Modify
  68. 68. 68 Declare ImplementModify Continuous Deployment Default dashboards Automated by software agents Monitor / Observe
  69. 69. 69 Declare ImplementModify Continuous Deployment Default dashboards Automated by software agents Monitor / Observe Software making commits
  70. 70. 70 Declare ImplementModify Continuous Deployment Default dashboards Automated by software agents Monitor / Observe Safe and reversible changes
  71. 71. 71 Declare ImplementModify Continuous Deployment Default dashboards Automated by software agents Monitor / Observe Automated, templated dashboards
  72. 72. 72 Feedback loop. This is what matters.
  73. 73. GitOps at Weaveworks 73
  74. 74. 74 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  75. 75. 75 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  76. 76. 76 Dep n a se c i h Flu
  77. 77. 77 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  78. 78. 78 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  79. 79. 79 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  80. 80. 80 Com n c u t
  81. 81. 81 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  82. 82. 82
  83. 83. 83 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  84. 84. 84
  85. 85. 85
  86. 86. 86 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  87. 87. 87
  88. 88. 88
  89. 89. 89
  90. 90. 90
  91. 91. 91
  92. 92. 92
  93. 93. 93 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  94. 94. 94 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production *“stress-reduced”
  95. 95. 95 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ *“stress-reduced”
  96. 96. 96 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery
  97. 97. 97 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team
  98. 98. 98 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team Incredibly fast regression response
  99. 99. 99 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team Incredibly fast regression response Permissive approach to production access
  100. 100. 10 0 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team Incredibly fast regression response Permissive approach to production access Excellent developer experience
  101. 101. 10 1 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team Incredibly fast regression response Permissive approach to production access Excellent developer experience Stress-free on-call*
  102. 102. 10 2 Kubernetes operator (Flux, Open Source) Multiple clusters (staging and prod) CD into staging Promotion from staging to prod Kubernetes Automated diff tools (*diff operators, Open Source) Dashboard definitions in Git (Grafanalib, Open Source) Alert definitions in git Read-only access to production for all developers Gated, PR-driven changes to production ⇒ < 30 minute total cluster recovery Dozens of changes per day with a very small team Incredibly fast regression response Permissive approach to production access Excellent developer experience Stress-free on-call* *“stress-reduced”
  • TomaszTarczyski1

    Aug. 7, 2019

These are the slides for a talk/workshop delivered to the Cloud Native Wales user group (@CloudNativeWal) on 2019-01-10. In these slides, we go over some principles of gitops and a hands on session to apply these to manage a microservice. You can find out more about GitOps online https://www.weave.works/technologies/gitops/

Views

Total views

417

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

46

Shares

0

Comments

0

Likes

1

×