Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-09-10T22:32:30.417Z
Answers: 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.
Answers: Matster2
Answers: CC BY-SA 4.0
Answers: 2019-09-10T22:34:01.190Z
Answers: 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
Answers: Matster2
Answers: CC BY-SA 4.0
Answers: 2019-09-10T22:45:47.197Z
Answers: If you have them in the task def., it means your secrets (password) are in clear text, no?
Answers: Kaymaz
Answers: CC BY-SA 4.0
Answers: 2019-09-11T06:44:28.983Z
Answers: 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
Answers: Matster2
Answers: CC BY-SA 4.0
Answers: 2019-09-10T22:17:45.257Z
Answers: 2019-09-10T22:17:45.257Z
Answers: Kaymaz
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-09-09T14:51:52.380Z
Comments: 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.
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2019-09-09T15:52:32.457Z
Comments: 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.
Comments: Matster2
Comments: CC BY-SA 4.0
Comments: 2019-09-09T15:53:41.873Z
Comments: I'm not quite sure of another way other than mounting those setting onto some sort of storage the deployable instances can access.
Comments: Matster2
Comments: CC BY-SA 4.0
Comments: 2019-09-09T15:54:35.853Z
Comments: I don't want any specific configuration for each client  production stored in the image (as it would lead to image per client)
Comments: Matster2
Tags: <docker><amazon-web-services><amazon-ecs>
Title: AWS Production Configuration ASP.NET Core & Docker
UserDisplayName: Matster2
ThreadText: # 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  
  
  ---
  
  