Cellier Clément, Maginot Quentin, Tripier Axel, Zaorski Jean, Zini Robin. 18 mars 2015

Transcription

1 TP Cellier Clément, Maginot Quentin, Tripier Axel, Zaorski Jean, Zini Robin 18 mars 2015

2 Résumé Ce TP a pour but de présenter, au travers de l outil principal Docker, Varnish, HAProxy et Nginx.

3 Installation Docker L installation de Docker se fait facilement à partir du gestionnaire de paquets. Pour Ubuntu : $ sudo apt-get update $ sudo apt-get install docker.io Vérifier que docker est bien lancé sur votre machine : $ sudo service docker status S il ne l est pas, vous pouvez le lancer : $ sudo service docker start Il est possible d avoir à utiliser docker.io au lieu de docker. Récupération de l image de base Pour travailler avec Docker nous allons avoir besoin d une image d un système d exploitation. Nous allons la télécharger à l avance, elle sera conservée en cache et prête à chaque fois que l on en aura besoin. $ sudo docker pull debian:wheezy Vous êtes prêt pour faire vos premiers pas avec Docker! Présentation de l architecture 1

4 NGINX NGINX (engine x) est un serveur HTTP libre, open-source et haute performance, ainsi qu un proxy inverse. Il sert également de proxy pour l IMAP et le POP3. Nginx héberge actuellement près de 22.8 millions des noms de domaine à travers le monde. Il est reconnu pour ses hautes performances, sa stabilité, son ensemble de fonctionnalités, sa configuration simple ainsi que sa faible consommation de ressources. Nginx est l un des rares serveurs développé pour le problème des C10K (servir simultanément plus de clients). Contrairement aux serveurs traditionnels, Nginx ne relie pas un processus à une requête client. A la place, il utilise un système évolutif et une architecture asynchrone. Cette architecture utilise de petites, mais plus important, prévisibles quantité de mémoire sous forte charge. Même si vous n avez pas besoin de gérer des milliers de requêtes simultanées, vous pouvez bénéficier des hautes performances de Nginx ainsi que de sa faible consommation mémoire. Nginx est évolutif dans les deux sens : du plus petit VPS (ou VDS) aux infrastructures cluster. HAProxy HAProxy est un logiciel open-source, une solution pour de la haute disponibilité de service. Il fournit l équilibrage de charge et le proxy pour les protocoles TCP et les applications basées sur le protocole HTTP, en répartissant les requêtes sur plusieurs serveurs. Il est écrit en C et a la réputation d être rapide et efficace (en termes de processeur et de consommation mémoire). HAProxy est utilisé par un certain nombre de sites de grande envergure, y compris GitHub, Bitbucket, Stack Overflow, Reddit, Tumblr et Twitter et est utilisé dans le produit de OpsWorks d Amazon Web Services. Varnish Varnish est un accélérateur HTTP conçue pour les sites web dynamiques a contenu lourd, ainsi que des API fortement consommées. Contrairement à d autres accélérateurs Web, tels que Squid, qui a commencé sa vie comme un cache côté client, ou Apache et nginx, qui sont principalement des serveurs web, Varnish a été conçu comme un accélérateur HTTP. Varnish se concentre exclusivement sur HTTP, contrairement à d autres serveurs proxy qui supportent souvent FTP, SMTP et d autres protocoles réseau. Varnish est utilisé par un grand nombre de sites à fort trafic, y compris les sites en ligne de journaux tels que le New York Times, The Guardian, The Hindu, Corriere della Sera, les médias sociaux et les sites de contenu comme Wikipedia, Facebook, Twitter, Vimeo, Tumblr et bien d autres. 2

5 Le Conteneur Docker L incontournable hello world Maintenant que vous avez docker d installé et que vous avez pull une image, essayez la commande suivante : $ sudo docker run debian:wheezy echo "Hello World" Grosse surprise : vous obtenez Hello World!! Essayons de comprendre ce qui s est passé. Un conteneur docker peut être vue comme une boite contenant un processus. Cette boite contient tout ce dont le processus peut avoir besoin : des fichiers sytème, les librairies sytème, un shell, etc... Mais par défaut, rien de tout ça n est en exécution. Un conteneur est démarré lorque on lance son processus contenu. Dans notre cas, lorsque on execute run sur debian :wheezy, l image étant trouvée en local, un conteneur docker basé sur debian est construit avec comme processus principal la commande echo hello world. Le processus s éxecute, se termine et par conséquent, termine le docker qui n a plus rien à éxecuter. Dockerfile Les commandes FROM <image>:<tag> Il s agit de la première instruction d un Dockerfile. Elle Permet de charger une image. L image récupérée est celle située en locale, si aucune image portant le nom renseigné existe en locale, elle est récupérée sur com. Le tag permet de spécifier la version de l image. Si aucun tag n est renseigné la dernière image est chargée. MAINTAINER <name> Auteur de l image générée. RUN <command> ou RUN ["executable", "param1", "param2"] Lance une commande Shell. CMD ["executable","param1","param2"] ou CMD command param1 param2 Commande exécutée au lancement du conteneur. Il doit y avoir une seule commande CMD par Dockerfile. 3

