debian-mirror-gitlab/doc/ci/examples/deployment/index.md

140 lines
4.5 KiB
Markdown
Raw Normal View History

2021-09-30 23:02:18 +05:30
---
2023-05-27 22:25:52 +05:30
stage: Configure
group: Configure
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-09-30 23:02:18 +05:30
type: tutorial
---
2021-10-27 15:23:28 +05:30
# Using Dpl as a deployment tool **(FREE)**
2021-09-30 23:02:18 +05:30
[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
continuous deployment that's developed and used by Travis CI, but can also be
used with GitLab CI/CD.
Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
## Requirements
To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
## Basic usage
Dpl can be installed on any machine with:
```shell
gem install dpl
```
This allows you to test all commands from your local terminal, rather than
having to test it on a CI server.
If you don't have Ruby installed you can do it on Debian-compatible Linux with:
```shell
apt-get update
apt-get install ruby-dev
```
The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more.
2022-11-25 23:54:43 +05:30
To use it, define provider and any additional parameters required by the provider.
2021-09-30 23:02:18 +05:30
For example if you want to use it to deploy your application to Heroku, you need to specify `heroku` as provider, specify `api_key` and `app`.
All possible parameters can be found in the [Heroku API section](https://github.com/travis-ci/dpl#heroku-api).
```yaml
staging:
stage: deploy
script:
- gem install dpl
2023-04-23 21:23:45 +05:30
- dpl heroku api --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
2022-10-11 01:57:18 +05:30
environment: staging
2021-09-30 23:02:18 +05:30
```
In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
## Using Dpl with Docker
In most cases, you configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
2021-11-18 22:05:49 +05:30
This means that all commands are run in the context of local user (for example `gitlab_runner` or `gitlab_ci_multi_runner`).
2021-09-30 23:02:18 +05:30
It also means that most probably in your Docker container you don't have the Ruby runtime installed.
You must install it:
```yaml
staging:
stage: deploy
script:
- apt-get update -yq
- apt-get install -y ruby-dev
- gem install dpl
2023-04-23 21:23:45 +05:30
- dpl heroku api --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
2021-09-30 23:02:18 +05:30
only:
2021-11-18 22:05:49 +05:30
- main
2022-10-11 01:57:18 +05:30
environment: staging
2021-09-30 23:02:18 +05:30
```
The first line `apt-get update -yq` updates the list of available packages,
where second `apt-get install -y ruby-dev` installs the Ruby runtime on system.
The above example is valid for all Debian-compatible systems.
## Usage in staging and production
It's pretty common in the development workflow to have staging (development) and
production environments
2021-11-18 22:05:49 +05:30
Let's consider the following example: we would like to deploy the `main`
2021-09-30 23:02:18 +05:30
branch to `staging` and all tags to the `production` environment.
The final `.gitlab-ci.yml` for that setup would look like this:
```yaml
staging:
stage: deploy
script:
- gem install dpl
2023-04-23 21:23:45 +05:30
- dpl heroku api --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
2021-09-30 23:02:18 +05:30
only:
2021-11-18 22:05:49 +05:30
- main
2022-10-11 01:57:18 +05:30
environment: staging
2021-09-30 23:02:18 +05:30
production:
stage: deploy
script:
- gem install dpl
2023-04-23 21:23:45 +05:30
- dpl heroku api --app=my-app-production --api_key=$HEROKU_PRODUCTION_API_KEY
2021-09-30 23:02:18 +05:30
only:
- tags
2022-10-11 01:57:18 +05:30
environment: production
2021-09-30 23:02:18 +05:30
```
We created two deploy jobs that are executed on different events:
2021-11-18 22:05:49 +05:30
- `staging`: Executed for all commits pushed to the `main` branch
2021-10-27 15:23:28 +05:30
- `production`: Executed for all pushed tags
2021-09-30 23:02:18 +05:30
We also use two secure variables:
2021-10-27 15:23:28 +05:30
- `HEROKU_STAGING_API_KEY`: Heroku API key used to deploy staging app
- `HEROKU_PRODUCTION_API_KEY`: Heroku API key used to deploy production app
2021-09-30 23:02:18 +05:30
## Storing API keys
2021-10-27 15:23:28 +05:30
To store API keys as secure variables:
2022-10-11 01:57:18 +05:30
1. On the top bar, select **Main menu > Projects** and find your project.
2021-10-27 15:23:28 +05:30
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **Variables**.
The variables defined in the project settings are sent along with the build script to the runner.
2021-09-30 23:02:18 +05:30
The secure variables are stored out of the repository. Never store secrets in
2021-10-27 15:23:28 +05:30
your project's `.gitlab-ci.yml` file. It is also important that the secret's value
2021-09-30 23:02:18 +05:30
is hidden in the job log.
You access added variable by prefixing it's name with `$` (on non-Windows runners)
or `%` (for Windows Batch runners):
2021-10-27 15:23:28 +05:30
- `$VARIABLE`: Use for non-Windows runners
- `%VARIABLE%`: Use for Windows Batch runners
2021-09-30 23:02:18 +05:30
2021-10-27 15:23:28 +05:30
Read more about [CI/CD variables](../../variables/index.md).