Pass CloudFormation Parameters to "cdk deploy"

[gmiano]

Hi,
I already use aws-cdk to create a CloudFormation that represents my infrastructure.

I would like to use CDK Toolkit for Continuous Integration in order to Deploy stack updates.
Unfortunately the stack I am working with contains CloudFormation Parameters and I have not found a way to pass Parameters values yet?

Is there a way, not documented, to achieve this purpose? Are you to integrate this feature in the near future?

Best regards,
Giuseppe.

[RomainMuller]

Hey @gmiano we don't currently provide a way to pass parameter values during the deployment. It is something e have considered, but generally speaking we'd advise to make your templates as concrete as possibly by using context instead of parameters.

If that's something you can share with us here, I'd like to know more of what you're using parameters for, and what your Continuous Integration solution is. That would help us determine the best way forward.

[gmiano]

Hi @RomainMuller,
In my case we use CF Parameter variables to inject configuration within cloudformation on deploy time rather than during build time using context variables.

During a release canvas a specific version of the CloudFormation is built and deployed within an artifactory server.
We also have an Ansible playbook that downloads these artifacts and deploy the CF and related assets and passes customizable parameters.

[john-shaskin]

We've got kind of a similar process we're trying to implement. Currently, we're using troposphere-based tools to generate a CloudFormation artifact to pass into CodePipeline, and deploy with a CloudFormation action. This artifact contains:

1. A single set of CloudFormation templates to represent each independently deployable stack needed by a service.
2. For each deployment environment, a set of JSON configuration files containing CloudFormation parameter values and tags, to use when deploying each stack to that environment.

We're liking the concept of reusable constructs in CDK as well as the option to use other languages for managing CloudFormation, but are not sure if its possible to use it to synthesize the same kind of deployment artifact. It seems like we would need to:

1. Instantiate all the environment-specific stacks with their appropriate configuration at the root app level.
2. Use a CodeBuild step or a Lambda that would execute the CDK deploy command(s) in the pipeline, passing in the set of stacks to deploy for a given environment.

Am I correct, or is there a way that we could continue to produce the same kind of artifact we currently are?

[john-shaskin]

@RomainMuller, saw your stackoverflow reply to a very similar question. We will look at trying that approach.

[brettswift]

My use case is similar to those above, but I can add a couple of points.

The main difference I see by not being allowed this at deployment time is split into some pros/cons:

Pros of forcing params at build time:

• Your code can output a more concise template. Include resources or omit them, or change them.
  • Essentially less need (or no need) for the painful cloudformation conditionals.

Cons:

• in a CD workflow, you have to run a build step as well now, and then a deploy. This isn't so aweful.
• because you have to run a build at deploy time, you lose the capability of comparing templates in prod and nonprod.
• If you find something is broken in prod, but works in dev.. now you have a slightly bigger radius to search for your issue. You also have another scenario to test (possibly) in non prod.

All in all - I kind of agree with the 'build time only' parameters because of the simplicity, and because I can still mitigate the Cons I listed. However, I can think of (and can read on this post) a few use cases where I'd want deploy time params.

