mirror/stackexchange-dnscontrol
1
0
Fork 0
mirror of https://github.com/StackExchange/dnscontrol.git synced 2024-05-11 05:55:12 +00:00
Code Issues Releases Activity

DOCS: Typo in the word GitLab (#2151)

Browse Source 
Co-authored-by: Tom Limoncelli <tlimoncelli@stackoverflow.com>
This commit is contained in:
Jeffrey Cafferata
2023-03-13 21:25:34 +01:00
committed by GitHub
parent cbf4f00686
commit 2e1333e06a
2 changed files with 26 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
documentation/ci-cd-gitlab.md
View File

@ -1,10 +1,10 @@
# Gitlab CI/CD example # GitLab CI/CD example
Before discussing the Gitlab CI/CD setup, let's assume you already have a working DNSControl setup. Aren't you there yet? Then first check out the '[Getting Started](getting-started.md)' section. Before discussing the GitLab CI/CD setup, let's assume you already have a working DNSControl setup. Aren't you there yet? Then first check out the '[Getting Started](getting-started.md)' section.
## DNSControl - Demo setup ## DNSControl - Demo setup
For this tutorial, there is a [Gitlab repository](https://gitlab.com/cafferata/dnscontrol/) ready with an example DNSControl setup/domain. For this tutorial, there is a [GitLab repository](https://gitlab.com/cafferata/dnscontrol/) ready with an example DNSControl setup/domain.
This is based on: This is based on:
- The domain `cafferata.dev`. - The domain `cafferata.dev`.
@ -42,9 +42,9 @@ D('cafferata.dev',
``` ```
{% endcode %} {% endcode %}
## Gitlab CI - Preparation ## GitLab CI - Preparation
You may have noticed that the `creds.json` file contains a variable `$TRANSIP_PRIVATE_KEY`. This variable is populated from the Gitlab CI variables and contain the TransIP API key. You may have noticed that the `creds.json` file contains a variable `$TRANSIP_PRIVATE_KEY`. This variable is populated from the GitLab CI variables and contain the TransIP API key.
```text ```text
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
@ -59,13 +59,13 @@ hY/gnT/MmXXko3YAcI4eQL8=
_Example of variable `$TRANSIP_PRIVATE_KEY` contents._ _Example of variable `$TRANSIP_PRIVATE_KEY` contents._
![Gitlab CI/CD variables](assets/ci-cd-gitlab/settings-ci-cd-variables.png) ![GitLab CI/CD variables](assets/ci-cd-gitlab/settings-ci-cd-variables.png)
![Insert Gitlab CI/CD variable TRANSIP_PRIVATE_KEY](assets/ci-cd-gitlab/settings-ci-cd-variables-insert.png) ![Insert GitLab CI/CD variable TRANSIP_PRIVATE_KEY](assets/ci-cd-gitlab/settings-ci-cd-variables-insert.png)
## Gitlab CI - DNSControl preview ## GitLab CI - DNSControl preview
Now it's time to apply the power of DNSControl within Gitlab CI merge requests. We'll start by adding the basic Gitlab CI setup. You can view the git diff online in the [Gitlab merge request #1](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/1/diffs). The Gitlab CI setup has also been added for convenience. Now it's time to apply the power of DNSControl within GitLab CI merge requests. We'll start by adding the basic GitLab CI setup. You can view the git diff online in the [GitLab merge request #1](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/1/diffs). The GitLab CI setup has also been added for convenience.
`.gitlab-ci.yml` `.gitlab-ci.yml`
@ -87,14 +87,14 @@ dnscontrol-preview:
What does this YAML configuration mean? What does this YAML configuration mean?
- The `dnscontrol preview` is run within the Gitlab CI [predefined stage](https://docs.gitlab.com/ee/ci/yaml/#stages) `test` using the Docker image [stackexchange/dnscontrol](https://hub.docker.com/r/stackexchange/dnscontrol). - The `dnscontrol preview` is run within the GitLab CI [predefined stage](https://docs.gitlab.com/ee/ci/yaml/#stages) `test` using the Docker image [stackexchange/dnscontrol](https://hub.docker.com/r/stackexchange/dnscontrol).
- A conscious decision has been made to always use the latest version so that no maintenance is required. Of course you can choose to include a Docker image version. You do this by choosing from the [available versions](https://hub.docker.com/r/stackexchange/dnscontrol/tags), and including it in `image:` for example: `name: 'stackexchange/dnscontrol:v3.20.0'` - A conscious decision has been made to always use the latest version so that no maintenance is required. Of course you can choose to include a Docker image version. You do this by choosing from the [available versions](https://hub.docker.com/r/stackexchange/dnscontrol/tags), and including it in `image:` for example: `name: 'stackexchange/dnscontrol:v3.20.0'`
- Because the choice was made not to adopt a version, it's nice to know from the Gitlab CI jobs which version DNSControl is running. - Because the choice was made not to adopt a version, it's nice to know from the GitLab CI jobs which version DNSControl is running.
We check and validate the DNSControl set-up `dnsconfig.js`. We check and validate the DNSControl set-up `dnsconfig.js`.
- Then we ask TransIP which DNS diff there is. - Then we ask TransIP which DNS diff there is.
- **(!)** This only happens in the context of a Gitlab merge request and (_**very important**_) only when there is a change in the DNSControl configuration (`dnsconfig.js`). - **(!)** This only happens in the context of a GitLab merge request and (_**very important**_) only when there is a change in the DNSControl configuration (`dnsconfig.js`).
Because the above Gitlab CI configuration expects a diff, we apply this by (_for example_) adding the Google Workspace SPF include. Because the above GitLab CI configuration expects a diff, we apply this by (_for example_) adding the Google Workspace SPF include.
`dnsconfig.js` `dnsconfig.js`
@ -114,7 +114,7 @@ D('cafferata.dev',
); );
``` ```
From that moment everything comes together! Within the [Gitlab merge request #1](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/1), a [Gitlab pipeline](https://gitlab.com/cafferata/dnscontrol/-/pipelines/656368053) with a [Gitlab job](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115895010) starts running containing the command `dnscontrol preview`. The outcome of this job? The desired change that will be made within TransIP. Wow this is cool! From that moment everything comes together! Within the [GitLab merge request #1](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/1), a [GitLab pipeline](https://gitlab.com/cafferata/dnscontrol/-/pipelines/656368053) with a [GitLab job](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115895010) starts running containing the command `dnscontrol preview`. The outcome of this job? The desired change that will be made within TransIP. Wow this is cool!
```shell ```shell
$ /usr/local/bin/dnscontrol version $ /usr/local/bin/dnscontrol version
@ -134,13 +134,13 @@ Done. 1 corrections.
![CI/CD job output for DNSControl preview](assets/ci-cd-gitlab/ci-cd-job-output-dnscontrol-preview.png) ![CI/CD job output for DNSControl preview](assets/ci-cd-gitlab/ci-cd-job-output-dnscontrol-preview.png)
## Gitlab CI - DNSControl push ## GitLab CI - DNSControl push
We just saw that we can view the DNSControl diff from the [Gitlab job](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115895010). Now it's time to make Gitlab CI responsible for the command `dnscontrol push`. We just saw that we can view the DNSControl diff from the [GitLab job](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115895010). Now it's time to make GitLab CI responsible for the command `dnscontrol push`.
From here several choices can be made. You can choose to have the `dnscontrol push` run as soon as a merge request is pushed to default branch (e.g. `main`), or from a Gitlab pipeline trigger within the [Gitlab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new). We have opted for the [Gitlab pipeline web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new) so that it cannot happen that DNS changes are made from previous merge requests in default branch (e.g. `main`). From here several choices can be made. You can choose to have the `dnscontrol push` run as soon as a merge request is pushed to default branch (e.g. `main`), or from a GitLab pipeline trigger within the [GitLab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new). We have opted for the [GitLab pipeline web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new) so that it cannot happen that DNS changes are made from previous merge requests in default branch (e.g. `main`).
It will probably not surprise you that the basis of this Gitlab YAML configuration corresponds for 90% with the DNSControl preview. See the [Gitlab merge request #2](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/2) here. It will probably not surprise you that the basis of this GitLab YAML configuration corresponds for 90% with the DNSControl preview. See the [GitLab merge request #2](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/2) here.
`.gitlab-ci.yml` `.gitlab-ci.yml`
@ -159,12 +159,12 @@ dnscontrol-push:
What does this (new) YAML configuration mean? What does this (new) YAML configuration mean?
- The `dnscontrol push` is run within the Gitlab CI [predefined stage](https://docs.gitlab.com/ee/ci/yaml/#stages) `deploy`. - The `dnscontrol push` is run within the GitLab CI [predefined stage](https://docs.gitlab.com/ee/ci/yaml/#stages) `deploy`.
- This only happens when you start a Gitlab pipeline from the [Gitlab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new) for the default branch (e.g. `main`). - This only happens when you start a GitLab pipeline from the [GitLab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new) for the default branch (e.g. `main`).
![Start new CI/CD pipeline from the Gitlab web interface](assets/ci-cd-gitlab/ci-cd-pipelines-new.png) ![Start new CI/CD pipeline from the GitLab web interface](assets/ci-cd-gitlab/ci-cd-pipelines-new.png)
When we start the new [Gitlab pipeline](https://gitlab.com/cafferata/dnscontrol/-/pipelines/656368384) from the [Gitlab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new), we see the Gitlab job [dnscontrol-push](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115896199) which makes the changes within the DNS provider TransIP. When we start the new [GitLab pipeline](https://gitlab.com/cafferata/dnscontrol/-/pipelines/656368384) from the [GitLab web interface](https://gitlab.com/cafferata/dnscontrol/-/pipelines/new), we see the GitLab job [dnscontrol-push](https://gitlab.com/cafferata/dnscontrol/-/jobs/3115896199) which makes the changes within the DNS provider TransIP.
```shell ```shell
$ /usr/local/bin/dnscontrol version $ /usr/local/bin/dnscontrol version
@ -185,11 +185,11 @@ Done. 1 corrections.
![CI/CD job output for DNSControl push](assets/ci-cd-gitlab/ci-cd-job-output-dnscontrol-push.png) ![CI/CD job output for DNSControl push](assets/ci-cd-gitlab/ci-cd-job-output-dnscontrol-push.png)
## Gitlab CI - Duplicate YAML configuration ## GitLab CI - Duplicate YAML configuration
We have a working setup at this point that includes a `dnscontrol preview` and a `dnscontrol push` command. Well done! You might consider cleaning up the duplicate Gitlab YAML configuration. We can move the DNSControl `image` `name` and `entrypoint` to a Gitlab YAML `extends`. Then we can also move the duplicate `dnscontrol version` command to a Gitlab `before_script`. See the third (_and also last_) [Gitlab merge request #3](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/3). We have a working setup at this point that includes a `dnscontrol preview` and a `dnscontrol push` command. Well done! You might consider cleaning up the duplicate GitLab YAML configuration. We can move the DNSControl `image` `name` and `entrypoint` to a GitLab YAML `extends`. Then we can also move the duplicate `dnscontrol version` command to a GitLab `before_script`. See the third (_and also last_) [GitLab merge request #3](https://gitlab.com/cafferata/dnscontrol/-/merge_requests/3).
This eventually brings us to the following Gitlab CI setup. This eventually brings us to the following GitLab CI setup.
`.gitlab-ci.yml` `.gitlab-ci.yml`

2
documentation/getting-started.md
View File

@ -332,5 +332,5 @@ If you are going to use this in production, we highly recommend the following:
* Store the configuration files in Git. * Store the configuration files in Git.
* Encrypt the `creds.json` file before storing it in Git. Do NOT store * Encrypt the `creds.json` file before storing it in Git. Do NOT store
API keys or other credentials without encrypting them. API keys or other credentials without encrypting them.
* Use a CI/CD tool like [Gitlab](ci-cd-gitlab.md), Jenkins, CircleCI, [GitHub Actions](https://github.com/StackExchange/dnscontrol#via-github-actions-gha), etc. to automatically push DNS changes. * Use a CI/CD tool like [GitLab](ci-cd-gitlab.md), Jenkins, CircleCI, [GitHub Actions](https://github.com/StackExchange/dnscontrol#via-github-actions-gha), etc. to automatically push DNS changes.
* Join the DNSControl community. File [issues](https://github.com/StackExchange/dnscontrol/issues) and [PRs](https://github.com/StackExchange/dnscontrol/pulls). * Join the DNSControl community. File [issues](https://github.com/StackExchange/dnscontrol/issues) and [PRs](https://github.com/StackExchange/dnscontrol/pulls).