| `AWS_CLI_IMAGE` | the Docker image used to run AWS CLI commands| `amazon/aws-cli:latest`**it is highly recommended to set the CLI version compatible with your AWS server**|
| `AWS_CLI_IMAGE` | the Docker image used to run AWS CLI commands| `amazon/aws-cli:latest` |
| `AWS_BASE_APP_NAME` | Base application name | `$CI_PROJECT_NAME` ([see GitLab doc](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)) |
| `AWS_SCRIPTS_DIR` | Directory where AWS scripts (deploy & cleanup) are located | `.` _(root project dir)_ |
@@ -79,7 +84,7 @@ Here are some advices about your **secrets** (variables marked with a :lock:):
### Deployment and cleanup scripts
The GitLab CI template for AWS requires you to provide a shell script that fully implements your application
The AWS template requires you to provide a shell script that fully implements your application
deployment and cleanup using the [`aws` CLI](https://aws.amazon.com/cli/) and all other tools available in the selected Docker image.
#### Lookup policy
@@ -152,17 +157,19 @@ The static way can be implemented simply by setting the appropriate configuratio
To implement the dynamic way, your deployment script shall simply generate a `environment_url.txt` file, containing only
the dynamically generated url.
### Environments configuration
As seen above, the AWS template may support up to 4 environments (`review`, `integration`, `staging` and `production`).
#### Deployment output variables
Each deployment job produces _output variables_ that are propagated to downstream jobs (using [dotenv artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#artifactsreportsdotenv)):
*`environment_type`: set to the type of environment (`review`, `integration`, `staging` or `production`),
*`environment_name`: the application name (see below),
*`environment_url`: set to `$CI_ENVIRONMENT_URL`.
*`$environment_type`: set to the type of environment (`review`, `integration`, `staging` or `production`),
*`$environment_name`: the application name (see below),
*`$environment_url`: set to `$CI_ENVIRONMENT_URL`.
Those variables may be freely used in downstream jobs (for instance to run acceptance tests against the latest deployed environment).
### Environments configuration
They may be freely used in downstream jobs (for instance to run acceptance tests against the latest deployed environment).
As seen above, the AWS template may support up to 4 predefined environments (`review`, `integration`, `staging` and `production`).
Here are configuration details for each environment.
@@ -179,10 +186,10 @@ Here are variables supported to configure review environments:
Note: By default, review `environment.url` will be built as `${AWS_REVIEW_ENVIRONMENT_SCHEME}://${$CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}.${AWS_REVIEW_ENVIRONMENT_DOMAIN}`
Note: If you're managing your environment URLs statically, review environment URLs will be built as `${AWS_REVIEW_ENVIRONMENT_SCHEME}://${$CI_PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}.${AWS_REVIEW_ENVIRONMENT_DOMAIN}`
#### Integration environment
@@ -196,7 +203,7 @@ Here are variables supported to configure the integration environment:
| `AWS_INTEG_ENABLED` | AWS project ID for `integration` env | _none_ (disabled) |
| `AWS_INTEG_APP_NAME` | Application name for `integration` env | `${AWS_BASE_APP_NAME}-integration` |
| `AWS_INTEG_ENVIRONMENT_URL`| The integration environment url **including scheme**(ex: `https://my-application-integration.compute-1.amazonaws.com`). Do not use variable inside variable definition as it will result in a two level cascade variable and gitlab does not allow that. | _none_ |
| `AWS_STAGING_ENABLED` | AWS project ID for `staging` env | _none_ (disabled) |
| `AWS_STAGING_APP_NAME` | Application name for `staging` env | `${AWS_BASE_APP_NAME}-staging` |
| `AWS_STAGING_ENVIRONMENT_URL` | The staging environment url **including scheme**(ex: `https://my-application-staging.compute-1.amazonaws.com`). Do not use variable inside variable definition as it will result in a two level cascade variable and gitlab does not allow that. | _none_ |
| `AWS_PROD_ENABLED` | AWS project ID for `production` env | _none_ (disabled) |
| `AWS_PROD_APP_NAME` | Application name for `production` env | `$AWS_BASE_APP_NAME` |
| `AWS_PROD_ENVIRONMENT_URL`| The production environment url **including scheme**(ex: `https://my-application.compute-1.amazonaws.com`) Do not use variable inside variable definition as it will result in a two level cascade variable and gitlab does not allow that. | _none_ |
| `AWS_PROD_ENVIRONMENT_URL`| The production environment url (ex: `https://my-application.compute-1.amazonaws.com`).<br/>_For static environment URLs declaration_ | _none_ |
| `AUTODEPLOY_TO_PROD` | Set this variable to auto-deploy to production. If not set deployment to production will be `manual` (default behaviour). | _none_ (disabled) |
