debian-mirror-gitlab/doc/ci/cloud_deployment/index.md

331 lines
15 KiB
Markdown
Raw Normal View History

2020-03-13 15:44:24 +05:30
---
2020-05-24 23:13:21 +05:30
stage: Release
2021-02-22 17:27:13 +05:30
group: Release
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-03-13 15:44:24 +05:30
type: howto
---
2021-10-27 15:23:28 +05:30
# Cloud deployment **(FREE)**
2020-03-13 15:44:24 +05:30
2020-06-23 00:09:42 +05:30
Interacting with a major cloud provider may have become a much needed task that's
2021-01-03 14:25:43 +05:30
part of your delivery process. With GitLab you can
[deploy your application anywhere](https://about.gitlab.com/stages-devops-lifecycle/deploy-targets/).
2021-03-08 18:12:59 +05:30
For some specific deployment targets, GitLab makes this process less painful by providing Docker
images with the needed libraries and tools pre-installed. By referencing them in your
CI/CD pipeline, you can interact with your chosen cloud provider more easily.
2020-03-13 15:44:24 +05:30
## AWS
2020-07-28 23:09:34 +05:30
GitLab provides Docker images that you can use to [run AWS commands from GitLab CI/CD](#run-aws-commands-from-gitlab-cicd), and a template to make
2020-06-23 00:09:42 +05:30
it easier to [deploy to AWS](#deploy-your-application-to-the-aws-elastic-container-service-ecs).
2021-04-17 20:07:23 +05:30
### Quick start
If you're using GitLab.com, see the [quick start guide](ecs/quick_start_guide.md)
for setting up Continuous Deployment to [AWS Elastic Container Service](https://aws.amazon.com/ecs/) (ECS).
2020-06-23 00:09:42 +05:30
### Run AWS commands from GitLab CI/CD
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31167) in GitLab 12.6.
2020-03-13 15:44:24 +05:30
2021-02-22 17:27:13 +05:30
The GitLab AWS Docker image provides the [AWS Command Line Interface](https://aws.amazon.com/cli/),
2020-03-13 15:44:24 +05:30
which enables you to run `aws` commands. As part of your deployment strategy, you can run `aws` commands directly from
2021-02-22 17:27:13 +05:30
`.gitlab-ci.yml` by specifying the [GitLab AWS Docker image](https://gitlab.com/gitlab-org/cloud-deploy).
2020-03-13 15:44:24 +05:30
Some credentials are required to be able to run `aws` commands:
1. Sign up for [an AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html) if you don't have one yet.
1. Log in onto the console and create [a new IAM user](https://console.aws.amazon.com/iam/home#/home).
1. Select your newly created user to access its details. Navigate to **Security credentials > Create a new access key**.
2021-02-22 17:27:13 +05:30
NOTE:
2021-03-08 18:12:59 +05:30
A new **Access key ID** and **Secret access key** are generated. Please take a note of them right away.
2020-03-13 15:44:24 +05:30
2021-04-17 20:07:23 +05:30
1. In your GitLab project, go to **Settings > CI/CD**. Set the following as
2021-09-30 23:02:18 +05:30
[CI/CD variables](../variables/index.md)
2020-06-23 00:09:42 +05:30
(see table below):
2020-03-13 15:44:24 +05:30
2020-06-23 00:09:42 +05:30
- Access key ID.
- Secret access key.
- Region code. You can check the [list of AWS regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).
You might want to check if the AWS service you intend to use is
[available in the chosen region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
2021-03-11 19:13:27 +05:30
| Environment variable name | Value |
|:-------------------------------|:-----------------------|
| `AWS_ACCESS_KEY_ID` | Your Access key ID |
| `AWS_SECRET_ACCESS_KEY` | Your Secret access key |
| `AWS_DEFAULT_REGION` | Your region code |
2020-03-13 15:44:24 +05:30
2021-11-18 22:05:49 +05:30
NOTE:
When you create a variable it's set to be [protected by default](../variables/index.md#protect-a-cicd-variable). If you want to use the `aws` commands on branches or tags that are not protected, make sure to uncheck the **Protect variable** checkbox.
2020-03-13 15:44:24 +05:30
1. You can now use `aws` commands in the `.gitlab-ci.yml` file of this project:
2020-05-24 23:13:21 +05:30
```yaml
2020-03-13 15:44:24 +05:30
deploy:
stage: deploy
2020-11-24 15:15:51 +05:30
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest # see the note below
2020-03-13 15:44:24 +05:30
script:
- aws s3 ...
- aws create-deployment ...
```
2021-02-22 17:27:13 +05:30
NOTE:
2020-06-23 00:09:42 +05:30
The image used in the example above
2020-04-22 19:07:51 +05:30
(`registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest`) is hosted on the [GitLab
2020-03-13 15:44:24 +05:30
Container Registry](../../user/packages/container_registry/index.md) and is
2020-06-23 00:09:42 +05:30
ready to use. Alternatively, replace the image with one hosted on AWS ECR.
2020-03-13 15:44:24 +05:30
2020-06-23 00:09:42 +05:30
### Use an AWS Elastic Container Registry (ECR) image in your CI/CD
2020-03-13 15:44:24 +05:30
2020-06-23 00:09:42 +05:30
Instead of referencing an image hosted on the GitLab Registry, you can
reference an image hosted on any third-party registry, such as the
2020-03-13 15:44:24 +05:30
[Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/).
2020-06-23 00:09:42 +05:30
To do so, [push your image into your ECR
repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html).
Then reference it in your `.gitlab-ci.yml` file and replace the `image`
path to point to your ECR image.
2020-04-08 14:13:33 +05:30
2020-06-23 00:09:42 +05:30
### Deploy your application to the AWS Elastic Container Service (ECS)
2020-04-08 14:13:33 +05:30
2020-10-24 23:57:45 +05:30
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207962) in GitLab 12.9.
> - The `Deploy-ECS.gitlab-ci.yml` template was [moved](https://gitlab.com/gitlab-org/gitlab/-/issues/220821) to `AWS/Deploy-ECS.gitlab-ci.yml` in GitLab 13.2.
2020-04-08 14:13:33 +05:30
2021-09-30 23:02:18 +05:30
GitLab provides a series of [CI templates that you can include in your project](../yaml/index.md#include).
2020-04-08 14:13:33 +05:30
To automate deployments of your application to your [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AWS ECS)
2020-10-24 23:57:45 +05:30
cluster, you can `include` the `AWS/Deploy-ECS.gitlab-ci.yml` template in your `.gitlab-ci.yml` file.
2020-04-08 14:13:33 +05:30
2021-11-11 11:23:49 +05:30
GitLab also provides [Docker images](https://gitlab.com/gitlab-org/cloud-deploy/-/tree/master/aws) that can be used in your `.gitlab-ci.yml` file to simplify working with AWS:
2020-07-28 23:09:34 +05:30
- Use `registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest` to use AWS CLI commands.
- Use `registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest` to deploy your application to AWS ECS.
2020-04-08 14:13:33 +05:30
Before getting started with this process, you need a cluster on AWS ECS, as well as related
2021-12-11 22:18:48 +05:30
components, like an ECS service, ECS task definition, a database on Amazon RDS, and so on.
2020-04-08 14:13:33 +05:30
[Read more about AWS ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html).
2020-10-24 23:57:45 +05:30
The ECS task definition can be:
- An existing task definition in AWS ECS
- A JSON file containing a task definition. Create the JSON file by using the template provided in
the [AWS documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html#task-definition-template).
Copy the task definition into a new file in your project, for example `<project-root>/ci/aws/task-definition.json`.
[Available](https://gitlab.com/gitlab-org/gitlab/-/issues/222618) in GitLab 13.3 and later.
After you have these prerequisites ready, follow these steps:
2020-04-08 14:13:33 +05:30
2021-03-11 19:13:27 +05:30
1. Make sure your AWS credentials are set up as CI/CD variables for your
2020-06-23 00:09:42 +05:30
project. You can follow [the steps above](#run-aws-commands-from-gitlab-cicd) to complete this setup.
2020-10-24 23:57:45 +05:30
1. Add these variables to your project's `.gitlab-ci.yml` file, or in the project's
2021-09-30 23:02:18 +05:30
[CI/CD settings](../variables/index.md#custom-cicd-variables):
2020-10-24 23:57:45 +05:30
- `CI_AWS_ECS_CLUSTER`: The name of the AWS ECS cluster that you're targeting for your deployments.
- `CI_AWS_ECS_SERVICE`: The name of the targeted service tied to your AWS ECS cluster.
- `CI_AWS_ECS_TASK_DEFINITION`: The name of an existing task definition in ECS tied
to the service mentioned above.
2020-04-08 14:13:33 +05:30
```yaml
variables:
CI_AWS_ECS_CLUSTER: my-cluster
CI_AWS_ECS_SERVICE: my-service
CI_AWS_ECS_TASK_DEFINITION: my-task-definition
```
You can find these names after selecting the targeted cluster on your [AWS ECS dashboard](https://console.aws.amazon.com/ecs/home):
![AWS ECS dashboard](../img/ecs_dashboard_v12_9.png)
2020-10-24 23:57:45 +05:30
Alternatively, if you want to use a task definition defined in a JSON file, use
`CI_AWS_ECS_TASK_DEFINITION_FILE` instead:
```yaml
variables:
CI_AWS_ECS_CLUSTER: my-cluster
CI_AWS_ECS_SERVICE: my-service
CI_AWS_ECS_TASK_DEFINITION_FILE: ci/aws/my_task_definition.json
```
You can create your `CI_AWS_ECS_TASK_DEFINITION_FILE` variable as a
2021-09-30 23:02:18 +05:30
[file-typed CI/CD variable](../variables/index.md#cicd-variable-types) instead of a
2021-03-11 19:13:27 +05:30
regular CI/CD variable. If you choose to do so, set the variable value to be the full contents of
2020-10-24 23:57:45 +05:30
the JSON task definition. You can then remove the JSON file from your project.
In both cases, make sure that the value for the `containerDefinitions[].name` attribute is
the same as the `Container name` defined in your targeted ECS service.
2021-02-22 17:27:13 +05:30
WARNING:
2021-03-11 19:13:27 +05:30
`CI_AWS_ECS_TASK_DEFINITION_FILE` takes precedence over `CI_AWS_ECS_TASK_DEFINITION` if both these
2020-10-24 23:57:45 +05:30
variables are defined within your project.
2021-02-22 17:27:13 +05:30
NOTE:
2020-10-24 23:57:45 +05:30
If the name of the task definition you wrote in your JSON file is the same name
as an existing task definition on AWS, then a new revision is created for it.
Otherwise, a brand new task definition is created, starting at revision 1.
2020-04-08 14:13:33 +05:30
1. Include this template in `.gitlab-ci.yml`:
```yaml
include:
2020-06-23 00:09:42 +05:30
- template: AWS/Deploy-ECS.gitlab-ci.yml
2020-04-08 14:13:33 +05:30
```
2020-10-24 23:57:45 +05:30
The `AWS/Deploy-ECS` template ships with GitLab and is available [on
2020-06-23 00:09:42 +05:30
GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/AWS/Deploy-ECS.gitlab-ci.yml).
2020-04-08 14:13:33 +05:30
1. Commit and push your updated `.gitlab-ci.yml` to your project's repository, and you're done!
2021-03-08 18:12:59 +05:30
Your application Docker image is rebuilt and pushed to the GitLab registry.
2020-10-24 23:57:45 +05:30
If your image is located in a private registry, make sure your task definition is
[configured with a `repositoryCredentials` attribute](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).
2021-03-08 18:12:59 +05:30
Then the targeted task definition is updated with the location of the new
Docker image, and a new revision is created in ECS as result.
2020-04-08 14:13:33 +05:30
2021-03-08 18:12:59 +05:30
Finally, your AWS ECS service is updated with the new revision of the
2020-04-08 14:13:33 +05:30
task definition, making the cluster pull the newest version of your
application.
2020-04-22 19:07:51 +05:30
2021-02-22 17:27:13 +05:30
WARNING:
2020-10-24 23:57:45 +05:30
The [`AWS/Deploy-ECS.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/AWS/Deploy-ECS.gitlab-ci.yml)
2020-06-23 00:09:42 +05:30
template includes both the [`Jobs/Build.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Build.gitlab-ci.yml)
and [`Jobs/Deploy/ECS.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml)
"sub-templates". Do not include these "sub-templates" on their own, and only include the main
2020-10-24 23:57:45 +05:30
`AWS/Deploy-ECS.gitlab-ci.yml` template. The "sub-templates" are designed to only be
2020-06-23 00:09:42 +05:30
used along with the main template. They may move or change unexpectedly causing your
pipeline to fail if you didn't include the main template. Also, the job names within
these templates may change. Do not override these jobs names in your own pipeline,
2021-03-08 18:12:59 +05:30
as the override stops working when the name changes.
2020-06-23 00:09:42 +05:30
2020-10-24 23:57:45 +05:30
Alternatively, if you don't wish to use the `AWS/Deploy-ECS.gitlab-ci.yml` template
2020-04-22 19:07:51 +05:30
to deploy to AWS ECS, you can always use our
`aws-base` Docker image to run your own [AWS CLI commands for ECS](https://docs.aws.amazon.com/cli/latest/reference/ecs/index.html#cli-aws-ecs).
```yaml
deploy:
stage: deploy
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- aws ecs register-task-definition ...
```
2021-01-03 14:25:43 +05:30
### Provision and deploy to your AWS Elastic Compute Cloud (EC2)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/201742) in GitLab 13.5.
You can use the `AWS/CF-Provision-and-Deploy-EC2` CI template to perform the
following actions within the same pipeline:
1. **Create stack**: Provision your own infrastructure by leveraging the [AWS CloudFormation](https://aws.amazon.com/cloudformation/) API.
1. **Push to S3**: Push your previously-built artifact to an [AWS S3](https://aws.amazon.com/s3/) bucket.
1. **Deploy to EC2**: Deploy this pushed content onto an [AWS EC2](https://aws.amazon.com/ec2/) instance.
![CF-Provision-and-Deploy-EC2 diagram](../img/cf_ec2_diagram_v13_5.png)
#### Run the `AWS/CF-Provision-and-Deploy-EC2.gitlab-ci.yml` template
To run the `AWS/CF-Provision-and-Deploy-EC2.gitlab-ci.yml` template, you must
pass three JSON input objects, based on existing templates:
1. The AWS documentation provides templates for the _Create stack_ and _Deploy to EC2_ steps (links
below). We provide the template for the remaining step, _Push to S3_:
- [Template for the _Create stack_ step on AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html).
- Template for the _Push to S3_ step. Note that `source` is where a preceding `build` job built
2021-09-30 23:02:18 +05:30
your application, exporting the build through [`artifacts:paths`](../yaml/index.md#artifactspaths):
2021-01-03 14:25:43 +05:30
```json
{
"applicationName": "string",
"source": "string",
"s3Location": "s3://your/bucket/project_built_file...]"
}
```
- [Template for the _Deploy to EC2_ step on AWS](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html).
2021-01-29 00:20:46 +05:30
1. After you have completed these three templates based on your requirements, you
2021-01-03 14:25:43 +05:30
have two ways to pass in these JSON objects:
- They can be three actual files located in your project. You must specify their path relative to
2021-03-11 19:13:27 +05:30
your project root in your `.gitlab-ci.yml` file, using the following CI/CD variables. For example, if
2021-01-03 14:25:43 +05:30
your files are in a `<project_root>/aws` folder:
```yaml
variables:
CI_AWS_CF_CREATE_STACK_FILE: 'aws/cf_create_stack.json'
CI_AWS_S3_PUSH_FILE: 'aws/s3_push.json'
CI_AWS_EC2_DEPLOYMENT_FILE: 'aws/create_deployment.json'
```
2021-09-30 23:02:18 +05:30
- Alternatively, you can provide these JSON objects as [file-typed CI/CD variables](../variables/index.md#cicd-variable-types).
2021-03-11 19:13:27 +05:30
In your project, go to **Settings > CI/CD > Variables** and add
the three variables listed above as file-typed CI/CD variables.
For each variable, set the value to its corresponding JSON object.
2021-01-03 14:25:43 +05:30
2021-03-11 19:13:27 +05:30
1. Provide the name of the stack you're creating and/or targeting, as a CI/CD variable:
2021-01-03 14:25:43 +05:30
```yaml
variables:
CI_AWS_CF_STACK_NAME: 'YourStackName'
```
1. Add this CI template to your `.gitlab-ci.yml`:
```yaml
include:
- template: AWS/CF-Provision-and-Deploy-EC2.gitlab-ci.yml
```
When running your project pipeline at this point:
- Your AWS CloudFormation stack is created based on the content of your
`CI_AWS_CF_CREATE_STACK_FILE` file/variable.
If your stack already exists, this step is skipped, but the `provision` job it belongs to still
runs.
- Your built application is pushed to your S3 bucket then and deployed to your EC2 instance, based
on the related JSON object's content. The deployment job finishes whenever the deployment to EC2
is done or has failed.
2021-01-29 00:20:46 +05:30
#### Custom build job for Auto DevOps
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216008) in GitLab 13.6.
To leverage [Auto DevOps](../../topics/autodevops/index.md) for your project when deploying to
2021-03-11 19:13:27 +05:30
AWS EC2, first you must define [your AWS credentials as CI/CD variables](#run-aws-commands-from-gitlab-cicd).
2021-01-29 00:20:46 +05:30
Next, define a job for the `build` stage. To do so, you must reference the
`Auto-DevOps.gitlab-ci.yml` template and include a job named `build_artifact` in your
`.gitlab-ci.yml` file. For example:
```yaml
# .gitlab-ci.yml
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
2021-03-11 19:13:27 +05:30
AUTO_DEVOPS_PLATFORM_TARGET: EC2
2021-01-29 00:20:46 +05:30
build_artifact:
stage: build
script:
- <your build script goes here>
artifacts:
paths:
- <built artifact>
```
2021-02-22 17:27:13 +05:30
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For a video walkthrough of this configuration process, see [Auto Deploy to EC2](https://www.youtube.com/watch?v=4B-qSwKnacA).
2021-01-29 00:20:46 +05:30
### Deploy to Amazon EKS
- [How to deploy your application to a GitLab-managed Amazon EKS cluster with Auto DevOps](https://about.gitlab.com/blog/2020/05/05/deploying-application-eks/)
## Deploy to Google Cloud
2021-04-17 20:07:23 +05:30
- [Deploying with GitLab on Google Cloud](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/)