Successfully reported this slideshow.

Test driven development for infrastructure as-a-code, the future trend_Gianfranco Panico

2

Share

Loading in …3
×
1 of 23
1 of 23

Test driven development for infrastructure as-a-code, the future trend_Gianfranco Panico

2

Share

Download to read offline

We stress our developers to write tests while they write the code. We set quality gates to avoid releasing code that didn’t pass tests, or doesn’t have enough coverage.
But then, when it’s about IaaC, we do exactly the opposite. The time has come for us to discuss the challenges of testing IaaC code, from the necessity of using different languages, to the problems of deploying expensive resources in real world – analyzing the current possibilities and common best practices and looking ahead at the most promising technologies and projects, to boldly go, where no man has gone before: TDD Infra as Code.

We stress our developers to write tests while they write the code. We set quality gates to avoid releasing code that didn’t pass tests, or doesn’t have enough coverage.
But then, when it’s about IaaC, we do exactly the opposite. The time has come for us to discuss the challenges of testing IaaC code, from the necessity of using different languages, to the problems of deploying expensive resources in real world – analyzing the current possibilities and common best practices and looking ahead at the most promising technologies and projects, to boldly go, where no man has gone before: TDD Infra as Code.

More Related Content

More from Katherine Golovinova

Related Books

Free with a 14 day trial from Scribd

See all

Test driven development for infrastructure as-a-code, the future trend_Gianfranco Panico

  1. 1. TDD for IaaC the future trend Dnipro, 28th feb 2018 Gianfranco Panico
  2. 2. привіт I am Gianfranco Dreaming of a world with more and better automation: - spreading DevOps mentality - educating to correct InfraDev approach
  3. 3. Why Testing IaaC … and why we aren’t already doing it! 1
  4. 4. “ “Confidence in code without tests is false confidence”. Buddha
  5. 5. Typical IaaC caveats The 200 paradigm Stack deployments in the Cloud are mostly requests to undergo some provisioning actions. HTTP status 200 means ‘copy’ not ‘done’. Cloud provider changes AWS keeps “improving” their offer – adding instance types, increasing the length of some IDs, changing SSL certs for services – every second day. Collaboration I ansible this box here, you terraform that DB instance there, works fine, right? Delays & Dependancies That forgotten firewall rule that won’t let you download the Docker image from your registry. Timeouts Lambdas timeout happily. Cross region transfers – guess what? – do timeout too! Some operations with infras are inherently long, and don’t give much sign of progression. Works… too much The resource is deployed, the service is up, the port is open. And all other 65534 ports are – as well!
  6. 6. Infra as a Code means applying SDLC methods and tooling to Infrastructure Development
  7. 7. TDD teachings Let’s learn from our beloved Devs 2
  8. 8. TDD loop 1. THINK of an expected behaviour 2. WRITE a test that fails 3. WRITE code to pass the test 4. REFACTOR 5. GOTO 1.
  9. 9. 1. THINK of an expected behaviour 2. WRITE a test that fails 3. WRITE code to pass the test 4. REFACTOR 5. GOTO 1. var strong = isStrongPassword('password string'); describe('isPasswordStrong', function() { it('should give negative result for empty string', function() { var password = ''; var result = isPasswordStrong(password); expect(result).to.be.false; }); }); function isPasswordStrong(password) { if(!password) { return false; } }
  10. 10. unit integration Oh Not Yet Another Test Pyramid acceptance Do our CD scripts work? Are instances up? Am I missing some best coding practice? Is code style “decent” enough? Can they connect to the DB/ELB…? Is Bastion Host up and connectable? How’s the security of VPCs? Am I actually solving the right problem? slow expensive
  11. 11. Test types for Infra Unit ◇ No code is actually run ◇ Check internal consistency ◇ Check format/style ◇ Check intrinsic language constructs Integration ◇ Code is run ◇ Systems are provisioned ◇ The result is validated ◇ E2E / functional testing goes here Security ◇ On already deployed infra ◇ Scans for “excesses” ◇ Respondance to hardening standards ◇ Infra-compliance
  12. 12. The tools? Are here.
  13. 13. *specLinter Unit testing IaaC Formatter Ruby terraform puppet rubocop YAML ansible_spec foodcritic align-yaml HCL tf fmt chef ansible chefspec tflint terraform-spec tf plan ansible-lint tf validate
  14. 14. rubocop & foodcritic
  15. 15. validate, fmt & tflint
  16. 16. chefspec
  17. 17. Functional Integration testing IaaC Ruby terraform puppet YAML HCL chef ansible ServerSpec tf plan ansible --check AWSpec
  18. 18. kitchenCI ansible Terraform kitchen-terraform provisioner (on Vagrant) YAML HCL Ruby puppetchef $ kitchen converge ServerSpec InSpec
  19. 19. Acceptance Security testing IaaC Ruby puppet nmap chef InSpec gauntlt Se BDD-security Owasp zed attack proxy
  20. 20. Computing the sha384sum digest of the deployable package $ sha512sum app123.war > app123.sig and then having Jenkins verify the checksum at deploy stage $ sha512sum –c app123.sig app123.war 2>&1 | grep OK app_v123.war: OK Trustable artifact to guarantee that each and every deployable component had been built through automation, and as such, has been tested fully before being promoted to production.
  21. 21. Compliance Compliance IaaC AWS Config AWS Lambda CloudTrail CloudWatch signed-artifact deployment
  22. 22. What to do next spread the voice develop & share tools build best practices
  23. 23. Thanks! Any questions? Credits: PPT template by SlidesCarnival

Editor's Notes

  • Always think to a failing situation first.
    Model a failing test. Rework that.
  • ×