## Containerisation dans le cloud

![LBNLogo](images/lbn.jpg) ###### By Jean-Michel PRATA DA SILVA

Monter une infrastructure **résiliente, *auto-scallable* et facilement exploitable** est une autre paire de manche que je ne vais pas aborder pour des raisons de temps et de maux de tête.

![Maux de tête](images/headache.jpg)

## LA Solution Cloud Aujourd’hui, le **CaaS (Containers As A Service)** est LA solution déportée. Elle commence à se démocratiser et devient abordable. Les principaux colosses du cloud publique y ont vu une niche en devenir et ont lancé une offre de service autour de la containerisation :
- Cloud Azure : [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/) (ACS) - Cloud AWS : [EC2 Container Service](https://aws.amazon.com/documentation/ecs/?nc1=h_ls) (ECS) - Cloud Google : [Google Container Engine](https://cloud.google.com/container-engine/) (GKE)
En quelques instants et en quelques clics, vous êtes au main d’une plateforme clustérisée de containers dockers. En fonction de votre cluster et des agents (Virtual Machines) que vous allez choisir, la facture sera plus où moins salée.

![coût infrastructure](images/cost.jpg) Tout dépend de votre besoin, si vous êtes sur une infrastructure de production à haute disponibilité ou d’un environnement de test pour des développeurs.

## Etes-vous prêt à relever ce petit défi ? ### Cas pratique sur sur le Cloud Azure..

![Docker and Azure](images/dockerazure.jpg)

### Le contexte Microsoft **Microsoft** s’est ouvert depuis quelques années au monde de l’Open-Source, contrairement à l’ère BALLMER qui l’en avait éloigné, en travaillant en étroite collaboration avec Cannonical sur divers projets : - [Le portage de Bash sous Windows](https://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/) - [Le portage de SQL Server sous Linux](https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/#sm.00019pjj6d7treg8rg92ro5qf35lf) - [L’ouverture de codes source ( .NET, PowerShell,..)](https://www.asp.net/open-source) - [LXD Container Supervisor](http://www.zdnet.com/article/ubuntu-is-working-on-a-new-secure-container-hypervisor-lxd/) - [The DC/OS Project](https://azure.microsoft.com/en-us/blog/microsoft-joins-the-new-dc-os-open-source-project/)

![Microsoft and OpenSource](images/mo.jpg) Ce rapprochement avec [Cannonical](https://www.canonical.com/) et la communauté Open-Source n’est sans un intérêt certain vis-à-vis de la présence de linux dans une environnement Cloud. Lorsqu’on parle actuellement container, la solution qui revient le plus est : [**Docker**](https://www.docker.com/what-docker). Aujourd’hui, Microsoft ne supporte pas Docker mais cela ne serait tarder car une version en *Preview* est en cours.

### Comment font ils donc pour fournir un service de containerisation me direz-vous ? Encore une fois, ce rapprochement ave Cannonical leur a été bénéfique car l’ensemble de la plateforme **ACS** repose sur des serveurs sous Ubuntu 16.04 LTS couplés à différents outils open-source.
### Let's go ! Construisons notre environnement Azure Conainer Service de demo Je vous propose en quelques instant de mettre en œuvre une infrastructure basique sur le cloud Pour commencer, voici le [lien](https://azure.microsoft.com/en-us/free/?b=16.51b) pour créer un compte Azure vous permettant le droit d’avoir **200$** de crédit pour vous permettre de tester l’un des services que Microsoft propose sur son cloud.
## Création du compte Azure & création de l'infrastructure 1. Authentifiez vous sur [le portail Azure](https://portal.azure.com/) 2. Récupérer [ici](files/basic_acs_template.json) le contenu au format json du template ACS de l'infrastructure de démo. 3. Dans la section **Templates** du portail Azure, créér un template "*demo-acs*" en utilisant le code json récupéré. 4. Déployer l'infrastructure à partir du template en répondant à quelques questions (Nom du RessourceGroup, mot de passe à définir ). 5. Patienter quelques minutes et voilà votre environnement ACS disponible
## Petit aparté Pour notre démo, j’ai opté pour [DC/OS](https://dcos.io/), solution d'entreprise permettant l'eslasticité d'une plateforme d'application conteneurisées. A ce jour, il s'agit de la solution la mieux intégrée et supportée par Microsoft. Pour ma part, j’apprécie assez la documentation chez [Mesosphere](https://mesosphere.com/) et leur participation sur Github autour de [Marathon](https://mesosphere.github.io/marathon/) et d’[Universe](http://mesosphere.github.io/universe/)
## Une infrastructure complète et scalable

![DCOS Infrastructure](images/dcos_infra.jpg)

Notre cluster possède un ou plusieurs master DCOS permettant la disponibilité des agents DC/OS (public & private). Nous conseillons de passer à **3 nodes masters** minima dès que vous souhaitez utiliser cette infrastructure pour un environnement de production.

![Warning](images/warning.jpg)

Ces différents groupes de serveurs font partie de « ScaleSet », entité permettant l’auto-scalling des nodes agents en fonction de la charge CPU/RAM de ces derniers. Deux groupes d’agents sont déployés, l’un accessible depuis internet à travers un loadbalancer Azure du fait que le subnet soit routé mais le second ne l’est pas.
### Création du tunnel SSH pour se connecter à l'infrastructure 1. Se connecter sur un master DC/OS Il faut identifier l'IP publique de votre **dcos-master**. Pour celà, aller dans le RessourceGroup crée et identifier l'objet **Public IP Address** 2. Utiliser un client SSH et créer un tunnel ssh

						ssh –L8882:localhost:80 –i ~/.ssh/yourprivatesshkey demo_adm@PUBLIC-IP
          

						demo_adm@dcos-master-2626893B-0:~$
					
### Accès aux interfaces de la plateforme (1/2) DC/OS URL:http://localhost:8882

![DCOS Interface](images/dcos_interface.jpg)

Cette interface possède un dashbord assez complet permettant d’avoir un aperçu assez complet de l’état de santé de la plateforme.

![Docker+DCOS+AZURE](images/dcosdockerazure.jpg)

### Accès aux interfaces de la plateforme (2/2) Marathon URL:http://localhost:8882/marathon/

![Marathon Interface](images/marathon_interface.jpg)

Marathon permet le déploiement de container que l’on appellera une application. Outre d’avoir une interface standard d’administration, marathon possède [une API de type REST](https://mesosphere.github.io/marathon/docs/rest-api.html) fort sympathique qui vous permettra d’automatiser vos déploiements.

![DMS Logo](images/docker_marathon_mesos.jpg)

### Différentes couches applicatives impactées dans un déploiement docker

![Docker Image Deployment](images/docker_workflow_deployment.jpg)

### Scalabilité avec marathon-lb Permettre le scalling au niveau « container » de façon transparente d’un type d’application nécessite la mise en place **d’un container marathon-lb** portant le service HAProxy. Pour chaque application, lors du déploiement du container applicatif, le service va s’auto-enregistrer auprès du marathon-lb.
### Déploiement d'un container marathon-lb (1/2) Depuis l’interface DC/OS, aller dans **Universe** (menu de gauche) puis sélectionner le package marathon-lb (HAProxy container) puis installer :

![Marathon LB Deployment](images/marathonlb_deployment.jpg)

### Déploiement d'un container marathon-lb (2/2) Une fois déployé, le container est présent et actif.

![Marathon LB Health](images/marathonlb_state.jpg)

### Déploiement d'une application "hello-world"(1/3) Depuis Marathon, l’orchestrateur de container fournis par DC/OS, nous allons à partir d’un fichier description en json déployer notre image docker sur un agent DCOS. Voici [un exemple de fichier json](files/hello.json) pour faire celà.
### Déploiement d'une application "hello-world"(2/3) Pour cela, il faut cliquer sur * **Create Application** * et passer en mode json. Il vous suffit ensuite de copier/coller le contenu de notre fichier json et de valider:

![Marathon json import](images/marathon_json_import.jpg)

### Déploiement d'une application "hello-world"(3/3)

![Result containers deployment](images/containers_deployement.jpg)

Voilà nos deux containers déployés qui seront accessible depuis internet à travers le marathon-lb. Il ne reste plus qu’à ouvrir les flux web et d’autoriser le flux http vers le port **10000/tcp** du marathon-lb sur le loadbalancer des public agents DCOS.
###Résultat"(1/2) - 1er essai Je saisi l’url de mon vhost dans mon navigateur et voilà le résultat:

![premier essai](images/resultat1.jpg)

###Résultat"(2/2) - 2eme essai

![deuxieme essai](images/resultat2.jpg)

Le résultat escompté est bien au rendez-vous car depuis notre url de demo, nous arrivons bien sur les deux containers en http.
### Mon feedback ! Les points positifs - Résultat probant car **en quelques minutes** nous avons une plateforme en **haute disponibilité** sur le Cloud Azure - SLA en corrélation avec un monde de production. - Nous avons le choix entre différents framework ( DC/OS, Swarm, Kubernetes..). Celà laisse le choix au plus réfractaires de migrer dans le Cloud en gardant leurs petites habitudes. - Des **services Azure disponible et complémentaire** à l'ACS sont disponibles: *Application Gateway, Azure container Registry...*
### Mon feedback ! Les points négatifs Pour moi, aujourd'hui l'offre ACS s'apparente à une offre packagée de type **PaaS** et non à une vrai offre **CaaS**. Les VMs sont accessibles en SSH, les modifications systèmes sont possibles mais déconseillées.Certe cette offre doit faire encore ces preuves et est en pleine évolution mais je m'attendais à quelque chose de plus contruit..
### Et vous, qu'en pensez vous ? Le meilleur moyen de vous faire votre idée est de suivre ce petit tutoriel.