To enable Auto Monitoring, you will need Prometheus installed somewhere
(inside or outside your cluster) and configured to scrape your Kubernetes cluster.
To enable Auto Monitoring, you need Prometheus installed either inside or
outside your cluster, and configured to scrape your Kubernetes cluster.
If you've configured GitLab's Kubernetes integration, you can deploy it to
your cluster by installing the
[GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus).
The [Prometheus service](../../user/project/integrations/prometheus.md)
integration needs to be enabled for the project (or enabled as a
integration must be enabled for the project, or enabled as a
[default service template](../../user/project/integrations/services_templates.md)
for the entire GitLab installation).
for the entire GitLab installation.
To get response metrics (in addition to system metrics), you need to
To get response metrics (in addition to system metrics), you must
[configure Prometheus to monitor NGINX](../../user/project/integrations/prometheus_library/nginx_ingress.md#configuring-nginx-ingress-monitoring).
-**cert-manager** (optional, for TLS/HTTPS)
To enable HTTPS endpoints for your application, you need to install cert-manager,
a native Kubernetes certificate management controller that helps with issuing certificates.
Installing cert-manager on your cluster will issue a certificate by
[Let’s Encrypt](https://letsencrypt.org/)and ensure that certificates are valid and up-to-date.
If you've configured GitLab's Kubernetes integration, you can deploy it to
your cluster by installing the
To enable HTTPS endpoints for your application, you must install cert-manager,
a native Kubernetes certificate management controller that helps with issuing
certificates. Installing cert-manager on your cluster issues a
[Let’s Encrypt](https://letsencrypt.org/)certificate and ensures the
certificates are valid and up-to-date. If you've configured GitLab's Kubernetes
integration, you can deploy it to your cluster by installing the
[GitLab-managed app for cert-manager](../../user/clusters/applications.md#cert-manager).
If you don't have Kubernetes or Prometheus installed, then Auto Review Apps,
Auto Deploy, and Auto Monitoring will be silently skipped.
If you don't have Kubernetes or Prometheus installed, then
[Auto Review Apps](stages.md#auto-review-apps),
[Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring)
are skipped.
One all requirements are met, you can go ahead and[enable Auto DevOps](#enablingdisabling-auto-devops).
After all requirements are met, you can[enable Auto DevOps](#enablingdisabling-auto-devops).
## Auto DevOps base domain
The Auto DevOps base domain is required if you want to make use of
The Auto DevOps base domain is required to use
[Auto Review Apps](stages.md#auto-review-apps), [Auto Deploy](stages.md#auto-deploy), and
[Auto Monitoring](stages.md#auto-monitoring). It can be defined in any of the following
places:
- either under the cluster's settings, whether for [projects](../../user/project/clusters/index.md#base-domain) or [groups](../../user/group/clusters/index.md#base-domain)
- or in instance-wide settings in the **Admin Area > Settings** under the "Continuous Integration and Delivery" section
[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
[projects](../../user/project/clusters/index.md#base-domain) or
- or in instance-wide settings in **{admin}****Admin Area > Settings** 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`.
...
...
@@ -211,9 +221,9 @@ The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of pr
as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
TIP: **Tip:**
If you're using the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress),
the URL endpoint should be automatically configured for you.
Use its value for the `KUBE_INGRESS_BASE_DOMAIN` variable.
If you use the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress),
the URL endpoint should be automatically configured for you. All you must do
is use its value for the `KUBE_INGRESS_BASE_DOMAIN` variable.
NOTE: **Note:**
`AUTO_DEVOPS_DOMAIN` was [deprecated in GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/issues/52363)
...
...
@@ -251,8 +261,7 @@ instance level.
### At the project level
If enabling, confirm your project does not have a `.gitlab-ci.yml`. If one
exists, remove it.
If enabling, check that your project does not have a `.gitlab-ci.yml`, or if one exists, remove it.
1. Go to your project's **{settings}****Settings > CI/CD > Auto DevOps**.
1. Select the **Default to Auto DevOps pipeline** checkbox to enable it.
...
...
@@ -329,7 +338,8 @@ 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-premium).
The [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) currently defines 3 environment names:
The [template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
used by Auto DevOps currently defines 3 environment names:
-`review/` (every environment starting with `review/`)
-`staging`
...
...
@@ -358,23 +368,24 @@ To add a different cluster for each environment:
1. After creating the clusters, navigate to each cluster and install Helm Tiller
and Ingress. Wait for the Ingress IP address to be assigned.
1. Make sure your [DNS is configured](#auto-devops-base-domain) with the
1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
specified Auto DevOps domains.
1. Navigate to each cluster's page, through **{cloud-gear}****Operations > Kubernetes**,
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 app is deployed as a review app in the Kubernetes
and verifying your application is deployed as a Review App in the Kubernetes
cluster with the `review/*` environment scope. Similarly, you can check the
other environments.
## Currently supported languages
Note that not all buildpacks support Auto Test yet, as it's a relatively new enhancement.
All of Heroku's [officially supported languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages)
support Auto Test. While some third-party buildpacks, such as Go, Node, Java, PHP,
Python, Ruby, Gradle, Scala, and Elixir all support Auto Test, the
multi-buildpack notably does not.
Note that not all buildpacks support Auto Test yet, as it's a relatively new
enhancement. All of Heroku's [officially supported
# This script deletes all test ssh keys (with titles including 'key for ssh tests' or 'key for audit event test') of a user specified by ENV['GITLAB_USERNAME']
# Required environment variables: GITLAB_QA_ACCESS_TOKEN, GITLAB_ADDRESS and GITLAB_USERNAME
moduleQA
moduleTools
classDeleteTestSSHKeys
includeSupport::Api
definitialize
raiseArgumentError,"Please provide GITLAB_ADDRESS"unlessENV['GITLAB_ADDRESS']
raiseArgumentError,"Please provide GITLAB_QA_ACCESS_TOKEN"unlessENV['GITLAB_QA_ACCESS_TOKEN']
raiseArgumentError,"Please provide GITLAB_USERNAME"unlessENV['GITLAB_USERNAME']
