|
| 1 | + |
| 2 | +FAQ |
| 3 | +=== |
| 4 | + |
| 5 | +Frequently Asked Questions |
| 6 | + |
| 7 | +.. contents:: |
| 8 | + :local: |
| 9 | + |
| 10 | +How to manage multiple environments? |
| 11 | +------------------------------------ |
| 12 | + |
| 13 | + *Terminology clarification: Environment and Stage can normally be used interchangeably but since AWS API Gateway relies on a concrete concept of Stages we'll use the term Environment here to avoid confusion.* |
| 14 | + |
| 15 | +**We recommend a one-to-one mapping of environment to Cloudformation Stack.** |
| 16 | + |
| 17 | +This means having a separate CloudFormation stack per environment, using a single template file with a dynamically set target stack via the ``--stack-name`` parameter in the ``aws cloudformation deploy`` command. |
| 18 | + |
| 19 | +For example, lets say we have 3 environments (dev, test, and prod). |
| 20 | +Each of those would have their own CloudFormation stack — `dev-stack`, `test-stack`, `prod-stack`. Our CI/CD system will deploy to `dev-stack`, `test-stack`, and then `prod-stack` but will be pushing one template through all of these stacks. |
| 21 | + |
| 22 | +This approach limits the 'blast radius' for any given deployment since all resources for each environment are scoped to a different CloudFormation Stack, so we will never be editing production resources on accident. |
| 23 | + |
| 24 | +If we need to bring up separate stacks for different reasons (multiple region deployments, developer/branch stacks) it will be straightforward to do so with this approach since the same template can be used to bring up and manage a new stack independent of any others. |
| 25 | + |
| 26 | +In cases where you need to manage different stages differently this can be done through a combination of Stack Parameters, Conditions, and Fn::If statements. |
| 27 | + |
| 28 | +How to enable API Gateway Logs |
| 29 | +------------------------------ |
| 30 | + |
| 31 | +Work is underway to make this functionality part of the SAM specification. Until then a suggested workaround is to use the ``aws cli update-stage`` command to enable it. |
| 32 | + |
| 33 | +.. code-block:: console |
| 34 | +
|
| 35 | + aws apigateway update-stage \ |
| 36 | + --rest-api-id <api-id> \ |
| 37 | + --stage-name <stage-name> \ |
| 38 | + --patch-operations \ |
| 39 | + op=replace,path=/*/*/logging/dataTrace,value=true \ |
| 40 | + op=replace,path=/*/*/logging/loglevel,value=Info \ |
| 41 | + op=replace,path=/*/*/metrics/enabled,value=true |
| 42 | +
|
| 43 | +The command above can be run as a post deployment CI step or it could be triggered by a `custom resource <https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html/>`_ within the same CloudFormation template. |
| 44 | + |
| 45 | +Please note that in either case you will see metric gaps between the time CloudFormation updates API Gateway and the time this command runs. |
0 commit comments