<p>So let's imagine you have 20 microservices, each in a separate repository. Each microservice needs to be deployed into 5+ environments: dev local, dev cloud, test, staging, prod. Understandably all configuration will be different in each environment. However, you don't need to put it into the Dockerfile - in fact you don't put any configuration into the Dockerfile. Your app gets all required parameters from environment variables, or may be from a config file, if it gets too complex. </p>

<p>So you would have one Dockerfile per project, and if your developers need to spin it up locally, they will just use docker-compose, which has all environment variables set up, and maybe a config file mounted as volume. In stage envs the configuration will be totally different, but the Docker image will be the same. Your app will need to be able to read this configuration at start up time, and bail out early if something doesn't work.</p>

<p>Read <a href="https://12factor.net/config" rel="nofollow noreferrer">https://12factor.net/config</a> for some inspiration on how to configure your app.</p>

<p>Now, provisioning the infrastructure with Terraform would follow the same approach. You would have a generic module which provisions a set of some resources, and it would accept a bunch of parameters which would depend on environment. You can use <a href="https://www.terraform.io/docs/state/workspaces.html" rel="nofollow noreferrer">workspaces</a> to manage this quite easily.</p>

<p>As for the last question, large companies solve this with a CI/CD system. This can be Jenkins, or Spinnaker, or any of the other tools, whichever you prefer.</p>

CC BY-SA 4.0
2018-09-04T09:43:24.923Z
2018-09-04T13:25:02.347Z
2018-09-04T13:25:02.347Z
Alexander
<p>We have adopted Docker and Terraform as the foundation forour devOps.
We have a basic version of it up and running today.</p>

<p>Dockerfiles live in each projects git repository and Terraform files
are more centralized. </p>

<p>The number of projects we manage is increasing as do the number of environments, data seeding To make things more interesting we are also
moving toward splitting services up into microservices where that makes sense.</p>

<p>So for each project, we have options like:</p>

