summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThong Kuah <tkuah@gitlab.com>2018-12-13 16:23:39 +1300
committerThong Kuah <tkuah@gitlab.com>2019-01-07 11:01:41 +1300
commit99f0539587fad35bdbf1b16ea4f082757f44b053 (patch)
tree36dd4eadf6bad2b844d5d7837d74771a00432e25
parenta4833f6fe0b725a4ee312367a311ec075352fba2 (diff)
downloadgitlab-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.md13
-rw-r--r--doc/topics/autodevops/index.md55
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,