<p>If you are going full on AWS, I would suggest to have a look at AWS SSM parameters. When EC2 or ECS container are starting, you have a script that is going to fetch the parameters. Then you can do whatever you need to do: replace variables in config files with the parameters fetched previously for example.
You could also use files stored in S3. You would be able to copy it and place it in the right application folder when your EC2 or ECS container are starting.</p>

CC BY-SA 4.0
2019-09-10T22:32:30.417Z
Yer I've decided ATM to use environment variables on my docker file then have them set in the task definition. Some of these values are set from the parameter store.
Matster2
CC BY-SA 4.0
2019-09-10T22:34:01.190Z
The thing that was holding me back originally with using environment variables is that it will mean if I debug using docker, I would have to set them, but I think it's a compromise
Matster2
CC BY-SA 4.0
2019-09-10T22:45:47.197Z
If you have them in the task def., it means your secrets (password) are in clear text, no?
Kaymaz
CC BY-SA 4.0
2019-09-11T06:44:28.983Z
Yes which is why I have some in the task definition and the rest which get it from the parameter store. Specifically my connection string, token secret
Matster2
CC BY-SA 4.0
2019-09-10T22:17:45.257Z
2019-09-10T22:17:45.257Z
Kaymaz
<p>So we have an asp.net core application we are hoping to start using with docker and host this all on aws.</p>

<p>We have multiple clients that we set up this project for, each with their own configuration settings, such as connection strings, application name, token secret, mailing server information, etc...</p>

<p>The problem we are going to have/are having, is how to make production configuration not built into the source code/docker whilst being accessible for multiple instances/containers that will need to use this on ECS/EC2.</p>

<p>So the idea we currently have, which i was hoping someone could check or suggest a better solution if there is one, is that we will build the container free of the specific configuration, then access the appSettings.production.json which we would mount from outside of the container. Because this would be on amazon it would be stored in EFS if capable or S3.</p>

<p>Is this possible and an appropriate solution?</p>

<p>Thanks</p>

CC BY-SA 4.0
2019-09-09T14:51:52.380Z
We have a few dotnet-core apps as well, deployed to EC2. We typically have a stage in the pipeline where Ansible is used to provision an image. If this is something that sounds acceptable to you, I could write it up as an answer.
Bruce Becker
CC BY-SA 4.0
2019-09-09T15:52:32.457Z
I am unfamiliar with ansible but I am unsure how this fits. I'm looking for configuration that is client instance specific. We have instance of applications that have app setting specific to that client. E.g. the connection string.
Matster2
CC BY-SA 4.0
2019-09-09T15:53:41.873Z
I'm not quite sure of another way other than mounting those setting onto some sort of storage the deployable instances can access.
Matster2
CC BY-SA 4.0
2019-09-09T15:54:35.853Z
I don't want any specific configuration for each client  production stored in the image (as it would lead to image per client)
Matster2
<docker><amazon-web-services><amazon-ecs>
AWS Production Configuration ASP.NET Core & Docker
Matster2
# AWS Production Configuration ASP.NET Core & Docker

(Asked by: username_0 on 2019-09-09)

So we have an asp.net core application we are hoping to start using with docker and host this all on aws.

We have multiple clients that we set up this project for, each with their own configuration settings, such as connection strings, application name, token secret, mailing server information, etc...

The problem we are going to have/are having, is how to make production configuration not built into the source code/docker whilst being accessible for multiple instances/containers that will need to use this on ECS/EC2.

So the idea we currently have, which i was hoping someone could check or suggest a better solution if there is one, is that we will build the container free of the specific configuration, then access the appSettings.production.json which we would mount from outside of the container. Because this would be on amazon it would be stored in EFS if capable or S3.

Is this possible and an appropriate solution?

Thanks

**Tags:** docker, amazon-web-services, amazon-ecs

> **Comments:**
> **username_1**: We have a few dotnet-core apps as well, deployed to EC2. We typically have a stage in the pipeline where Ansible is used to provision an image. If this is something that sounds acceptable to you, I could write it up as an answer.  
> **username_0**: I am unfamiliar with ansible but I am unsure how this fits. I'm looking for configuration that is client instance specific. We have instance of applications that have app setting specific to that client. E.g. the connection string.  
> **username_0**: I'm not quite sure of another way other than mounting those setting onto some sort of storage the deployable instances can access.  
> **username_0**: I don't want any specific configuration for each client  production stored in the image (as it would lead to image per client)  

---

## 1 answers

### Answer by username_2 on 2019-09-10. Score: 1

If you are going full on AWS, I would suggest to have a look at AWS SSM parameters. When EC2 or ECS container are starting, you have a script that is going to fetch the parameters. Then you can do whatever you need to do: replace variables in config files with the parameters fetched previously for example.
You could also use files stored in S3. You would be able to copy it and place it in the right application folder when your EC2 or ECS container are starting.

> **Comments:**
> **username_0**: Yer I've decided ATM to use environment variables on my docker file then have them set in the task definition. Some of these values are set from the parameter store.  
> **username_0**: The thing that was holding me back originally with using environment variables is that it will mean if I debug using docker, I would have to set them, but I think it's a compromise  
> **username_2**: If you have them in the task def., it means your secrets (password) are in clear text, no?  
> **username_0**: Yes which is why I have some in the task definition and the rest which get it from the parameter store. Specifically my connection string, token secret  

---

