astonishing-dentist-11149
03/15/2023, 1:45 PMawsx.ecs.FargateService
under FargateTaskDefinitionArgs
then under Container
you will see an option called Secrets. This type definition can be found under: <node>@pulumi/aws/ecs/container.d.ts/Secret
. On my file it is around line 198. I will also add my deps here as well so you can get the exact versions.
NOTE: I moved pulumi back down( this does not change anything in the code, .40 awsx is the same as 1.0.0 awsx/classic that we talked about yesterday.)
"dependencies": {
"@pulumi/pulumi": "^3.0.0",
"@pulumi/aws": "^5.0.0",
"@pulumi/awsx": "^0.40.0"
},
Secret interface definition.
export interface Secret {
/**
* The name of the secret.
*/
name: pulumi.Input<string>;
/**
* The secret to expose to the container. The supported values are either the full ARN of the
* AWS Secrets Manager secret or the full ARN of the parameter in the AWS Systems Manager
* Parameter Store.
*
* Note: If the AWS Systems Manager Parameter Store parameter exists in the same Region as the
* task you are launching, then you can use either the full ARN or name of the parameter. If the
* parameter exists in a different Region, then the full ARN must be specified.
*/
valueFrom: pulumi.Input<string>;
}
Previously we used this same concept of secrets inside a .ecs_taskdefinition yaml file and passed in a name and an ARN to a secret value from ssm. I am currently trying to move our infra to pulumi. (I am coming from python to typescript, so assume I know nothing about proper typescript)
To make things simple, I will refer to my two projects as infra (all of our share none service specific code goes here) and ms (service level pulumi code that is only meant for that service)
on infra we have one stack called base. In this stack a create base common shared secrets, that do not change from environment to environment. I create an ssm entry and set it to the value that is in my pulumi config, then I populate an array of aws.ecs.Secret
(mentioned above) with the name that I want the variable to be in the container (name) and the arn of the param. I then export this aws.ecs.Secret[]
for later stack reference.
I then do the exact same thing for the envSecrets in infra on the dev stack. These values are things like DB connection strings that need the same variable name in the container, but have different values per env. These values use the env name (dev, stage, prod) so the values can be different per environment. Then I export a similar aws.ecs.Secret[]
.
I now have two different stacks (base and dev) each with different secret arrays on infra.
On ms I then import that with a stack reference AS pulumi.Output<aws.ecs.Secret[])
I do this because later I have to use apply to merge the two arrays together. This is really messy and frankly bad code. It assumes that I will always be handed the proper data, I genericly hate using as
like this. And then merging the two arrays the way you have to is not ideal. I do it this way though because FargateTaskDefinitionArgs
/ Container
/ secrets
is expecting only the type of `pulumi.Input<aws.ecs.Secret[]>
const baseSecretArns = baseStackRef.getOutput('baseSecrets') as pulumi.Output<aws.ecs.Secret[]>; //Please don't do this.
const envSecretArns = envStackRef.getOutput(`envSecrets`) as pulumi.Output<aws.ecs.Secret[]>;
const secrets: pulumi.Output<aws.ecs.Secret[]> = pulumi
.all([baseSecretArns, envSecretArns])
.apply(([base, env]) => {
return base.concat(env);
});
The end goal, I would like to have both of the arrays combined on the infra side and stored as an export per environment (dev, stage, prod), that way when I do an env stack reference on ms I will get one big pulumi.Output<aws.ecs.Secret[]>
that I can just pass into secrets. So every environment will grab the base secrets array that has already been made and add it to their own array. The nice thing here is, when I do the stack reference I will not need to do the as, because pulumi can infere the type when I pass it in. So the code is cleaner and I can avoid that as statement on ms.
The challenge that I face is, on infra, when I cam creating the env variables on the dev stack, I can not find a good way to "import" the config values of the base stack. I think I can do a stack reference into my env stack and just pull the base secrets array in. However, that is going to give me a pulumi.Output<T> I am not sure how to pull T out, unless .apply is the right way to do that, then I will just do that. What I mean is, I can not combine pulumi.Output<aws.ecs.Secret[]> with aws.ecs.Secret[]. The type are not compatible.
I just thought about this though as I have typed all this out, I am going to have trouble when I update anything in the base stack, EVERY stack in my infra will need to run an update to pull the latest values....
I think I might just need a different way to think about this problem ultimately. Maybe a better route is to keep environment specific variables in ms. This will be annoying because if one of those env specific variables needs updated, like a DB connection string, it is going to have to be updated on every project.little-cartoon-10569
03/15/2023, 8:01 PMastonishing-dentist-11149
03/15/2023, 8:04 PMlittle-cartoon-10569
03/15/2023, 8:05 PMastonishing-dentist-11149
03/15/2023, 8:08 PMlittle-cartoon-10569
03/15/2023, 8:09 PMastonishing-dentist-11149
03/15/2023, 8:13 PMlittle-cartoon-10569
03/15/2023, 8:16 PMastonishing-dentist-11149
03/15/2023, 8:18 PMlittle-cartoon-10569
03/15/2023, 8:19 PMastonishing-dentist-11149
03/15/2023, 8:19 PMlittle-cartoon-10569
03/15/2023, 8:19 PMastonishing-dentist-11149
03/15/2023, 8:20 PMlittle-cartoon-10569
03/15/2023, 8:21 PMastonishing-dentist-11149
03/15/2023, 8:22 PMlittle-cartoon-10569
03/15/2023, 8:24 PMastonishing-dentist-11149
03/15/2023, 8:26 PMlittle-cartoon-10569
03/15/2023, 8:28 PM