The biggest use case as pointed out here: (#169 (comment)), is helping to increase adoption rates of CDK.

I don't know if allowing for deployment parameters would weaken CDK. And if not, maybe it should support deploy time parameters. Let the user decide which approach is best (with the advice of a well written best practices document to guide them :) )

Just my 2 bit ($CAD)

[SomayaB]

@fulghum Is this still relevant/should this still be p0?

[jderose9]

This certainly seems relevant to me. It is a necessity to be able to generate a single cdk synth output during my application build phase that can be deployed to as many environments as needed.

[john-tipper]

I'd second @jderose9's requirement. I want to be able to define a stack of resources that will be created for a tenant on a SaaS I'm working on. I want to apply this stack for each tenant, so that all tenants have an identical set of resources. I would prefer to supply parameters to a known-good version of cdk synth, rather than re-build for each tenant.

[geekybaiyi]

this is still very relevant.
anyone has any alternative until this get implemented?
thx

[geekybaiyi]

Hey @gmiano we don't currently provide a way to pass parameter values during the deployment. It is something e have considered, but generally speaking we'd advise to make your templates as concrete as possibly by using context instead of parameters.

just would like to make sure that using context is the preferred approach ?

[gmiano]

Hi @geekybaiyi that solution is not compliant with corporate requirements of reproducibility of deploy in different environments. We moved to terraform that allows us to apply the behaviour we expect.

[manast]

I am a bit confused about how the codepipeline can be used to deploy fargate services if we cannot pass parameters from the pipeline to the template at deploy time.
For instance, in the build step I am building a docker image, that image is uploaded to a ECR repository and tagged. In the deploy step I want to use that particular image, however I have no means to pass that value to the template.
I thought that a workaround would be to use "latest" as tag, however this does not work, because cloudformation does not update a stack if the template itself has not changed (or any of its input paramters have changed).
Any suggestions on what is AWS recommended approach for solving an scenario like this?

[manast]

@RomainMuller sorry for tagging you, but you requested some information to the poster and it seems that you forgot to give any feedback.

[skinny85]

@manast I'm not sure where you got "we cannot pass parameters from the pipeline to the template at deploy time.", but that is not true. The parameterOverrides property of the CloudFormation deployment CodePipeline actions allows you to do that. We have an example using it for Lambda deployments here: https://docs.aws.amazon.com/cdk/latest/guide/codepipeline_example.html

Thanks,
Adam

[skinny85]

@manast can you look at this example? It uses an older version of the CDK (0.31.0), but it does what you're looking for: it builds a Docker image in a CodeBuild project, pushes it to an ECR repository, and then deploys the image with CloudFormation, all within a CodePipeline.

Now, there is one important element in that example that is missing from the main library: this special ecs.ContainerImage implementation that allows you to "late-bind" the image used for an ECS service (with a CloudFormation parameter). If you confirm that this does what you're looking for, I'll open a PR adding it to our main Construct Library.

[manast]

@skinny85 yes, this is exactly what I was looking for. And actually the implementation of the PipelineContainerImage is precisely the part of the code that I find more difficult to understand. I am used to use parametersOverride in CF and just pass to standard parameters, but in this case it seems it is using SSM which confuses me a bit.

[skinny85]

I'm not sure where you got the idea that PipelineContainerImage uses SSM... I can assure you it uses CloudFormation parameters.

[manast]

I got it from here: https://github.com/rix0rrr/cdk-ecs-demo/blob/master/lib/pipeline-container-image.ts#L8
And https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-ssm.CfnParameter.html
"A CloudFormation AWS::SSM::Parameter"

[skinny85]

OK. There is more than one class called CfnParameter :).

The one you linked to is an auto-generated class for the SSM Parameter resource - our convention for the auto-generated classes is to prefix them with Cfn (for example, CfnBucket is the auto-generated class for the S3 bucket resource). SSM has a resource called Parameter, hence CfnParameter. That class resides in the @aws-cdk/aws-ssm package.

The CfnParameter class used in PipelineContainerImage is from the @aws-cdk/core package (you can see it by the import: import cdk = require('@aws-cdk/cdk');, which is what the core package used to be called in version 0.31.0, and the usage: private parameter?: cdk.CfnParameter;). This is a link to its documentation: https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_core.CfnParameter.html

Does this clear things up?

[skinny85]

@manast do you want me to add the PipelineContainerImage from above to the CDK library - will it fix your problem?

[manast]

@skinny85 I would need to revisit that code again since it has passed some weeks now and i do not remember all the details anymore.

[ghost]

We have had the same issues, where we would like to be able to pass parameters to CloudFormation with cdk deploy. So I have made a pull request with something that we have found to work for us. Please let me know if this could work.