Rubendob
Rubendob

Reputation: 1704

Dockerized terraform and tfstate

I have this docker container to run terraform.

alias terraform='docker run -i -t -v ~/.aws:/root/.aws:ro -v $(pwd):/app -w /app/ rubendob/terraform:0.11.8'

is just a copy of the official terraform image. Nothing fancy.

FROM golang:alpine
MAINTAINER "HashiCorp Terraform Team <[email protected]>"

ENV TERRAFORM_VERSION=0.11.8

RUN apk add --update git bash openssh

ENV TF_DEV=true
ENV TF_RELEASE=true

WORKDIR $GOPATH/src/github.com/hashicorp/terraform
RUN git clone https://github.com/hashicorp/terraform.git ./ && \
    git checkout v${TERRAFORM_VERSION} && \
    /bin/bash scripts/build.sh

RUN rm -rf /var/lib/apt/lists/*

WORKDIR $GOPATH
ENTRYPOINT ["terraform"]

So I called this way:

alias terraform='docker run -i -t -v ~/.aws:/root/.aws:ro -v $(pwd):/app -w /app/ rubendob/terraform:0.11.8'

Then I have the next folder structure and it was working ok since ups, I decided to run some terraform stuff in the dev folder.

ls -ls tf
total 0
0 drwxr-xr-x  3 ruben.ortiz  staff   96 15 sep 23:43 dev
0 drwxr-xr-x  6 ruben.ortiz  staff  192 11 sep 19:53 modules
0 drwxr-xr-x  4 ruben.ortiz  staff  128 15 sep 12:39 prod

I ran the container like

terraform plan tf/prod/

and worked ok but container created then the .terraform folder with tfstate, and other stuff.

So if I want to run the same command but to dev environment simply cannot because it detects and previous .terraform folder

ls -lisah tf/.terraform/
total 8
901814 0 drwxr-xr-x   5 ruben.ortiz  staff   160B 15 sep 12:38 .
885805 0 drwxr-xr-x   6 ruben.ortiz  staff   192B 15 sep 23:54 ..
901815 0 drwxr-xr-x  15 ruben.ortiz  staff   480B 16 sep 00:05 modules
901821 0 drwxr-xr-x   3 ruben.ortiz  staff    96B 10 sep 23:02 plugins
901819 8 -rw-r--r--   1 ruben.ortiz  staff   567B 16 sep 18:43 terraform.tfstate

And if I enter into the dev folder, as I just set up a volume to the current directory it is not able to see the shared modules folder.

How do you do guys to workaround this?

Thanks!

Upvotes: 0

Views: 1827

Answers (1)

Henry Dobson
Henry Dobson

Reputation: 212

I have to agree with the comments here. I would encourage you to re-evaluate the benefits you are gaining from this process.

That being said, the reason it’s causing conflicts is because you are trying to invoke 2 different workspaces from a common directory. You can avoid this by overriding the working directory when you enter the container (see https://docs.docker.com/engine/reference/run/#workdir) or simply changing directory to the correct context.

I would also suggest you try an alternative to managing environments using different workspaces.

  1. Don’t use folders to manage your IaC environments. This leads to drift as there’s no common template for your infrastructure.
  2. Do use a single workspace and variables to control environment specifications. Example: Write your modules so that when you change the environment variable (var.stage is popular) the plan alters to fit your requirements. Typically the environments should vary as little as possible with quantity, exposure and capacity usually being the variable configurations. Dev might deploy 1 VM with 1 core and 1GB RAM in private topology but production may be 3 VMs with 2 cores and 4GB RAM with additional public topology. You can of course have more variation: dev may run database process on the same server as the application to save cost but production may have a dedicated DB instance. All of this can be managed by changing a single variable, ternary statements and interpolation.

Upvotes: 3

Related Questions