Using Terraform to Streamline Your Dev and Demo Environments
How to use Terraform for infrastructure as code with Vagrant and Docker in order to streamline dev and demo environments.
Join the DZone community and get the full member experience.Join For Free
i recently came back from portland, or, where i got to speak at hashiconf. i had a great time at the conference, and also got to tour a little bit of portland and taste the famous voodoo donuts.
my presentation at hashiconf was on how we at electric cloud have used some of hashicorp’s tools – orchestrated by our own electricflow – to create and share a reusable demo library across the organization from dev, qa and even sales. the overall pattern i spoke about was to find the business problem, determine the requirements and then find a solution that works. for each of the above tools we used, i explained how they addressed the business problem we had at the time, how we got buy-in from various stakeholders in the organization, and how we configured these tools as part of the overall solution.
hashiconf would publish the video recording of my talk soon (for now, help yourself to the slides on speaker deck – embedded below). in this post i would explain a bit how we used terraform for infrastructure as code (a similar outcome could have been achieved using chef or puppet.)
using terraform to bootstrap a wildfly cluster:
a wildfly cluster in domain mode requires some configuration between the domain and host controllers. our model is described in the picture below- where we deploy to the domain controller, and users are served off the different hosts.
deployment to wildfly cluster in domain mode
terraform allowed us to write a definition of what we desired, check it into source control and share it with all interested parties. (check out our code on github: https://gist.github.com/nikhilv/74a107af7e44866e3f14 )
after coding the terraform files, we can see a visual representation of the execution plan.
terraform execution plan
after using terraform, we appreciated the ability to reproduce the infrastructure, that allowed for fast experimentation while still preserving the building blocks that could be used in the future for other demos.
in order to keep a record of the changes that terraform makes, an operator should not use terraform directly to control production. instead, it needs to be executed within a tool that can keep track of history and allow users to accept or reject the proposed changes to infrastructure.
once terraform had created the infrastructure, we used electricflow to deploy applications to the wildfly cluster. one of the statements i made during the presentation that got a lot of responses was to be mindful of the way you use the ui to construct your process – since this work, usually, can not be re-used (with the exception of cloning). for example, terraform allows you to define as code a lot of the aws configuration that you’d normally input via the aws ui. this makes your configuration documented, checked-in to source control, and repeatable. similarly, for the same benefits, we were using our electricflow dsl for defining our process as code – so that our deployment and application processes are also in source control and are versioned and reusable. also, it allows us to clone/scale more quickly (since we only need to copy the code, versus using the ui).
thank you hashiconf for inviting me to speak, and thanks for the great conference and for this awesome jacket!
Published at DZone with permission of Nikhil Vaze, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.