<ul>
<li>What destination are you targetting (dev local, dev cloud, test (several variations), staging prod)</li>
<li>What version / tag of the source code should it build from.</li>
<li>What data should be seeded? </li>
<li>Who should be notified?</li>
<li>What infrastructure should it use? (We want to be able to allow "prod infrastructure) to be available for developers to spin up in dev cloud for debugging and testing) (along with several other combination)</li>
</ul>

<p>There are a few other parameters we are considering and all in all the
number of possible permutations become very high. </p>

<p>There is no way we can cleanly keep order of that many Dockerfiles.</p>

<p>So I am looking for a tool that helps us keep track of all the different configurations and makes it easy to find them. </p>

<p>Ideally, inside my head, I am picturing a wizard-based web app, where you enter in the parameters and it executes the necessary scripts automagically. 
This would also contain logs of what has been done, what environments are running and a few other things.</p>

<p>So far I havent had much luck. 
I know a lot of companies must have solved it and I must be thinking about it
wrong, or there is a big opportunity here.</p>

<p>Is there such a tool? How do large companies solve this?</p>

CC BY-SA 4.0
2018-09-03T15:15:37.190Z
I don't get why you would need more dockerfiles than project, the project should build its container, release it as an artifact and then you deploy with needed services (each being an artifact also) in a specific environment, usually with a pipeline to promote from one environment to another.
Tensibai
CC BY-SA 4.0
2018-09-03T15:17:03.890Z
But if you want to keep a file based 'all in one' approach, I assume using templates is the way to go, how to write those templates is highly dependent on your needs and common ground between project and infrastructures
Tensibai
CC BY-SA 4.0
2018-09-03T18:52:43.507Z
Each project, can be deployed to any of lets say 5 different destinations where each destination can have different "hardware" setups, require different data seeding.
Development 4.0
CC BY-SA 4.0
2018-09-04T07:25:49.980Z
So the main process is the same and you just need different variables for those environments ?
Tensibai
CC BY-SA 4.0
2018-09-10T02:52:40.037Z
Nice to see you're using containers to deploy your IaC/terraform code. I think it's more about how you organize that IaC that will help you locate it. For example using a combination of repos per AWS account and extensive use of terraform modules. Also, the way you organize your CI/CD pipelines will help visually too.The way we do it is documented here https://docs.cloudposse.com/reference-architectures/introduction/
Erik Osterman
<docker><terraform><configuration-management>
How do you handle the huge number of possible permutations of Dockerfiles / Teraform files?
Development 4.0
# How do you handle the huge number of possible permutations of Dockerfiles / Teraform files?

(Asked by: username_0 on 2018-09-03)

We have adopted Docker and Terraform as the foundation forour devOps.
We have a basic version of it up and running today.

Dockerfiles live in each projects git repository and Terraform files
are more centralized.

The number of projects we manage is increasing as do the number of environments, data seeding To make things more interesting we are also
moving toward splitting services up into microservices where that makes sense.

So for each project, we have options like:

* What destination are you targetting (dev local, dev cloud, test (several variations), staging prod)
* What version / tag of the source code should it build from.
* What data should be seeded?
* Who should be notified?
* What infrastructure should it use? (We want to be able to allow "prod infrastructure) to be available for developers to spin up in dev cloud for debugging and testing) (along with several other combination)

There are a few other parameters we are considering and all in all the
number of possible permutations become very high.

There is no way we can cleanly keep order of that many Dockerfiles.

So I am looking for a tool that helps us keep track of all the different configurations and makes it easy to find them.

Ideally, inside my head, I am picturing a wizard-based web app, where you enter in the parameters and it executes the necessary scripts automagically.
This would also contain logs of what has been done, what environments are running and a few other things.

So far I havent had much luck.
I know a lot of companies must have solved it and I must be thinking about it
wrong, or there is a big opportunity here.

Is there such a tool? How do large companies solve this?

**Tags:** docker, terraform, configuration-management

> **Comments:**
> **username_1**: I don't get why you would need more dockerfiles than project, the project should build its container, release it as an artifact and then you deploy with needed services (each being an artifact also) in a specific environment, usually with a pipeline to promote from one environment to another.  
> **username_1**: But if you want to keep a file based 'all in one' approach, I assume using templates is the way to go, how to write those templates is highly dependent on your needs and common ground between project and infrastructures  
> **username_0**: Each project, can be deployed to any of lets say 5 different destinations where each destination can have different "hardware" setups, require different data seeding.  
> **username_1**: So the main process is the same and you just need different variables for those environments ?  
> **username_2**: Nice to see you're using containers to deploy your IaC/terraform code. I think it's more about how you organize that IaC that will help you locate it. For example using a combination of repos per AWS account and extensive use of terraform modules. Also, the way you organize your CI/CD pipelines will help visually too.The way we do it is documented here https://docs.cloudposse.com/reference-architectures/introduction/  

---

## 1 answers

### Answer by username_3 on 2018-09-04. Score: 5

So let's imagine you have 20 microservices, each in a separate repository. Each microservice needs to be deployed into 5+ environments: dev local, dev cloud, test, staging, prod. Understandably all configuration will be different in each environment. However, you don't need to put it into the Dockerfile - in fact you don't put any configuration into the Dockerfile. Your app gets all required parameters from environment variables, or may be from a config file, if it gets too complex.

So you would have one Dockerfile per project, and if your developers need to spin it up locally, they will just use docker-compose, which has all environment variables set up, and maybe a config file mounted as volume. In stage envs the configuration will be totally different, but the Docker image will be the same. Your app will need to be able to read this configuration at start up time, and bail out early if something doesn't work.

Read <https://12factor.net/config> for some inspiration on how to configure your app.

Now, provisioning the infrastructure with Terraform would follow the same approach. You would have a generic module which provisions a set of some resources, and it would accept a bunch of parameters which would depend on environment. You can use [workspaces](https://www.terraform.io/docs/state/workspaces.html) to manage this quite easily.

As for the last question, large companies solve this with a CI/CD system. This can be Jenkins, or Spinnaker, or any of the other tools, whichever you prefer.


---

