I am trying to deploy multiple infra cloud formations through Jenkins and in one of the situations, there are two stacks in which one of the stacks is having a dependency on the other stack. As the deployment script will not be able to maintain the order. So how can I achieve it here in cloud formation
PS: Is there any way that the dependent stack will wait until the other stack got deployed. Here Jenkins can deploy multiple stacks in parallel.
Have you tried using the Stack resource type itself?
The AWS::CloudFormation::Stack type nests a stack as a resource in a
top-level template.
You can use that along with things like a WaitCondition or a DependsOn attribute to ensure that one resource is created before another, so you could have a parent Stack that creates two nested Stacks, where one depends on the other.
Related
I have an AWS Lambda "Application" which was created from an AWS Lambda app template. This in turn created two stacks. The serverlessrepo-??-toolchain stack and the Lambda Application stack that has the actual application...
I've done the development and added lambdas, permission, and such. Really evolved the template.yml and the buildspec.yml.
It all works and properly rebuilds the stack.
But in an AWS Lambda Application that is using CodeDeploy/CodePipeline, what is the best strategy for deploying additional environments? Let's assume the first one - the one made by the serverlessrepo-??-toolchain stack -- is Dev. How do I create a QA and Prod from my template.yml?
They need to be new stacks, yes? As in each environment is its own stack.
Thank you.
I've got a big-ass Serverless project and I wonder if matching the cloud formation template schema with CDK would do the trick, or is there something extra to the process.
It is possible to deploy a CDK app to an existing CloudFormation stack, although it would be very difficult to achieve for non-trivial stacks since CDK apps usually involve many resources.
The cdk diff command will be your best friend. You can name your stack in the CDK app using the same name as the existing stack:
MyExistingStack(app, 'my-existing-stack')
Then you can iteratively add/remove resources and run cdk diff to check your success in matching the current deployment. CDK will additionally create metadata resources that will be added to the stack in addition to the currently existing resources.
Matching resource names can be difficult. CDK automatically names many of the resources in a way that will not match you existing stack. Following the instructions on CDK Escape Hatches, you can access lower level CFN Resources directly and modify the name.
If a Construct is missing a feature or you are trying to work around an issue, you can modify the CFN Resource that is encapsulated by the Construct.
All Constructs contain within them the corresponding CFN Resource. For example, the high-level Bucket construct wraps the low-level CfnBucket construct. Because the CfnBucket corresponds directly to the AWS CloudFormation resource, it exposes all features that are available through AWS CloudFormation.
The basic approach to get access to the CFN Resource class is to use construct.node.defaultChild (Python: default_child), cast it to the right type (if necessary), and modify its properties.
I have more than 20 different services in AWS which are stacks defined in one main file (there are reference to template in .json), so these stacks are nested. Update of this stack is triggered by Codepipeline which is well configured with Github and production site. My problem is with during updating CF script because only main level resources are updated, unfortunately, I cannot see any changes which are linked with nested stacks. Why?
When using infrastructure as code tools like Terraform to create resources, what are the best practices for creating of one-off creation resources like VPCs and databases via an automated pipeline?
For example, when creating an Lambda function, we need to provide a VPC ID. This VPC ID can only be supplied if the VPC is already created via the Terraform. So should there be 2 different pipelines based on the resource type created? For one-off resources a separate pipeline which will be ideally only run once and another pipeline to create disposable resources?
If you're talking about general best practices for IaC (Infrastructure as Code), check out the following:
Codify everything.
Document as little as possible.
Maintain version control.
Continuously test, integrate, and deploy.
Make your infrastructure code modular.
Make your infrastructure immutable whenever possible.
I would recommend using AWS CloudFormation as it is free and provides you an interface to manage stacks and get visibility of the resources created. Also, it has the auto-rollback capability on the stack create or update failure.
This VPC ID can only be supplied if the VPC is already created via the Terraform. So should there be 2 different pipelines based on the resource type created?
Not really as you can use the VPC ID as a parameter to your AWS CloudFormation template or Terraform template.
For one-off resources a separate pipeline which will be ideally only run once and another pipeline to create disposable resources?
It is always better to have a separate stack for continuous deployment or disposable resources and a separate stack for one-off resources defining your base infrastructure.
I would like to make an automated call to a custom program API as soon as CloudFormation has completed the entire stack creation (deployment of instances, setup of VPC, Puppet scripts, etc.).
What is the correct way to go about this?
After some research, it seems a good option would be to launch an AWS Lambda function triggered by the event that stack creation has been completed successfully, but I have no idea how to approach this.
Any ideas or advice would be appreciated.
You can provision and coordinate a lot of what you're talking about (setup of VPC, etc.) with CloudFormation, the DependsOn attribute and nested CloudFormation stacks. This way you can order the execution of the CloudFormation stacks so that, for example, your VPC is created first followed by launching your EC2 instance(s) followed by the deployment of the software on the instance(s).
You can also coordinate the execution of the other behavior you mentioned (deployment [on] instances, [calling] Puppet scripts, etc.) using AWS::CloudFormation::Init. This way, you can call out to your Puppet scripts from your EC2 instance within the CloudFormation template. The actual execution of your Puppet scripts occurs on the EC2 instance(s).
If you want to see an example of calling out to a configuration management tool from CloudFormation (in this case, we're using Chef Solo), see app-instance.json.
If you'd like to see an example of using nested stacks, see dromedary-master.json.
There's also some examples of using Lambda on our blog as well (Stelligent), but it doesn't seem like you need to use Lambda in this case based on the problem you're trying to solve.
P.S. You don't have to use nested stacks either, but it can make things a little cleaner. But, you do want to control the creation order of the resources so the DependsOn attribute will help you in doing so.