@@ -199,11 +199,11 @@ In this mode, you only have to provide a shell script that fully implements the
The deployment script is searched as follows:
1. look for a specific `k8s-deploy-$env.sh` in the `$K8S_SCRIPTS_DIR` directory in your project (e.g. `k8s-deploy-staging.sh` for staging environment),
1. look for a specific `k8s-deploy-$environment_type.sh` in the `$K8S_SCRIPTS_DIR` directory in your project (e.g. `k8s-deploy-staging.sh` for staging environment),
2. if not found: look for a default `k8s-deploy.sh` in the `$K8S_SCRIPTS_DIR` directory in your project,
3. if not found: the GitLab CI template assumes you're using the template-based deployment policy.
:warning: `k8s-deploy-$env.sh` or `k8s-deploy.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-deploy.sh`
:warning: `k8s-deploy-$environment_type.sh` or `k8s-deploy.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-deploy.sh`
Your script(s) may use [dynamic variables](#dynamic-variables).
@@ -216,7 +216,7 @@ The template processes the following steps:
1. _optionally_ executes the `k8s-pre-apply.sh` script in your project to perform specific environment pre-initialization (for e.g. create required services),
2. looks for your Kubernetes deployment file, substitutes [dynamic variables](#dynamic-variables) and [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) it,
1. look for a specific `deployment-$env.yml` in your project (e.g. `deployment-staging.yml` for staging environment),
1. look for a specific `deployment-$environment_type.yml` in your project (e.g. `deployment-staging.yml` for staging environment),
2. fallbacks to default `deployment.yml`.
3. _optionally_ executes the `k8s-post-apply.sh` script in your project to perform specific environment post-initialization stuff,
@@ -233,7 +233,7 @@ The template processes the following steps:
1. _optionally_ executes the `k8s-pre-apply.sh` script in your project to perform specific environment pre-initialization (for e.g. create required services),
2. looks for your Kustomization file and [`kubectl apply`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) it,
1. looks for an environment-specific [overlay](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay) file `./$env/kustomization.yaml` (e.g. `./staging/kustomization.yaml ` for staging environment),
1. looks for an environment-specific [overlay](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay) file `./$environment_type/kustomization.yaml` (e.g. `./staging/kustomization.yaml ` for staging environment),
2. fallbacks to default `kustomization.yaml`.
3. _optionally_ executes the `k8s-post-apply.sh` script in your project to perform specific environment post-initialization stuff,
@@ -265,17 +265,17 @@ In this mode, you only have to provide a shell script that fully implements the
The a deployment script is searched as follows:
1. look for a specific `k8s-cleanup-$env.sh` in the `$K8S_SCRIPTS_DIR` directory in your project (e.g. `k8s-cleanup-staging.sh` for staging environment),
1. look for a specific `k8s-cleanup-$environment_type.sh` in the `$K8S_SCRIPTS_DIR` directory in your project (e.g. `k8s-cleanup-staging.sh` for staging environment),
2. if not found: look for a default `k8s-cleanup.sh` in the `$K8S_SCRIPTS_DIR` directory in your project,
3. if not found: the GitLab CI template assumes you're using the template-based cleanup policy.
:warning: `k8s-cleanup-$env.sh` or `k8s-cleanup.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-cleanup.sh`
:warning: `k8s-cleanup-$environment_type.sh` or `k8s-cleanup.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-cleanup.sh`
Your script(s) may use [dynamic variables](#dynamic-variables).
> TIP: a nice way to implement environment cleanup is to declare the label `app=${appname}` on every Kubernetes
> TIP: a nice way to implement environment cleanup is to declare the label `app=${environment_name}` on every Kubernetes
> object associated to your environment.
> Then environment cleanup can be implemented very easily with command `kubectl delete all,pvc,secret,ingress -l "app=${appname}"`
> Then environment cleanup can be implemented very easily with command `kubectl delete all,pvc,secret,ingress -l "app=${environment_name}"`
#### 2: template-based cleanup
@@ -285,7 +285,7 @@ The template processes the following steps:
1. _optionally_ executes the `k8s-pre-cleanup.sh` script in your project to perform specific environment pre-cleanup stuff,
2. looks for your Kubernetes deployment file, substitutes [dynamic variables](#dynamic-variables) and [`kubectl delete`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) it,
1. look for a specific `deployment-$env.yml` in your project (e.g. `deployment-staging.yml` for staging environment),
1. look for a specific `deployment-$environment_type.yml` in your project (e.g. `deployment-staging.yml` for staging environment),
2. fallbacks to default `deployment.yml`.
3. _optionally_ executes the `k8s-post-cleanup.sh` script in your project to perform specific environment post-cleanup (for e.g. delete bound services).
@@ -301,7 +301,7 @@ The template processes the following steps:
1. _optionally_ executes the `k8s-pre-cleanup.sh` script in your project to perform specific environment pre-cleanup stuff,
2. looks for your Kustomization file and [`kubectl delete`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply) it,
1. looks for an environment-specific [overlay](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay) file `./$env/kustomization.yaml` (e.g. `./staging/kustomization.yaml ` for staging environment),
1. looks for an environment-specific [overlay](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay) file `./$environment_type/kustomization.yaml` (e.g. `./staging/kustomization.yaml ` for staging environment),
2. fallbacks to default `kustomization.yaml`.
3. _optionally_ executes the `k8s-post-cleanup.sh` script in your project to perform specific environment post-cleanup (for e.g. delete bound services).
@@ -336,10 +336,10 @@ In order to be able to implement some **genericity** in your scripts and templat
2. any [custom variable](https://docs.gitlab.com/ee/ci/variables/#custom-environment-variables)
(ex: `${SECRET_TOKEN}` that you have set in your project CI/CD variables)
3.**dynamic variables** set by the template:
*`${appname}`: the application target name to use in this environment (ex: `myproject-review-fix-bug-12` or `myproject-staging`)
*`${appname_ssc}`: the application target name in [SCREAMING_SNAKE_CASE](https://en.wikipedia.org/wiki/Snake_case) format
*`${environment_name}`: the application target name to use in this environment (ex: `myproject-review-fix-bug-12` or `myproject-staging`)
*`${environment_name_ssc}`: the application target name in [SCREAMING_SNAKE_CASE](https://en.wikipedia.org/wiki/Snake_case) format
(ex: `MYPROJECT_REVIEW_FIX_BUG_12` or `MYPROJECT_STAGING`)
*`${env}`: the environment type (`review`, `integration`, `staging` or `production`)
*`${environment_type}`: the environment type (`review`, `integration`, `staging` or `production`)
*`${hostname}`: the environment hostname, extracted from `${CI_ENVIRONMENT_URL}` (has to be explicitly declared as [`environment:url`](https://docs.gitlab.com/ee/ci/yaml/#environmenturl) in your `.gitlab-ci.yml` file)
* any [GitLab CI variable](https://docs.gitlab.com/ee/ci/variables/#predefined-environment-variables)
(ex: `${CI_ENVIRONMENT_URL}` to retrieve the actual environment exposed route)