diff options
Diffstat (limited to 'doc/topics/autodevops')
| -rw-r--r-- | doc/topics/autodevops/customize.md | 39 | ||||
| -rw-r--r-- | doc/topics/autodevops/index.md | 84 | ||||
| -rw-r--r-- | doc/topics/autodevops/quick_start_guide.md | 16 | ||||
| -rw-r--r-- | doc/topics/autodevops/requirements.md | 4 | ||||
| -rw-r--r-- | doc/topics/autodevops/stages.md | 16 | ||||
| -rw-r--r-- | doc/topics/autodevops/troubleshooting.md | 2 | ||||
| -rw-r--r-- | doc/topics/autodevops/upgrading_auto_deploy_dependencies.md | 8 | ||||
| -rw-r--r-- | doc/topics/autodevops/upgrading_postgresql.md | 4 |
8 files changed, 101 insertions, 72 deletions
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 42c54961c1d..8f48b1fc57a 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -146,7 +146,7 @@ repository or by specifying a project CI/CD variable: file in it, Auto DevOps detects the chart and uses it instead of the [default chart](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app), enabling you to control exactly how your application is deployed. -- **Project variable** - Create a [project CI/CD variable](../../ci/variables/README.md) +- **Project variable** - Create a [project CI/CD variable](../../ci/variables/index.md) `AUTO_DEVOPS_CHART` with the URL of a custom chart to use, or create two project variables: `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository, and `AUTO_DEVOPS_CHART` with the path to the chart. @@ -181,17 +181,17 @@ list of options. ## Custom Helm chart per environment You can specify the use of a custom Helm chart per environment by scoping the CI/CD variable -to the desired environment. See [Limit environment scope of CI/CD variables](../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable). +to the desired environment. See [Limit environment scope of CI/CD variables](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable). ## Customizing `.gitlab-ci.yml` Auto DevOps is completely customizable because the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) -is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/README.md) file, +is just an implementation of a [`.gitlab-ci.yml`](../../ci/yaml/index.md) file, and uses only features available to any implementation of `.gitlab-ci.yml`. To modify the CI/CD pipeline used by Auto DevOps, -[`include` the template](../../ci/yaml/README.md#includetemplate), and customize +[`include` the template](../../ci/yaml/index.md#includetemplate), and customize it as needed by adding a `.gitlab-ci.yml` file to the root of your repository containing the following: @@ -202,7 +202,7 @@ include: Add your changes, and your additions are merged with the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) -using the behavior described for [`include`](../../ci/yaml/README.md#include). +using the behavior described for [`include`](../../ci/yaml/index.md#include). If you need to specifically remove a part of the file, you can also copy and paste the contents of the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) @@ -254,13 +254,13 @@ include: See the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) for information on available jobs. WARNING: -Auto DevOps templates using the [`only`](../../ci/yaml/README.md#only--except) or -[`except`](../../ci/yaml/README.md#only--except) syntax have switched -to the [`rules`](../../ci/yaml/README.md#rules) syntax, starting in +Auto DevOps templates using the [`only`](../../ci/yaml/index.md#only--except) or +[`except`](../../ci/yaml/index.md#only--except) syntax have switched +to the [`rules`](../../ci/yaml/index.md#rules) syntax, starting in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336). If your `.gitlab-ci.yml` extends these Auto DevOps templates and override the `only` or `except` keywords, you must migrate your templates to use the -[`rules`](../../ci/yaml/README.md#rules) syntax after the +[`rules`](../../ci/yaml/index.md#rules) syntax after the base template is migrated to use the `rules` syntax. For users who cannot migrate just yet, you can alternatively pin your templates to the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12-10). @@ -314,6 +314,19 @@ The version of the chart used to provision PostgreSQL: GitLab encourages users to [migrate their database](upgrading_postgresql.md) to the newer PostgreSQL. +### Customize values for PostgreSQL Helm Chart + +> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/issues/113) in auto-deploy-image v2, in GitLab 13.8. + +To set custom values, do one of the following: + +- Add a file named `.gitlab/auto-deploy-postgres-values.yaml` to your repository. If found, this + file is used automatically. This file is used by default for PostgreSQL Helm upgrades. +- Add a file with a different name or path to the repository, and set the + `POSTGRES_HELM_UPGRADE_VALUES_FILE` [environment variable](#database) with the path + and name. +- Set the `POSTGRES_HELM_UPGRADE_EXTRA_ARGS` [environment variable](#database). + ### Using external PostgreSQL database providers While Auto DevOps provides out-of-the-box support for a PostgreSQL container for @@ -378,7 +391,7 @@ applications. | `HELM_UPGRADE_EXTRA_ARGS` | From GitLab 11.11, allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. | | `INCREMENTAL_ROLLOUT_MODE` | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. | | `K8S_SECRET_*` | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. | -| `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. | +| `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. | | `PRODUCTION_REPLICAS` | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. | | `REPLICAS` | Number of replicas to deploy. Defaults to 1. | | `ROLLOUT_RESOURCE_TYPE` | From GitLab 11.9, allows specification of the resource type being deployed when using a custom Helm chart. Default value is `deployment`. | @@ -387,7 +400,7 @@ applications. NOTE: After you set up your replica variables using a -[project CI/CD variable](../../ci/variables/README.md), +[project CI/CD variable](../../ci/variables/index.md), you can scale your application by redeploying it. WARNING: @@ -406,8 +419,10 @@ The following table lists CI/CD variables related to the database. | `POSTGRES_ENABLED` | Whether PostgreSQL is enabled. Defaults to `true`. Set to `false` to disable the automatic deployment of PostgreSQL. | | `POSTGRES_USER` | The PostgreSQL user. Defaults to `user`. Set it to use a custom username. | | `POSTGRES_PASSWORD` | The PostgreSQL password. Defaults to `testing-password`. Set it to use a custom password. | -| `POSTGRES_DB` | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-cicd-variables). Set it to use a custom database name. | +| `POSTGRES_DB` | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/index.md#predefined-cicd-variables). Set it to use a custom database name. | | `POSTGRES_VERSION` | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.16` for tests and deployments as of GitLab 13.0 (previously `9.6.2`). If `AUTO_DEVOPS_POSTGRES_CHANNEL` is set to `1`, deployments uses the default version `9.6.2`. | +| `POSTGRES_HELM_UPGRADE_VALUES_FILE` | In GitLab 13.8 and later, and when using [auto-deploy-image v2](upgrading_auto_deploy_dependencies.md), this variable allows the `helm upgrade` values file for PostgreSQL to be overridden. Defaults to `.gitlab/auto-deploy-postgres-values.yaml`. | +| `POSTGRES_HELM_UPGRADE_EXTRA_ARGS` | In GitLab 13.8 and later, and when using [auto-deploy-image v2](upgrading_auto_deploy_dependencies.md), this variable allows extra PostgreSQL options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. | ### Disable jobs diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index f2ce61044ef..beb5f6a58f6 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -9,9 +9,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - Introduced in GitLab 11.0 for general availability. GitLab Auto DevOps helps to reduce the complexity of software delivery by -setting up pipelines and integrations for you. Instead of requiring you to -manually configure your entire GitLab environment, Auto DevOps configures -many of these areas for you, including security auditing and vulnerability +setting up pipelines and integrations for you. Auto DevOps configures +GitLab CI/CD pipelines including security auditing and vulnerability testing. Using Auto DevOps, you can: @@ -54,17 +53,17 @@ following levels: | GitLab SaaS | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | | GitLab self-managed | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | -When you enable AutoDevOps for your instance, it attempts to run on all -pipelines in each project, but will automatically disable itself for individual +When you enable Auto DevOps for your instance, it attempts to run on all +pipelines in each project. The Auto DevOps setting automatically disables itself for individual projects on their first pipeline failure. An instance administrator can enable or disable this default in the [Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops). -Since [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/issues/26655), +[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) in GitLab 12.7, Auto DevOps runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](stages.md#auto-build) exists. -If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the -project, it isn't changed and won't be affected by Auto DevOps. +If a [CI/CD configuration file](../../ci/yaml/index.md) is present in the +project, it remains unchanged and Auto DevOps doesn't affect it. ### At the project level @@ -80,7 +79,7 @@ To enable it: and choose the [deployment strategy](#deployment-strategy). 1. Click **Save changes** for the changes to take effect. -After enabling the feature, an Auto DevOps pipeline is triggered on the `master` branch. +After enabling the feature, an Auto DevOps pipeline is triggered on the default branch. ### At the group level @@ -88,9 +87,8 @@ After enabling the feature, an Auto DevOps pipeline is triggered on the `master` Only administrators and group owners can enable or disable Auto DevOps at the group level. -When enabling or disabling Auto DevOps at group level, group configuration is -implicitly used for the subgroups and projects inside that group, unless Auto DevOps -is specifically enabled or disabled on the subgroup or project. +When you enable Auto DevOps at group level, the subgroups and projects in that group inherit the configuration. Auto DevOps +can be specifically enabled or disabled individually for projects and subgroups. To enable or disable Auto DevOps at the group level: @@ -103,7 +101,8 @@ To enable or disable Auto DevOps at the group level: Even when disabled at the instance level, group owners and project maintainers can still enable Auto DevOps at the group and project level, respectively. -1. As an administrator, go to **Admin Area > Settings > CI/CD > Continuous Integration and Deployment**. +1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**. +1. Go to **Settings > CI/CD > Continuous Integration and Deployment**. 1. Select **Default to Auto DevOps pipeline for all projects** to enable it. 1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain), for Auto Deploy and Auto Review Apps to use. @@ -118,7 +117,7 @@ project's **Settings > CI/CD > Auto DevOps**. The following options are available: - **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy) - with `master` branch directly deployed to production. + with the default branch directly deployed to production. - **Continuous deployment to production using timed incremental rollout**: Sets the [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production) variable to `timed`. Production deployments execute with a 5 minute delay between @@ -128,7 +127,7 @@ are available: [`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production) variables to `1` and `manual`. This means: - - `master` branch is directly deployed to staging. + - The default branch is directly deployed to staging. - Manual actions are provided for incremental rollout to production. NOTE: @@ -137,12 +136,12 @@ to minimize downtime and risk. ## Quick start -If you're using GitLab.com, see the [quick start guide](quick_start_guide.md) -for setting up Auto DevOps with GitLab.com and a Kubernetes cluster on Google Kubernetes +For GitLab.com users, see the [quick start guide](quick_start_guide.md) +for setting up Auto DevOps deploying to a Kubernetes cluster on Google Kubernetes Engine (GKE). If you use a self-managed instance of GitLab, you must configure the -[Google OAuth2 OmniAuth Provider](../../integration/google.md) before +[Google OAuth 2.0 OmniAuth Provider](../../integration/google.md) before configuring a cluster on GKE. After configuring the provider, you can follow the steps in the [quick start guide](quick_start_guide.md) to get started. @@ -173,7 +172,7 @@ NOTE: Depending on your target platform, some features might not be available to you. Comprised of a set of [stages](stages.md), Auto DevOps brings these best practices to your -project in a simple and automatic way: +project automatically: - [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing) - [Auto Build](stages.md#auto-build) @@ -222,18 +221,17 @@ The Auto DevOps base domain is required to use [Auto Monitoring](stages.md#auto-monitoring). You can define the base domain in any of the following places: -- either under the cluster's settings, whether for an instance, - [projects](../../user/project/clusters/index.md#base-domain) or +- Either under the cluster's settings, whether for an instance, + [projects](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) or [groups](../../user/group/clusters/index.md#base-domain) -- or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` -- or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN` -- or as an instance-wide fallback in **Admin Area > Settings > CI/CD** under the - **Continuous Integration and Delivery** section +- Or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` +- Or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN` +- Or as an instance-wide fallback in **Menu >** **{admin}** **Admin >** + **Settings > CI/CD** under the **Continuous Integration and Delivery** section. The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence -as other environment [variables](../../ci/variables/README.md#cicd-variable-precedence). -If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain** -setting is used if set. +as other environment [variables](../../ci/variables/index.md#cicd-variable-precedence). +If this variable isn't set and the cluster setting is left blank, the instance-wide domain is used if set for your instance. Auto DevOps requires a wildcard DNS A record matching the base domain(s). For a base domain of `example.com`, you'd need a DNS entry like: @@ -258,14 +256,14 @@ to the Kubernetes pods running your application. See [Auto DevOps requirements for Amazon ECS](requirements.md#auto-devops-requirements-for-amazon-ecs). -## Using multiple Kubernetes clusters +## Use multiple Kubernetes clusters When using Auto DevOps, you can deploy different environments to different Kubernetes clusters, due to the 1:1 connection -[existing between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters). +[existing between them](../../user/project/clusters/multiple_kubernetes_clusters.md). The [Deploy Job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) -used by Auto DevOps currently defines 3 environment names: +used by Auto DevOps defines 3 environment names: - `review/` (every environment starting with `review/`) - `staging` @@ -274,7 +272,7 @@ used by Auto DevOps currently defines 3 environment names: Those environments are tied to jobs using [Auto Deploy](stages.md#auto-deploy), so except for the environment scope, they must have a different deployment domain. You must define a separate `KUBE_INGRESS_BASE_DOMAIN` variable for each of the above -[based on the environment](../../ci/variables/README.md#limit-the-environment-scope-of-a-cicd-variable). +[based on the environment](../../ci/variables/index.md#limit-the-environment-scope-of-a-cicd-variable). The following table is an example of how to configure the three different clusters: @@ -296,8 +294,8 @@ To add a different cluster for each environment: 1. Navigate to each cluster's page, through **Infrastructure > Kubernetes clusters**, and add the domain based on its Ingress IP address. -After completing configuration, you can test your setup by creating a merge request -and verifying your application is deployed as a Review App in the Kubernetes +After completing configuration, test your setup by creating a merge request. +Verify whether your application deployed as a Review App in the Kubernetes cluster with the `review/*` environment scope. Similarly, you can check the other environments. @@ -337,5 +335,23 @@ spec: value: "PUT_YOUR_HTTPS_PROXY_HERE" ``` +## Upgrade Auto DevOps dependencies when updating GitLab + +When updating GitLab, you may need to upgrade Auto DevOps dependencies to +match your new GitLab version: + +- [Upgrading Auto DevOps resources](upgrading_auto_deploy_dependencies.md): + - Auto DevOps template. + - Auto Deploy template. + - Auto Deploy image. + - Helm. + - Kubernetes. + - Environment variables. +- [Upgrading PostgreSQL](upgrading_postgresql.md). + +## Troubleshooting + +See [troubleshooting Auto DevOps](troubleshooting.md). + <!-- DO NOT ADD TROUBLESHOOTING INFO HERE --> <!-- Troubleshooting information has moved to troubleshooting.md --> diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 448e9526b88..196f6dec7e7 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -14,7 +14,7 @@ to create a Kubernetes cluster manually using the Google Cloud Platform console. You are creating and deploying a simple application that you create from a GitLab template. These instructions also work for a self-managed GitLab instance; -ensure your own [runners are configured](../../ci/runners/README.md) and +ensure your own [runners are configured](../../ci/runners/index.md) and [Google OAuth is enabled](../../integration/google.md). ## Configure your Google account @@ -131,7 +131,7 @@ Follow these steps to configure the Base Domain where your apps will be accessib 1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can get the external IP address with the following command: - + ```shell kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip' ``` @@ -155,7 +155,7 @@ these steps to enable Auto DevOps if it's disabled: 1. Navigate to **Settings > CI/CD > Auto DevOps**, and click **Expand**. 1. Select **Default to Auto DevOps pipeline** to display more options. 1. In **Deployment strategy**, select your desired [continuous deployment strategy](index.md#deployment-strategy) - to deploy the application to production after the pipeline successfully runs on the `master` branch. + to deploy the application to production after the pipeline successfully runs on the default branch. 1. Click **Save changes**.  @@ -199,7 +199,7 @@ The jobs are separated into stages: licenses and is allowed to fail ([Auto License Compliance](stages.md#auto-license-compliance)) **(ULTIMATE)** -- **Review** - Pipelines on `master` include this stage with a `dast_environment_deploy` job. +- **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job. To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md). - **Production** - After the tests and checks finish, the application deploys in @@ -208,7 +208,7 @@ The jobs are separated into stages: - **Performance** - Performance tests are run on the deployed application ([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)). **(PREMIUM)** -- **Cleanup** - Pipelines on `master` include this stage with a `stop_dast_environment` job. +- **Cleanup** - Pipelines on the default branch include this stage with a `stop_dast_environment` job. After running a pipeline, you should view your deployed website and learn how to monitor it. @@ -267,7 +267,7 @@ you should next create a feature branch to add content to your application: After submitting the merge request, GitLab runs your pipeline, and all the jobs in it, as [described previously](#deploy-the-application), in addition to -a few more that run only on branches other than `master`. +a few more that run only on branches other than the default branch.  @@ -303,7 +303,7 @@ the **View app** **{external-link}** button to see your changes deployed.  -After merging the merge request, GitLab runs the pipeline on the `master` branch, +After merging the merge request, GitLab runs the pipeline on the default branch, and then deploys the application to production. ## Conclusion @@ -314,7 +314,7 @@ all in GitLab. Despite its automatic nature, Auto DevOps can also be configured and customized to fit your workflow. Here are some helpful resources for further reading: 1. [Auto DevOps](index.md) -1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters) +1. [Multiple Kubernetes clusters](index.md#use-multiple-kubernetes-clusters) 1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)** 1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables) 1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks) diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md index 7e59ecb4916..9c330aede17 100644 --- a/doc/topics/autodevops/requirements.md +++ b/doc/topics/autodevops/requirements.md @@ -62,7 +62,7 @@ To make full use of Auto DevOps with Kubernetes, you need: The runners don't need to be installed in the Kubernetes cluster, but the Kubernetes executor is easy to use and automatically autoscales. You can configure Docker-based runners to autoscale as well, using - [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html). + [Docker Machine](https://docs.gitlab.com/runner/executors/docker_machine.html). Runners should be registered as [shared runners](../../ci/runners/runners_scope.md#shared-runners) for the entire GitLab instance, or [specific runners](../../ci/runners/runners_scope.md#specific-runners) @@ -125,7 +125,7 @@ only the deployment to Kubernetes runs. WARNING: Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml). -However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate) +However, it's not recommended to [include](../../ci/yaml/index.md#includetemplate) it on its own. This template is designed to be used with Auto DevOps only. It may change unexpectedly causing your pipeline to fail if included on its own. Also, the job names within this template may also change. Do not override these jobs' names in your diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md index d3f217d3749..f689183d556 100644 --- a/doc/topics/autodevops/stages.md +++ b/doc/topics/autodevops/stages.md @@ -250,7 +250,7 @@ such as after merging a merge request, the Review App is also deleted. Review apps are deployed using the [auto-deploy-app](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) chart with Helm, which you can [customize](customize.md#custom-helm-chart). The application deploys -into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) +into the [Kubernetes namespace](../../user/project/clusters/deploy_to_cluster.md#deployment-variables) for the environment. In GitLab 11.4 and later, [local Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) is @@ -350,8 +350,7 @@ Any load performance test result differences between the source and target branc Auto Deploy is an optional step for Auto DevOps. If the [requirements](requirements.md) are not met, the job is skipped. -After a branch or merge request is merged into the project's default branch (usually -`master`), Auto Deploy deploys the application to a `production` environment in +After a branch or merge request is merged into the project's default branch, Auto Deploy deploys the application to a `production` environment in the Kubernetes cluster, with a namespace based on the project name and unique project ID, such as `project-4321`. @@ -367,7 +366,7 @@ commands. This is an easy way to Helm uses the [auto-deploy-app](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app) chart to deploy the application into the -[Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables) +[Kubernetes namespace](../../user/project/clusters/deploy_to_cluster.md#deployment-variables) for the environment. In GitLab 11.4 and later, a @@ -542,7 +541,7 @@ You must use a Kubernetes network plugin that implements support for `NetworkPolicy`. The default network plugin for Kubernetes (`kubenet`) [does not implement](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet) support for it. The [Cilium](https://cilium.io/) network plugin can be -installed as a [cluster application](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd) +installed as a [cluster application](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium) to enable support for network policies. You can enable deployment of a network policy by setting the following @@ -578,7 +577,7 @@ networkPolicy: ``` For more information on installing Network Policies, see -[Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd). +[Use the Cluster Management Template to Install Cilium](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium). ### Cilium Network Policy @@ -597,7 +596,7 @@ As the default network plugin for Kubernetes (`kubenet`) support for it, you must have [Cilium](https://docs.cilium.io/en/v1.8/intro/) as your Kubernetes network plugin. The [Cilium](https://cilium.io/) network plugin can be -installed as a [cluster application](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd) +installed with a [cluster management project template](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium) to enable support for network policies. #### Configuration @@ -644,11 +643,10 @@ ciliumNetworkPolicy: enabled: true alerts: enabled: true - ``` For more information on installing Network Policies, see -[Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd). +[Use the Cluster Management Template to Install Cilium](../../user/project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium). ### Running commands in the container diff --git a/doc/topics/autodevops/troubleshooting.md b/doc/topics/autodevops/troubleshooting.md index cf2a2133fa3..cee4ba68b49 100644 --- a/doc/topics/autodevops/troubleshooting.md +++ b/doc/topics/autodevops/troubleshooting.md @@ -49,7 +49,7 @@ To fix this issue, you must either: Auto Deploy fails if GitLab can't create a Kubernetes namespace and service account for your project. For help debugging this issue, see -[Troubleshooting failed deployment jobs](../../user/project/clusters/index.md#troubleshooting). +[Troubleshooting failed deployment jobs](../../user/project/clusters/deploy_to_cluster.md#troubleshooting). ## Detected an existing PostgreSQL database diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md index 48d37e5125c..4cf699ce25a 100644 --- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md +++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md @@ -1,6 +1,6 @@ --- -stage: Release -group: Release +stage: Configure +group: Configure info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments type: reference --- @@ -31,11 +31,11 @@ are using. First verify which template is in use: - [The GitLab.com stable Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml) is being used if **one** of the following is true: - Your Auto DevOps project doesn't have a `.gitlab-ci.yml` file. - - Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/README.md#includetemplate) + - Your Auto DevOps project has a `.gitlab-ci.yml` and [includes](../../ci/yaml/index.md#includetemplate) the `Auto-DevOps.gitlab-ci.yml` template. - [The latest Auto Deploy template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.latest.gitlab-ci.yml) is being used if **both** of the following is true: - - Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/README.md#includetemplate) + - Your Auto DevOps project has a `.gitlab-ci.yml` file and [includes](../../ci/yaml/index.md#includetemplate) the `Auto-DevOps.gitlab-ci.yml` template. - It also includes [the latest Auto Deploy template](#early-adopters) diff --git a/doc/topics/autodevops/upgrading_postgresql.md b/doc/topics/autodevops/upgrading_postgresql.md index 35b9d2e055c..c03c4171d6d 100644 --- a/doc/topics/autodevops/upgrading_postgresql.md +++ b/doc/topics/autodevops/upgrading_postgresql.md @@ -195,7 +195,7 @@ higher*. This is the remove the variables, or rename the variables temporarily to `XDB_INITIALIZE` or the `XDB_MIGRATE` to effectively disable them. 1. Run a new CI pipeline for the branch. In this case, we run a new CI - pipeline for `master`. + pipeline for `main`. 1. After the pipeline is successful, your application is upgraded with the new PostgreSQL installed. Zero replicas exist at this time, so no traffic is served for your application (to prevent @@ -250,5 +250,5 @@ steps to reinstate your application: removed or disabled. 1. Restore the `PRODUCTION_REPLICAS` or `REPLICAS` variable to its original value. 1. Run a new CI pipeline for the branch. In this case, we run a new CI - pipeline for `master`. After the pipeline is successful, your + pipeline for `main`. After the pipeline is successful, your application should be serving traffic as before. |