diff options
Diffstat (limited to 'doc/topics/autodevops/index.md')
| -rw-r--r-- | doc/topics/autodevops/index.md | 297 |
1 files changed, 20 insertions, 277 deletions
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index d95e5568e0b..44072147fde 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -6,50 +6,36 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Auto DevOps **(FREE)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) in GitLab 10.0. > - Generally available on GitLab 11.0. -Auto DevOps are default CI/CD templates that auto-discover the source code you have. They -enable GitLab to automatically detect, build, test, deploy, and monitor your applications. -Leveraging [CI/CD best practices](../../ci/pipelines/pipeline_efficiency.md) and tools, -Auto DevOps aims to simplify the setup and execution of a mature and modern software -development lifecycle. +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 +testing. -## Overview +Using Auto DevOps, you can: -You can spend a lot of effort to set up the workflow and processes required to -build, deploy, and monitor your project. It gets worse when your company has -hundreds, if not thousands, of projects to maintain. With new projects -constantly starting up, the entire software development process becomes -impossibly complex to manage. +- Detect the language of your code. +- Automatically build, test, and measure code quality. +- Scan for potential vulnerabilities, security flaws, and licensing issues. +- Monitor in real-time. +- Deploy your application. -Auto DevOps provides you a seamless software development process by -automatically detecting all dependencies and language technologies required to -test, build, package, deploy, and monitor every project with minimal -configuration. Automation enables consistency across your projects, seamless -management of processes, and faster creation of new projects: push your code, -and GitLab does the rest, improving your productivity and efficiency. +The functionality of Auto DevOps is based on default CI/CD templates that +auto-discover your source code. These templates enable GitLab to provide +consistency across your projects, seamless management of processes, and faster +creation of new projects. Leveraging [CI/CD best practices](../../ci/pipelines/pipeline_efficiency.md) +and tools, Auto DevOps lets you push your code, with GitLab doing the rest, +improving your productivity and efficiency. <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> -For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4). +For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4) or see this [overview](https://about.gitlab.com/stages-devops-lifecycle/auto-devops/). For requirements, read [Requirements for Auto DevOps](requirements.md) for more information. For a developer's guide, read [Auto DevOps development guide](../../development/auto_devops.md). -### Share your feedback - -As Auto DevOps continues to gain popularity, and lowers the barrier to entry for -getting started with DevOps and CI/CD, see what our wider community is saying: - -From [AlexJonesax](https://twitter.com/AlexJonesax) and [KaiPMDH](https://twitter.com/KaiPMDH) on Twitter: - - - - - -We welcome everyone to [share your experience by tagging GitLab on Twitter](https://twitter.com/gitlab). - ## Enabled by default > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3. @@ -162,7 +148,7 @@ any of the following places: [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** under the +- or as an instance-wide fallback in **Admin Area > Settings > CI/CD** under the **Continuous Integration and Delivery** section The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence @@ -238,7 +224,7 @@ 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. Go to **Admin Area > Settings > Continuous Integration and Deployment**. +1. Go to **Admin Area > 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. @@ -348,246 +334,3 @@ spec: - name: https_proxy value: "PUT_YOUR_HTTPS_PROXY_HERE" ``` - -## Troubleshooting - -### Unable to select a buildpack - -Auto Build and Auto Test may fail to detect your language or framework with the -following error: - -```plaintext -Step 5/11 : RUN /bin/herokuish buildpack build - ---> Running in eb468cd46085 - -----> Unable to select a buildpack -The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1 -``` - -The following are possible reasons: - -- Your application may be missing the key files the buildpack is looking for. - Ruby applications require a `Gemfile` to be properly detected, - even though it's possible to write a Ruby app without a `Gemfile`. -- No buildpack may exist for your application. Try specifying a - [custom buildpack](customize.md#custom-buildpacks). - -### Pipeline that extends Auto DevOps with only / except fails - -If your pipeline fails with the following message: - -```plaintext -Found errors in your .gitlab-ci.yml: - - jobs:test config key may not be used with `rules`: only -``` - -This error appears when the included job’s rules configuration has been overridden with the `only` or `except` syntax. -To fix this issue, you must either: - -- Transition your `only/except` syntax to rules. -- (Temporarily) Pin your templates to the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12-10). - -### Failure to create a Kubernetes namespace - -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). - -### Detected an existing PostgreSQL database - -After upgrading to GitLab 13.0, you may encounter this message when deploying -with Auto DevOps: - -```plaintext -Detected an existing PostgreSQL database installed on the -deprecated channel 1, but the current channel is set to 2. The default -channel changed to 2 in of GitLab 13.0. -[...] -``` - -Auto DevOps, by default, installs an in-cluster PostgreSQL database alongside -your application. The default installation method changed in GitLab 13.0, and -upgrading existing databases requires user involvement. The two installation -methods are: - -- **channel 1 (deprecated):** Pulls in the database as a dependency of the associated - Helm chart. Only supports Kubernetes versions up to version 1.15. -- **channel 2 (current):** Installs the database as an independent Helm chart. Required - for using the in-cluster database feature with Kubernetes versions 1.16 and greater. - -If you receive this error, you can do one of the following actions: - -- You can *safely* ignore the warning and continue using the channel 1 PostgreSQL - database by setting `AUTO_DEVOPS_POSTGRES_CHANNEL` to `1` and redeploying. - -- You can delete the channel 1 PostgreSQL database and install a fresh channel 2 - database by setting `AUTO_DEVOPS_POSTGRES_DELETE_V1` to a non-empty value and - redeploying. - - WARNING: - Deleting the channel 1 PostgreSQL database permanently deletes the existing - channel 1 database and all its data. See - [Upgrading PostgreSQL](upgrading_postgresql.md) - for more information on backing up and upgrading your database. - -- If you are not using the in-cluster database, you can set - `POSTGRES_ENABLED` to `false` and re-deploy. This option is especially relevant to - users of *custom charts without the in-chart PostgreSQL dependency*. - Database auto-detection is based on the `postgresql.enabled` Helm value for - your release. This value is set based on the `POSTGRES_ENABLED` CI variable - and persisted by Helm, regardless of whether or not your chart uses the - variable. - -WARNING: -Setting `POSTGRES_ENABLED` to `false` permanently deletes any existing -channel 1 database for your environment. - -### Error: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1" - -After upgrading your Kubernetes cluster to [v1.16+](stages.md#kubernetes-116), -you may encounter this message when deploying with Auto DevOps: - -```plaintext -UPGRADE FAILED -Error: failed decoding reader into objects: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1" -``` - -This can occur if your current deployments on the environment namespace were deployed with a -deprecated/removed API that doesn't exist in Kubernetes v1.16+. For example, -if [your in-cluster PostgreSQL was installed in a legacy way](#detected-an-existing-postgresql-database), -the resource was created via the `extensions/v1beta1` API. However, the deployment resource -was moved to the `app/v1` API in v1.16. - -To recover such outdated resources, you must convert the current deployments by mapping legacy APIs -to newer APIs. There is a helper tool called [`mapkubeapis`](https://github.com/hickeyma/helm-mapkubeapis) -that works for this problem. Follow these steps to use the tool in Auto DevOps: - -1. Modify your `.gitlab-ci.yml` with: - - ```yaml - include: - - template: Auto-DevOps.gitlab-ci.yml - - remote: https://gitlab.com/shinya.maeda/ci-templates/-/raw/master/map-deprecated-api.gitlab-ci.yml - - variables: - HELM_VERSION_FOR_MAPKUBEAPIS: "v2" # If you're using auto-depoy-image v2 or above, please specify "v3". - ``` - -1. Run the job `<environment-name>:map-deprecated-api`. Ensure that this job succeeds before moving - to the next step. You should see something like the following output: - - ```shell - 2020/10/06 07:20:49 Found deprecated or removed Kubernetes API: - "apiVersion: extensions/v1beta1 - kind: Deployment" - Supported API equivalent: - "apiVersion: apps/v1 - kind: Deployment" - ``` - -1. Revert your `.gitlab-ci.yml` to the previous version. You no longer need to include the - supplemental template `map-deprecated-api`. - -1. Continue the deployments as usual. - -### Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached - -As [announced in the official CNCF blog post](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/), -the stable Helm chart repository was deprecated and removed on November 13th, 2020. -You may encounter this error after that date. - -Some GitLab features had dependencies on the stable chart. To mitigate the impact, we changed them -to use new official repositories or the [Helm Stable Archive repository maintained by GitLab](https://gitlab.com/gitlab-org/cluster-integration/helm-stable-archive). -Auto Deploy contains [an example fix](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/merge_requests/127). - -In Auto Deploy, `v1.0.6+` of `auto-deploy-image` no longer adds the deprecated stable repository to -the `helm` command. If you use a custom chart and it relies on the deprecated stable repository, -specify an older `auto-deploy-image` like this example: - -```yaml -include: - - template: Auto-DevOps.gitlab-ci.yml - -.auto-deploy: - image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v1.0.5" -``` - -Keep in mind that this approach stops working when the stable repository is removed, -so you must eventually fix your custom chart. - -To fix your custom chart: - -1. In your chart directory, update the `repository` value in your `requirements.yaml` file from : - - ```yaml - repository: "https://kubernetes-charts.storage.googleapis.com/" - ``` - - to: - - ```yaml - repository: "https://charts.helm.sh/stable" - ``` - -1. In your chart directory, run `helm dep update .` using the same Helm major version as Auto DevOps. -1. Commit the changes for the `requirements.yaml` file. -1. If you previously had a `requirements.lock` file, commit the changes to the file. - If you did not previously have a `requirements.lock` file in your chart, - you do not need to commit the new one. This file is optional, but when present, - it's used to verify the integrity of the downloaded dependencies. - -You can find more information in -[issue #263778, "Migrate PostgreSQL from stable Helm repository"](https://gitlab.com/gitlab-org/gitlab/-/issues/263778). - -### Error: release .... failed: timed out waiting for the condition - -When getting started with Auto DevOps, you may encounter this error when first -deploying your application: - -```plaintext -INSTALL FAILED -PURGING CHART -Error: release staging failed: timed out waiting for the condition -``` - -This is most likely caused by a failed liveness (or readiness) probe attempted -during the deployment process. By default, these probes are run against the root -page of the deployed application on port 5000. If your application isn't configured -to serve anything at the root page, or is configured to run on a specific port -*other* than 5000, this check fails. - -If it fails, you should see these failures in the events for the relevant -Kubernetes namespace. These events look like the following example: - -```plaintext -LAST SEEN TYPE REASON OBJECT MESSAGE -3m20s Warning Unhealthy pod/staging-85db88dcb6-rxd6g Readiness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused -3m32s Warning Unhealthy pod/staging-85db88dcb6-rxd6g Liveness probe failed: Get http://10.192.0.6:5000/: dial tcp 10.192.0.6:5000: connect: connection refused -``` - -To change the port used for the liveness checks, pass -[custom values to the Helm chart](customize.md#customize-values-for-helm-chart) -used by Auto DevOps: - -1. Create a directory and file at the root of your repository named `.gitlab/auto-deploy-values.yaml`. - -1. Populate the file with the following content, replacing the port values with - the actual port number your application is configured to use: - - ```yaml - service: - internalPort: <port_value> - externalPort: <port_value> - ``` - -1. Commit your changes. - -After committing your changes, subsequent probes should use the newly-defined ports. -The page that's probed can also be changed by overriding the `livenessProbe.path` -and `readinessProbe.path` values (shown in the -[default `values.yaml`](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/blob/master/assets/auto-deploy-app/values.yaml) -file) in the same fashion. - -## Development guides - -[Development guide for Auto DevOps](../../development/auto_devops.md) |