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.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 93

Infrastructure as code 101

0

Share

Download to read offline

Infrastructure as code is eating the world (well, part of it). Cloud providers and tool vendors are treating developer and operator experience as a first priority. Code is used to describe the desired state of your infrastructure (either on-prem or in the cloud). It's declarative (yes, it is), it's readable (in most cases) and it's getting close to real programming (no kidding). In this talk, we'll go on an illustrated journey behind the machinery of various infrastructure-as-code tools like Terraform, Ansible, Kubernetes, and others.

Related Books

Free with a 30 day trial from Scribd

See all

Infrastructure as code 101

  1. 1. 01
  2. 2. 02
  3. 3. 03
  4. 4. Andrew Clay Shafer 04
  5. 5. Infrastructure as code Infrastructure as Code: Track, Test, Deploy, Reproduce, Scale Code commits log shows the history of change on the infrastructure Reproducible setups: Do once, repeat forever Scale quickly: Done for one, use on many Coherent and consistent setups Aligned Environments for dev, test, qa, prod • • • • • • 05
  6. 6. How do you manage infra/config?06
  7. 7. The process 07
  8. 8. GitOps! 08
  9. 9. GitOps Provisioning and deployment is declarative Entire system state is under version control Operational changes are made by pull request (plus build & release pipelines) Diff tools detect any divergence and sync tools enable convergence Rollback and audit logs are also provided via Git • • • • • 09
  10. 10. Ops by pull request 10
  11. 11. Code propagation 11
  12. 12. No Manual Changes! 12
  13. 13. Single source of truth! 13
  14. 14. Knowledge capture 14
  15. 15. Which tools do you use? 15
  16. 16. The machine 16
  17. 17. 17
  18. 18. The machine Yaml (or any similar language) is just the declaration of WHAT Heavy lifting of HOW is done by the machinery • • 18
  19. 19. 19
  20. 20. 20
  21. 21. New version They just released v1.16 this month 21
  22. 22. U.S.E. 22
  23. 23. CLI 23
  24. 24. 24
  25. 25. 25
  26. 26. Let's play! 26
  27. 27. 27
  28. 28. Pluto's status 28
  29. 29. Pluto's status 29
  30. 30. Pluto's status 30
  31. 31. 31
  32. 32. Comet 32
  33. 33. Let's check it 33
  34. 34. Let's remove the code 34
  35. 35. Compensating actions 35
  36. 36. 36
  37. 37. That's no moon 37
  38. 38. That's no moon 38
  39. 39. Go! Go! Go! 39
  40. 40. Wait! What? 40
  41. 41. SOL-101: Bug report Earth is overpopulated. We need to scale it up to house more biological forms. 41
  42. 42. Bug fix 42
  43. 43. Push it 43
  44. 44. No way! 44
  45. 45. Backup 45
  46. 46. 10 days later... 46
  47. 47. Real life state machines Kubernetes Terraform CloudFormation Serverless.com Ansible Puppet etc. • • • • • • • 47
  48. 48. Idempotance 48
  49. 49. Idempotance 49
  50. 50. Idempotent 50
  51. 51. Not idempotent 51
  52. 52. More code 52
  53. 53. Declarative catalogue 53
  54. 54. Readability! 54
  55. 55. Pipeline- integratable 55
  56. 56. Resource graph 56
  57. 57. 57
  58. 58. 58
  59. 59. Resource graph Resource depedency cluster detection Parallel execution Automatic ordering • • • 59
  60. 60. Attribute management 60
  61. 61. 61
  62. 62. Attribute management L0: Write-once L1: Updatable, requires extra action to take effect L2: Updatable, forces resource recreation L3: Updatable, applied right-away • • • • 62
  63. 63. Data query 63
  64. 64. 64
  65. 65. Data query 65
  66. 66. Resource deletion 66
  67. 67. Resource deletion 67
  68. 68. Resource recreation 68
  69. 69. Resource protection 69
  70. 70. Dry-run 70
  71. 71. State verification 71
  72. 72. 72
  73. 73. Compensating actions Compensating actions may sometimes be required Not every state change is allowed Any software has bugs! • • • 73
  74. 74. Additional goodies Modularity Module hub (public repository) Module-level dependencies Resource-level dependencies Documentation • • • • • 74
  75. 75. SM-index idempotence maturity language/declarativeness maturity (readiblity) data query richness execution engine maturity (parallel execution, auto-ordering of dependencies, deletion of obsolete objects) modularity maturity documentation maturity (searchable, structured, different level audience) • • • • • • 75
  76. 76. 76
  77. 77. 77
  78. 78. Ansible machine 78
  79. 79. 79
  80. 80. Ansible machine Signs of state management, idempotance is not always achievable. Can be parallel only on node level, not resource (task) level. No model for resource dependencies. Imperative logic elements implemented in a declarative, but hardly readable way ( register , set_fact , when ). • • • • 80
  81. 81. Kubernetes machine 81
  82. 82. 82
  83. 83. Kubernetes machine api-server will accept any valid object definition. Will it be created and running? Eventually, it should. Run-time state validation. Not all attributes are changeable. Custom resource definitions (+ operators). Queries and dependencies only through labels. • • • • • • 83
  84. 84. Terraform machine 84
  85. 85. 85
  86. 86. Terraform machine Terraform remembers previous state (supports resource deletion). Deployment time validation, no run-time validation. Not YAML, rich expression language. Powerful query capabilities. • • • • 86
  87. 87. Conclusion 87
  88. 88. Side effects are real Know the tool Know which resources you are managing Know the side effects • • • 88
  89. 89. Tools There are tools for tools: linters, IDE plugins, schema validators. 89
  90. 90. Everything is a spectrum Avoid dichotomy (bad/good, persistent/volatlie etc.), use a spectrum to define your relationship with a tool/language. 90
  91. 91. Keep it simple 91
  92. 92. Thank you! 92
  93. 93. 93

×