From 72754e7faed59dff72535366d97029654a997e58 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 12 Jun 2018 12:38:10 +0200 Subject: Document end to end flow for Kubernetes and Auto DevOps --- doc/topics/autodevops/img/auto_monitoring.png | Bin 69473 -> 26675 bytes doc/topics/autodevops/img/guide_choose_gke.png | Bin 0 -> 7895 bytes doc/topics/autodevops/img/guide_cluster_apps.png | Bin 0 -> 28667 bytes .../autodevops/img/guide_connect_cluster.png | Bin 38724 -> 15225 bytes doc/topics/autodevops/img/guide_create_cluster.png | Bin 0 -> 18915 bytes doc/topics/autodevops/img/guide_create_project.png | Bin 0 -> 17704 bytes .../autodevops/img/guide_enable_autodevops.png | Bin 0 -> 27763 bytes doc/topics/autodevops/img/guide_environments.png | Bin 0 -> 8570 bytes .../autodevops/img/guide_environments_metrics.png | Bin 0 -> 10231 bytes doc/topics/autodevops/img/guide_first_pipeline.png | Bin 0 -> 10350 bytes .../autodevops/img/guide_gitlab_gke_details.png | Bin 0 -> 22677 bytes doc/topics/autodevops/img/guide_gke_apis_after.png | Bin 0 -> 26811 bytes .../autodevops/img/guide_gke_apis_before.png | Bin 0 -> 14882 bytes doc/topics/autodevops/img/guide_google_auth.png | Bin 0 -> 12729 bytes doc/topics/autodevops/img/guide_google_signin.png | Bin 0 -> 14343 bytes doc/topics/autodevops/img/guide_ide_commit.png | Bin 0 -> 22035 bytes doc/topics/autodevops/img/guide_integration.png | Bin 44263 -> 0 bytes doc/topics/autodevops/img/guide_merge_request.png | Bin 0 -> 31157 bytes .../autodevops/img/guide_merge_request_ide.png | Bin 0 -> 35052 bytes .../img/guide_merge_request_review_app.png | Bin 0 -> 25596 bytes .../autodevops/img/guide_pipeline_stages.png | Bin 0 -> 12557 bytes .../autodevops/img/guide_project_landing_page.png | Bin 0 -> 19227 bytes .../autodevops/img/guide_project_template.png | Bin 0 -> 14699 bytes doc/topics/autodevops/img/guide_secret.png | Bin 16233 -> 0 bytes .../autodevops/img/rollout_staging_disabled.png | Bin 13837 -> 13834 bytes .../autodevops/img/rollout_staging_enabled.png | Bin 17306 -> 17299 bytes doc/topics/autodevops/img/staging_enabled.png | Bin 17929 -> 17922 bytes doc/topics/autodevops/index.md | 31 +- doc/topics/autodevops/quick_start_guide.md | 352 +++++++++++++++------ doc/user/project/clusters/index.md | 89 +++--- 30 files changed, 313 insertions(+), 159 deletions(-) create mode 100644 doc/topics/autodevops/img/guide_choose_gke.png create mode 100644 doc/topics/autodevops/img/guide_cluster_apps.png create mode 100644 doc/topics/autodevops/img/guide_create_cluster.png create mode 100644 doc/topics/autodevops/img/guide_create_project.png create mode 100644 doc/topics/autodevops/img/guide_enable_autodevops.png create mode 100644 doc/topics/autodevops/img/guide_environments.png create mode 100644 doc/topics/autodevops/img/guide_environments_metrics.png create mode 100644 doc/topics/autodevops/img/guide_first_pipeline.png create mode 100644 doc/topics/autodevops/img/guide_gitlab_gke_details.png create mode 100644 doc/topics/autodevops/img/guide_gke_apis_after.png create mode 100644 doc/topics/autodevops/img/guide_gke_apis_before.png create mode 100644 doc/topics/autodevops/img/guide_google_auth.png create mode 100644 doc/topics/autodevops/img/guide_google_signin.png create mode 100644 doc/topics/autodevops/img/guide_ide_commit.png delete mode 100644 doc/topics/autodevops/img/guide_integration.png create mode 100644 doc/topics/autodevops/img/guide_merge_request.png create mode 100644 doc/topics/autodevops/img/guide_merge_request_ide.png create mode 100644 doc/topics/autodevops/img/guide_merge_request_review_app.png create mode 100644 doc/topics/autodevops/img/guide_pipeline_stages.png create mode 100644 doc/topics/autodevops/img/guide_project_landing_page.png create mode 100644 doc/topics/autodevops/img/guide_project_template.png delete mode 100644 doc/topics/autodevops/img/guide_secret.png diff --git a/doc/topics/autodevops/img/auto_monitoring.png b/doc/topics/autodevops/img/auto_monitoring.png index 92902e3ca72..2900e5d1877 100644 Binary files a/doc/topics/autodevops/img/auto_monitoring.png and b/doc/topics/autodevops/img/auto_monitoring.png differ diff --git a/doc/topics/autodevops/img/guide_choose_gke.png b/doc/topics/autodevops/img/guide_choose_gke.png new file mode 100644 index 00000000000..6da3a7220da Binary files /dev/null and b/doc/topics/autodevops/img/guide_choose_gke.png differ diff --git a/doc/topics/autodevops/img/guide_cluster_apps.png b/doc/topics/autodevops/img/guide_cluster_apps.png new file mode 100644 index 00000000000..33d25f2950d Binary files /dev/null and b/doc/topics/autodevops/img/guide_cluster_apps.png differ diff --git a/doc/topics/autodevops/img/guide_connect_cluster.png b/doc/topics/autodevops/img/guide_connect_cluster.png index b856b81a1d0..703d536f37a 100644 Binary files a/doc/topics/autodevops/img/guide_connect_cluster.png and b/doc/topics/autodevops/img/guide_connect_cluster.png differ diff --git a/doc/topics/autodevops/img/guide_create_cluster.png b/doc/topics/autodevops/img/guide_create_cluster.png new file mode 100644 index 00000000000..cd1d0fdd8da Binary files /dev/null and b/doc/topics/autodevops/img/guide_create_cluster.png differ diff --git a/doc/topics/autodevops/img/guide_create_project.png b/doc/topics/autodevops/img/guide_create_project.png new file mode 100644 index 00000000000..4ed1071db03 Binary files /dev/null and b/doc/topics/autodevops/img/guide_create_project.png differ diff --git a/doc/topics/autodevops/img/guide_enable_autodevops.png b/doc/topics/autodevops/img/guide_enable_autodevops.png new file mode 100644 index 00000000000..0fc3ecca19a Binary files /dev/null and b/doc/topics/autodevops/img/guide_enable_autodevops.png differ diff --git a/doc/topics/autodevops/img/guide_environments.png b/doc/topics/autodevops/img/guide_environments.png new file mode 100644 index 00000000000..1d8d5614e64 Binary files /dev/null and b/doc/topics/autodevops/img/guide_environments.png differ diff --git a/doc/topics/autodevops/img/guide_environments_metrics.png b/doc/topics/autodevops/img/guide_environments_metrics.png new file mode 100644 index 00000000000..f0d31f31581 Binary files /dev/null and b/doc/topics/autodevops/img/guide_environments_metrics.png differ diff --git a/doc/topics/autodevops/img/guide_first_pipeline.png b/doc/topics/autodevops/img/guide_first_pipeline.png new file mode 100644 index 00000000000..57459dcc9d9 Binary files /dev/null and b/doc/topics/autodevops/img/guide_first_pipeline.png differ diff --git a/doc/topics/autodevops/img/guide_gitlab_gke_details.png b/doc/topics/autodevops/img/guide_gitlab_gke_details.png new file mode 100644 index 00000000000..bc5a53800f7 Binary files /dev/null and b/doc/topics/autodevops/img/guide_gitlab_gke_details.png differ diff --git a/doc/topics/autodevops/img/guide_gke_apis_after.png b/doc/topics/autodevops/img/guide_gke_apis_after.png new file mode 100644 index 00000000000..380de958867 Binary files /dev/null and b/doc/topics/autodevops/img/guide_gke_apis_after.png differ diff --git a/doc/topics/autodevops/img/guide_gke_apis_before.png b/doc/topics/autodevops/img/guide_gke_apis_before.png new file mode 100644 index 00000000000..d06fc707887 Binary files /dev/null and b/doc/topics/autodevops/img/guide_gke_apis_before.png differ diff --git a/doc/topics/autodevops/img/guide_google_auth.png b/doc/topics/autodevops/img/guide_google_auth.png new file mode 100644 index 00000000000..b97b2be9f15 Binary files /dev/null and b/doc/topics/autodevops/img/guide_google_auth.png differ diff --git a/doc/topics/autodevops/img/guide_google_signin.png b/doc/topics/autodevops/img/guide_google_signin.png new file mode 100644 index 00000000000..e59fc94bd4c Binary files /dev/null and b/doc/topics/autodevops/img/guide_google_signin.png differ diff --git a/doc/topics/autodevops/img/guide_ide_commit.png b/doc/topics/autodevops/img/guide_ide_commit.png new file mode 100644 index 00000000000..188f60f2a4b Binary files /dev/null and b/doc/topics/autodevops/img/guide_ide_commit.png differ diff --git a/doc/topics/autodevops/img/guide_integration.png b/doc/topics/autodevops/img/guide_integration.png deleted file mode 100644 index 723b2619ea2..00000000000 Binary files a/doc/topics/autodevops/img/guide_integration.png and /dev/null differ diff --git a/doc/topics/autodevops/img/guide_merge_request.png b/doc/topics/autodevops/img/guide_merge_request.png new file mode 100644 index 00000000000..d78e69be776 Binary files /dev/null and b/doc/topics/autodevops/img/guide_merge_request.png differ diff --git a/doc/topics/autodevops/img/guide_merge_request_ide.png b/doc/topics/autodevops/img/guide_merge_request_ide.png new file mode 100644 index 00000000000..c825b0849e1 Binary files /dev/null and b/doc/topics/autodevops/img/guide_merge_request_ide.png differ diff --git a/doc/topics/autodevops/img/guide_merge_request_review_app.png b/doc/topics/autodevops/img/guide_merge_request_review_app.png new file mode 100644 index 00000000000..1b9b854ddac Binary files /dev/null and b/doc/topics/autodevops/img/guide_merge_request_review_app.png differ diff --git a/doc/topics/autodevops/img/guide_pipeline_stages.png b/doc/topics/autodevops/img/guide_pipeline_stages.png new file mode 100644 index 00000000000..6e2f078152b Binary files /dev/null and b/doc/topics/autodevops/img/guide_pipeline_stages.png differ diff --git a/doc/topics/autodevops/img/guide_project_landing_page.png b/doc/topics/autodevops/img/guide_project_landing_page.png new file mode 100644 index 00000000000..4f8d2eb10b1 Binary files /dev/null and b/doc/topics/autodevops/img/guide_project_landing_page.png differ diff --git a/doc/topics/autodevops/img/guide_project_template.png b/doc/topics/autodevops/img/guide_project_template.png new file mode 100644 index 00000000000..298ac0f6fcf Binary files /dev/null and b/doc/topics/autodevops/img/guide_project_template.png differ diff --git a/doc/topics/autodevops/img/guide_secret.png b/doc/topics/autodevops/img/guide_secret.png deleted file mode 100644 index 01f5aa49908..00000000000 Binary files a/doc/topics/autodevops/img/guide_secret.png and /dev/null differ diff --git a/doc/topics/autodevops/img/rollout_staging_disabled.png b/doc/topics/autodevops/img/rollout_staging_disabled.png index 71e36b440f0..4c7c6768666 100644 Binary files a/doc/topics/autodevops/img/rollout_staging_disabled.png and b/doc/topics/autodevops/img/rollout_staging_disabled.png differ diff --git a/doc/topics/autodevops/img/rollout_staging_enabled.png b/doc/topics/autodevops/img/rollout_staging_enabled.png index d0d1d356627..f45c1c2cb37 100644 Binary files a/doc/topics/autodevops/img/rollout_staging_enabled.png and b/doc/topics/autodevops/img/rollout_staging_enabled.png differ diff --git a/doc/topics/autodevops/img/staging_enabled.png b/doc/topics/autodevops/img/staging_enabled.png index 0ef1a67d641..f0e0cd1cfcd 100644 Binary files a/doc/topics/autodevops/img/staging_enabled.png and b/doc/topics/autodevops/img/staging_enabled.png differ diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 103836e59d0..9b1acbac17f 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -1,6 +1,6 @@ # Auto DevOps -> [Introduced][ce-37115] in GitLab 10.0. +> [Introduced][ce-37115] in GitLab 10.0. Generally available on GitLab 11.0. Auto DevOps automatically detects, builds, tests, deploys, and monitors your applications. @@ -13,6 +13,12 @@ without needing to configure anything. Just push your code and GitLab takes care of everything else. This makes it easier to start new projects and brings consistency to how applications are set up throughout a company. +## Quick start + +If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) +for using Auto DevOps with GitLab.com and a Kubernetes cluster on Google Kubernetes +Engine. + ## Comparison to application platforms and PaaS Auto DevOps provides functionality described by others as an application @@ -34,7 +40,7 @@ in a couple of ways: ## Features Comprised of a set of stages, Auto DevOps brings these best practices to your -project in an easy and automatic way: +project in a simple and automatic way: 1. [Auto Build](#auto-build) 1. [Auto Test](#auto-test) @@ -135,10 +141,9 @@ 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) or -[nip.io](http://nip.io) which provide automatic wildcard DNS without any -configuration. Just set the Auto DevOps base domain to `1.2.3.4.nip.io` or -`1.2.3.4.nip.io`. +Alternatively you can use free public services like [nip.io](http://nip.io) +which provide automatic wildcard DNS without any configuration. Just set the +Auto DevOps base domain to `1.2.3.4.nip.io`. Once set up, all requests will hit the load balancer, which in turn will route them to the Kubernetes pods that run your application(s). @@ -198,12 +203,6 @@ and verifying that your app is deployed as a review app in the Kubernetes cluster with the `review/*` environment scope. Similarly, you can check the other environments. -## Quick start - -If you are using GitLab.com, see our [quick start guide](quick_start_guide.md) -for using Auto DevOps with GitLab.com and an external Kubernetes cluster on -Google Cloud. - ## Enabling Auto DevOps If you haven't done already, read the [requirements](#requirements) to make @@ -288,7 +287,7 @@ NOTE: **Note:** Auto Test uses tests you already have in your application. If there are no tests, it's up to you to add them. -### Auto Code Quality +### Auto Code Quality **[STARTER]** Auto Code Quality uses the [Code Quality image](https://gitlab.com/gitlab-org/security-products/codequality) to run @@ -323,7 +322,7 @@ to run analysis on the project dependencies and checks for potential security is report is created, it's uploaded as an artifact which you can later download and check out. -In GitLab Ultimate, any security warnings are also +Any security warnings are also [shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/dependency_scanning.html). ### Auto License Management **[ULTIMATE]** @@ -331,12 +330,12 @@ In GitLab Ultimate, any security warnings are also > Introduced in [GitLab Ultimate][ee] 11.0. License Management uses the -[License Management Docker image](https://gitlab.com/gitlab-org/security-products/license_management) +[License Management Docker image](https://gitlab.com/gitlab-org/security-products/license-management) to search the project dependencies for their license. Once the report is created, it's uploaded as an artifact which you can later download and check out. -In GitLab Ultimate, any licenses are also +Any licenses are also [shown in the merge request widget](https://docs.gitlab.com/ee//user/project/merge_requests/license_management.html). ### Auto Container Scanning diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 61c04f3d9bb..07ba61b48e6 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -1,143 +1,295 @@ -# Auto DevOps: quick start guide +# Getting started with Auto DevOps -> [Introduced][ce-37115] in GitLab 10.0. +This is a step-by-step guide that will help you deploy a project hosted on +GitLab.com to Google Kubernetes Engine, using [Auto DevOps](index.md). -This is a step-by-step guide to deploying a project hosted on GitLab.com to -Google Cloud, using Auto DevOps. +We will use the Kubernetes integration that GitLab provides, so you won't have +to create a Kubernetes cluster manually using the GCP console. -We made a minimal [Ruby -application](https://gitlab.com/auto-devops-examples/minimal-ruby-app) to use -as an example for this guide. It contains two main files: +## Configuring your Google account -* `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` +Before creating and connecting your Kubernetes cluster to your GitLab project, +you have to set up your Google Cloud account. If you don't already have one, go +and create it at https://console.cloud.google.com. If you already have a +Google account that you use to access Gmail, etc., you can use it to sign in +the Google Cloud. -## Fork sample project on GitLab.com +1. Follow the steps as outlined in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin) + in order for the required APIs and related services to be enabled. +1. Make sure you have created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account). -Let’s start by forking our sample application. Go to [the project -page](https://gitlab.com/auto-devops-examples/minimal-ruby-app) and press the -**Fork** button. Soon you should have a project under your namespace with the -necessary files. +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. -You can also start a new project from a -[GitLab project template](https://gitlab.com/gitlab-org/project-templates) if -you want to use a different language. +## Creating a new project from a template -## Setup your own cluster on Google Kubernetes Engine +We will use one of GitLab's project templates to get started. AS the name suggests, +those projects provide a barebone of an application built on some well known frameworks. -If you do not already have a Google Cloud account, create one at -https://console.cloud.google.com. +1. Find the plus icon (**+**) at the top of the navigation bar, click it and select + **New project**. +1. Go to the **Create from template** tab where you can choose among a Ruby on + Rails, a Spring, or a NodeJS Express project. For the sake of the example + let's use the Ruby on Rails template. -Visit the [**Kubernetes 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. + ![Select project template](img/guide_project_template.png) -## Connect to Kubernetes cluster +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). -You need to have the Google Cloud SDK installed. e.g. -On macOS, install [homebrew](https://brew.sh): + ![Create project](img/guide_create_project.png) -1. Install Brew Caskroom: `brew install caskroom/cask/brew-cask` -2. Install Google Cloud SDK: `brew cask install google-cloud-sdk` -3. Add `kubectl` with: `gcloud components install kubectl` -4. Log in: `gcloud auth login` +1. Finally, click on the **Create project** button. -Now go back to the Google interface, find your cluster, follow the instructions -under "Connect to the cluster" and open the Kubernetes Dashboard. It will look -something like: +Now that the project is created, the next step is to create the Kubernetes cluster +under which this application will be deployed. -```sh -gcloud container clusters get-credentials ruby-autodeploy \ --zone europe-west2-c --project api-project-XXXXXXX -``` +## Creating a Kubernetes cluster -Finally, run `kubectl proxy`. +One thing you should notice after you created the project is the **Add Kubernetes cluster** +button on the project's landing page. Go ahead and click it. -![connect to cluster](img/guide_connect_cluster.png) +![Project landing page](img/guide_project_landing_page.png) -## Copy credentials to GitLab.com project +TIP: **Tip:** +Another way is to navigate to **Operations > Kubernetes** and click on +**Add Kubernetes cluster**. -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. +From there on, let's see how to create a new Kubernetes cluster on GKE: -![connect to cluster](img/guide_secret.png) +1. Choose **Create on Google Kubernetes Engine**. -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. + ![Choose GKE](img/guide_choose_gke.png) -![connect to cluster](img/guide_integration.png) +1. Sign in with Google. -For the API URL, you should use the "Endpoint" IP from your cluster page on -Google Cloud Platform. + ![Google sign in](img/guide_google_signin.png) -## Expose application to the world +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). -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. Let's -see how that's done. + ![Google auth](img/guide_google_auth.png) -### Set up Ingress controller +1. The last step is to fill in 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 (if you followed the instructions when you + [configured your Google account](#configuring-your-google-account), a project + should have 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). -You’ll need to make sure you have an ingress controller. If you don’t have one, do: + ![GitLab GKE cluster details](img/guide_gitlab_gke_details.png) -```sh -brew install kubernetes-helm -helm init -helm install --name ruby-app stable/nginx-ingress -``` +1. Once ready, hit the **Create Kubernetes cluster** button. -This should create several services including `ruby-app-nginx-ingress-controller`. -You can list your services by running `kubectl get svc` to confirm that. +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). -### Point DNS at Cluster IP +The next step is to install some applications on your cluster that are needed +to take full advantage of Auto DevOps. -Find out the external IP address of the `ruby-app-nginx-ingress-controller` by -running: +## Installing Helm, Ingress and Prometheus -```sh -kubectl get svc ruby-app-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}' -``` +GitLab's Kubernetes integration comes with some +[pre-defined applications](../../user/project/clusters/index.md#installing-applications) +for you to install. + +![Cluster applications](img/guide_cluster_apps.png) + +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 +its **Install** button. + +Once it's installed, the other applications that rely on it will have their **Install** +button enabled. For this guide, we need Ingress and Prometheus. Ingress provides +load balancing, SSL termination, and name-based virtual hosting, using NGINX behind +the scenes. Prometheus is an open-source monitoring and alerting system that we'll +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 +will show up, we'll use in the next step when enabling Auto DevOps. + +## Enabling Auto DevOps + +Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps. + +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. 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 `master` branch. +1. Hit **Save changes** for the changes to take effect. + + ![Auto DevOps settings](img/guide_enable_autodevops.png) + +Once you complete all the above and save your changes, a new pipeline will be +automatically created. Go to **CI/CD > Pipelines** to check it out. + +![First pipeline](img/guide_first_pipeline.png) + +In the next section we'll break down the pipeline and explain what each job does. + +## Deploying the application + +So, by now you should see the pipeline running, but what is it running exactly? + +To navigate inside the pipeline, click on its status badge (it should say running) +The pipeline is split into 4 stages, each running a couple of jobs. + +![Pipeline stages](img/guide_pipeline_stages.png) + +In the **build** stage, the application is built into a Docker image and then +uploaded to your project's [Container Registry](../../user/project/container_registry.md) ([Auto Build](index.md#auto-build)). + +In the **test** stage, GitLab runs various checks on the application: + +- The `test` job runs unit and integration tests by detecting the language and + framework ([Auto Test](index.md#auto-test)) +- The `code_quality` job checks the code quality and is allowed to fail + ([Auto Code Quality](index.md#auto-code-quality)) **[STARTER]** +- The `container_scanning` job checks the Docker container if it has any + vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning)) +- The `dependency_scanning` job checks if the application has any dependencies + susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning)) **[ULTIMATE]** +- The `sast` job runs static analysis on the current code and checks for potential + security issues and is allowed to fail([Auto SAST](index.md#auto-sast)) **[ULTIMATE]** +- The `license_management` job searches the application's dependencies for their + license and is allowed to fail ([Auto License Management](index.md#auto-license-management)) **[ULTIMATE]** NOTE: **Note:** -If your ingress controller has been installed in a different way, you can find -how to get the external IP address in the -[Cluster documentation](../../user/project/clusters/index.md#getting-the-external-ip-address). +As you might have noticed, all jobs except `test` are allowed to fail in the +test stage. + +The **production** stage is run after the tests and checks finish, and it automatically +deploys the application in Kubernetes ([Auto Deploy](index.md#auto-deploy)). + +Lastly, in the **performance** stage, some performance tests will run +on the deployed application +([Auto Browser Performance Testing](index.md#auto-browser-performance-testing)). **[PREMIUM]** + +--- + +The URL for the deployed application can be found under the **Environments** +page where you can also monitor your application. Let's explore that. + +### Monitoring + +Now that the application is successfully deployed, let's navigate to its +website, by first going to **Operations > Environments**. + +![Environments](img/guide_environments.png) + +This is the **Environments** where you can see some details about the deployed +applications. At the upper right or the production environment, you should see +some icons: + +- The first one will take you to the URL of the application that is deployed in + production. It's a very simple page, but the purpose is that it works! +- The next icon with the little graph will take you to the metrics page where + prometheus collects data about the Kubernetes cluster and how the application + affects it (in terms of memory/CPU usage, latency etc.). -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 `*.`. + ![Environments metrics](img/guide_environments_metrics.png) -Use `nslookup minimal-ruby-app-staging.` to confirm that domain is -assigned to the cluster IP. +- 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 + application is running. -## Set up Auto DevOps +Right below, there is the +[Deploy Board](https://docs.gitlab.com/ee/user/project/deploy_boards.md). +The squares represent pods in your Kubernetes cluster that are associated with +the given environment. Hovering above each square you can see the state of a +deployment and clicking on the square will take you to the pod's logs page. -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. +TIP: **Tip:** +There is only one pod hosting the application at the moment, but you can add +more pods by defining the [`REPLICAS` variable](index.md#environment-variables) +under **Settings > CI/CD > Variables**. -Next, a pipeline needs to be triggered. Since the test project doesn't have a -`.gitlab-ci.yml`, you need to either push a change to the repository or -manually visit `https://gitlab.com//minimal-ruby-app/pipelines/new`, -where `` is your username. +### Working with branches -This will create a new pipeline with several jobs: `build`, `test`, `code_quality`, -and `production`. The `build` job will create a Docker image with your new -change and push it to the Container Registry. The `test` job will test your -changes, whereas the `code_quality` job will run static analysis on your changes. -Finally, the `production` job will deploy your changes to a production application. +Following the [GitLab flow](../../workflow/gitlab_flow.md#working-with-feature-branches) +let's create a feature branch that will add some content to the 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. +Under your repository, navigate to the following file: `app/views/welcome/index.html.erb`. +By now, it should only contain a paragraph: `

