@@ -41,6 +41,7 @@ Shortcuts to GitLab's most visited docs:
...
@@ -41,6 +41,7 @@ Shortcuts to GitLab's most visited docs:
- See also [GitLab Workflow - an overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/).
- See also [GitLab Workflow - an overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/).
-[GitLab Markdown](user/markdown.md): GitLab's advanced formatting system (GitLab Flavored Markdown).
-[GitLab Markdown](user/markdown.md): GitLab's advanced formatting system (GitLab Flavored Markdown).
-[GitLab Quick Actions](user/project/quick_actions.md): Textual shortcuts for common actions on issues or merge requests that are usually done by clicking buttons or dropdowns in GitLab's UI.
-[GitLab Quick Actions](user/project/quick_actions.md): Textual shortcuts for common actions on issues or merge requests that are usually done by clicking buttons or dropdowns in GitLab's UI.
and [`kube-lego`](https://github.com/kubernetes/charts/tree/master/stable/kube-lego)
Helm charts respectively. The [Kubernetes service][kubernetes-service]
integration will need to be enabled for the project, or enabled as a
[default service template](../../user/project/integrations/services_templates.md)
for the entire GitLab installation.
1.**Prometheus** - To enable Auto Monitoring, you will need Prometheus installed
somewhere (inside or outside your cluster) and configured to scrape your
Kubernetes cluster. To get response metrics (in addition to system metrics),
you need to [configure Prometheus to monitor NGINX](../../user/project/integrations/prometheus_library/nginx_ingress.md#configuring-prometheus-to-monitor-for-nginx-ingress-metrics).
The [Prometheus service](../../user/project/integrations/prometheus.md)
integration needs to be enabled for the project, or enabled as a
[default service template](../../user/project/integrations/services_templates.md)
for the entire GitLab installation.
## Enabling Auto DevOps
In your GitLab.com project, go to **Settings > CI/CD** and find the Auto DevOps
section. Select "Enable Auto DevOps", add in your base domain, and save.
* System Metrics: CPU utilization, memory utilization
To view the metrics, open the [Monitoring dashboard for a deployed environment](../../ci/environments.md#monitoring-environments).
### Configuring Auto Monitoring
If GitLab has been deployed using the
[omnibus-gitlab](../../install/kubernetes/gitlab_omnibus.md) Helm chart, no
configuration is required.
If you have installed GitLab using a different method:
1.[Deploy Prometheus](../../user/project/integrations/prometheus.md#configuring-your-own-prometheus-server-within-kubernetes) into your Kubernetes cluster
1. If you would like response metrics, ensure you are running at least version 0.9.0 of NGINX Ingress and [enable Prometheus metrics](https://github.com/kubernetes/ingress/blob/master/examples/customization/custom-vts-metrics/nginx/nginx-vts-metrics-conf.yaml).
1. Finally, [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) the NGINX Ingress deployment to be scraped by Prometheus using `prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"`.
## Customizing
### PostgreSQL Database Support
In order to support applications that require a database,
[PostgreSQL][postgresql] is provisioned by default. Credentials to access the
database are preconfigured, but can be customized by setting the associated
[variables](#postgresql-variables). These credentials can be used for defining a
> [Introduced][ce-37115] in GitLab 10.0. Auto DevOps is currently in Beta and
**not recommended for production use**.
This is a step-by-step guide to deploying a project hosted on GitLab.com to
Google Cloud, using Auto DevOps.
We made a minimal [Ruby
application](https://gitlab.com/gitlab-examples/minimal-ruby-app) to use as an
example for this guide. It contains two files:
*`server.rb` - our application. It will start an HTTP server on port 5000 and
render "Hello, world!"
*`Dockerfile` - to build our app into a container image. It will use a ruby
base image and run `server.rb`
## Fork sample project on GitLab.com
Let’s start by forking our sample application. Go to [the project
page](https://gitlab.com/gitlab-examples/minimal-ruby-app) and press the `Fork`
button. Soon you should have a project under your namespace with the necessary
files.
## Setup your own cluster on Google Container Engine
If you do not already have a Google Cloud account, create one at https://console.cloud.google.com.
Visit the [`Container Engine`](https://console.cloud.google.com/kubernetes/list) tab and create a new cluster. You can change the name and leave the rest of the default settings. Once you have your cluster running, you need to connect to the cluster by following the Google interface.
## Connect to Kubernetes cluster
You need to have the Google Cloud SDK installed. e.g.
Now go back to the Google interface, find your cluster, and follow the instructions under `Connect to the cluster` and open the Kubernetes Dashboard. It will look something like `gcloud container clusters get-credentials ruby-autodeploy \ --zone europe-west2-c --project api-project-XXXXXXX` and then `kubectl proxy`.
## Copy credentials to GitLab.com project
Once you have the Kubernetes Dashboard interface running, you should visit `Secrets` under the `Config` section. There you should find the settings we need for GitLab integration: ca.crt and token.
You need to copy-paste the ca.crt and token into your project on GitLab.com in the Kubernetes integration page under project **Settings > Integrations > Project services > Kubernetes**. Don't actually copy the namespace though. Each project should have a unique namespace, and by leaving it blank, GitLab will create one for you.
For API URL, you should use the `Endpoint` IP from your cluster page on Google Cloud Platform.
## Expose application to the world
In order to be able to visit your application, you need to install an NGINX ingress controller and point your domain name to its external IP address.
### Set up Ingress controller
You’ll need to make sure you have an ingress controller. If you don’t have one, do:
```sh
brew install kubernetes-helm
helm init
helm install--name ruby-app stable/nginx-ingress
```
This should create several services including `ruby-app-nginx-ingress-controller`. You can list your services by running `kubectl get svc` to confirm that.
### Point DNS at Cluster IP
Find out the external IP address of the `ruby-app-nginx-ingress-controller` by running:
```sh
kubectl get svc ruby-app-nginx-ingress-controller -ojsonpath='{.status.loadBalancer.ingress[0].ip}'
```
Use this IP address to configure your DNS. This part heavily depends on your preferences and domain provider. But in case you are not sure, just create an A record with a wildcard host like `*.<your-domain>`.
Use `nslookup minimal-ruby-app-staging.<yourdomain>` to confirm that domain is assigned to the cluster IP.
## Set up Auto DevOps
In your GitLab.com project, go to **Settings > CI/CD** and find the Auto DevOps section. Select "Enable Auto DevOps", add in your base domain, and save.
Then trigger your first pipeline run. This will create a new pipeline with several jobs: `build`, `test`, `codequality`, and `production`. The `build` job will create a docker image with your new change and push it to the GitLab Container Registry. The `test` job will test your change. The `codequality` job will run static analysis on your change. The `production` job will deploy your change to a production application. Once the deploy job succeeds you should be able to see your application by visiting the Kubernetes dashboard. Select the namespace of your project, which will look like `minimal-ruby-app-23`, but with a unique ID for your project, and your app will be listed as "production" under the Deployment tab.
Once its ready - just visit http://minimal-ruby-app.example.com to see “Hello, world!”