6 EXPOSE <port> [<port>...] Permet d informer Docker sur quel port le conteneur va écouter. Docker utilise cette information pour interconnecter des conteneurs au moyen de liens et pour déterminer quels ports présenter à l hôte. Option à utiliser au lancement du conteneur pour mapper le(s) port(s) renseigné(s) sur le(s) port(s) de l hôte : -p ip :hostport :containerport Option à utiliser au lancement du conteneur pour le linker à un conteneur : link name :alias ENV <key> <value> ou ENV <key>=<value>... Permet de modifier des variables d environnement. ADD <src>... <dest> ou ADD ["<src>"... "<dest>"] Copie les fichiers, les répertoires de l hôte ou les fichiers d une URL (src) et les ajoute au système de fichiers du conteneur (dest). Si src est une archive tar de l hôte avec un format reconnu (gzip, bzip2 ou xz) elle sera décompressée automatiquement dans le conteneur. COPY <src>... <dest> ou COPY ["<src>"... "<dest>"] Copie les fichiers, les répertoires de l hôte (src) et les ajoute au système de fichiers du conteneur (dest). VOLUME ["/data"] Crée un point de montage. Permet ensuite de monter ce volume sur l hôte ou sur un autre conteneur au moment du lancement du conteneur. Option à utiliser au lancement du conteneur pour monter un volume du conteneur sur l hôte : -v /host/directory :/chemin/vers/volume/du/conteneur Option à utiliser au lancement du conteneur pour monter les volumes d un conteneur sur un autre conteneur : -volumes-from nom conteneur Plus d infos sur les commandes d un Dockerfile reference/builder#from 4

7 Exemple avec nginx Dockerfile du nginx officiel blob/e35d ca5221fcf958ed8aa6a55a5b043af/dockerfile : # Image à charger FROM debian:wheezy # Nom de l auteur de l image MAINTAINER NGINX Docker Maintainers "docker-maint@nginx.com" # Commande shell RUN apt-key adv --keyserver pgp.mit.edu \ --recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62 # Commande shell RUN echo "deb wheezy nginx" \ >> /etc/apt/sources.list # Fixe la variable d environnement NGINX_VERSION à ~wheezy ENV NGINX_VERSION ~wheezy RUN apt-get update && apt-get install -y ca-certificates nginx=${nginx_version} \ && rm -rf /var/lib/apt/lists/* # forward request and error logs to docker log collector # Commande shell RUN ln -sf /dev/stdout /var/log/nginx/access.log # Commande shell RUN ln -sf /dev/stderr /var/log/nginx/error.log # Déclare un volume VOLUME ["/var/cache/nginx"] # Ports à exposer à l exterieur EXPOSE # Commande à éxécuter au lancement du conteneur, # lance nginx en premier plan et pas en arrière plan afin # que le conteneur ne se termine pas CMD ["nginx", "-g", "daemon off;"] Dockerfile nginx de notre projet tripier/projetingres/blob/nginx/nginx/dockerfile : # image à charger FROM nginx # Copie le contenu du répertoire html local et le met # dans /usr/share/nginx/html du conteneur COPY html /usr/share/nginx/html Faire un Dockerfile Vous allez maintenant créer un Dockerfile répondant aux critères suivants : 5

