Terraform @IMMOWELT GROUP

Transcript

1. @ IMMOWELT GROUP Now talking: Robert Köbbert
2. Starting Point Why did we adopt Terraform? What did we expect from Terraform? How did we start using Terraform?
3. Why did we adopt Terraform? But doing it in the cloud is faster and needs absolutely no maintenance work! - random product team
4. What did we expect from Terraform? That‘s pretty cool stuff! - random developer
5. What actually happened... That‘s pretty cool stuff! - random developer
6. The future of our Terraform Maybe we should write our own providers and share them! - random developer Yeah!
7. What Do Ops Think? Do you remember how we got this application working? I can't find any recent docs and it stopped working smh. - random operator I have no idea. Bob did this. Now talking: Leroy Förster (@gersilex) Ops office talk
8. What Do Ops Think? Wait, there must be a script on the old deployment server, copy that, change it and then run it as root. - random operator Now talking: Leroy Förster (@gersilex) Ops office talk btw: Only works in production
9. Jumpstarting DevOps App DevOps Infrastructure Ops AWS Bootstrap
10. Jumpstarting DevOps App DevOps Infrastructure Ops AWS Bootstrap
12. Avoid Trouble From The Start Persist your state on a shared storage Learn how to modify your state files Keep old versions of your state Keep your state secure (contains secrets) Did I mention state persistence already? AWS S3 terraform state --help
13. Code Shopping DNS Record Module Mall
14. terraform-modules/opennebula-vm terraform-modules/aws-bootstrap terraform-modules/powerdns-record Public devops team infrastructure Using terraform modules from git
15. All Code Is Public (Internally) • Look at other teams' code • Look at the resulting infrastructure • Copy and adapt • Use and contribute modules • ??? • Profit!
16. How We Use It After One Year Use local modules (subfolders) for stages Force everyone to use Terraform (incl. Ops) Don't mix manual with Terraform infrastructure Run Terraform from a central instance (CI Software) Use multiple, smaller Terraform infrastructures instead of one big one for everyone Keep code public and keep secrets away from code
17. The developer‘s perspective Why should I care? Infrastructure is an Operations Job! Now talking: Jens Gerdes
18. The Sorrows of a developer…
19. My learnings… • Delegating resource creation is: • Time consuming (Ticket bingo) • Error prone • OPS and DEV should work closer together (DEVOPS!) • Software isn‘t isolated! • Infrastructure as a Solution
20. What is about? Terraform is about creating RESOURCES. A resource is any infrastructure component, such as: • Classic VM • AWS Lambda Service • PostgreSQL database • Github repository • A DNS record
21. Using Use HCL (Hashicorp Config Language) to define the desired state. Sample Terraform file creating a VM.
22. Using These .tf files are part of your application and should become a part of its deployment. Jenkinsfile with a Terraform stage. Good developers test their code!
23. Caveats using: Terraform is as good as its providers • Terraform delegates infrastructure creation to resource-specific providers • Usability of Terraform for your usecase depends on the quality of the provider Terraform Provider A Provider B Provider C Provider D Provider E
24. ImmoweltGroup/terraform-provider-opennebula No official OpenNebula support • Existing implementation of Runtastic works, but • not well documented • not actively maintained • A bit hacky in terms of template definitions • Missing features OpenNebula offers
25. Comparison of IaC tools Open Source Agent- less Server provisioning Config mgmt
26. Terraform is • A great resource provisioning tool • Simple to use (HCL) • Extensible (Open source) • Supports a wide variety of resource providers out-of-the-box Give it a try!