When I changed AWS::ApiGateway::Method properties by AWS SAM template and deployed it. but I noticed that change was not reflected until I deploy API manually from AWS management console. I think it is because I didn't change the resource of AWS::ApiGateway::Deployment and AWS::ApiGateway::Stage on the template.(The deployment history of AWS::ApiGateway::Stage was not updated.)
How can I reflect the change when I trigger sam deploy?
No, you have to manually deploy the api from the console :) it's a limitation at the moment.
Related
am trying to create S3 bucket using serverless framework. but when I deploy, it's creating two buckets one with the name I have mentioned in the severless.yml file and another bucket.
serverless.yml
service: aws-file-upload-tos3
provider:
name: aws
runtime: nodejs12.x
stage: dev
region: us-east-2
lambdaHashingVersion: 20201221
custom:
fileUploadBucketName: ${self:service}-${self:provider.stage}-bucket
resources:
Resources:
FileBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: ${self:custom.fileUploadBucketName}
AccessControl: PublicRead
Buckets created are
why its creating two buckets like this
By default, serverless framework creates a bucket with a generated name like <service name>-serverlessdeploymentbuck-1x6jug5lzfnl7 to store your service's stack state.
Each successive version of your serverless app is bundled and uploaded by sls to the deployment bucket, and deployed from there.
I think you have some control over how sls does this if you use the serverless-deployment-bucket plugin.
By default, the Serverless Framework creates a number of things on your machine in order to deploy what you have configured in your serverles.yml. It then needs to make use of a service inside AWS called CloudFormation to actually create the resources you configured, like your S3 bucket. The best way to do this is to take the things it created on your machine and upload them to AWS to ensure that the deployment continues without interruption or issue and the best place to do that is S3.
So the Serverless Framework will always (by default) create its own S3 bucket entirely unrelated to what you configured as a location to store the files it generated on your AWS account, then point CloudFormation at it to build the things you configured to get built.
While you have some control over this deployment bucket there always needs to be one. And it is completely unrelated to the bucket you configured.
I am using CloudFormation with SAM to deploy a stack which contains:
S3 Bucket
Cognito
AWS::Serverless::Api
AWS::Serverless::Function (authorizers + microservices, Type: Api and endpoints of the API Gateway)
Log Groups
To deploy my stack, I first run aws cloudformation package to package the lambda and then run aws cloudformation deploy to deploy the generated stack. This is working.
My goal now is to be able to update a microservice without deploying the entire stack (not building authorizers and other microservices), similar to serverless deploy function in the Serverless framework. This should preferably be one reusable template that uses a macro or just replaces text in the file.
The problem I am facing with this:
Running aws lambda update-function-code requires the lambda to be redeployed
To redeploy the lambda I have to declare AWS::Serverless::Function. For the function to be part of the API Gateway, AWS::Serverless::Api must be declared as well.
Declaring AWS::Serverless::Api requires all the other functions to be defined or they will be removed from the API Gateway.
I feel like I am stuck here and have not found other options of achieving my goal.
Since you're using SAM, I'd recommend deploying and updating your application using the sam cli commands.
You can run
sam build
sam package
sam deploy
When you run sam deploy, it deploys your application, but all subsequent sam deploy commands will update your existing cloudformation stack with only the appropriate resources that need updating.
If you opt for keeping with the standard Cloudformation cli commands, you could use the aws cloudformation update-stack command so that you're not re-deploying an entire new stack.
Im creating API gateway stage using cloudformation.
ApiDeployment:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId: !Ref ExampleRestApi
StageName: dev
Here is the problem, Whenever I create a new API, I just need to deploy the stage using AWS console. is there any way that I can automate the deploy process so that no further console action is required.
When you define a Deployment resource like this, CloudFormation will create the deployment only on the first run. On the second run it will observe that the resource already exists and the CloudFormation definition did not change, so it won't create another deployment. To work around that, you can add something like a UUID/timestamp placeholder to the resource ID and replace it everytime before doing the CloudFormation update:
ApiDeployment#TIMESTAMP#:
Type: AWS::ApiGateway::Deployment
Properties:
RestApiId: !Ref ExampleRestApi
StageName: dev
This way you are still able to see your deployment history in the API Gateway console.
If you don't want to manipulate your template like this, you can also add a Lambda-backed Custom Resource to your CloudFormation stack. Using an AWS SDK, you can have the Lambda function automatically creating new deployments for you when the API was updated.
I've found berenbums response to be mostly correct, but there are a few things I don't like.
The proposed method of creating a resource like ApiDeployment#TIMESTAMP# doesn't keep the deployment history. This makes sense, since the old ApiDeployment#TIMESTAMP# element is being deleted and a new one is being created every time.
Using ApiDeployment#TIMESTAMP# creates a new deployment every time the template is deployed, which might be undesirable if the template is being deployed to create/update other resources.
Also, using ApiDeployment#TIMESTAMP# didn't work well when adding the StageDescription property. A potential solution is to add a static APIGwDeployment resource for the initial deployment (with StageDescription) and ApiDeployment#TIMESTAMP# for the updates.
The fundamental issue though, is that creating a new api gw deployment is not well suited for cloudformation (beyond the initial deployment). I think after the initial deployment, it's better to do an AWS API invocation to update the deployment (see https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-deployments.html).
In my particular case I created a small Ansible module to invoke aws apigateway create-deployment which updates an existing stage in one operation.
How would I go about automating the deployment of an AWS API Gateway via a Python script using Boto3? For example, if I have created a stage named "V1" in the AWS Console for API Gateway, how would I write a script to deploy that stage ("V1")?
The current process involves deploying the stage manually from the AWS Console and is not scriptable. For purposes of automation, I would like to have a script to do the same.
Consulting the Boto3 documentation, I see there's a method for creating a stage (http://boto3.readthedocs.io/en/latest/reference/services/apigateway.html#APIGateway.Client.create_stage), but none for deploying one.
If you want to stick with deploying via specific boto3 API calls, then you want to follow this rough sequence of boto3 API calls:
Use get_rest_apis to retrieve the API ID.
Possibly check if it's deployed already using get_deployments.
Use create_deployment to create the deployment. Use the stageName parameter to specify the stage to create.
Consider using create_base_path_mapping if needed.
Also consider using update_stage if you need to turn on something like logging.
To deploy a typical (API Gateway/Lambda) I would recommend AWS SAM, instead of writing own code.
It even supports Swagger and you can define your stages in SAM definition files.
e.g.
ApiGatewayApi:
Type: AWS::Serverless::Api
Properties:
StageName: v1
CacheClusterEnabled: true
CacheClusterSize: "0.5"
DefinitionUri: "swagger.yaml"
Variables:
[...]
[...]
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: ratings.handler
Runtime: python3.6
Events:
Api:
Type: Api
Properties:
Path: /here
Method: get
RestApiId: !Ref ApiGatewayApi
Deployment is easily integrable into CD pipelines using AWS CLI
aws cloudformation package \
--template-file path/example.yaml \
--output-template-file serverless-output.yaml \
--s3-bucket s3-bucket-name
aws cloudformation deploy \
--template-file serverless-output.yaml \
--stack-name new-stack-name \
--capabilities CAPABILITY_IAM
See also: Deploying Lambda-based Applications
Yes, your current way of creating and deploying the apis manually through the AWS browser console is not very scriptable, but pretty much anything you can click in the console can be done with the AWS cli. It sounds to me like you want an automated CI / CD pipeline. Once you figure out what commands you would run with the aws cli, just add them to your CI pipeline and you should be good to go.
But actually, there's an even easier way. Go to AWS Codestar. Click "create new project" and check "Web Service", "Python", and "AWS Lambda". As of today there's only one Codestar template that fits all three, so choose that one. This will scaffold a full CI / CD pipeline (AWS CodePipeline) with one dev environment, hooked up to a git project. I think would be a good way for you so you can leverage the dev-opsy automated deployment stuff without having to worry about setting up and maintaining this on top of your main project.
I'm working with AWS API Gateway and AWS Lambda. Often I face this type of error message when attempt to deploy API. The error message says to select a deployment stage. But I still selecting and trying to deploy! but same error occur!
In this API I have multiple resources with multiple methods. Previously I succeed to deploy this same API with the same way. But now I can't deploy it.
Please anyone help me to fix it. For addition: I don't use AWS CLI tool, just use AWS web dashboard.
I talked with customer service center of AWS. The problem was:
In this API there was an unintegrated method. Suppose there are a resource image and I create a POST method for this resource. But I forgot to integrate it to any AWS Lambda Function or HTTP. So the API cannot be deployed.
If the method is unnecessary then delete the method. OR you can integrate it as Mock endpoint. You can change this endpoint anytime.
Note: For this unintegration problem AWS gives this type of wrong error message. They should update their message to save developer's time.
I was getting same error but when creating API using CloudFormation.
It turned out that in my AWS::ApiGateway::Deployment resource, I needed to include DependsOn attribute that "depends" on all my API methods.
For example, when building API with two AWS::ApiGateway::Method resources, AWS::ApiGateway::Deployment needs to depend on both these methods:
MyFirstApiMethod:
Type: AWS::ApiGateway::Method
Properties:
<your properties>
MySecondApiMethod:
Type: AWS::ApiGateway::Method
Properties:
<your properties>
MyDeployment:
Type: AWS::ApiGateway::Deployment
DependsOn: [MyFirstApiMethod, MySecondApiMethod] # <-- REQUIRED
Properties:
RestApiId: !Ref MyRestApi
Without the DependOn attribute on all the API methods, CloudFormation may be
creating them after the deployment resource, resulting in No integration defined for method error.
If you have another resource which is not completed to configuration it will read as well. In short, if you haven't given them a lambda function, the api itself is not allowed to be deployed until you finish the rest.
I encountered the same error with deploying via Terraform. The reason was I defined an IAM role for my API and I didn't include the role resource to triggers when deploying the API. Just make sure all resources that are defined before deploying are included in triggers.
Just integrate Lambda function in every method you created.
Make sure every resource and method is configured properly.
Let's say your api-gateway is hierarchy is like:
/
R1
R2
M1
M2
R3
M3
so every resource(R1,R2,R3) and every method(M1,M2,M3) should be configured properly.
I deployed using CDK with --no-rollback (this should work for any cloudformation though)
In my case, the API was created and I could inspect it in the AWS Console, and only the "AWS::ApiGateway::Deployment" failed to create. It turns out I had a bad value for service attribute (I was using StepFunctions, which was not working)
THEN I see that I have a dangling resouce/method that is broken - so my deployment was failing due to garbage in AWS, not my CDK/template.