diff options
Diffstat (limited to 'doc/topics')
22 files changed, 228 insertions, 60 deletions
diff --git a/doc/topics/application_development_platform/index.md b/doc/topics/application_development_platform/index.md index 85741c4b631..c38b067f1f3 100644 --- a/doc/topics/application_development_platform/index.md +++ b/doc/topics/application_development_platform/index.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Application Development Platform The GitLab Application Development Platform refers to the set of GitLab features used to create, configure, and manage diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md index 9e37ebb699b..8a876e07791 100644 --- a/doc/topics/authentication/index.md +++ b/doc/topics/authentication/index.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Authentication This page gathers all the resources for the topic **Authentication** within GitLab. diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 0026cf4d18a..95b6241583f 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Customizing Auto DevOps While [Auto DevOps](index.md) provides great defaults to get you started, you can customize @@ -68,7 +74,6 @@ Docker image based on based on the `ruby:alpine` instead of the default `ruby:la # ... put your stuff here ``` -NOTE: **Note:** Use Base64 encoding if you need to pass complex values, such as newlines and spaces. Left unencoded, complex values like these can cause escaping issues due to how Auto DevOps uses the arguments. @@ -117,7 +122,6 @@ to `CI_COMMIT_SHA,CI_ENVIRONMENT_NAME`. RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND ``` -NOTE: **Note:** When `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` is set, Auto DevOps enables the experimental [Docker BuildKit](https://docs.docker.com/develop/develop-images/build_enhancements/) feature to use the `--secret` flag. @@ -447,7 +451,6 @@ the updated secrets. To update the secrets, either: - Manually delete running pods to cause Kubernetes to create new pods with updated secrets. -NOTE: **Note:** Variables with multi-line values are not currently supported due to limitations with the current Auto DevOps scripting environment. @@ -514,8 +517,7 @@ on the default branch. However, there are cases where you might want to use a staging environment, and deploy to production manually. For this scenario, the `STAGING_ENABLED` environment variable was introduced. -If you define `STAGING_ENABLED`, such as setting `STAGING_ENABLED` to -`1` as a CI/CD variable, then GitLab automatically deploys the application +If you define `STAGING_ENABLED` with a non-empty value, then GitLab automatically deploys the application to a `staging` environment, and creates a `production_manual` job for you when you're ready to manually deploy to production. @@ -526,8 +528,7 @@ you when you're ready to manually deploy to production. You can use a [canary environment](../../user/project/canary_deployments.md) before deploying any changes to production. -If you define `CANARY_ENABLED` in your project, such as setting `CANARY_ENABLED` to -`1` as a CI/CD variable, then two manual jobs are created: +If you define `CANARY_ENABLED` with a non-empty value, then two manual jobs are created: - `canary` - Deploys the application to the canary environment. - `production_manual` - Manually deploys the application to production. diff --git a/doc/topics/autodevops/img/autodevops_multiple_clusters.png b/doc/topics/autodevops/img/autodevops_multiple_clusters.png Binary files differdeleted file mode 100644 index f4d101ca921..00000000000 --- a/doc/topics/autodevops/img/autodevops_multiple_clusters.png +++ /dev/null diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 1952fadc076..014690c4cdf 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Auto DevOps > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) in GitLab 10.0. @@ -160,7 +166,7 @@ a base domain of `example.com`, you'd need a DNS entry like: ``` In this case, the deployed applications are served from `example.com`, and `1.2.3.4` -is the IP address of your load balancer; generally NGINX ([see requirements](#requirements)). +is the IP address of your load balancer; generally NGINX ([see requirements](requirements.md)). Setting up the DNS record is beyond the scope of this document; check with your DNS provider for information. @@ -177,7 +183,7 @@ See [Auto DevOps requirements for Amazon ECS](requirements.md#auto-devops-requir ## Enabling/Disabling Auto DevOps -When first using Auto DevOps, review the [requirements](#requirements) to ensure +When first using Auto DevOps, review the [requirements](requirements.md) to ensure all the necessary components to make full use of Auto DevOps are available. First-time users should follow the [quick start guide](quick_start_guide.md). @@ -401,7 +407,7 @@ If you receive this error, you can do one of the following actions: database by setting `AUTO_DEVOPS_POSTGRES_DELETE_V1` to a non-empty value and redeploying. - DANGER: **Danger:** + DANGER: **Warning:** Deleting the channel 1 PostgreSQL database permanently deletes the existing channel 1 database and all its data. See [Upgrading PostgreSQL](upgrading_postgresql.md) @@ -415,7 +421,7 @@ If you receive this error, you can do one of the following actions: and persisted by Helm, regardless of whether or not your chart uses the variable. -DANGER: **Danger:** +DANGER: **Warning:** Setting `POSTGRES_ENABLED` to `false` permanently deletes any existing channel 1 database for your environment. @@ -467,6 +473,104 @@ that works for this problem. Follow these steps to use the tool in Auto DevOps: 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 blogpost](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 will be 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 will eventually stop 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 repo"](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 within 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) diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 02d9669a9bc..3531035eb67 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Getting started with Auto DevOps This step-by-step guide will help you use [Auto DevOps](index.md) to @@ -108,7 +114,6 @@ In this guide, we will install Ingress and Prometheus: - Prometheus - An open-source monitoring and alerting system used to supervise the deployed application. -NOTE: **Note:** We won't install GitLab Runner in this quick start guide, as this guide uses the shared runners provided by GitLab.com. @@ -155,7 +160,8 @@ The jobs are separated into stages: - **Build** - The application builds a Docker image and uploads it to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](stages.md#auto-build)). -- **Test** - GitLab runs various checks on the application: +- **Test** - GitLab runs various checks on the application, but all jobs except `test` + are allowed to fail in the test stage: - The `test` job runs unit and integration tests by detecting the language and framework ([Auto Test](stages.md#auto-test)) @@ -173,9 +179,6 @@ The jobs are separated into stages: licenses and is allowed to fail ([Auto License Compliance](stages.md#auto-license-compliance)) **(ULTIMATE)** - NOTE: **Note:** - All jobs except `test` are allowed to fail in the test stage. - - **Review** - Pipelines on `master` include this stage with a `dast_environment_deploy` job. To learn more, see [Dynamic Application Security Testing (DAST)](../../user/application_security/dast/index.md). diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md index af98e0a438b..acec7b79d6b 100644 --- a/doc/topics/autodevops/requirements.md +++ b/doc/topics/autodevops/requirements.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Requirements for Auto DevOps You can set up Auto DevOps for [Kubernetes](#auto-devops-requirements-for-kubernetes) @@ -120,11 +126,9 @@ When you trigger a pipeline, if you have Auto DevOps enabled and if you have cor [entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs), your application will be deployed to AWS ECS. -NOTE: **Note:** [GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS. You must manually configure your application (such as Ingress or Help) on AWS ECS. -NOTE: **Note:** If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project, only the deployment to Kubernetes will run. diff --git a/doc/topics/autodevops/stages.md b/doc/topics/autodevops/stages.md index d3f02889a2e..f2d3b78e2b0 100644 --- a/doc/topics/autodevops/stages.md +++ b/doc/topics/autodevops/stages.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Stages of Auto DevOps The following sections describe the stages of [Auto DevOps](index.md). @@ -161,10 +167,7 @@ see the documentation. > - [Select functionality made available in all tiers](../../user/application_security/secret_detection/#making-secret-detection-available-to-all-gitlab-tiers) in 13.3 Secret Detection uses the -[Secret Detection Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) to run Secret Detection on the current code, and checks for leaked secrets. The -Auto Secret Detection stage runs only on the -[Ultimate](https://about.gitlab.com/pricing/) tier, and requires -[GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above. +[Secret Detection Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) to run Secret Detection on the current code, and checks for leaked secrets. Auto Secret Detection requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above. After creating the report, it's uploaded as an artifact which you can later download and evaluate. The merge request widget also displays any security @@ -285,7 +288,7 @@ see the documentation. 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. -DANGER: **Danger:** +DANGER: **Warning:** If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is enabled, GitLab strongly advises **not** to set `DAST_WEBSITE` to any staging or production environment. DAST Full Scan @@ -428,7 +431,7 @@ To use Auto Deploy on a Kubernetes 1.16+ cluster: 1. If you are deploying your application for the first time and are using GitLab 12.9 or 12.10, set `AUTO_DEVOPS_POSTGRES_CHANNEL` to `2`. -DANGER: **Danger:** +DANGER: **Warning:** On GitLab 12.9 and 12.10, opting into `AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes the version `1` PostgreSQL database. Follow the [guide to upgrading PostgreSQL](upgrading_postgresql.md) @@ -668,4 +671,16 @@ To use Auto Monitoring: ## Auto Code Intelligence -Code Intelligence is powered by [LSIF](https://lsif.dev/) and available for Go at this stage. We'll support more languages as they become available. +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216438) in GitLab 13.5. + +[GitLab code intelligence](../../user/project/code_intelligence.md) adds +code navigation features common to interactive development environments (IDE), +including type signatures, symbol documentation, and go-to definition. It's powered by +[LSIF](https://lsif.dev/) and available for Auto DevOps projects using Go language only. +GitLab plans to add support for more languages as more LSIF indexers become available. +You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org/-/epics/4212) +for updates. + +This stage is enabled by default. You can disable it by adding the +`CODE_INTELLIGENCE_DISABLED` environment variable. Read more about +[disabling Auto DevOps jobs](../../topics/autodevops/customize.md#disable-jobs). diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md index 1aefb6b34df..16536e5b586 100644 --- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md +++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md @@ -71,6 +71,10 @@ The v2 auto-deploy-image contains multiple dependency and architectural changes. If your Auto DevOps project has an active environment deployed with the v1 `auto-deploy-image`, please proceed with the following upgrade guide. Otherwise, you can skip this process. +#### Kubernetes 1.16+ + +The v2 auto-deploy-image also drops support for Kubernetes 1.15 and lower. + #### Helm 3 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/228609) in GitLab 13.4. diff --git a/doc/topics/autodevops/upgrading_postgresql.md b/doc/topics/autodevops/upgrading_postgresql.md index bcbc1d914be..a3c9f562f5e 100644 --- a/doc/topics/autodevops/upgrading_postgresql.md +++ b/doc/topics/autodevops/upgrading_postgresql.md @@ -1,3 +1,9 @@ +--- +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/#designated-technical-writers +--- + # Upgrading PostgreSQL for Auto DevOps Auto DevOps provides an [in-cluster PostgreSQL database](customize.md#postgresql-database-support) diff --git a/doc/topics/cron/index.md b/doc/topics/cron/index.md index 851dd6d3f77..2be579b4e98 100644 --- a/doc/topics/cron/index.md +++ b/doc/topics/cron/index.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Cron Cron syntax is used to schedule when jobs should run. diff --git a/doc/topics/git/git_rebase.md b/doc/topics/git/git_rebase.md index 6f50dea26dd..c01080400ac 100644 --- a/doc/topics/git/git_rebase.md +++ b/doc/topics/git/git_rebase.md @@ -119,7 +119,7 @@ repository, you can run `git remote -v`. If there are [merge conflicts](#merge-conflicts), Git will prompt you to fix them before continuing the rebase. -To learn more, check Git's documentation on [rebasing](ttps://git-scm.com/book/en/v2/Git-Branching-Rebasing) +To learn more, check Git's documentation on [rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) and [rebasing strategies](https://git-scm.com/book/en/v2/Git-Branching-Rebasing). ### Interactive rebase diff --git a/doc/topics/git/lfs/index.md b/doc/topics/git/lfs/index.md index 7235ba07d0a..80014358230 100644 --- a/doc/topics/git/lfs/index.md +++ b/doc/topics/git/lfs/index.md @@ -114,8 +114,11 @@ See the documentation on [File Locking](../../../user/project/file_lock.md). ## LFS objects in project archives > - Support for including Git LFS blobs inside [project source downloads](../../../user/project/repository/index.md) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15079) in GitLab 13.5. -> - It's [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-lfs-objects-in-project-archives). **(CORE ONLY)** +> - It was [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. +> - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/268409) on GitLab 13.6. +> - It's enabled on GitLab.com. +> - It's recommended for production use. +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-lfs-objects-in-project-archives). CAUTION: **Warning:** This feature might not be available to you. Check the **version history** note above for details. @@ -139,10 +142,10 @@ Technical details about how this works can be found in the [development document ### Enable or disable LFS objects in project archives -_LFS objects in project archives_ is under development and not ready for production use. It is -deployed behind a feature flag that is **disabled by default**. +_LFS objects in project archives_ is under development but ready for production use. +It is deployed behind a feature flag that is **enabled by default**. [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) -can enable it. +can opt to disable it. To enable it: diff --git a/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md index c62b7e1cc12..d65d52841aa 100644 --- a/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md +++ b/doc/topics/git/lfs/migrate_from_git_annex_to_git_lfs.md @@ -7,7 +7,7 @@ type: reference, howto # Migration guide from Git Annex to Git LFS -NOTE: **Note:** +DANGER: **Deprecated:** Git Annex support [has been removed](https://gitlab.com/gitlab-org/gitlab/-/issues/1648) in GitLab Enterprise Edition 9.0 (2017/03/22). @@ -37,7 +37,6 @@ ones that GitLab developed. ## Migration steps -NOTE: **Note:** Since Git Annex files are stored in a sub-directory of the normal repositories (`.git/annex/objects`) and LFS files are stored outside of the repositories, they are not compatible as they are using a different scheme. Therefore, the diff --git a/doc/topics/git/lfs/migrate_to_git_lfs.md b/doc/topics/git/lfs/migrate_to_git_lfs.md index f0ad7570d87..596b2cb400f 100644 --- a/doc/topics/git/lfs/migrate_to_git_lfs.md +++ b/doc/topics/git/lfs/migrate_to_git_lfs.md @@ -1,4 +1,7 @@ --- +stage: none +group: unassigned +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/#designated-technical-writers description: "How to migrate an existing Git repository to Git LFS with BFG." --- diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md index c976eda688a..58fa6d2f112 100644 --- a/doc/topics/git/partial_clone.md +++ b/doc/topics/git/partial_clone.md @@ -91,7 +91,7 @@ Updating files: 100% (28/28), done. $ cd www-gitlab-com -$ git sparse-checkout init --clone +$ git sparse-checkout init --cone $ git sparse-checkout add data remote: Enumerating objects: 301, done. diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 8c5a2092a92..32676658bff 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -250,7 +250,7 @@ Atlassian has a more thorough explanation of the tradeoffs between merging and r A good way to prevent creating many merge commits is to not frequently merge `master` into the feature branch. There are three reasons to merge in `master`: utilizing new code, resolving merge conflicts, and updating long-running branches. -If you need to utilize some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit. +If you need to use some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit. If your feature branch has a merge conflict, creating a merge commit is a standard way of solving this. diff --git a/doc/topics/index.md b/doc/topics/index.md index 3b92bbb55cb..91b1905f1b6 100644 --- a/doc/topics/index.md +++ b/doc/topics/index.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Topics Welcome to Topics! We have organized our content resources into topics @@ -16,6 +22,3 @@ tutorials, technical overviews, blog posts) and videos. - [GitLab Installation](../install/README.md) - [GitLab Pages](../user/project/pages/index.md) - [Offline GitLab](offline/index.md) - -NOTE: **Note:** -More topics will be available soon. diff --git a/doc/topics/offline/index.md b/doc/topics/offline/index.md index a8366659c22..b40f5e92738 100644 --- a/doc/topics/offline/index.md +++ b/doc/topics/offline/index.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Offline GitLab Computers in an offline environment are isolated from the public internet as a security measure. This diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md index 8b9996cb66f..92f8f9167b7 100644 --- a/doc/topics/offline/quick_start_guide.md +++ b/doc/topics/offline/quick_start_guide.md @@ -1,3 +1,9 @@ +--- +stage: none +group: unassigned +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/#designated-technical-writers +--- + # Getting started with an offline GitLab Installation This is a step-by-step guide that helps you install, configure, and use a self-managed GitLab @@ -7,9 +13,7 @@ instance entirely offline. NOTE: **Note:** This guide assumes the server is Ubuntu 18.04. Instructions for other servers may vary. - -NOTE: **Note:** -This guide assumes the server host resolves as `my-host`, which you should replace with your +This guide also assumes the server host resolves as `my-host`, which you should replace with your server's name. Follow the installation instructions [as outlined in the omnibus install diff --git a/doc/topics/web_application_firewall/index.md b/doc/topics/web_application_firewall/index.md index 5ce7c0779bb..83b3bfb1cef 100644 --- a/doc/topics/web_application_firewall/index.md +++ b/doc/topics/web_application_firewall/index.md @@ -1,5 +1,5 @@ --- -stage: Defend +stage: Protect group: Container Security 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/#designated-technical-writers --- @@ -15,19 +15,14 @@ much more. ## Overview -GitLab provides a WAF out of the box after Ingress is deployed. -All you need to do is deploy your application along with a service -and Ingress resource. +GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your +application along with a service and Ingress resource. In GitLab's [Ingress](../../user/clusters/applications.md#ingress) +deployment, the [ModSecurity](https://modsecurity.org/) +module is loaded into Ingress-NGINX by default and monitors the traffic going to the applications +which have an Ingress. The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/) +by default. The OWASP CRS detects and logs a wide range of common attacks. -In GitLab's [Ingress](../../user/clusters/applications.md#ingress) deployment, the [ModSecurity](https://modsecurity.org/) module is loaded -into Ingress-NGINX by default and monitors the traffic going to the -applications which have an Ingress. - -The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/) by default. The OWASP CRS will detect and log a wide range of common attacks. - -NOTE: **Note:** -The WAF is deployed in "Detection-only mode" by default and will only log attack -attempts. +By default, the WAF is deployed in Detection-only mode and only logs attack attempts. ## Requirements @@ -98,5 +93,5 @@ It is good to have a basic knowledge of the following: ## Roadmap -More information on the direction of the WAF can be -found in [Product Vision - Defend](https://about.gitlab.com/direction/defend/#waf) +You can find more information on the product direction of the WAF in +[Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/). diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md index 971250cd526..3df22854437 100644 --- a/doc/topics/web_application_firewall/quick_start_guide.md +++ b/doc/topics/web_application_firewall/quick_start_guide.md @@ -1,5 +1,5 @@ --- -stage: Defend +stage: Protect group: Container Security 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/#designated-technical-writers --- @@ -17,7 +17,7 @@ These instructions will also work for a self-managed GitLab instance. However, y need to ensure your own [runners are configured](../../ci/runners/README.md) and [Google OAuth is enabled](../../integration/google.md). -**Note**: GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress), +GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress), so it will be available to your applications no matter how you deploy them to Kubernetes. ## Configuring your Google account @@ -107,7 +107,7 @@ the scenes. Make sure to switch the toggle to the enabled position before instal Both logging and blocking modes are available for WAF. While logging mode is useful for auditing anomalous traffic, blocking mode ensures the traffic doesn't reach past Ingress. - + After Ingress is installed, wait a few seconds and copy the IP address that is displayed in order to add in your base **Domain** at the top of the page. For @@ -252,7 +252,7 @@ You can now see the benefits of a using a Web Application Firewall. ModSecurity and the OWASP Core Rule Set, offer many more benefits. You can explore them in more detail: -- [GitLab Defend Vision](https://about.gitlab.com/direction/defend/#waf) +- [Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/) - [ModSecurity](https://www.modsecurity.org/) - [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/) - [AutoDevOps](../autodevops/index.md) |
