Where are these infrastructure entries coming from in AWS SAM? - amazon-web-services

I'm learning SAM, and I created two projects.
The first one, example1, I created it from the AWS web console, by going to Lambda, Applications, and choosing this template:
After the wizard finishes creating the app, it looks like this:
I'm interested in the yellow-highlighted area because I don't understand it yet.
I tried to replicate this more or less manually by using sam init and created example2. It's easy to look at the template.yml it creates and see how the stuff in Resources are created, but how is the stuff in Infrastructure created.
When I deploy example2 with sam deploy --guided, indeed there's nothing in Infrastructure:
Given example2, how should I go about creating the same infrastructure as example1 had out of the box (and then changing it, for example, I want several environments, prod, staging, etc). Is this point and click in the AWS console or can it be done with CloudFormation?
I tried adding a permission boundary to example2, on of the things example1 has in Infrastructure, I created the policy in IAM (manually, in the console), added it to the template.yml, and deployed it but it didn't show up in "Infrastructure".

Part 1: In which I answer your question
Where are these infrastructure entries coming from in AWS SAM?
I replicated your steps in the Lambda console to create a "Serverless API Backend" called super-app. When you press create, AWS creates
two CloudFormation Stacks, each with a YAML template. You can view the stack resources and the YAML templates in the CloudFormation console under Stacks > Templates Tab.
super-app: the "Resources" stack with the lambda and dynamo resources you managed to replicate.
serverlessrepo-super-app-toolchain: the mystery stack with the "Infrastructure" CI/CD resources1.
Is this point and click in the AWS console or can it be done with CloudFormation?
Yes and Yes. You can use sam deploy (or aws cloudformation deploy) to update the stacks. Or point and click.
Example: update the serverlessrepo-super-app-toolchain template with the SAM CLI:
# compile
sam build -t cicd_template.yaml --region us-east-1 --profile sandbox
# send changes to the cloud
sam deploy --stack-name serverlessrepo-super-app-toolchain --capabilities CAPABILITY_NAMED_IAM --region us-east-1 --profile sandbox
You must pass in values for the template parameters at deploy-time. The current values for the parameters are in the console under CloudFormation > Stack > Parameters Tab. You can pass them using the --parameter-overrides param in the deploy command. If the
parameters are static, I find it easier to pass SAM parameter values in samconfig.toml, which sam deploy will use by default:
# samconfig.toml
version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
# template default parameters - fill in the template blanks
# Where do the values come from? the CloudFormation console, Parameters tab
AppId = "super-app"
AppResourceArns = "arn:aws:lambda:us-east-1:1xxxxxx:function..."
ConnectionArn = "arn:aws:codestar-connections:us-east-1:xxxxxx:connection/xxxx3c5c-f0fe-4eb9-8164-d3c2xxxxx6e2"
GitHubRepositoryOwner = "mygithuborg"
RepositoryName = "super-app"
SourceCodeBucketKey = "sample-apps/nodejs/14.x/javascript/sam/web-backend.zip"
SourceCodeBucketName = "prodiadstack-subsystemsn-apptemplatesbucket03axxx-96eem3xxxxxx"
UseCodeCommit = false
If there were changes made in the template, they will deploy. Success!
Part 2: In which I try to convince you to use the CDK instead
SAM and YAML templates are far from dead, but I think it's safe to say that for proficient developers starting out with AWS, the newer AWS Cloud Development Kit is a natural first choice for ambitious applications that need CI/CD and testing. For most of us, editing a 800-line YAML file is not a fun experience.
AWS Infrastructure-As-Code
There are lots AWS and 3rd Party IaaC tools to deploy infra on AWS. Each abstraction is best for somebody sometime. The important thing to remember is that no matter what higher-level IaaC toolset you use, it ends up being deployed as a CloudFormation template. Here are the AWS approaches, oldest to newest:
CloudFormation YAML2 templates
The OG, all-powerful, lowest-level approach is to hand-code YAML templates. The Cfn template reference
docs are indespensible no
matter what tool you use, because that's what gets deployed.
SAM YAML templates
With AWS SAM, you
still handcode YAML, but less3. A SAM template is a superset of CloudFormation with some higher-level abstractions for the main serverless components like Lambdas, DynamoDB tables and Queues. The SAM CLI compiles the SAM template to Cfn. It has nifty features like local testing and deploy conveniences.
Cloud Development Kit
The newest, shiniest IaaC approach is the CDK, now on V2. With the CDK, we write Typescript/Python/Java/etc. instead of YAML. The CDK CLI compiles your language code to Cfn and deploys with cdk deploy. It has a bigger set of high-level infra abstractions that goes beyond serverless, and escape hatches to expose low-level Cfn constructs for advanced use cases. It natively supports testing and CI/CD.
AWS CDK workshop including testing and pipelines. Lots of AWS CDK example apps.
Note that CloudFormation is the ultimate soure of this info. The lambda console makes a cloudformation.DescribeStack API call to fetch it.
YAML or JSON
SAM also has a marketplace-like repository with reusable AWS and 3rd party components

