diff options
Diffstat (limited to 'doc/topics/autodevops')
34 files changed, 115 insertions, 82 deletions
diff --git a/doc/topics/autodevops/img/disable_postgres.png b/doc/topics/autodevops/img/disable_postgres.png Binary files differnew file mode 100644 index 00000000000..f8fe508915c --- /dev/null +++ b/doc/topics/autodevops/img/disable_postgres.png diff --git a/doc/topics/autodevops/img/guide_base_domain_v12_3.png b/doc/topics/autodevops/img/guide_base_domain_v12_3.png Binary files differnew file mode 100644 index 00000000000..0c8ab9b26e4 --- /dev/null +++ b/doc/topics/autodevops/img/guide_base_domain_v12_3.png diff --git a/doc/topics/autodevops/img/guide_choose_gke.png b/doc/topics/autodevops/img/guide_choose_gke.png Binary files differdeleted file mode 100644 index 6da3a7220da..00000000000 --- a/doc/topics/autodevops/img/guide_choose_gke.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_cluster_apps.png b/doc/topics/autodevops/img/guide_cluster_apps.png Binary files differdeleted file mode 100644 index 33d25f2950d..00000000000 --- a/doc/topics/autodevops/img/guide_cluster_apps.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png b/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png Binary files differnew file mode 100644 index 00000000000..f903ae40c02 --- /dev/null +++ b/doc/topics/autodevops/img/guide_cluster_apps_v12_3.png diff --git a/doc/topics/autodevops/img/guide_create_project.png b/doc/topics/autodevops/img/guide_create_project.png Binary files differdeleted file mode 100644 index 4ed1071db03..00000000000 --- a/doc/topics/autodevops/img/guide_create_project.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_create_project_v12_3.png b/doc/topics/autodevops/img/guide_create_project_v12_3.png Binary files differnew file mode 100644 index 00000000000..68ab7f23f3c --- /dev/null +++ b/doc/topics/autodevops/img/guide_create_project_v12_3.png diff --git a/doc/topics/autodevops/img/guide_enable_autodevops.png b/doc/topics/autodevops/img/guide_enable_autodevops.png Binary files differdeleted file mode 100644 index 0fc3ecca19a..00000000000 --- a/doc/topics/autodevops/img/guide_enable_autodevops.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png b/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png Binary files differnew file mode 100644 index 00000000000..7f0e7c60086 --- /dev/null +++ b/doc/topics/autodevops/img/guide_enable_autodevops_v12_3.png diff --git a/doc/topics/autodevops/img/guide_environments.png b/doc/topics/autodevops/img/guide_environments.png Binary files differdeleted file mode 100644 index 404db17c57a..00000000000 --- a/doc/topics/autodevops/img/guide_environments.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_environments_metrics.png b/doc/topics/autodevops/img/guide_environments_metrics.png Binary files differdeleted file mode 100644 index f0d31f31581..00000000000 --- a/doc/topics/autodevops/img/guide_environments_metrics.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png b/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png Binary files differnew file mode 100644 index 00000000000..74f997a5122 --- /dev/null +++ b/doc/topics/autodevops/img/guide_environments_metrics_v12_3.png diff --git a/doc/topics/autodevops/img/guide_environments_v12_3.png b/doc/topics/autodevops/img/guide_environments_v12_3.png Binary files differnew file mode 100644 index 00000000000..0ad282cfe4e --- /dev/null +++ b/doc/topics/autodevops/img/guide_environments_v12_3.png diff --git a/doc/topics/autodevops/img/guide_first_pipeline.png b/doc/topics/autodevops/img/guide_first_pipeline.png Binary files differdeleted file mode 100644 index 57459dcc9d9..00000000000 --- a/doc/topics/autodevops/img/guide_first_pipeline.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png b/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png Binary files differnew file mode 100644 index 00000000000..7654b4f0934 --- /dev/null +++ b/doc/topics/autodevops/img/guide_first_pipeline_v12_3.png diff --git a/doc/topics/autodevops/img/guide_gitlab_gke_details.png b/doc/topics/autodevops/img/guide_gitlab_gke_details.png Binary files differdeleted file mode 100644 index bc5a53800f7..00000000000 --- a/doc/topics/autodevops/img/guide_gitlab_gke_details.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png b/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png Binary files differnew file mode 100644 index 00000000000..ba2b00dd984 --- /dev/null +++ b/doc/topics/autodevops/img/guide_gitlab_gke_details_v12_3.png diff --git a/doc/topics/autodevops/img/guide_google_auth.png b/doc/topics/autodevops/img/guide_google_auth_v12_3.png Binary files differindex b97b2be9f15..b97b2be9f15 100644 --- a/doc/topics/autodevops/img/guide_google_auth.png +++ b/doc/topics/autodevops/img/guide_google_auth_v12_3.png diff --git a/doc/topics/autodevops/img/guide_google_signin.png b/doc/topics/autodevops/img/guide_google_signin.png Binary files differdeleted file mode 100644 index e59fc94bd4c..00000000000 --- a/doc/topics/autodevops/img/guide_google_signin.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_google_signin_v12_3.png b/doc/topics/autodevops/img/guide_google_signin_v12_3.png Binary files differnew file mode 100644 index 00000000000..ac8a325dde6 --- /dev/null +++ b/doc/topics/autodevops/img/guide_google_signin_v12_3.png diff --git a/doc/topics/autodevops/img/guide_ide_commit.png b/doc/topics/autodevops/img/guide_ide_commit.png Binary files differdeleted file mode 100644 index d7be66f4049..00000000000 --- a/doc/topics/autodevops/img/guide_ide_commit.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_ide_commit_v12_3.png b/doc/topics/autodevops/img/guide_ide_commit_v12_3.png Binary files differnew file mode 100644 index 00000000000..c40658e9ba9 --- /dev/null +++ b/doc/topics/autodevops/img/guide_ide_commit_v12_3.png diff --git a/doc/topics/autodevops/img/guide_merge_request.png b/doc/topics/autodevops/img/guide_merge_request.png Binary files differdeleted file mode 100644 index d78e69be776..00000000000 --- a/doc/topics/autodevops/img/guide_merge_request.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app.png b/doc/topics/autodevops/img/guide_merge_request_review_app.png Binary files differdeleted file mode 100644 index 1b9b854ddac..00000000000 --- a/doc/topics/autodevops/img/guide_merge_request_review_app.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png b/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png Binary files differnew file mode 100644 index 00000000000..e1a4f181744 --- /dev/null +++ b/doc/topics/autodevops/img/guide_merge_request_review_app_v12_3.png diff --git a/doc/topics/autodevops/img/guide_merge_request_v12_3.png b/doc/topics/autodevops/img/guide_merge_request_v12_3.png Binary files differnew file mode 100644 index 00000000000..8c70620162c --- /dev/null +++ b/doc/topics/autodevops/img/guide_merge_request_v12_3.png diff --git a/doc/topics/autodevops/img/guide_pipeline_stages.png b/doc/topics/autodevops/img/guide_pipeline_stages.png Binary files differdeleted file mode 100644 index 6e2f078152b..00000000000 --- a/doc/topics/autodevops/img/guide_pipeline_stages.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png b/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png Binary files differnew file mode 100644 index 00000000000..f55a985f543 --- /dev/null +++ b/doc/topics/autodevops/img/guide_pipeline_stages_v12_3.png diff --git a/doc/topics/autodevops/img/guide_project_landing_page.png b/doc/topics/autodevops/img/guide_project_landing_page.png Binary files differdeleted file mode 100644 index 4f8d2eb10b1..00000000000 --- a/doc/topics/autodevops/img/guide_project_landing_page.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png b/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png Binary files differnew file mode 100644 index 00000000000..4d62588ed90 --- /dev/null +++ b/doc/topics/autodevops/img/guide_project_landing_page_v12_3.png diff --git a/doc/topics/autodevops/img/guide_project_template.png b/doc/topics/autodevops/img/guide_project_template.png Binary files differdeleted file mode 100644 index 298ac0f6fcf..00000000000 --- a/doc/topics/autodevops/img/guide_project_template.png +++ /dev/null diff --git a/doc/topics/autodevops/img/guide_project_template_v12_3.png b/doc/topics/autodevops/img/guide_project_template_v12_3.png Binary files differnew file mode 100644 index 00000000000..9ce730518d0 --- /dev/null +++ b/doc/topics/autodevops/img/guide_project_template_v12_3.png diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index e42c89ac567..a1373639a87 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -77,7 +77,7 @@ As Auto DevOps relies on many different components, it's good to have a basic knowledge of the following: - [Kubernetes](https://kubernetes.io/docs/home/) -- [Helm](https://docs.helm.sh/) +- [Helm](https://helm.sh/docs/) - [Docker](https://docs.docker.com) - [GitLab Runner](https://docs.gitlab.com/runner/) - [Prometheus](https://prometheus.io/docs/introduction/overview/) @@ -85,7 +85,7 @@ knowledge of the following: Auto DevOps provides great defaults for all the stages; you can, however, [customize](#customizing) almost everything to your needs. -For an overview on the creation of Auto DevOps, read the blog post [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci/). +For an overview on the creation of Auto DevOps, read the blog post [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/). NOTE: **Note** Kubernetes clusters can [be used without](../../user/project/clusters/index.md) @@ -98,7 +98,7 @@ To make full use of Auto DevOps, you will need: - **GitLab Runner** (for all stages) Your Runner needs to be configured to be able to run Docker. Generally this - means using the either the [Docker](https://docs.gitlab.com/runner/executors/docker.html) + means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html) or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode). @@ -122,9 +122,9 @@ To make full use of Auto DevOps, you will need: - Kubernetes 1.5+. - A [Kubernetes cluster][kubernetes-clusters] for the project. - - A load balancer. You can use NGINX ingress by deploying it to your + - A load balancer. You can use NGINX Ingress by deploying it to your Kubernetes cluster by either: - - Using the [`nginx-ingress`](https://github.com/kubernetes/charts/tree/master/stable/nginx-ingress) Helm chart. + - Using the [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) Helm chart. - Installing the Ingress [GitLab Managed App](../../user/clusters/applications.md#ingress). - **Prometheus** (for Auto Monitoring) @@ -172,7 +172,7 @@ and `1.2.3.4` is the IP address of your load balancer; generally NGINX ([see requirements](#requirements)). How to set up the DNS record is beyond the scope of this document; you should check with your DNS provider. -Alternatively you can use free public services like [nip.io](http://nip.io) +Alternatively you can use free public services like [nip.io](https://nip.io) which provide automatic wildcard DNS without any configuration. Just set the Auto DevOps base domain to `1.2.3.4.nip.io`. @@ -331,7 +331,7 @@ If a project's repository contains a `Dockerfile`, Auto Build will use If you are also using Auto Review Apps and Auto Deploy and choose to provide your own `Dockerfile`, make sure you expose your application to port `5000` as this is the port assumed by the -[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy helm chart](#custom-helm-chart) +[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy Helm chart](#custom-helm-chart) #### Auto Build using Heroku buildpacks @@ -487,6 +487,9 @@ in the first place, and thus not realize that it needs to re-apply the old confi > Introduced in [GitLab Ultimate][ee] 10.4. +This is an optional step, since it requires a [review app](#auto-review-apps). +If that requirement is not met, the job will be silently skipped. + Dynamic Application Security Testing (DAST) uses the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) to perform an analysis on the current code and checks for potential security @@ -498,6 +501,29 @@ later download and check out. Any security warnings are also shown in the merge request widget. Read how [DAST works](../../user/application_security/dast/index.md). +On your default branch, DAST scans an app deployed specifically for that purpose. +The app is deleted after DAST has run. + +On feature branches, DAST scans the [review app](#auto-review-apps). + +#### Overriding the DAST target + +To use a custom target instead of the auto-deployed review apps, +set a `DAST_WEBSITE` environment variable to the URL for DAST to scan. + +NOTE: **Note:** +If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is enabled, it is strongly advised **not** +to set `DAST_WEBSITE` to any staging or production environment. DAST Full Scan +actively attacks the target, which can take down the application and lead to +data loss or corruption. + +#### Disabling Auto DAST + +DAST can be disabled: + +- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`. +- Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH` environment variable to `"true"`. + ### Auto Browser Performance Testing **(PREMIUM)** > Introduced in [GitLab Premium][ee] 10.4. @@ -529,7 +555,7 @@ Auto Deploy doesn't include deployments to staging or canary by default, but the enable them. You can make use of [environment variables](#environment-variables) to automatically -scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy helm chart](#custom-helm-chart). +scale your pod replicas and to apply custom arguments to the Auto DevOps `helm upgrade` commands. This is an easy way to [customize the Auto Deploy Helm chart](#custom-helm-chart). Apps are deployed using the [auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app) chart with @@ -572,7 +598,7 @@ within the application pod by setting the project variables `DB_INITIALIZE` and `DB_MIGRATE` respectively. If present, `DB_INITIALIZE` will be run as a shell command within an -application pod as a helm post-install hook. As some applications will +application pod as a Helm post-install hook. As some applications will not run without a successful database initialization step, GitLab will deploy the first release without the application deployment and only the database initialization step. After the database initialization completes, @@ -583,7 +609,7 @@ Note that a post-install hook means that if any deploy succeeds, `DB_INITIALIZE` will not be processed thereafter. If present, `DB_MIGRATE` will be run as a shell command within an application pod as -a helm pre-upgrade hook. +a Helm pre-upgrade hook. For example, in a Rails application in an image built with [Herokuish](https://github.com/gliderlabs/herokuish): @@ -734,14 +760,16 @@ Avoid passing secrets as Docker build arguments if possible, as they may be persisted in your image. See [this discussion](https://github.com/moby/moby/issues/13490) for details. -### Passing secrets to `docker build` (beta) +### Passing secrets to `docker build` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/25514) in GitLab 12.3, but available in versions 11.9 and above. CI environment variables can be passed as [build secrets](https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-secret-information) to the `docker build` command by listing them comma separated by name in the `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` variable. For example, in order to forward the variables `CI_COMMIT_SHA` and `CI_ENVIRONMENT_NAME`, one would set `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` to `CI_COMMIT_SHA,CI_ENVIRONMENT_NAME`. Unlike build arguments, these are not persisted by Docker in the final image -(though you can still persist them yourself, so be careful). +(though you can still persist them yourself, so **be careful**). In projects: @@ -845,6 +873,35 @@ the database are preconfigured, but can be customized by setting the associated postgres://user:password@postgres-host:postgres-port/postgres-database ``` +#### Using external PostgreSQL database providers + +While Auto DevOps provides out-of-the-box support for a PostgreSQL container for +production environments, for some use-cases it may not be sufficiently secure or +resilient and you may wish to use an external managed provider for PostgreSQL. +For example, AWS Relational Database Service. + +You will need to define environment-scoped variables for `POSTGRES_ENABLED` and `DATABASE_URL` in your project's CI/CD settings. + +To achieve this: + +1. Disable the built-in PostgreSQL installation for the required environments using + scoped [environment variables](../../ci/environments.md#scoping-environments-with-specs). + For this use case, it's likely that only `production` will need to be added to this + list as the builtin PostgreSQL setup for Review Apps and staging will be sufficient + as a high availability setup is not required. + +  + +1. Define the `DATABASE_URL` CI variable as a scoped environment variable that will be + available to your application. This should be a URL in the following format: + + ```yaml + postgres://user:password@postgres-host:postgres-port/postgres-database + ``` + +You will need to ensure that your Kubernetes cluster has network access to wherever +PostgreSQL is hosted. + ### Environment variables The following variables can be used for setting up the Auto DevOps domain, @@ -858,27 +915,27 @@ applications. | **Variable** | **Description** | |-----------------------------------------|------------------------------------| -| `ADDITIONAL_HOSTS` | Fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. | -| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. | +| `ADDITIONAL_HOSTS` | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. | +| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. | | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | Extra arguments to be passed to the `docker build` command. Note that using quotes will not prevent word splitting. [More details](#passing-arguments-to-docker-build). | -| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#passing-secrets-to-docker-build-beta) to be passed to the `docker build` command as secrets. | +| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#passing-secrets-to-docker-build) to be passed to the `docker build` command as secrets. | | `AUTO_DEVOPS_CHART` | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/charts/auto-deploy-app). | | `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. | -| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | From Gitlab 11.11, used to set the name of the helm repository. Defaults to `gitlab`. | -| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From Gitlab 11.11, used to set a username to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. | -| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From Gitlab 11.11, used to set a password to connect to the helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. | +| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. | +| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From GitLab 11.11, used to set a username to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. | +| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. | | `BUILDPACK_URL` | Buildpack's full URL. Can point to either Git repositories or a tarball URL. For Git repositories, it is possible to point to a specific `ref`. For example `https://github.com/heroku/heroku-buildpack-ruby.git#v142`. | | `CANARY_ENABLED` | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments-premium). | | `CANARY_PRODUCTION_REPLICAS` | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. | | `CANARY_REPLICAS` | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md). Defaults to 1. | | `HELM_RELEASE_NAME` | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. | -| `HELM_UPGRADE_EXTRA_ARGS` | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. | +| `HELM_UPGRADE_EXTRA_ARGS` | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes will not prevent word splitting. **Tip:** you can use this variable to [customize the Auto Deploy Helm chart](#custom-helm-chart) by applying custom override values with `--values my-values.yaml`. | | `INCREMENTAL_ROLLOUT_MODE` | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production-premium) 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) will be 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. | | `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`. | +| `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`. | | `ROLLOUT_STATUS_DISABLED` | From GitLab 12.0, used to disable rollout status check because it doesn't support all resource types, for example, `cronjob`. | | `STAGING_ENABLED` | From GitLab 10.8, used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). | @@ -1138,13 +1195,13 @@ This configuration is deprecated and will be removed in the future. TIP: **Tip:** You can also set this inside your [project's settings](#deployment-strategy). -This configuration based on +This configuration is based on [incremental rollout to production](#incremental-rollout-to-production-premium). Everything behaves the same way, except: - It's enabled by setting the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`. -- Instead of the standard `production` job, the following jobs with a 5 minute delay between each are created: +- Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each : 1. `timed rollout 10%` 1. `timed rollout 25%` 1. `timed rollout 50%` @@ -1181,22 +1238,6 @@ As of GitLab 10.0, the supported buildpacks are: The following restrictions apply. -### Private project support - -CAUTION: **Caution:** Private project support in Auto DevOps is experimental. - -When a project has been marked as private, GitLab's [Container -Registry][container-registry] requires authentication when downloading -containers. Auto DevOps will automatically provide the required authentication -information to Kubernetes, allowing temporary access to the registry. -Authentication credentials will be valid while the pipeline is running, allowing -for a successful initial deployment. - -After the pipeline completes, Kubernetes will no longer be able to access the -Container Registry. **Restarting a pod, scaling a service, or other actions which -require on-going access to the registry may fail**. On-going secure access is -planned for a subsequent release. - ### Private registry support There is no documented way of using private container registry with Auto DevOps. @@ -1265,11 +1306,11 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/ [review-app]: ../../ci/review_apps/index.md [container-registry]: ../../user/packages/container_registry/index.md [postgresql]: https://www.postgresql.org/ -[Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml +[Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml [ee]: https://about.gitlab.com/pricing/ [ce-21955]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/21955 [ce-19507]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/19507 ## Development guides -Configuring [GDK for Auto DevOps](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/auto_devops.md). +[Development guide for Auto DevOps](../../development/auto_devops.md) diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index d0ff149cf31..d9bdd73221f 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -25,7 +25,7 @@ Google account (for example, one that you use to access Gmail, Drive, etc.) or c TIP: **Tip:** Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial), and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab's -Google Kubernetes Engine Integration. All you have to do is [follow this link](https://goo.gl/AaJzRW) and apply for credit. +Google Kubernetes Engine Integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit. ## Creating a new project from a template @@ -35,16 +35,16 @@ those projects provide a barebones application built on some well-known framewor 1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select **New project**. 1. Go to the **Create from template** tab where you can choose among a Ruby on - Rails, Spring, or NodeJS Express project. For this example, - we'll use the Ruby on Rails template. + Rails, Spring, or NodeJS Express project. + We'll use the Ruby on Rails template. -  +  1. Give your project a name, optionally a description, and make it public so that you can take advantage of the features available in the [GitLab Gold plan](https://about.gitlab.com/pricing/#gitlab-com). -  +  1. Click **Create project**. @@ -56,37 +56,30 @@ under which this application will be deployed. 1. On the project's landing page, click the button labeled **Add Kubernetes cluster** (note that this option is also available when you navigate to **Operations > Kubernetes**). -  +  -1. Choose **Create on Google Kubernetes Engine**. +1. One the **Create new cluster on GKE** tab, click "Sign in with Google". -  - -1. Sign in with Google. - -  +  1. Connect with your Google account and press **Allow** when asked (this will be shown only the first time you connect GitLab with your Google account). -  +  -1. The last step is to fill in the cluster details. Give it a name, leave the +1. The last step is to provide the cluster details. Give it a name, leave the environment scope as is, and choose the GCP project under which the cluster will be created. (Per the instructions when you [configured your Google account](#configuring-your-google-account), a project should have already been created for you.) Next, choose the [region/zone](https://cloud.google.com/compute/docs/regions-zones/) under which the cluster will be created, enter the number of nodes you want it to have, and - finally choose their [machine type](https://cloud.google.com/compute/docs/machine-types). + finally choose the [machine type](https://cloud.google.com/compute/docs/machine-types). -  +  1. Once ready, click **Create Kubernetes cluster**. -NOTE: **Note:** -Do not select `f1-micro` from the **Machine type** dropdown. `f1-micro` machines cannot support a full GitLab installation. - After a couple of minutes, the cluster will be created. You can also see its status on your [GCP dashboard](https://console.cloud.google.com/kubernetes). @@ -99,7 +92,7 @@ GitLab's Kubernetes integration comes with some [pre-defined applications](../../user/project/clusters/index.md#installing-applications) for you to install. - + The first one to install is Helm Tiller, a package manager for Kubernetes, which is needed in order to install the rest of the applications. Go ahead and click @@ -113,32 +106,31 @@ use to supervise the deployed application. We will not install GitLab Runner as we'll use the shared Runners that GitLab.com provides. After the Ingress is installed, wait a few seconds and copy the IP address that -is displayed, which we'll use in the next step when enabling Auto DevOps. +is displayed in order to add in your base **Domain** at the top of the page. For +the purpose of this guide, we will use the one suggested by GitLab. Once you have +filled in the domain, click **Save changes**. + + -## Enabling Auto DevOps +## Enabling Auto DevOps (optional) -Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps. +Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable +Auto DevOps at both the instance-level (for self-managed instances) and also at the group-level. +Follow these steps if Auto DevOps has been manually disabled. 1. First, navigate to **Settings > CI/CD > Auto DevOps**. -1. Select **Enable Auto DevOps**. -1. Add in your base **Domain** by using the one GitLab suggests. Note that - generally, you would associate the IP address with a domain name on your - registrar's settings. In this case, for the sake of the guide, we will use - an alternative DNS that will map any domain name of the scheme - `anything.ip_address.nip.io` to the corresponding `ip_address`. For example, - if the IP address of the Ingress is `1.2.3.4`, the domain name to fill in - would be `1.2.3.4.nip.io`. +1. Select **Default to Auto DevOps pipeline**. 1. Lastly, let's select the [continuous deployment strategy](index.md#deployment-strategy) which will automatically deploy the application to production once the pipeline successfully runs on the `master` branch. 1. Click **Save changes**. -  +  Once you complete all the above and save your changes, a new pipeline is automatically created. To view the pipeline, go to **CI/CD > Pipelines**. - + In the next section we'll break down the pipeline and explain what each job does. @@ -149,7 +141,7 @@ By now you should see the pipeline running, but what is it running exactly? To navigate inside the pipeline, click its status badge. (Its status should be "running"). The pipeline is split into 4 stages, each running a couple of jobs. - + In the **build** stage, the application is built into a Docker image and then uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](index.md#auto-build)). @@ -190,7 +182,7 @@ page where you can also monitor your application. Let's explore that. Now that the application is successfully deployed, let's navigate to its website. First, go to **Operations > Environments**. - + In **Environments** you can see some details about the deployed applications. In the rightmost column for the production environment, you can make use of the three icons: @@ -201,7 +193,7 @@ applications. In the rightmost column for the production environment, you can ma Prometheus collects data about the Kubernetes cluster and how the application affects it (in terms of memory/CPU usage, latency, etc.). -  +  - The third icon is the [web terminal](../../ci/environments.md#web-terminals) and it will open a terminal session right inside the container where the @@ -235,13 +227,13 @@ you're on the Web IDE, make the following change: Stage the file, add a commit message, and create a new branch and a merge request by clicking **Commit**. - + Once you submit the merge request, you'll see the pipeline running. This will run all the jobs as [described previously](#deploying-the-application), as well as a few more that run only on branches other than `master`. - + After a few minutes you'll notice that there was a failure in a test. This means there's a test that was 'broken' by our change. @@ -259,7 +251,7 @@ bin/rails test test/controllers/welcome_controller_test.rb:4 Let's fix that: -1. Back to the merge request, click the **Web IDE** button. +1. Back to the merge request, click the **Open in Web IDE** button. 1. Find the `test/controllers/welcome_controller_test.rb` file and open it. 1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.` 1. Click **Commit**. @@ -269,10 +261,10 @@ Let's fix that: Now, if you go back to the merge request you should not only see the test passing, but also the application deployed as a [review app](index.md#auto-review-apps). You -can visit it by following the URL in the merge request. The changes that we -previously made should be there. +can visit it by following clicking the **View app** button. You will see +the changes that we previously made. - + Once you merge the merge request, the pipeline will run on the `master` branch, and the application will be eventually deployed straight to production. |