You're on Rails!

`, so let's +start adding content. Let's use GitLab's [Web IDE]() to make the change. Once +you're on the Web IDE, make the following change: -Once its ready, just visit `http://minimal-ruby-app.example.com` to see the -famous "Hello, world!"! +```html +

You're on Rails! Powered by GitLab Auto DevOps.

+``` + +Stage the file, add a commit message, and create a new branch and a merge request +by clicking **Commit**. + +![Web IDE commit](img/guide_ide_commit.png) + +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 +a few more that run only on branches other than `master`. + +![Merge request](img/guide_merge_request.png) + +After a few minutes you'll realize that there was a failure in a test. +That means that there's a test that was broken when we made the change. +Navigating in the `test` job that failed, you can see what the broken test is: + +``` +Failure: +WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]: + expected but was +.. +Expected 0 to be >= 1. + +bin/rails test test/controllers/welcome_controller_test.rb:4 +``` -[ce-37115]: https://gitlab.com/gitlab-org/gitlab-ce/issues/37115 +Let's fix that: + +1. Back to the merge request, click the **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**. +1. On your left, under "Unstaged changes", click the little checkmark icon + to stage the changes. +1. Write a commit message and hit **Commit** + +Now, if you go back to the merge request you should see not only the test passing, +but 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. + +![Review app](img/guide_merge_request_review_app.png) + +Once you merge the merge request, the pipeline will run on the `master` branch, +and the application will be eventually deployed straight to production. + +## Conclusion + +By now, you should have gained a solid understanding of how Auto DevOps works. +We started from building and testing to deploying and monitoring an application +all within GitLab. In spite of its auto nature, this doesn't mean that you can't +configure and customize Auto DevOps to fit your workflow. Here are a few +interesting links: + +1. [Auto DevOps](index.md) +1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters) **[PREMIUM]** +1. [Incremental rollout to production](index.md#incremental-rollout-to-production) **[PREMIUM]** +1. [Disable jobs you don't need with environment variables](index.md#environment-variables) +1. [Use a static IP for your cluster](../../user/project/clusters/index.md#using-a-static-ip) +1. [Use your own buildpacks to build your application](index.md#custom-buildpacks) +1. [Prometheus monitoring](../../user/project/integrations/prometheus.md) diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 48bb2e543c1..58106184c2a 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -7,9 +7,10 @@ cluster in a few steps. ## Overview -With a Kubernetes cluster associated to your project, you can use +With one or more Kubernetes clusters associated to your project, you can use [Review Apps](../../../ci/review_apps/index.md), deploy your applications, run -your pipelines, and much more, in an easy way. +your pipelines, use it with [Auto DevOps](../../../topics/autodevops/index.md), +and much more, all from within GitLab. There are two options when adding a new cluster to your project; either associate your account with Google Kubernetes Engine (GKE) so that you can [create new @@ -18,59 +19,65 @@ or provide the credentials to an [existing Kubernetes cluster](#adding-an-existi ## Adding and creating a new GKE cluster via GitLab +TIP: **Tip:** +Every new Google Cloud Platform (GCP) account receives [$300 in credit upon sign up](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. + NOTE: **Note:** -You need Maintainer [permissions] and above to access the Kubernetes page. - -Before proceeding, make sure the following requirements are met: - -- The [Google authentication integration](../../../integration/google.md) must - be enabled in GitLab at the instance level. If that's not the case, ask your - GitLab administrator to enable it. -- Your associated Google account must have the right privileges to manage - clusters on GKE. That would mean that a [billing - account](https://cloud.google.com/billing/docs/how-to/manage-billing-account) - must be set up and that you have to have permissions to access it. -- You must have Maintainer [permissions] in order to be able to access the - **Kubernetes** page. -- You must have [Cloud Billing API](https://cloud.google.com/billing/) enabled -- You must have [Resource Manager - API](https://cloud.google.com/resource-manager/) +The [Google authentication integration](../../../integration/google.md) must +be enabled in GitLab at the instance level. If that's not the case, ask your +GitLab administrator to enable it. On GitLab.com, this is enabled. + +### Requirements + +Before creating your first cluster on Google Kubernetes Engine with GitLab's +integration, make sure the following requirements are met: + +- A [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account) + is set up and you have permissions to access it. +- The Kubernetes Engine API is enabled. Follow the steps as outlined in the + ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin). + +### Creating the cluster If all of the above requirements are met, you can proceed to create and add a -new Kubernetes cluster that will be hosted on GKE to your project: +new Kubernetes cluster to your project: 1. Navigate to your project's **Operations > Kubernetes** page. + + NOTE: **Note:** + You need Maintainer [permissions] and above to access the Kubernetes page. + 1. Click on **Add Kubernetes cluster**. 1. Click on **Create with Google Kubernetes Engine**. 1. Connect your Google account if you haven't done already by clicking the **Sign in with Google** button. -1. Fill in the requested values: +1. From there on, choose your cluster's settings: - **Kubernetes cluster name** - The name you wish to give the cluster. - **Environment scope** - The [associated environment](#setting-the-environment-scope) to this cluster. - - **Google Cloud Platform project** - The project you created in your GCP - console that will host the Kubernetes cluster. This must **not** be confused - with the project ID. Learn more about [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects). - - **Zone** - The [zone](https://cloud.google.com/compute/docs/regions-zones/) + - **Google Cloud Platform project** - Choose the project you created in your GCP + console that will host the Kubernetes cluster. Learn more about + [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects). + - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/) under which the cluster will be created. - - **Number of nodes** - The number of nodes you wish the cluster to have. + - **Number of nodes** - Enter the number of nodes you wish the cluster to have. - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types) of the Virtual Machine instance that the cluster will be based on. 1. Finally, click the **Create Kubernetes cluster** button. -After a few moments, your cluster should be created. If something goes wrong, -you will be notified. - -You can now proceed to install some pre-defined applications and then -enable the Cluster integration. +After a couple of minutes, your cluster will be ready to go. You can now proceed +to install some [pre-defined applications](#installing-applications). ## Adding an existing Kubernetes cluster -NOTE: **Note:** -You need Maintainer [permissions] and above to access the Kubernetes page. - To add an existing Kubernetes cluster to your project: 1. Navigate to your project's **Operations > Kubernetes** page. + + NOTE: **Note:** + You need Maintainer [permissions] and above to access the Kubernetes page. + 1. Click on **Add Kubernetes cluster**. 1. Click on **Add an existing Kubernetes cluster** and fill in the details: - **Kubernetes cluster name** (required) - The name you wish to give the cluster. @@ -91,9 +98,8 @@ To add an existing Kubernetes cluster to your project: to create one. You can also view or create service tokens in the [Kubernetes dashboard](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#config) (under **Config > Secrets**). - - **Project namespace** (optional) - The following apply: - - By default you don't have to fill it in; by leaving it blank, GitLab will - create one for you. + - **Project namespace** (optional) - You don't have to fill it in; by leaving + it blank, GitLab will create one for you. Also: - Each project should have a unique namespace. - The project namespace is not necessarily the namespace of the secret, if you're using a secret with broader permissions, like the secret from `default`. @@ -103,11 +109,8 @@ To add an existing Kubernetes cluster to your project: be the same. 1. Finally, click the **Create Kubernetes cluster** button. -After a few moments, your cluster should be created. If something goes wrong, -you will be notified. - -You can now proceed to install some pre-defined applications and then -enable the Kubernetes cluster integration. +After a couple of minutes, your cluster will be ready to go. You can now proceed +to install some [pre-defined applications](#installing-applications). ## Security implications @@ -152,9 +155,9 @@ added directly to your configured cluster. Those applications are needed for | Application | GitLab version | Description | | ----------- | :------------: | ----------- | -| [Helm Tiller](https://docs.helm.sh/) | 10.2+ | Helm is a package manager for Kubernetes and is required to install all the other applications. It will be automatically installed as a dependency when you try to install a different app. It is installed in its own pod inside the cluster which can run the `helm` CLI in a safe environment. | +| [Helm Tiller](https://docs.helm.sh/) | 10.2+ | Helm is a package manager for Kubernetes and is required to install all the other applications. It is installed in its own pod inside the cluster which can run the `helm` CLI in a safe environment. | | [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) | 10.2+ | Ingress can provide load balancing, SSL termination, and name-based virtual hosting. It acts as a web proxy for your applications and is useful if you want to use [Auto DevOps] or deploy your own web apps. | -| [Prometheus](https://prometheus.io/docs/introduction/overview/) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications | +| [Prometheus](https://prometheus.io/docs/introduction/overview/) | 10.4+ | Prometheus is an open-source monitoring and alerting system useful to supervise your deployed applications. | | [GitLab Runner](https://docs.gitlab.com/runner/) | 10.6+ | GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with [GitLab CI/CD](https://about.gitlab.com/features/gitlab-ci-cd/), the open-source continuous integration service included with GitLab that coordinates the jobs. When installing the GitLab Runner via the applications, it will run in **privileged mode** by default. Make sure you read the [security implications](#security-implications) before doing so. | | [JupyterHub](http://jupyter.org/) | 11.0+ | The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. | -- cgit v1.2.1 From 140be51fd5a4c9540bff52b777bacda099c345ba Mon Sep 17 00:00:00 2001 From: Mike Lewis Date: Thu, 21 Jun 2018 21:54:47 +0000 Subject: Edits to quick_start_guide.md --- doc/topics/autodevops/quick_start_guide.md | 112 +++++++++++++---------------- 1 file changed, 51 insertions(+), 61 deletions(-) diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 07ba61b48e6..2a114a1a783 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -1,18 +1,18 @@ # Getting started with Auto DevOps -This is a step-by-step guide that will help you deploy a project hosted on -GitLab.com to Google Kubernetes Engine, using [Auto DevOps](index.md). +This is a step-by-step guide that will help you use [Auto DevOps](index.md) to +deploy a project hosted on GitLab.com to Google Kubernetes Engine. -We will use the Kubernetes integration that GitLab provides, so you won't have -to create a Kubernetes cluster manually using the GCP console. +We will use GitLab's native Kubernetes integration, so you will not need +to create a Kubernetes cluster manually using the Google Cloud Platform console. +We will create and deploy a simple application that we create from a GitLab template. ## Configuring your Google account Before creating and connecting your Kubernetes cluster to your GitLab project, -you have to set up your Google Cloud account. If you don't already have one, go -and create it at https://console.cloud.google.com. If you already have a -Google account that you use to access Gmail, etc., you can use it to sign in -the Google Cloud. +you need a Google Cloud Platform account. If you don't already have one, +sign up at https://console.cloud.google.com. You'll need to either sign in with an existing +Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one. 1. Follow the steps as outlined in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin) in order for the required APIs and related services to be enabled. @@ -25,14 +25,14 @@ Google Kubernetes Engine Integration. All you have to do is [follow this link](h ## Creating a new project from a template -We will use one of GitLab's project templates to get started. AS the name suggests, -those projects provide a barebone of an application built on some well known frameworks. +We will use one of GitLab's project templates to get started. As the name suggests, +those projects provide a barebones application built on some well-known frameworks. -1. Find the plus icon (**+**) at the top of the navigation bar, click it and select +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, a Spring, or a NodeJS Express project. For the sake of the example - let's use the Ruby on Rails template. + Rails, Spring, or NodeJS Express project. For this example, + we'll use the Ruby on Rails template. ![Select project template](img/guide_project_template.png) @@ -42,23 +42,16 @@ those projects provide a barebone of an application built on some well known fra ![Create project](img/guide_create_project.png) -1. Finally, click on the **Create project** button. +1. Click **Create project**. Now that the project is created, the next step is to create the Kubernetes cluster under which this application will be deployed. -## Creating a Kubernetes cluster +## Creating a Kubernetes cluster from within GitLab -One thing you should notice after you created the project is the **Add Kubernetes cluster** -button on the project's landing page. Go ahead and click it. +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.) -![Project landing page](img/guide_project_landing_page.png) - -TIP: **Tip:** -Another way is to navigate to **Operations > Kubernetes** and click on -**Add Kubernetes cluster**. - -From there on, let's see how to create a new Kubernetes cluster on GKE: + ![Project landing page](img/guide_project_landing_page.png) 1. Choose **Create on Google Kubernetes Engine**. @@ -75,16 +68,16 @@ From there on, let's see how to create a new Kubernetes cluster on GKE: 1. The last step is to fill in 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 (if you followed the instructions when you + will be created. (Per the instructions when you [configured your Google account](#configuring-your-google-account), a project - should have been created for you). Next, choose the + 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). ![GitLab GKE cluster details](img/guide_gitlab_gke_details.png) -1. Once ready, hit the **Create Kubernetes cluster** button. +1. Once ready, click **Create Kubernetes cluster**. 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). @@ -92,7 +85,7 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes). The next step is to install some applications on your cluster that are needed to take full advantage of Auto DevOps. -## Installing Helm, Ingress and Prometheus +## Installing Helm, Ingress, and Prometheus GitLab's Kubernetes integration comes with some [pre-defined applications](../../user/project/clusters/index.md#installing-applications) @@ -104,7 +97,7 @@ 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 its **Install** button. -Once it's installed, the other applications that rely on it will have their **Install** +Once it's installed, the other applications that rely on it will each have their **Install** button enabled. For this guide, we need Ingress and Prometheus. Ingress provides load balancing, SSL termination, and name-based virtual hosting, using NGINX behind the scenes. Prometheus is an open-source monitoring and alerting system that we'll @@ -112,14 +105,13 @@ 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 -will show up, we'll use in the next step when enabling Auto DevOps. +is displayed, which we'll use in the next step when enabling Auto DevOps. ## Enabling Auto DevOps Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps. 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 @@ -130,13 +122,13 @@ Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps. would be `1.2.3.4.nip.io`. 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 `master` branch. -1. Hit **Save changes** for the changes to take effect. + successfully runs on the `master` branch. +1. Click **Save changes**. ![Auto DevOps settings](img/guide_enable_autodevops.png) -Once you complete all the above and save your changes, a new pipeline will be -automatically created. Go to **CI/CD > Pipelines** to check it out. +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**. ![First pipeline](img/guide_first_pipeline.png) @@ -144,9 +136,9 @@ In the next section we'll break down the pipeline and explain what each job does ## Deploying the application -So, by now you should see the pipeline running, but what is it running exactly? +By now you should see the pipeline running, but what is it running exactly? -To navigate inside the pipeline, click on its status badge (it should say running) +To navigate inside the pipeline, click its status badge. (It's status should be "running"). The pipeline is split into 4 stages, each running a couple of jobs. ![Pipeline stages](img/guide_pipeline_stages.png) @@ -164,10 +156,10 @@ In the **test** stage, GitLab runs various checks on the application: vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning)) - The `dependency_scanning` job checks if the application has any dependencies susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning)) **[ULTIMATE]** -- The `sast` job runs static analysis on the current code and checks for potential +- The `sast` job runs static analysis on the current code to check for potential security issues and is allowed to fail([Auto SAST](index.md#auto-sast)) **[ULTIMATE]** -- The `license_management` job searches the application's dependencies for their - license and is allowed to fail ([Auto License Management](index.md#auto-license-management)) **[ULTIMATE]** +- The `license_management` job searches the application's dependencies to determine each of their + licenses and is allowed to fail ([Auto License Management](index.md#auto-license-management)) **[ULTIMATE]** NOTE: **Note:** As you might have noticed, all jobs except `test` are allowed to fail in the @@ -188,19 +180,18 @@ page where you can also monitor your application. Let's explore that. ### Monitoring Now that the application is successfully deployed, let's navigate to its -website, by first going to **Operations > Environments**. +website. First, go to **Operations > Environments**. ![Environments](img/guide_environments.png) -This is the **Environments** where you can see some details about the deployed -applications. At the upper right or the production environment, you should see -some icons: +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: -- The first one will take you to the URL of the application that is deployed in - production. It's a very simple page, but the purpose is that it works! -- The next icon with the little graph will take you to the metrics page where - prometheus collects data about the Kubernetes cluster and how the application - affects it (in terms of memory/CPU usage, latency etc.). +- The first icon will open the URL of the application that is deployed in + production. It's a very simple page, but the important part is that it works! +- The next icon with the small graph will take you to the metrics page where + Prometheus collects data about the Kubernetes cluster and how the application + affects it (in terms of memory/CPU usage, latency, etc.). ![Environments metrics](img/guide_environments_metrics.png) @@ -212,7 +203,7 @@ Right below, there is the [Deploy Board](https://docs.gitlab.com/ee/user/project/deploy_boards.md). The squares represent pods in your Kubernetes cluster that are associated with the given environment. Hovering above each square you can see the state of a -deployment and clicking on the square will take you to the pod's logs page. +deployment and clicking a square will take you to the pod's logs page. TIP: **Tip:** There is only one pod hosting the application at the moment, but you can add @@ -226,7 +217,7 @@ let's create a feature branch that will add some content to the application. Under your repository, navigate to the following file: `app/views/welcome/index.html.erb`. By now, it should only contain a paragraph: `

