- Newest
- Most votes
- Most comments
Hello,
I understand that you are trying to figure out how to set the DB_CONNECTION_STRING environment variable for a Fargate container.
If are using CDK to create ECS resources, then you should be able to pass environment variables to the container with your Task definition - https://docs.aws.amazon.com/cdk/api/v1/docs/@aws-cdk_aws-ecs.TaskDefinition.html
ECS allow you declare environment variables to be populated with secret values from SecretsManager. Since the secret values does not get evaluated until ECS is running the container, there is no good way to inject those values into another string, unless you do it from inside the container. Since MS SQL seems to want to use DB_CONNECTION_STRING containing these details, you would have to either have that connection string stored in secrets manager, or assemble the connection string at your end by generating it from the DBUSER and DBPASS values.
The links below would help shed light into how to achieve your use case - https://docs.aws.amazon.com/cdk/api/v1/docs/@aws-cdk_aws-rds.Credentials.html
I hope this information can help achieve your use case.
If the information above does not help, please open a support case with AWS using the following https://console.aws.amazon.com/support/home#/case/create and provide details on the code snippet and also please let us know if you are using CDK to create ECS resources in the support case.
It's not the creating the secret that is the issue, but transforming the secret to the connection string format that mssql wants. I would have liked that secret had a function that could take a format string ( for example "User Id={username};Password={password}") and generate the string when deploying the image to fargate. secrets = { CONNECTION_STRING=yourSecretObject.string_format("User Id={username};Password={password}") }
I'm sadly now building a new docker image based on the official docker image and generating a script that builds the connection string from environment variables and executing the original entrypoint command and then setting my custom script as the entrypoint. This causes the problem that I have to keep an eye that the original docker image do not change entrypoint between releases, which makes the whole solution less automated than one would like.
Relevant content
- asked 3 months ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
I'm not 100% sure I follow the issue you're facing - are you trying to build the connection string from secrets manager dynamically? If so, I see maybe a couple of options:
DB_CONNECTION_STRING="Server=${DB_HOST},144;Database=${DB_NAME}..."
But, I'm not sure if that's a bad idea or not. Ideally, you'd break up the reference in your config files to reference the individual values, and not a full string. So, essentially, #2 above, but you're doing that in your config file and not in the env vars. But I know that's not always a possibility.
@dozenyommer:
So that both DBUSER/DBPASS are set before DB_CONNECTION_STRING, it's worth a try at least.
The issue is that the docker image is an official image provide by the company who done the application, so I do not have a say on what variables can be used and I'm trying to avoid to make my own docker image based on that official docker image where I do build up the variable in the docker and then execute the binary, but sure I have to in worst case :(
@dozenyommer: Sadly the second suggestion of building the connection string from environment variables do not work, it will be literal as you wrote without any value substitutions. I guess I have to go the step and create a Dockerfile which based on the official package and try to build the connection string as a variable and start the application with the environment variable set.