Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

DOCKER 1 CONCERNANT CES SUPPORTS DE COURS 2 . 1 SUPPORTS DE COURS RÉALISÉS PAR

DOCKER 1 CONCERNANT CES SUPPORTS DE COURS 2 . 1 SUPPORTS DE COURS RÉALISÉS PAR ALTER WAY CLOUD CONSULTING ex Osones - Copyright © 2014 - 2019 alter way Cloud Consulting Licence : Sources : HTML/PDF : Licence Creative Commons BY-SA 4.0 https://cloud-consulting.alterway.fr Creative Commons BY-SA 4.0 https://github.com/Alterway/formations/ https://osones.com/formations/ 2 . 2 LE CLOUD : VUE D’ENSEMBLE 3 . 1 LE CLOUD, C’EST LARGE ! Stockage/calcul distant (on oublie, cf. externalisation) Virtualisation++ Abstraction du matériel (voire plus) Accès normalisé par des APIs Service et facturation à la demande Flexibilité, élasticité 3 . 2 WAAS : WHATEVER AS A SERVICE IaaS : Infrastructure as a Service PaaS : Platform as a Service SaaS : Software as a Service 3 . 3 LE CLOUD EN UN SCHÉMA 3 . 4 POURQUOI DU CLOUD ? CÔTÉ TECHNIQUE Abstraction des couches basses On peut tout programmer à son gré (API) Permet la mise en place d’architectures scalables 3 . 5 VIRTUALISATION DANS LE CLOUD Le cloud IaaS repose souvent sur la virtualisation Ressources compute : virtualisation Virtualisation complète : KVM, Xen Virtualisation conteneurs : OpenVZ, LXC, Docker, RKT 3 . 6 NOTIONS ET VOCABULAIRE IAAS L’instance est par définition éphémère Elle doit être utilisée comme ressource de calcul Séparer les données des instances 3 . 7 ORCHESTRATION DES RESSOURCES ? Groupement fonctionnel de ressources : micro services Infrastructure as Code : Définir toute une infrastructure dans un seul fichier texte de manière déclarative Scalabilité : passer à l'échelle son infrastructure en fonction de différentes métriques. 3 . 8 POSITIONNEMENT DES CONTENEURS DANS L'ÉCOSYSTÈME CLOUD ? Facilitent la mise en place de PaaS Fonctionnent sur du IaaS ou sur du bare-metal Simplifient la décomposition d'applications en micro services 3 . 9 LES CONTENEURS 4 . 1 DÉFINITION Les conteneurs fournissent un environnement isolé sur un système hôte, semblable à un chroot sous Linux ou une jail sous BSD, mais en proposant plus de fonctionnalités en matière d'isolation et de configuration. Ces fonctionnalités sont dépendantes du système hôte et notamment du kernel. 4 . 2 LE KERNEL LINUX Namespaces Cgroups (control groups) 4 . 3 LES NAMESPACES 4 . 4 MOUNT NAMESPACES ( LINUX 2.4.19) Permet de créer un arbre des points de montage indépendants de celui du système hôte. 4 . 5 UTS NAMESPACES (LINUX 2.6.19) Unix Time Sharing : Permet à un conteneur de disposer de son propre nom de domaine et d’identité NIS sur laquelle certains protocoles tel que LDAP peuvent se baser. 4 . 6 IPC NAMESPACES (LINUX 2.6.19) Inter Process Communication : Permet d’isoler les bus de communication entre les processus d’un conteneur. 4 . 7 PID NAMESPACES (LINUX 2.6.24) Isole l’arbre d’exécution des processus et permet donc à chaque conteneur de disposer de son propre processus maître (PID 0) qui pourra ensuite exécuter et manager d'autres processus avec des droits illimités tout en étant un processus restreint au sein du système hôte. 4 . 8 USER NAMESPACES (LINUX 2.6.23-3.8) Permet l’isolation des utilisateurs et des groupes au sein d’un conteneur. Cela permet notamment de gérer des utilisateurs tels que l’UID 0 et GID 0, le root qui aurait des permissions absolues au sein d’un namespace mais pas au sein du système hôte. 4 . 9 NETWORK NAMESPACES (LINUX 2.6.29) Permet l’isolation des ressources associées au réseau, chaque namespace dispose de ses propres cartes réseaux, plan IP, table de routage, etc. 4 . 10 CGROUPS : CONTROL CROUPS CGroup: / |--docker | |--7a977a50f48f2970b6ede780d687e72c0416d9ab6e0b02030698c1633fdde956 | |--6807 nginx: master process ngin | | |--6847 nginx: worker proces 4 . 11 CGROUPS : LIMITATION DE RESSOURCES Limitation des ressources : des groupes peuvent être mis en place afin de ne pas dépasser une limite de mémoire. 4 . 12 CGROUPS : PRIORISATION Priorisation : certains groupes peuvent obtenir une plus grande part de ressources processeur ou de bande passante d'entrée-sortie. 4 . 13 CGROUPS : COMPTABILITÉ Comptabilité : permet de mesurer la quantité de ressources consommées par certains systèmes, en vue de leur facturation par exemple. 4 . 14 CGROUPS : ISOLATION Isolation : séparation par espace de nommage pour les groupes, afin qu'ils ne puissent pas voir les processus des autres, leurs connexions réseaux ou leurs fichiers. 4 . 15 CGROUPS : CONTRÔLE Contrôle : figer les groupes ou créer un point de sauvegarde et redémarrer. 4 . 16 DEUX PHILOSOPHIES DE CONTENEURS Systeme : simule une séquence de boot complète avec un init process ainsi que plusieurs processus (LXC, OpenVZ). Process : un conteneur exécute un ou plusieurs processus directement, en fonction de l'application conteneurisée (Docker, Rkt). 4 . 17 ENCORE PLUS “CLOUD” QU’UNE INSTANCE Partage du kernel Un seul processus par conteneur Le conteneur est encore plus éphémère que l’instance Le turnover des conteneurs est élevé : orchestration 4 . 18 CONTAINER RUNTIME Docker Rkt LXC 4 . 19 LXC Conteneur système Utilise la liblxc Virtualisation d'un système complet (boot) 4 . 20 DOCKER Développé par dotCloud et open sourcé en mars 2013 Fonctionne en mode daemon : difficulté d'intégration avec les init-process Utilisait la liblxc Utilise désormais la libcontainer 4 . 21 ROCKET (RKT) Se prononce “rock-it” Développé par CoreOS Pas de daemon : intégration avec systemd Utilise systemd-nspawn et propose maintenant d'autres solutions (eg. KVM) Adresse certains problèmes de sécurité inhérents à Docker 4 . 22 LES CONTENEURS: CONCLUSION Fonctionnalités offertes par le Kernel Les conteneurs engine fournissent des interfaces d'abstraction Plusieurs types de conteneurs pour différents besoins 4 . 23 LES CONCEPTS 5 . 1 UN ENSEMBLE DE CONCEPTS ET DE COMPOSANTS Layers Stockage Volumes Réseau Publication de ports Service Discovery 5 . 2 LAYERS Les conteneurs et leurs images sont décomposés en couches (layers) Les layers peuvent être réutilisés entre différents conteneurs Gestion optimisée de l'espace disque. 5 . 3 LAYERS : UNE IMAGE Une image se decompose en layers 5 . 4 LAYERS : UN CONTENEUR Une conteneur = une image + un layer r/w 5 . 5 LAYERS : PLUSIEURS CONTENEURS Une image, plusieurs conteneurs 5 . 6 LAYERS : RÉPÉTITION DES LAYERS Les layers sont indépendants de l'image 5 . 7 STOCKAGE Images Docker, données des conteneurs, volumes Multiples backends (extensibles via plugins): AUFS DeviceMapper OverlayFS NFS (via plugin Convoy) GlusterFS (via plugin Convoy) 5 . 8 STOCKAGE : AUFS A unification filesystem Stable : performance écriture moyenne Non intégré dans le Kernel Linux (mainline) 5 . 9 STOCKAGE : DEVICE MAPPER Basé sur LVM Thin Provisionning et snapshot Intégré dans le Kernel Linux (mainline) Stable : performance écriture moyenne 5 . 10 STOCKAGE : OVERLAYFS Successeur de AUFS Performances accrues Relativement stable mais moins éprouvé que AUFS ou Device Mapper 5 . 11 STOCKAGE : PLUGINS Étendre les drivers de stockages disponibles Utiliser des systèmes de fichier distribués (GlusterFS) Partager des volumes entre plusieurs hôtes docker 5 . 12 VOLUMES Assurent une persistance des données Indépendance du volume par rapport au conteneur et aux layers Deux types de volumes : Conteneur : Les données sont stockées dans ce que l'on appelle un data conteneur Hôte : Montage d'un dossier de l'hôte docker dans le conteneur Partage de volumes entre plusieurs conteneurs 5 . 13 VOLUMES : EXEMPLE Un volume monté sur deux conteneurs 5 . 14 VOLUMES : PLUGINS Permettre le partage de volumes entre differents hôtes Fonctionnalité avancées : snapshot, migration, restauration Quelques exemples: Convoy : multi-host et multi-backend (NFS, GlusterFS) Flocker : migration de volumes dans un cluster 5 . 15 RÉSEAU : A LA BASE, PAS GRAND CHOSE... NETWORK ID NAME DRIVER 42f7f9558b7a bridge bridge 6ebf7b150515 none null 0509391a1fbd host host 5 . 16 RÉSEAU : BRIDGE 5 . 17 RÉSEAU : HOST 5 . 18 RÉSEAU : NONE Explicite 5 . 19 RÉSEAU : LES ÉVOLUTIONS Refactorisation des composants réseau (libnetwork) Système de plugins : multi host et multi backend (overlay network) Quelques exemples d'overlay : Flannel : UDP et VXLAN Weaves : UDP 5 . 20 RÉSEAU : MULTIHOST OVERLAY 5 . 21 PUBLICATION DE PORTS Dans le cas d'un réseau diffèrent de l'hôte Les conteneurs ne sont pas accessible depuis l'extérieur Possibilité de publier des ports depuis l'hôte vers le conteneur (iptables) L'hôte sert de proxy au service 5 . 22 PUBLICATION DE PORTS 5 . 23 LINKS Les conteneurs d'un même réseau peuvent communiquer via IP Les liens permettent de lier deux conteneurs par nom Système de DNS rudimentaire (/etc/hosts) Remplacés par les discovery services 5 . 24 LES CONCEPTS: CONCLUSION Les composants de Docker sont modulaires Nombreuses possibilités offertes par défaut. Possibilité d'étendre les fonctionnalités via des plugins 5 . 25 BUILD, SHIP AND RUN ! 6 . 1 BUILD 6 . 2 LE CONTENEUR ET SON IMAGE Flexibilité et élasticité Format standard de facto Instanciation illimitée 6 . 3 CONSTRUCTION D'UNE IMAGE Possibilité de construire son image à la main (long et source d'erreurs) Suivi de version et construction d'images de manière automatisée Utilisation de Dockerfile afin de garantir l'idempotence des images 6 . 4 DOCKERFILE Suite d'instruction qui définit une image Permet de vérifier le contenu d'une image FROM alpine:3.4 MAINTAINER Osones <docker@osones.io> uploads/s1/ docker.pdf