Recently I was working on a project which includes Terraform and AWS stuff. While working on that I was using my local machine for terraform code testing and luckily everything was going fine. But when we actually want to test it for the production environment we got some issues there. Then, as usual, we started to dig into the issue and finally, we got the issue which was quite a silly one 😜. The production server Terraform version and my local development server Terraform version was not the same. After wasting quite a time on this issue, I decided to come up with a solution so this will never happen again. But before jumping to the solution, let’s think is this problem was only related to Terraform or do we have faced the similar kind of issue in other scenarios as well. Well, I guess we face a similar kind of issue in other scenarios as well. Let’s talk about some of the scenarios first. Suppose you have to create a CI pipeline for a project and that too with code re-usability. Now the pipeline is ready and it is working fine in your project and then after some time, you have to implement the same kind of pipeline for the different projects. Now you can use the same code but you don’t know the exact version of tools that you were using with the CI pipeline. This will lead you to error elevation. Let’s take another example, suppose you are developing something in any of the programming languages. Surely that utility or program will have some dependencies as well. While installing those dependencies on the local system, it can corrupt your complete system or package manager for dependency management. A decent example is which is a dependency manager of Python 😉. Pip These are some example scenarios which we have faced actually and based on that we got the motivation for writing this blog. The Solution To resolve all this problem we just need one thing i.e. . I can also say docker as well but container and docker are two different things. containers But yes for container management we use docker. So let’s go back to our first problem the terraform one. If we have to solve that problem there are multiple ways to solve this. But we tried it to solve this using Docker. As Docker says “ Build Once and Run Anywhere” So based on this statement what we did, we created a Dockerfile for required Terraform version and stored it alongside the code. Basically our Dockerfile looks like this:- alpine: OpsTree.com TERRAFORM_VERSION= . BASE_URL=https://releases.hashicorp.com/terraform opstree FROM 3.8 MAINTAINER ENV 0.11 10 ARG RUN apk add --no-cache curl unzip bash \
    && curl -fsSL -o /tmp/terraform.zip / /terraform_ _linux_amd64.zip \
    && unzip /tmp/terraform.zip -d /usr/bin/ ${BASE_URL} ${TERRAFORM_VERSION} ${TERRAFORM_VERSION} WORKDIR /opstree/terraform USER In this Dockerfile, we are defining the version of Terraform which needs to run the code. In a similar fashion, all other above listed problems can be solved using Docker. We just have to create a Dockerfile with exact dependencies that are needed and that same file can work in various environments and projects. To take it to the next level you can also dump a Makefile as well to make everyone's life easier. For example:- IMAGE_TAG=latest docker build -t opstree/terraform:${IMAGE_TAG} -f Dockerfile . docker run -itd --name terraform -v ~/.ssh:/root/.ssh/ -v ~/.aws:/root/.aws -v ${PWD}:/opstree/terraform opstree/terraform:${IMAGE_TAG} docker exec -t terraform bash -c docker exec -t terraform bash -c docker exec -t terraform bash -c build-image: run-container: plan-infra: "terraform plan" create-infra: "terraform apply -auto-approve" destroy-infra: "terraform destroy -auto-approve" And trust me after making this utility available the reactions of the people who will be using this utility will be something like this:- Now I am assuming you guys will also try to simulate the Docker in multiple scenarios as much as possible. There are a few more scenarios which yet to be explored to enhance the use of Docker if you find that before I do, please let me know. Thanks for reading, I’d really appreciate any and all feedback, please leave your comment below if you guys have any feedback. Cheers till the next time.

Alongside

Why GitOps is so exciting?

How To Create a Foolproof Shell Script

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Another Reason to Use Docker

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Why GitOps is so exciting?

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Using Kubernetes Network Policies

10 Best Practices for Every React Developer

12 Essential Coding Standards for Quality Web Development

Why GitOps is so exciting?

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Using Kubernetes Network Policies

10 Best Practices for Every React Developer

12 Essential Coding Standards for Quality Web Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps