diff options
author | Thong Kuah <tkuah@gitlab.com> | 2018-12-13 16:23:39 +1300 |
---|---|---|
committer | Thong Kuah <tkuah@gitlab.com> | 2019-01-07 11:01:41 +1300 |
commit | 99f0539587fad35bdbf1b16ea4f082757f44b053 (patch) | |
tree | 36dd4eadf6bad2b844d5d7837d74771a00432e25 | |
parent | a4833f6fe0b725a4ee312367a311ec075352fba2 (diff) | |
download | gitlab-ce-99f0539587fad35bdbf1b16ea4f082757f44b053.tar.gz |
Document Auto DevOps secret variables
Cross link from GitLab CI variable doc too
Add note about running pods and updating secrets without any code change
-rw-r--r-- | doc/ci/variables/README.md | 13 | ||||
-rw-r--r-- | doc/topics/autodevops/index.md | 55 |
2 files changed, 68 insertions, 0 deletions
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 209a2c15d90..396fd91174e 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -249,6 +249,19 @@ the project services that you are using to learn which variables they define. An example project service that defines deployment variables is the [Kubernetes integration](../../user/project/clusters/index.md#deployment-variables). +## Auto DevOps application variables + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/49056) in GitLab 11.7. + +You can configure [Auto DevOps](../../topics/autodevops/index.md) to +pass CI variables to the running application by prefixing the key of the +variable with `K8S_SECRET_`. + +These [prefixed +variables](../../topics/autodevops/index.md#application-secret-variables) will +then be available as environment variables on the running application +container. + ## Debug tracing > Introduced in GitLab Runner 1.7. diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index b41f401e14c..b3fd4261711 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -673,6 +673,7 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac | `REVIEW_DISABLED` | From GitLab 11.0, this variable can be used to disable the `review` and the manual `review:stop` job. If the variable is present, these jobs will not be created. | | `DAST_DISABLED` | From GitLab 11.0, this variable can be used to disable the `dast` job. If the variable is present, the job will not be created. | | `PERFORMANCE_DISABLED` | From GitLab 11.0, this variable can be used to disable the `performance` job. If the variable is present, the job will not be created. | +| `K8S_SECRET_*` | From GitLab 11.7, any variable prefixed with `K8S_SECRET_` will be made available by Auto DevOps as environment variables to the deployed application. | TIP: **Tip:** Set up the replica variables using a @@ -684,6 +685,60 @@ You should *not* scale your application using Kubernetes directly. This can cause confusion with Helm not detecting the change, and subsequent deploys with Auto DevOps can undo your changes. +### Application secret variables + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/49056) in GitLab 11.7. + +Some applications need to define secret variables that are +accessible by the deployed application. Starting in GitLab +11.7, Auto DevOps will now detect variables where the key starts with +`K8S_SECRET_` and make these prefixed variables available to the +deployed application, as environment variables. + +To configure your application variables: + +1. Go to your project's **Settings > CI/CD**, then expand the section + called **Variables** + +2. Create a CI Variable, ensuring the key is prefixed with + `K8S_SECRET_`. For example, you can create a variable with key +`K8S_SECRET_RAILS_MASTER_KEY`. + +3. Run an Auto Devops pipeline either by manually creating a new + pipeline or by pushing a code change to GitLab. + +Auto DevOps pipelines will take your application secret variables to +populate a Kubernetes secret. This secret is unique per environment. +When deploying your application, the secret is loaded as environment +variables in the container running the application. Following the +example above, you can see the secret below containing the +`RAILS_MASTER_KEY` variable. + +```sh +$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml +apiVersion: v1 +data: + RAILS_MASTER_KEY: MTIzNC10ZXN0 +kind: Secret +metadata: + creationTimestamp: 2018-12-20T01:48:26Z + name: production-secret + namespace: minimal-ruby-app-54 + resourceVersion: "429422" + selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret + uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4 +type: Opaque +``` + +NOTE: **Note:** +Environment variables are generally considered immutable in a Kubernetes +pod. Therefore, if you update an application secret without changing any +code then manually create a new pipeline, you will find that any running +application pods will not have the updated secrets. In this case, you +can either 1) push a code update to GitLab to force the Kubernetes +Deployment to recreate pods; or 2) manually delete running pods to +cause Kubernetes to create new pods with updated secrets. + #### Advanced replica variables setup Apart from the two replica-related variables for production mentioned above, |