Edit :
If I understand correctly, you want to reproduce the deployment on the SAM app. If that's the case, there is an AWS sample that covers the same approach.
It seems you are using either CodeStar/CodeCommit/CodePipeline/CodeDeploy/Code... etc. from AWS to deploy your SAM application on example1.
At deploy time, these resources under infrastructure are created by the "Code" services family in order to authorize, instantiate, build, validate, store, and deploy your application to CloudFormation.
On the other hand, on example2, whenever you build your project in your local machine, both instantiation, build, validation, storage (of the upload-able built artifacts) are leveraged by your own device, hence not needed be provisioned by AWS.
To shortly answer your question: No. Your can't recreate these infrastructure resources on your own. But again, you wouldn't need to do so while deploying outside of AWS' code services.

Related

AWS Lambda Container deployment without SAM

Is this possible to deploy AWS Lambda Containers without using SAM.
Every article I found on internet is suggesting to use SAM to deploy.
As SAM is a wrapper on AWS cloud formation I want to use only cloud formation YAML to deploy lambda containers.
As you already know, you need to create a docker image of your lambda application and then push to AWS docker registry which is ECR, now there are several ways to deploy your lambda:
1- use AWS console, go into lambda in GUI choose "container image" in the options and provide ECR link (No cloudformation will be used this way)
2- create a SAM template and then use AWS CLI or AWS Console again to setup a cloudformation and SAM will be compiled to cloudformation later in the process.
3- directly create a cloudformation template and then use CLI or AWS console to deploy your lambda
4- use CDK to do your deployment
And maybe many other choices and methods. now depending on what exactly you want to do, ask for more specific detail.

Can we export Cloud Formation template from an existing VPC?

We have a VPC which contains all services and databases used for the testing. We are now planning to setup another such VPC, so that we can have an extra testing env.
Is there a way to export the CloudFormation template from the existing infrastructure ( VPC )?
Depends upon what all you want to clone/duplicate as well as to what level you would like to duplicate resources, you can look at following options;
Use deprecated CloudFomer which is part of AWS CFN, you can built templates from your existing resources. Not recommended, just putting in list in case your use-cases are meet with this with less efforts, time and money.
Use former2 a third party tool, which is more reliable than CloudFomer. Please refer this existing thread for more details.
Use N2WS, a third party partnered solution with AWS. Please refer this Blog from AWS.
Use CloudRanger, third party solution knows as Druva.
If the existing infrastructure were created using CloudFormation then you can just run the following command:
aws cloudformation get-template --stack-name myteststack
If not it's not possible because aws only uses cloudformation stacks visible for clients in products than you can change parameters after creation, like ECS.
You can export Cloud Formation template using Functionbeat which is Elastic Beat that we can deploy as a function in our serverless environment to collect data from cloud services. After configuring functionbeat use the following command to export the CloudFormation template.
For Linux and Mac ./functionbeat export function FUNCTION_NAME
For Windows .\functionbeat.exe export function FUNCTION_NAME
Functionbeat will write the CloudFormation template to standard output or stdout which you can modify if needed.

AWS CLI vs Console and CloudFormation stacks