You're on Rails!

`, so let's -start adding content. Let's use GitLab's [Web IDE]() to make the change. Once +start adding content. Let's use GitLab's [Web IDE](../../user/project/web_ide/index.md) to make the change. Once you're on the Web IDE, make the following change: ```html @@ -244,9 +235,9 @@ a few more that run only on branches other than `master`. ![Merge request](img/guide_merge_request.png) -After a few minutes you'll realize that there was a failure in a test. -That means that there's a test that was broken when we made the change. -Navigating in the `test` job that failed, you can see what the broken test is: +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. +Navigating into the `test` job that failed, you can see what the broken test is: ``` Failure: @@ -266,10 +257,10 @@ Let's fix that: 1. Click **Commit**. 1. On your left, under "Unstaged changes", click the little checkmark icon to stage the changes. -1. Write a commit message and hit **Commit** +1. Write a commit message and click **Commit**. -Now, if you go back to the merge request you should see not only the test passing, -but the application deployed as a [review app](index.md#auto-review-apps). You +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. @@ -280,11 +271,10 @@ and the application will be eventually deployed straight to production. ## Conclusion -By now, you should have gained a solid understanding of how Auto DevOps works. +After implementing this project, you should now have a solid understanding of the basics of Auto DevOps. We started from building and testing to deploying and monitoring an application -all within GitLab. In spite of its auto nature, this doesn't mean that you can't -configure and customize Auto DevOps to fit your workflow. Here are a few -interesting links: +all within GitLab. Despite its automatic nature, Audo DevOps can also be configured +and customized to fit your workflow. Here are some helpful resources for further reading: 1. [Auto DevOps](index.md) 1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters) **[PREMIUM]** -- cgit v1.2.1 From 1781ec14f5ba91fe66499d398b65b5055e0fca00 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Fri, 22 Jun 2018 08:12:20 +0200 Subject: Add paragraph for self-hosted instances --- doc/topics/autodevops/quick_start_guide.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 2a114a1a783..44b0cf758dc 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -7,6 +7,10 @@ We will use GitLab's native Kubernetes integration, so you will not need to create a Kubernetes cluster manually using the Google Cloud Platform console. We will create and deploy a simple application that we create from a GitLab template. +These instructions will also work for a self-hosted GitLab instance; you'll just +need to ensure your own [Runners are configured](../../ci/runners/README.md) and +[Google OAuth is enabled](../../integration/google.md). + ## Configuring your Google account Before creating and connecting your Kubernetes cluster to your GitLab project, @@ -49,7 +53,8 @@ under which this application will be deployed. ## Creating a Kubernetes cluster from within GitLab -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. 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**). ![Project landing page](img/guide_project_landing_page.png) -- cgit v1.2.1