Port changes from Autodeploy EE to CE

2 files changed, 171 insertions, 0 deletions

diff --git a/doc/ci/autodeploy/index.md b/doc/ci/autodeploy/index.md
index a714689ebd5..5272e9e8e68 100644
--- a/doc/ci/autodeploy/index.md
+++ b/doc/ci/autodeploy/index.md
@@ -15,6 +15,10 @@ You can use [project services][project-services] to store credentials to
 your infrastructure provider and they will be available during the
 deployment.
 
+## Quick start
+
+We made a [simple guide](quick_start_guide.md) to using Auto Deploy with GitLab.com.
+
 ## Supported templates
 
 The list of supported auto deploy templates is available in the
@@ -35,6 +39,85 @@ enable [Kubernetes service][kubernetes-service].
 1. Test your deployment configuration using a [Review App][review-app] that was
 created automatically for you.
 
+## Using the Kubernetes deploy example project with Nginx
+
+The Autodeploy templates are based on the [kubernetes-deploy][kube-deploy]
+project which is used to simplify the deployment process to Kubernetes by
+providing intelligent `build`, `deploy` and `destroy` commands which you can
+use in your `.gitlab-ci.yml` as-is. It uses Heroku'ish build packs to do some
+of the work, plus some of GitLab's own tools to package it all up. For your
+convenience, a [Docker image][kube-image] is also provided.
+
+---
+
+A simple example would be the deployment of Nginx on Kubernetes.
+Consider a `nginx-deployment.yaml` file in your project with contents:
+
+```yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: __CI_ENVIRONMENT_SLUG__
+  labels:
+    app: __CI_ENVIRONMENT_SLUG__
+    track: stable
+spec:
+  replicas: 3
+  template:
+    metadata:
+      labels:
+        app: __CI_ENVIRONMENT_SLUG__
+        track: stable
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.7.9
+        ports:
+        - containerPort: 80
+```
+
+The important part is where we set up `app: __CI_ENVIRONMENT_SLUG__`. As you'll
+see later this is replaced by the [`CI_ENVIRONMENT_SLUG` env variable][variables].
+
+The `.gitlab-ci.yml` would be:
+
+```yaml
+image: registry.gitlab.com/gitlab-examples/kubernetes-deploy
+
+stages:
+  - deploy
+
+kubernetes deploy:
+  stage: deploy
+  environment:
+    name: production
+  script:
+    - echo "$KUBE_CA_PEM" > kube_ca.pem
+    - cat kube_ca.pem
+    - kubectl config set-cluster default-cluster --server=$KUBE_URL --certificate-authority="$(pwd)/kube_ca.pem"
+    - kubectl config set-credentials default-admin --token=$KUBE_TOKEN
+    - kubectl config set-context default-system --cluster=default-cluster --user=default-admin --namespace $KUBE_NAMESPACE
+    - kubectl config use-context default-system
+
+    - sed -i "s/__CI_ENVIRONMENT_SLUG__/$CI_ENVIRONMENT_SLUG/" nginx-deployment.yaml
+    - cat nginx-deployment.yaml
+    - kubectl cluster-info
+    - kubectl get deployments -l app=$CI_ENVIRONMENT_SLUG
+    - kubectl create -f nginx-deployment.yaml || kubectl replace -f nginx-deployment.yaml
+```
+
+Notice that we use a couple of Kubernetes environment variables to configure
+the Kubernetes cluster. These are exposed from the
+[Kubernetes service](../../user/project/integrations/kubernetes.md#deployment-variables).
+The most important one is the `$KUBE_NAMESPACE` which should be unique for
+every project.
+
+Next, we replace `__CI_ENVIRONMENT_SLUG__` with the content of the
+`CI_ENVIRONMENT_SLUG` variable, so that the `app` label has the correct value.
+
+Finally, the Nginx pod is created from the definition of the
+`nginx-deployment.yaml` file.
+
 ## Private Project Support
 
 > Experimental support [introduced][mr-2] in GitLab 9.1.
@@ -67,6 +150,8 @@ PostgreSQL provisioning can be disabled by setting the variable `DISABLE_POSTGRE
 [kubernetes-service]: ../../user/project/integrations/kubernetes.md
 [docker-in-docker]: ../docker/using_docker_build.md#use-docker-in-docker-executor
 [review-app]: ../review_apps/index.md
+[kube-image]: https://gitlab.com/gitlab-examples/kubernetes-deploy/container_registry "Kubernetes deploy Container Registry"
+[kube-deploy]: https://gitlab.com/gitlab-examples/kubernetes-deploy "Kubernetes deploy example project"
 [container-registry]: https://docs.gitlab.com/ce/user/project/container_registry.html
 [postgresql]: https://www.postgresql.org/
 
diff --git a/doc/ci/autodeploy/quick_start_guide.md b/doc/ci/autodeploy/quick_start_guide.md
new file mode 100644
index 00000000000..0f7c255147d
--- /dev/null
+++ b/doc/ci/autodeploy/quick_start_guide.md
@@ -0,0 +1,86 @@
+# Auto deploy: quick start guide
+
+This is a step-by-step guide to deploying a project hosted on GitLab.com to Google Cloud, using Auto Deploy.
+
+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.
+On OSX, install [homebrew](https://brew.sh):
+
+1. Install Brew Caskroom: `brew install caskroom/cask/brew-cask`
+2. Install Google Cloud SDK: `brew cask install google-cloud-sdk`
+3. Add `kubectl`: `gcloud components install kubectl`
+4. Log in: `gcloud auth login`
+
+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`.
+
+![connect to cluster](img/guide_connect_cluster.png)
+
+## 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.
+
+![connect to cluster](img/guide_secret.png)
+
+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.
+
+![connect to cluster](img/guide_integration.png)
+
+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 -o jsonpath='{.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.
+
+## Setup Auto Deploy
+
+Visit the home page of your GitLab.com project and press "Set up Auto Deploy" button.
+
+![auto deploy button](img/auto_deploy_btn.png)
+
+You will be redirected to the New file page where you can apply one of the Auto Deploy templates. Select "Kubernetes" to apply the template, then in the file, replace "domain.example.com" with your domain name and any other adjustments you feel comfortable with.
+
+![auto deploy template](img/auto_deploy_dropdown.png)
+
+Change the target branch to `master`, and submit your changes. This should create a new pipeline with several jobs. If you made only the domain name change, the pipeline will have 3 jobs: `build`, `staging` and `production`. The `build` job will create a docker image with your new change and push it to the GitLab Container Registry. The `staging` job will deploy this image on your cluster. 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 `ruby-autodeploy-23`, but with a unique ID for your project, and your app will be listed as “staging” under the Deployment tab.
+
+Once its ready - just visit http://minimal-ruby-app-staging.yourdomain.com to see “Hello, world!”