Is there any known downside to creating resources on aws through the CLI? Is it more reliable/easier/error prone/largely accepted/recommended to use one method over the other? While setting up recurring scripts, is there a reason why i would want to use CloudFormation or the AWS Console over the AWS CLI to run commands directly?
For example, if I were to create an ECS Fargate Task Definition, is there any reason why I might want to use AWS CloudFormation or the Console over AWS CLI? Cli syntax is straightforward and easy to use, and there are a few things (like setting up event rules/targets for a fargate task specifically) that are not supported via cloudformation yet.
The AWS CLI and AWS CloudFormation are two different tools that can be used to create infrastructure on AWS. The CLI is more powerful and has finer grained control than CloudFormation. CloudFormation makes it very easy to use yaml or json text files that can describe an entire enterprise in the cloud.
One of the strong benefits of CloudFormation is the automatic support for rolling back changes if anything fails while deploying a stack. The CLI in comparison would require you to figure out the details of what went wrong and how to get back to where your state was. Updating infrastructure using CloudFormation is another benefit. Make the change in the template and update the stack.
For small setups, using the CLI is fine. However, once you get past launching an EC2 instance and start building VPCs, Instances, KeyPairs, Security Groups, RDS, etc. etc. you will find that the CLI has some real limitations: mostly being too manual of a process, not easily repeatable, difficult to put the process into version control, ....
If you are constantly building, testing and deleting complex setups, CloudFormation is absolutely one of the best tools from AWS. Note that there are a number of third party solutions that have a huge number of followers such as Bamboo, Octopus, Jenkins, Chef, etc.
If your job is SysOps or DevOps then you absolutely want to master the CLI and CloudFormation. These are amazing tools for working with AWS. Also master Beanstalk, maybe OpsWorks and one of the third party tools like Jenkins.

A way to automate cloudformation templates deployment

Is there any way to automate cloudformation templates deployment? I mean it would be awesome if I just push the changes in the code and somebody looking for those changes in the code and once they appear - deploy the updated template.
Yes, with AWS Code Pipeline !
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html
With AWS CloudFormation and AWS CodePipeline, you can use continuous delivery to automatically build and test changes to your AWS CloudFormation templates [...]
AWS CodePipeline has built-in integration with AWS CloudFormation, so you can specify AWS CloudFormation-specific actions, such as creating, updating, or deleting a stack, within a pipeline.
CodePipeline is a great way to do what you're looking for.
At Giftbit we do this is by having a Github Repo that has our CloudFormation template in it.
When we want to make a change, we make the changes on a branch in the repo, and create a pull request into the staging branch. CodePipeline monitors the staging branch then automates a CodeBuild to validate the templates, package any SubStacks, then creates a Change Set and Executes it.
Below are have some examples to help Quick Start anyone interested:
Continuous Integration CloudFormation Template Example
Serverless Application Model (SAM) that gets deployed

Export AWS configuration as CloudFormation template

I´m using AWS CLI and CloudFormation, and I could not find any reference in the documentation.
Does anybody know if it´s possible to create a CloudFormation template from a current configuration.
Let´s say that I want to get a CloudFormation template from my current security group configuration.
Any idea if it´s possible to export that configuration as a template using CLI?
Based on our experience we found 3 possible ways to translate existing manually deployed (from Web Console UI) AWS infra to Cloudformation (CF).
Using a new CloudFormation native introduced feature (since Nov 2019) that allows you to Import existing resources into a CloudFormation stack
Using aws cli execute $aws service_name_here describe for each element that make up your stack eg for RDS Database Stack:
RDS Instance -> Type: AWS::RDS::DBInstance,
RDS (EC2) SG -> Type: AWS::EC2::SecurityGroup,
RDS Subnet Group -> Type: AWS::RDS::DBSubnetGroup and
RDS DB Param Group -> Type: AWS::RDS::DBParameterGroup
And manually translate to CF based on the outputs obtained from the aws cli for each of the components. This approach usually requires more experience in both AWS and CF but the templates that you are creating can be structured and designed under good practices, fully parameterized (Sub, Ref, Join, Fn::GetAtt:, Fn::ImportValue), modular, applying conditions and in a 1st iteration the result would probably be close to the final state of the templates (interesting reference examples: https://github.com/widdix/aws-cf-templates/).
Extra points! :)
Some other new alternatives to export your current deployed AWS infra to Cloudformation / Terraform code:
https://former2.com
https://modules.tf
https://www.brainboard.co/
Related Article: https://medium.com/#exequiel.barrirero/aws-export-configuration-as-code-cloudformation-terraform-b1bca8949bca
It's not possible using the AWS CLI but you can use the CloudFormer [1] tool to create a CloudFormation template from existing resources. I've had decent success with it. The templates aren't as "pretty" as hand-made templates but they provide a good starting point.
[1] http://aws.amazon.com/developertools/6460180344805680
In addition to CloudFormer, you might want to take a look at Bellerophon: https://github.com/arminhammer/bellerophon.
I had some problems getting the tradidtional tools - mentioned above - working in our environment; we have a complicated API Gateway. Former2 didnt' find it at all (although seemed ideal for other resources)
I found another tool, "Terraformer" which extracts AWS into Terraform, which can then be turned into CloudFormation -or used directly as IaC.
https://github.com/GoogleCloudPlatform/terraformer#installation
Maybe that will work for others if the above tools don't.