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.

Patterns for Infrastructure-as-code for DevOps Linz 2016

376 views

Published on

One of the ways to describe software architecture is to express its configuration in executable and therefore repeatable form – infrastructure as code. Tools that are often used for this purpose (for example, Puppet, Ansible, Chef) are not utilized to their full potential. Provided abstractions, extension points, existing modules are ignored by turning provisioning software into just a fancy file copying utility. Software configuration has a variety of frequently appearing patterns and ready-made abstractions to better communicate the intent of the architecture described in the form of infrastructure as code. The intent of this presentation is to provide summary of such patterns.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Patterns for Infrastructure-as-code for DevOps Linz 2016

  1. 1. 01
  2. 2. About me 02
  3. 3. Andrey Adamovich Java/Groovy developer, clean coder DevOps guy, automation junkie Co­organizer of @latcraft and @devternity Coach at @devchampions Twitter: @codingandrey • • • • • 03
  4. 4. What this talk is about? 04
  5. 5. Well... Collection of patterns (and anti­patterns) for representing your infrastructure­as­code. Work in progress (never done). Feedback is more than welcome! • • • 05
  6. 6. Infrastructure­as­code Infrastructure­as­Code (IaC) is a type of IT infrastructure that operations teams can automatically manage and provision through code, rather than using a manual process. Infrastructure­as­Code is sometimes referred to as programmable infrastructure. “ 06
  7. 7. Images, declarations, tasks 07
  8. 8. IaC players Image defitions Provisioning declarations Automation scripts • • • 08
  9. 9. Tools Image creation/management: Packer, Docker, AWS AMI/EC2 etc. State declarations: Puppet, Chef, Ansible etc. Automation blocks: SSH, API +  <your favorite scripting language> • • • 09
  10. 10. Periodic table of DevOps 10
  11. 11. Everything is code! 11
  12. 12. Code "deployment" (one click away) 12
  13. 13. Code "deployment" (one commit away) 13
  14. 14. Let's see some patterns!14
  15. 15. Images 15
  16. 16. Anti­pattern: Golden Image Manually crafted base infrastructure server image that nobody dares or knows how to change. • 16
  17. 17. Pattern: Reproducible Images Operating system distributions ( *.iso ). Base provider images. Packer can create images for many virtualization software and cloud providers. Docker can build and package containers as images for distribution. • • • • 17
  18. 18. Secrets 18
  19. 19. Pattern: Secret Isolating Everything is code, but secrets are not! Secrets should reside in a separate location! Secrets should be injected on the very last stage of "deploying" your code. In this way, the actual code still remains sharable. • • • • 19
  20. 20. Pattern: Encrypted Secrets Shared secrets must be encrypted! Well, all stored secrets must be encrypted! Decryption password is shared through a different channel. • • • 20
  21. 21. Encryption options Encrypt hard drives Encrypt files in version control Use vault service • • • 21
  22. 22. Encryption options: GPG GPG/PGP: > cd <path‐to‐your‐repo>/ > gpg ‐‐encrypt sensitive_file > git add sensitive_file > git commit ‐m 'Add encrypted version of a sensitive file' • 01. 02. 03. 04. 22
  23. 23. Encryption options: Transcrypt OpenSSL + Transcrypt (https://github.com/elasticdog/transcrypt): > cd <path‐to‐your‐repo>/ > transcrypt > echo 'sensitive_file  filter=crypt diff=crypt' >> .gitattributes > git add .gitattributes sensitive_file > git commit ‐m 'Add encrypted version of a sensitive file' • 01. 02. 03. 04. 05. 23
  24. 24. Vault services Generic: Vault from HashiCorp Chef: encrypted data bags Puppet: hiera­gpg, hiera­eyaml Ansible: ansible­vault • • • • 24
  25. 25. Anti­pattern: Postponing Secret Isolation "It's OK for now" does not really work! It creates a culture of security being not so important! It may alienate your Dev and Ops teams, because they can't share code due to hard­coded secrets! • • • 25
  26. 26. Code organization 26
  27. 27. Anti­pattern: "Fancy­File­Copying" To configure package X, you keep all configuration files it needs within your "code". You use provisioning tool abstractions to copy every single file onto the target system. • • 27
  28. 28. Anti­pattern: "Fancy­File­Copying" 28
  29. 29. Example: nginx nginx.conf mime.conf servers.conf params.conf nginx.pp | nginx.rb | nginx.yml • • • • • 29
  30. 30. Example: nginx file { 'servers.conf': ... } file { 'mime.conf': ... } file { 'nginx.conf': ... } file { 'params.conf': ... } ... 01. 02. 03. 04. 05. 30
  31. 31. Example: nginx ‐ template: src=servers.conf ...  ‐ template: src=mime.conf ...  ‐ template: src=nginx.conf ...  ‐ template: src=params.conf ...  ... 01. 02. 03. 04. 05. 31
  32. 32. Hiding abstractions Well, there are much simpler ways to copy files. You actually hide your intent and the goal of your configuration. File and package are not always the right abstractions. • • • 32
  33. 33. Example: nginx Upstream Server Virtual Host Static Directory System Wide Setting • • • • 33
  34. 34. Pattern: Infrastructure Component DSL Nobody knows your domain better than you! You can write your own DSL or you can leverage existing tools. The main thing is to group infrastructure configuration into reusable components. That's what we do with application code, that's what we should do with IaC! • • • • 34
  35. 35. Pattern: Infrastructure Component DSL 35
  36. 36. Example: pseudo­code system1 {   http_proxy {      cache=true     business_app {       param1=A     }   }   database {     memory=3GB   } 01. 02. 03. 04. 05. 06. 07. 08. 09. 10. 36
  37. 37. DSL Bash, Perl, Python, Groovy,... anything works. Though, Puppet, Chef, Ansible provide facilities to define and group abstractions. • • 37
  38. 38. Pattern: Incremental Configuration Many packages will already be on the system in their default state. Instead of duplicating default state in your code, you can only define an incremental change. • • 38
  39. 39. Pattern: Incremental Configuration 39
  40. 40. Examples Disallow root access on the system Set SELinux into permissive mode Set default caching timeout in Nginx • • • 40
  41. 41. Tooling examples Generic: sed, perl, regular expressions Puppet: file_line, augeas Ansible: lineinfile, replace Chef: ruby • • • • 41
  42. 42. Pattern: Configuration Composition Compose your configuration of several template calls or API call blocks. Expose abstractions through configuration blocks. • • 42
  43. 43. Pattern: Configuration Composition 43
  44. 44. Tooling examples Puppet: concat module Ansible: assemble module Chef: partials • • • 44
  45. 45. Pattern: Extra­Packaging Code Package your application in the most approriate format that is ready for the most hassle­free deployment. Publish it to artifact repository (Maven, RubyGems, Yum, Apt...). Artifact repository serves as a layer of isolation between pipelines. Reduces amount of code needed on later stages of configuration management. • • • • 45
  46. 46. Pattern: Extra­Packaging Code 46
  47. 47. Application can be packaged differently jar|gem|pyc|... tar.gz|tar.bz2|zip|... rpm|deb|msi|... server|container image 1. 2. 3. 4. 47
  48. 48. Anti­pattern: Data as Code Data has different lifecycle. It's more dynamic. Data changes more often than code. Example 1: use your provisioning tool to define organization users. Example 2: manifest that lists all your 500 servers. • • • • 48
  49. 49. Pattern: Configuration Discovery Part or all of system configuration is distributed through auto­discovery mechanism. This cleans your IaC from storing specifics. Define keys instead of values. Basically, "convention over configuration" for your cluster. • • • 49
  50. 50. Pattern: Configuration Discovery 50
  51. 51. Tooling examples Etcd (https://github.com/coreos/etcd) Eureka (https://github.com/Netflix/eureka) ZooKeeper (https://zookeeper.apache.org/) Consul (http://www.consul.io/) • • • • 51
  52. 52. Pattern: Configuration Data Source Useful when number of managed items exceeds certain amount. Data file (Text, Excel, etc.) Database (PuppetDB etc.) Infrastructure Service API • • • • 52
  53. 53. Pattern: Infrastructure Query Language or API that allows to query your infrastructure state (real time or last available report). Examples: AWS EC2 API, PuppetDB, MCollective, Salt • • 53
  54. 54. Pattern: Environment Template Define template from which you can create a fully working environment. It gives scaling. It gives isolation. It gives flexibilty. • • • • 54
  55. 55. Tooling examples Vagrant AWS Cloud Formation Terraform Docker and Docker Compose Kubernetes API • • • • • 55
  56. 56. Code Quality 56
  57. 57. Anti­pattern: Not Treating IaC as Code Code must be in Version Control. Lack of experience with new tool may require Code Reviews. Yes, there are tools for Static Code Analysis even for IaC products. Unit testing does not make a lot of sense for IaC, but Integration Testing does. Applying all the above techniques gives the best QA result for any code. • • • • • 57
  58. 58. Testing IaC Serverspec (http://serverspec.org/) BATS (https://github.com/sstephenson/bats) • • 58
  59. 59. Anti­pattern: Ignoring Styling Guidelines Each tool/language out there has one. Nobody canceled clean code teachings. Reading, writing and eventually merging code is always easier if people follow the same formatting and styling. • • • 59
  60. 60. Static code analysis tools shellcheck (https://github.com/koalaman/shellcheck) yaml­lint (https://github.com/Pryz/yaml­lint) Puppet Lint (http://puppet­lint.com/) Ansible Lint (https://github.com/willthames/ansible­lint) FoodCritic (http://www.foodcritic.io/) • • • • • 60
  61. 61. Side effects 61
  62. 62. Pattern: Metrics as Code Metrics that your application provides evolve with your application. New components, new endpoints, new KPIs... Keep monitoring configuration close to the code! Or make it auto­discoverable and visible! • • • • 62
  63. 63. Configuring and collecting metrics Monitoring software has configuration files and/or an API that can be programmed. There a plenty of libraries that allow making monitoring a built­in feature of your application. • • 63
  64. 64. Examples: Java DropWizard Metrics Hystrix StageMonitor • • • 64
  65. 65. Pattern: Control Panel as Code Repeatable things live well in scripts. Scripts can (and will) be well executed by your CI server (or any other UI you can build around your automation). Effectively, that server becomes your "control panel". Keep configuration of your "control panel" in version control. • • • • 65
  66. 66. Example: Jenkins Jenkins API (https://jenkinsapi.readthedocs.org/en/latest/) Job DSL (https://github.com/jenkinsci/job­dsl­plugin) Gradle plugin (https://github.com/ghale/gradle­jenkins­plugin) • • • 66
  67. 67. Example: RunDeck RunDeck API (http://rundeck.org/2.5.3/api/index.html) RunDeck Command Line (http://rundeck.org/docs/man1/index.html) • • 67
  68. 68. Anti­pattern: Private Fork of a Community Module There is a lot of code out there. Private fork may work as a short­term solution. Do not keep your updates only to yourself. Share them back. • • • 68
  69. 69. Pattern: Community Module Wrapper It's better to create a wrapper. This simplifies upgrades. And tracebilty. • • • 69
  70. 70. Anti­pattern: "Other Stuff" Team members do not fully understand the logic behind code organization. They still are eager to contribute, but when they actually do, they break it. • • 70
  71. 71. Example: "Other Stuff" 71
  72. 72. Example: "Other Stuff" 72
  73. 73. Example: "Other Stuff" 73
  74. 74. Anti­pattern: Big Ball of Mud Well, it's possible to create mess out of anything.• 74
  75. 75. Pattern: Automation over Documentation It's quite common that Ops team have been given or have created a bunch of documents describing procedures for system operations. Code can do it better! It happens that writing those documents take as much time as writing and testing code that implement the same guide lines. Automating procedures can reduce the amount of documentation needed or eliminate the documentation completely. • • • • 75
  76. 76. Conclusion 76
  77. 77. Conclusion Patterns are everywhere! Patterns help understanding bigger picture, but not always provide a solution to your specific problem. It helps to set a common language. List is not complete! • • • • 77
  78. 78. Feedback is welcome! 78
  79. 79. Share your patterns: Write a blog post! Share a tweet with @codingandrey or #iacpatterns. Or just write me to andrey@aestasit.com. • • • 79
  80. 80. For the reference 80
  81. 81. Summary of anti­patterns I Anti­pattern: Golden Image Anti­pattern: Postponing Secret Isolation Anti­pattern: "Fancy­File­Copying" Anti­pattern: Data as Code • • • • 81
  82. 82. Summary of anti­patterns II Anti­pattern: Not Treating IaC as Code Anti­pattern: Ignoring Styling Guidelines Anti­pattern: Private Fork of a Community Module Anti­pattern: "Other Stuff" Anti­pattern: Big Ball of Mud • • • • • 82
  83. 83. Summary of patterns I Pattern: Reproducible Images Pattern: Secret Isolating Pattern: Encrypted Secrets Pattern: Infrastructure Component DSL Pattern: Incremental Configuration Pattern: Configuration Composition Pattern: Extra­Packaging Code • • • • • • • 83
  84. 84. Summary of patterns II Pattern: Configuration Discovery Pattern: Configuration Data Source Pattern: Infrastructure Query Pattern: Metrics as Code Pattern: Control Panel as Code Pattern: Community Module Wrapper Pattern: Environment Template Pattern: Automation over Documentation • • • • • • • • 84
  85. 85. That's it! 85
  86. 86. Thank you! 86
  87. 87. Questions? 87
  88. 88. 88

×