8 1. Création d un Docker à partir de l image debian :wheezy 2. Ecriture sur la console d un message 3. Spécifier le lancement de la commande ping au démarage de la machine Pour tester vous allez devoir utiliser les commandes suivantes : $ sudo docker build -t your_repo/your_name. $ sudo docker run -i your_repo/your_name -name mondocker La commande build permet de préparer votre docker à partir du dockerfile. L option -t permet de nommer le docker. L option -i de Docker permet de lancer le conteneur en mode intéractif, c est à dire de voir la sortie standard du conteneur. Enfin, l option -name permet de nommer son docker. Durant le build vous devriez voir votre message. Une fois la machine lancée, vous devriez voir la commande ping s exécuter. Lancer un Docker en intéractif est intéressant pour voir ce qu il se passe directement. Mais Docker donne la possibilité d accéder à la sortie standard sans laisser la machine au premier plan. Pour cela, lancer le conteneur avec la commande : $ sudo docker run -d your_repo/your_name Tapez la commande suivante pour voir la liste des dockers lancés : $ sudo docker ps Il est intéressant de remarquer que chaque docker dispose d un nom associé, même lorsque vous ne le donnez pas explicitement avec l option name. C est ce nom qu on va pouvoir utiliser pour obtenir la sortie standard du docker en cours d éxécution. Pour cela, il suffit d utiliser la commande : $ sudo docker logs docker_name Pour arrêter la machine il faudra utiliser la commande stop, pour supprimer le docker il faudra utiliser rm : $ sudo docker stop docker_name $ sudo docker rm docker_name Solution FROM debian:wheezy RUN echo "I just started to play with docker" CMD ["ping", " 6

9 Mise en pratique Présentation Nous allons maintenant mettre en place une architecture permettant de visualiser le partage de charge au niveau de connexions HTTP, grâce à Docker. Comme indiqué dans la présentation de l architecture, un serveur de cache, ici Varnish, sera le point d entrée de notre système. Il mettra en cache les contenu statiques d un site web que nous avons réalisé. Il sera lié à un serveur de partage de charge, HAProxy, qui répartira en round-robin les requêtes dynamiques (et celles qui ne sont pas encore cachées par Varnish) sur trois serveurs de back-end, faisant tourner un nginx chacun. Cette architecture est très standard dans le web actuel, si ce n est que le nombre de serveurs de back-end est bien plus grand habituellement. Nous allons tout d abord lancer les serveurs de back-end, puis nous lancerons le serveur de partage de charge en le liant aux serveur de back-end pour qu il sache à quelle adresse IP les contacter, et nous finirons par lancer le serveur de cache en le liant à son tour au serveur de partage de charge. Lancement des serveurs de back-end Dans le repo git que vous avez cloné, vous retrouverez 3 dossiers : varnish haproxy nginx L application qui nous intéresse pour le serveur de back-end est nginx. Ouvrez un terminal dans ce dossier. Ce dossier comporte un Dockerfile, décrivant comment construire l image, ainsi qu un dossier html, contenant les sources de notre site web d exemple. Commencez par lire le Dockerfile. Ce dernier est très simple : on se base sur l image officielle de nginx, qui est déjà faite pour nous et présente dans le Docker Hub, et on copie juste tout le contenu du dossier html dans le container pour qu il puisse servir notre site web. Nginx est donc déjà pré-configuré comme il faut pour tourner correctement dans Docker. Dans le terminal ouvert dans le dossier nginx, on peut donc construire le container défini par le Dockerfile : $ sudo docker build -t octamaille/nginx. On peut ensuite lancer ce conteneur 3 fois, car nous voulons 3 instances du serveur de back-end. Le contenu de chaque instance est le même, seul le nom de l instance change. 7

10 $ sudo docker run -d --name="backend-serv-1" octamaille/nginx $ sudo docker run -d --name="backend-serv-2" octamaille/nginx $ sudo docker run -d --name="backend-serv-3" octamaille/nginx Vous devriez maintenant voir les 3 instances tourner dans Docker. Vérifiez avec un : $ sudo docker ps Attention! Ne continuez pas si les 3 instances ne tournent pas! Si les instances tournent bien, vous pouvez passer à l étape suivante. Lancement du serveur de partage de charge Le serveur de partage de charge est HAProxy. Donc, déplacez vous dans le dossier haproxy récupéré avec git. Lisez là encore le Dockerfile : vous voyez que nous partons là aussi d une image officielle, ici HAProxy en version 1.5, dans laquelle nous copions notre propre fichier de configuration, haproxy.cfg. Ce fichier contient notamment la configuration des serveurs sur lesquels HA- Proxy doit effectuer la répartition de charge (à la fin du fichier). Ici, on a défini 3 serveurs, qui seront choisis en round-robin : [...] balance roundrobin [...] server backend-1 backend-serv-1:80 check server backend-2 backend-serv-2:80 check server backend-3 backend-serv-3:80 check La syntaxe pour chaque serveur est : server <nom serveur> <adresse IP serveur>:<port> check L option check permet à HAProxy de vérifier régulièrement que le serveur est bien accessible, pour ne pas y envoyer des clients en cas de panne. Le nom du serveur permet de l identifier dans les logs. Ici, la partie intéressante est l adresse IP de chaque serveur. Il s agit dans notre cas de noms de machines, qui seront résolus en interne vers les adresses IP des serveurs de back-end dynamiquement au moment de l exécution du conteneur HAProxy, via un système de liens entre conteneurs que nous verrons dans quelques instants. On construit donc le conteneur : $ sudo docker build -t octamaille/haproxy. Et on le lance, en liant chaque conteneur de back-end au conteneur HAProxy via leur nom d instance Docker : 8

11 $ sudo docker run -d --name="load-balancer" \ --link backend-serv-1:backend-serv-1 \ --link backend-serv-2:backend-serv-2 \ --link backend-serv-3:backend-serv-3 \ octamaille/haproxy Syntaxt de link : --link <nom conteneur docker actif>:<alias dans le conteneur lancé> Là encore, le conteneur haproxy devrait maintenant avoir démarré et tourner : $ sudo docker ps Attention! Ne continuez pas si les 4 instances lancées (3 nginx et 1 haproxy) ne tournent pas! Si les instances tournent bien, vous pouvez passer à l étape suivante. Lancement du serveur de cache Le dernier serveur à lancer est Varnish, qui fait office de serveur de cache. Déplacez vous dans le dossier varnish. Ouvrez le Dockerfile. Ce dernier est plus complexe, car il ne se base pas sur une image officielle de Varnish : il a été créé à partir de Debian, et donc toutes les étapes d installation et de configuration de Varnish sont décrites dedans. Lisez et comprenez le Dockerfile. Notez que le default ttl, temps pendant lequel sera stocké les ressources statiques avant d être réactualisées depuis le serveur de back-end, est de 120 secondes. Une fois compris, lisez le fichier de configuration de Varnish. Dedans est spécifié l IP du serveur auquel est lié Varnish, donc ici le load-balancer HAProxy. Il est aussi défini quelques options utiles pour notre exemple : nous désactivons le cache sur les fichiers en.html, habituellement cachés automatiquement, et nous enlevons le header Authorization des requêtes entrantes sur toutes les URL à pars celles contenant haproxy, pour qu elles soient bien cachées par Varnish. Vous pouvez maintenant construire l image, ce qui prendra plus de temps que les autres car toutes les étapes doivent être effectuées : $ sudo docker build -t octamaille/varnish. A noter : vous pouvez ignorer les quelques messages en rouge dans la sortie, tant que la construction de l image se finit avec succès! On peut enfin lancer le dernier élément de notre architecture : 9

12 $ sudo docker run -d --name="cache-serv" \ --link load-balancer:load-balancer \ -p 8000:80 octamaille/varnish L option -p 8000 :80 permet de spécifier que l on veut pouvoir accéder à ce conteneur via notre port 8000, qui redirigera en interne dans le conteneur sur le port 80. Nous n avons pas eu à faire ça pour les autres conteneurs car nous n y accédons pas directement depuis l extérieur, seul Varnish est visible. Vérifiez que vous avez bien tous les conteneurs d actifs sur Docker : $ sudo docker ps Si oui, il est temps de tester notre architecture! Test d accès au site web Tout d abord, ouvrez 3 consoles pour visualiser les logs des 3 serveurs de back-end. $ sudo docker logs -f backend-serv-1 $ sudo docker logs -f backend-serv-2 $ sudo docker logs -f backend-serv-3 Ensuite, ouvrez votre navigateur web, et accédez à l URL suivante : Un magnifique site web devrait s afficher! Regardez maintenant les consoles de logs des serveurs de back-end : vous remarquerez que les différentes requêtes sont réparties entre les différents serveurs, grâce à HAProxy! Rafraichissez ensuite la page : vous ne devriez avoir aucune nouvelle requête sur les logs des serveurs de back-end : Varnish a caché les résultats, et sert donc chaque composant à la place du serveur de back-end. Dans la configuration de Varnish, nous avons désactivé le cache des URL finissant par.html. Effectuez donc quelques fois la commande suivante depuis un terminal : $ curl Vous devriez observer que les requêtes vers cette page sont bien envoyées en round-robin entre les différents serveurs de back-end. Vous pouvez ensuite afficher les différentes statistiques de Varnish en ouvrant dans votre navigateur la page : $ curl 10

13 Le nom d utilisateur est octamaille, le mot de passe est octamaille. Une fois la page ouverte, vous pouvez effectuer plusieurs fois la commande curl précédente, et observer que les requêtes sont bien réparties entre chaque serveur. Attendez plus de 2 minutes et réessayez de charger le site. Varnish devrait mettre à jour son cache, et donc redemander les fichiers aux différents serveurs de back-end via HAProxy. Voilà, l architecture est donc entièrement fonctionnelle! Nettoyage Pour nettoyer votre ordinateur à la fin du TP, effectuez les commandes suivantes : $ sudo docker stop cache-serv load-balancer \ backend-serv-3 backend-serv-2 backend-serv-1 $ sudo docker rm cache-serv load-balancer \ backend-serv-3 backend-serv-2 backend-serv-1 $ sudo docker rmi octamaille/varnish octamaille/haproxy octamaille/nginx $ sudo docker rmi debian:wheezy Architecture globale générale Voici un schéma de ce à quoi nous voulons arriver pour notre démonstration finale. Les composants de base sont les mêmes que ceux employés dans ce TP, il y aura juste plus d outils autour pour les configurer et les gérer automatiquement. 11