Update Docker PaaS tutorials to include all new changes in the gamma (LB, labels..) (#150)

Signed-off-by: Balthazar Rouberol <balthazar.rouberol@corp.ovh.com>

Author: brouberol

en/_posts/2016-04-20-introduction-to-docker-with-mesos-marathon.md

@@ -24,25 +24,24 @@ If you want more information about the Apache Mesos architecture, please read th
 
 ##What is Marathon?
 
-[Marathon](https://mesosphere.github.io/marathon/) is an Apache Mesos framework to run Docker containers. It provides a lot of features like framework high availibility through an active/passive system, anti-affinity constraints to ensure containers are launched on different hosts or racks, application health checks, etc. You can manage your applications and containers using a web UI, allowing you to easily launch new containers, scale your applications, and more.
+[Marathon](https://mesosphere.github.io/marathon/) is an Apache Mesos framework to run long-running processes, such as Docker containers. It provides a lot of features like framework high availibility through an active/passive system, anti-affinity constraints to ensure containers are launched on different hosts or racks, application health checks, etc. You can manage your applications and containers using a web UI or an API, allowing you to easily launch new containers, scale your applications, and more.
 
 #What do we provide?
 
-The Docker PaaS lab is based on all these software stacks, adding some other cool stuff, like redirecting your application Logs to our PaaS Logs, and your application metrics our PaaS Timeseries.. Our lab is stack managed, it means that **we** deploy and manage your infrastructure.
+The Docker PaaS lab is based on all these software stacks, adding some other cool stuff, like redirecting your application Logs to our [PaaS Logs](https://www.runabove.com/paas-logs.xml), and your application metrics the [DBaaS Time Series](https://www.ovh.com/fr/dbaas/timeseries/). Our lab is stack managed, it means that **we** deploy and manage your infrastructure.
 
 ##Your resources are dedicated
 
-We are not providing a pool of slaves where everybody launches containers. You have **dedicated** Public Cloud instances, and dedicated resources. Your containers are running on your instances, and only yours, without noisy neighbours.
-During the beta, you'll be limited to a single (and free) [VPS SSD 3](https://www.ovh.com/fr/vps/vps-ssd.xml). However, you'll be able to add more resources as we advance, not limited to the OVH cloud.
+We are not providing a pool of nodes where everybody launches containers. You have **dedicated** Public Cloud instances, and dedicated resources. Your containers are running on your instances, and only yours, without noisy neighbours. You're of course free to add more resource nodes to be able to deploy more containers.
 
 ##We manage everything
 
 We manage Mesos masters, ZooKeepers, load balancers and Mesos slaves. However, we provide you with an access to the marathon web UI and to your HAProxy load balancer stats.
 
 ##We do not only give you containers
-We provide you with a full stack, integrated with the OVH ecosystem. It means that your stack is fully extensible: as the beta evolves, you'll be able to add new instances, as your needs evolve, from any kind (Public Cloud, Dedicated Server, etc).
+We provide you with a full stack, integrated with the OVH ecosystem. It means that your stack is fully extensible: as the lab evolves, you'll be able to add new instances, as your needs evolve, from any kind (Public Cloud, Dedicated Server, etc).
 
-To easily assess if you have enough resources for your running applications, we provide you with [a way to obtain metrics using the Timeseries PaaS lab](/kb/en/docker/marathon-container-metrics.html), and exploit them with Grafana dashboards.
+To easily assess if you have enough resources for your running applications, we provide you with [a way to visualize your application metrics using the DBaaS Time Series](/kb/en/docker/marathon-container-metrics.html), and exploit them with Grafana dashboards.
 
 Also, you can have access to your application logs [using the PaaS Logs lab](/kb/en/docker/marathon-container-logs.html) in Graylog.
 

en/_posts/2016-04-21-quick-start-with-marathon.md

@@ -6,15 +6,15 @@ author: devatoria
 lang: en
 ---
 
-Welcome to the quick start tutorial of the Docker PaaS lab. This document will help you launch your first application using the Marathon Web UI.
+Welcome to the quick start tutorial of the Docker PaaS lab. This tutorial will help you launch your first application using the Marathon Web UI.
 
 # First and foremost
 
 If you haven't already read our [introduction to Docker with Mesos and Marathon](/kb/en/docker/introduction-to-docker-with-mesos-marathon.html), you should probably read it before diving in.
 
 #Access to your Marathon Web UI
 
-Once your Mesos slave has been installed, you'll receive an email containing the URL and credentials of your marathon.
+Once your resource node has been installed, you'll receive an email containing the URL and credentials of your marathon. You can of course change this password in the [manager](https://www.ovh.com/manager/sunrise/containers/index.html#/containers).
 
 
 ![Main interface](/kb/images/2016-04-20-quick-start-with-marathon/marathon.png)
@@ -47,7 +47,6 @@ The docker container settings allow you to use multiple docker options defined i
 - **Image**: the name of the docker image, can be prefixed with the URL of the registry to use
 - **Network**: the network to use *(actually, whatever you choose, the network will be defaulted to Bridged)*
 - **Force Pull Image**: enable it if you want the image to be pulled everytime you launch the container, to make sure your app is always based on the ``latest`` tag.
-- **Privileges**: enable this to launch your container in privileged mode *(actually automatically disabled)*
 
 ![Create interface - Docker settings](/kb/images/2016-04-20-quick-start-with-marathon/create_container_2.png)
 
@@ -71,6 +70,10 @@ Now, your container is going to be deployed on a valid host which is able to han
 
 # Accessing your app
 
-You now have access to your nginx server via the URL `https://<username>.lb.sbg-1.containers.ovh.net:10080`, where `<username>` is the login you received by email (for example, `docker-abcdef-1`).
+You now have access to your nginx server via the URL `https://<username>.lb.<cluster>.containers.ovh.net:10080`.
 
-However, if you think that this URL is not elegant enough, fear not and read our [next tutorial](/kb/en/docker/marathon-load-balancer.html)!
+**Note**: you can derive the value of both `username` and `cluster` from the address of your marathon web ui. For example, if your UI URL is `http://lb.sbg-1.containers.ovh.net/marathon/docker-abcdef-1/`, the value of `cluster` and `username` are respectively `sbg-1` and `docker-abcdef-1`.
+
+# Conclusion
+
+You now have a publicly accessible nginx, running in a Docker container. However, it's access URL is not very elegant. Fear not, and learn how to configure your load balancer by reading our [next tutorial](/kb/en/docker/marathon-load-balancer.html)!

en/_posts/2016-04-23-marathon-health-checks.md

@@ -6,12 +6,13 @@ author: devatoria
 lang: en
 ---
 
-Health checks are useful to ensure that your containers are running; and even better, are behaving as expected. You can add multiple health checks per application. Marathon supports both high level HTTP and lower level TCP health checks.
+Health checks are useful to ensure that your containers are running; and even better, are behaving as expected. If your container is found to be unhealthy, it will be automatically redeployed. You can add multiple health checks per application. Marathon supports both high level HTTP and lower level TCP health checks.
+
 HTTP checks allow for better, higher level checks on a specific URL like `http://localhost:port/my/health/path`. It automatically ignores informational status codes in the range 100 to 199.
 
 # Configure a health check for a nginx application
 
-In the [previous tutorial](/kb/en/docker/quick-start-with-marathon.html), we ran a simple nginx container. Let's now configure some HTTP health check for this application.
+In one of the [previous tutorials](/kb/en/docker/quick-start-with-marathon.html), we deployed and ran a simple nginx container on Marathon. Let's now configure some HTTP health check for this application.
 
 ![Main interface](/kb/images/2016-04-20-marathon-health-checks/health_check.png)
 

en/_posts/2016-04-24-marathon-container-logs.md

@@ -10,6 +10,6 @@ It may be useful to send your application logs to the [PaaS Logs RunAbove lab](h
 
 #Inject my token into my container
 
-To be able to push logs into the PaaS Logs platform, you have to generate a new token from the RunAbove user interface. You will find more information on the [PaaS Logs quick start guide](https://community.runabove.com/kb/en/logs/quick-start.html). Once you have your token, you must inject it into your application containers using the label `USER_THOT_TOKEN`, when creating/editing your app.
+To be able to push logs into the PaaS Logs platform, you have to generate a new token from the RunAbove user interface. You will find more information on the [PaaS Logs quick start guide](https://community.runabove.com/kb/en/logs/quick-start.html). Once you have your token, you must inject it into your application containers using the label `USER_LOGS_TOKEN`, when creating/editing your app.
 
 ![Main interface](/kb/images/2016-04-21-marathon-logs/logs.png)

en/_posts/2016-04-25-marathon-container-metrics.md

@@ -1,12 +1,12 @@
 ---
 layout: post
-title:  "Marathon containers metrics in PaaS Timeseries"
+title:  "Marathon containers metrics in DBaaS Time Series"
 categories: Docker
 author: devatoria
 lang: en
 ---
 
-We integrated the Docker PaaS with the [Timeseries PaaS lab](https://www.runabove.com/iot-paas-timeseries.xml), to allow you to graph your application metrics about your containers in a Grafana dashboard. We automatically send metrics for:
+We integrated the Docker PaaS with the [DBaaS Time Series](https://www.ovh.com/fr/dbaas/timeseries/), to allow you to graph your application metrics about your containers in a Grafana dashboard. We automatically send metrics for:
 
 - CPU usage
 - memory usage
@@ -16,7 +16,7 @@ We integrated the Docker PaaS with the [Timeseries PaaS lab](https://www.runabov
 
 #Configure your token
 
-From the RunAbove manager, join the PaaS Timeseries lab and generate a new credentials pair (read/write). Next, inject the write credentials into your applications using `USER_IOT_ID` and `USER_IOT_KEY` labels.
+From the RunAbove manager, join the DBaaS Time Series lab and generate a new credentials pair (read/write). Next, inject the write credentials into your applications using `USER_TIMESERIES_ID` and `USER_TIMESERIES_KEY` labels.
 
 ![Main interface](/kb/images/2016-04-21-marathon-metrics/metrics.png)
 
@@ -25,7 +25,7 @@ Metrics are aggregated, averaged and pushed every minute.
 #Analyse my data
 ##Create graphs
 
-Once your applications metrics are sent to the PaaS Timeseries, you can create some graphs to easily watch how your applications behave, and adapt your stack according to your needs. Available metrics for graphs are:
+Once your applications metrics are sent to the DBaaS Time Series, you can create some graphs to easily watch how your applications behave, and adapt your stack according to your needs. Available metrics for graphs are:
 
 - cpu
 - memory.usage

en/_posts/2016-06-17-marathon-api-worker-architecture.markdown

@@ -37,7 +37,7 @@ Then, mount `/data` as a read-write docker volume. This will ensure data persist
 
 ![redis configuration 1/2](/kb/images/2016-06-17-marathon-api-worker-queue/redis.png)
 
-Then, you can add your [PaaS Logs](https://www.runabove.com/paas-logs.xml) token and [PaaS Timeseries](https://www.runabove.com/iot-paas-timeseries.xml) token to the app labels, to [redirect your logs](https://community.runabove.com/kb/en/docker/marathon-container-logs.html) [and container metrics](https://community.runabove.com/kb/en/docker/marathon-container-metrics.html) to these infrastructures.
+Then, you can add your [PaaS Logs](https://www.runabove.com/paas-logs.xml) token and [DBaaS Time Series](https://www.ovh.com/fr/dbaas/timeseries/) token to the app labels, to [redirect your logs](https://community.runabove.com/kb/en/docker/marathon-container-logs.html) [and container metrics](https://community.runabove.com/kb/en/docker/marathon-container-metrics.html) to these infrastructures.
 
 Finally, configure a TCP health check on container port 6379. By doing so, marathon will check if a TCP connection can be established with redis, and will restart the container if that's not the case.
 
@@ -111,7 +111,7 @@ We define these environment variables:
 
 ![worker configuration](/kb/images/2016-06-17-marathon-api-worker-queue/worker.png)
 
-We don't define any health check, as the worker does not expose any TCP nor HTTP port. As for the other applications, we can add our PaaS Logs and Timeseries tokens as labels.
+We don't define any health check, as the worker does not expose any TCP nor HTTP port. As for the other applications, we can add our PaaS Logs and Time Series tokens as labels.
 
 # Testing
 

en/_posts/2016-06-21-deploying-wordpress-on-marathon.md

@@ -25,18 +25,7 @@ You can refer to the [PaaS DB tutorial](https://www.ovh.co.uk/g2216.getting_star
 
 ## Restrict access to the database to your container IPs
 
-In order to make your database accessible from your containers only, you have to specify which IPs are authorised to connect to your instance. You can get your containers IP using our API. For example
-
-```bash
-$ curl -u "<username>:<password>" https://lb.<cluster>.containers.ovh.net/api/v1/slaves/ip
-{
-  "objects": [
-    "165.118.227.114",
-    "165.118.231.44"
-  ]
-}
-```
-**Note**: you can derive the value of both `username` and `cluster` from the address of your marathon web ui. For example, if your UI URL is `http://lb.sbg-1.containers.ovh.net/marathon/docker-abcdef-1/`, the value of `cluster` and `username` are respectively `sbg-1` and `docker-abcdef-1`. The password is the one you use to access the Marathon web UI.
+In order to make your database accessible from your containers only, you have to specify which IPs are authorised to connect to your instance. You can get your containers IP in the [manager](https://www.ovh.com/manager/sunrise/containers/index.html#/containers) (a container IP is the public IP of the slave it is running on).
 
 ![whitelist](/kb/images/2016-06-21-deploying-wordpress-on-marathon/whitelist.png)