L'agence
WanadevStudio
Tuto Docker - Comprendre Docker (Partie1)
Docker, c'est la solution qui grimpe en ce moment. Vous en avez certainement entendu parler ces derniers temps. Cet article a pour but de comprendre les bases de Docker. il est le premier d'une série de 4 articles intégralement dédiés à Docker.
Cet article fait partie d'une série de billets portants sur Docker et son environnement :
- Tuto Docker : comprendre Docker (partie1)
- Tuto Docker : démarrer Docker (partie 2)
- Tuto Docker : les commandes Docker (partie 3)
Pourquoi un article sur Docker ?
Lorsque je me suis lancé dans l'écriture de cet article, j'avais l'intention de décrire le fonctionnement de Docker ainsi que les fondamentaux. À force d'écrire, il m'a bien fallu faire le constat que Docker est peut-être simple à décrire à la pause café, mais que donner sa description de manière plus fonctionnelle est quelque chose d'un peu plus compliqué que ça.
Aujourd'hui, je vais tenter d'être simple et concret. Mon objectif : vous faire comprendre le fonctionnement de Docker en 10 minutes.
Présentation de Docker
Docker est un produit développé par la société du même nom. Initialement développé par un ingénieur français, Solomon Hykes, le produit a été dévoilé en mars 2013. Depuis cette date, Docker est devenu LE soft à la mode ! Nous allons voir à quoi il sert et comment vous pouvez vous en servir au quotidien.
Qu'est-ce que Docker ?
Eh bien non, pas encore. Ou du moins pas nativement (ni de façon très fiable), pour l'instant au moins. Sois patient, j'en parle dans les paragraphes suivants.
Docker, isoler un environnement ? Comme une VM ?
Oui… et non ! Docker et les containers Linux ne se comportent pas de la même manière qu'une VM. Une machine virtuelle isole tout un système (son OS), et dispose de ses propres ressources.
Dans le cas de Docker, le kernel va partager les ressources du système hôte et interagir avec le(s) container(s). Techniquement, Docker n'est pas une VM, pas le moins du monde, mais en terme d'utilisation, Docker peut-être apparenté à une VM.
Lancer un environnement, et isoler les composants de ce container avec les composants de mon hôte, voilà ce que Docker sait faire ! Il le fait d'ailleurs très bien, et reste une alternative bien plus performante que les VMs (à utilisation équivalente).
Schema réalisé par Docker themselves
@ Ok je comprends mieux. Dans une machine virtuelle, tu alloues "physiquement" de la RAM et du stockage, comme 2go de RAM et 20Go. Alors que sur Docker, tout est partagé avec le Linux hôte qui utilise Docker. C'est pour ça que tout est plus rapide, je me trompe ?
C'est exactement ça ! Si tu as déjà une petite expérience avec les machines virtuelles (Virtual Box ou même avec Vagrant), tu verras que Docker est beaucoup, beaucoup plus rapide ! D'ailleurs, si Docker ressemble à une VM de loin, voici un point que devrait te convaincre qu'il n'en est pas une. Docker est installable sur un Linux uniquement et sait instancier du Linux uniquement. Convaincu ?
Docker, uniquement sur Linux ? I'm sure !
Tout à l'heure, nous avons abordé la compatibilité entre Windows et Docker. Je vois déjà la tête de certains qui ne sont déjà pas convaincus. Peut-être que vous l'avez déjà essayé ou utilisé via Windows ou MacOS. Pourtant, Docker ne peut travailler qu'avec la présence du Kernel Linux !
Pour malgré tout ne pas exclure les développeurs travaillant sur une autre plateforme qu'une Linux, des VMs (oui cette fois on parle bien de véritables machines virtuelles) ont été mises en place. La plus connue est boot2docker. Elle repose sur une VM VirtualBox. Cette machine virtuelle contient un Linux qui va alors pouvoir exécuter un Docker. Bien évidemment, une instance suffit pour exécuter autant de Docker que vous souhaitez. Depuis le dépôt GitHub de boot2docker, il est indiqué celle-ci pèse environ 24 Mo et démarre en 5 secondes à peu près.
De cette manière, tous les développeurs, quelle que soit leur plateforme, sont en mesure de travailler sur une même application, avec un environnement similaire.
Oui, cependant boot2docker et les autres VMs disponibles ne sont pas destinées à fonctionner en production, mais seulement pour des développeurs souhaitant se placer dans les exactes conditions que les serveurs de production.
Dans le cadre d'une production, l'utilisation d'un environnement Linux (et donc pas d'un Docker) est FORTEMENT conseillée.
Attention, Docker nécessite une version 3.8 du Kernel (compatible donc pour une Debian 8 ou un Ubuntu) au minimum. Pour les serveurs qui sont actuellement sur Debian 7 (donc avec un noyau en version 3.2), l'équipe en charge du développement Docker a mis en place un fallback qui permet d'installer un noyau plus récent sans devoir passer sur Debian 8 (aussi appelée Jessie).
Docker, bientôt disponible nativement sur Windows
Aujourd'hui, Docker n'est disponible que pour Linux mais un partenariat récent entre Docker Inc. et Microsoft prévoit le développement de container Windows. Ceux-ci ne seront pas compatibles avec Linux mais répondront au même besoin.
Docker, cas d'utilisation
Prenons un cas d'utilisation simple et concret.
Une entreprise lyonnaise que j’appellerai à tout hasard Wanadev, souhaite développer un projet Symfony comme ils savent le faire. Leur équipe est composée de deux personnes.
- Manu est un vieux de la vieille. Lui, Debian 7, c'est parfait. De plus, il est ISO avec les serveurs de production.
- Baptiste lui est un vrai hippie. Il dispose de la dernière distribution exotique. Lui, PHP, c'est la toute dernière version ou rien. Cependant, il peut générer du code qui ne peut pas s’exécuter correctement avec une version plus vieille, comme celle de Manu.
Jusqu'à aujourd'hui, on disait tous, « faisons des tests unitaires ». Oui, cela répondait à une bonne partie de nos problèmes (à la condition de faire de bons tests unitaires complets).
Exactement ! Dans ce cas, le plus simple est de mettre en place un Dockerfile, document "chef d'orchestre", qui permettra à Manu et à Baptiste de monter une image similaire. En étant malin, ce Dockerfile sera calqué sur les éléments présents en production. De ce fait, Manu et Baptiste en plus de travailler sur un environnement identique, seront sur un environnement similaire à celui de la production !
Docker, déployer vos applications facilement
Dans mon exemple précédent, j'ai mis en avant l'utilisation de Docker pour déclarer un unique environnement de développement. Je pense que tous les utilisateurs de Docker doivent commencer par ça avant de voir plus grand.
Plus haut, je vous parlais d'une version particulière de PHP. Il est évident que vous ne risquez pas d'oublier d'installer PHP sur votre serveur de production, mais peut-être que la configuration de votre PHP-FPM sera légèrement différente. Peut-être avez-vous besoin d'une librairie supplémentaire comme Imagick et de son extension PHP. Peut-être avez-vous besoin d'un Postfix pour envoyer des mails. Autant de détails que vous pourriez oublier lorsque vous monterez votre serveur de production.
Pour limiter ces erreurs, ne serait-il pas plus simple de déployer le ou les container(s) permettant de faire tourner votre application ? De cette manière, plutôt que de pull un code source et d'effectuer quelques scripts de déploiement, vous pourriez déployer un ensemble cohérent packagé correspondant à une application.
On parle souvent d'application dans le monde du web, une "application" Symfony, ne serait pas grand-chose sans un frontal comme Nginx ou Apache2, un engine comme FPM ou HHVM, et une base de donnée.
C'est tout à fait ça ! De cette manière, vous pouvez construire des environnements autonomes et isolés les uns les autres. Le bon vieux projet SPIP en 5.3 pourrait côtoyer sur le même serveur le dernier projet Symfony avec PHP 5.5. Cool non ?
Conclusion
Grâce à Docker, multipliez les environnements sur votre machine, sans limiter les performances de votre ordinateur. Les ressources sont partagées avec la machine hôte ! Chaque environnement peut être configuré simplement grâce à son Dockerfile, présent à sa racine.
Cet article avait pour but de vous présenter Docker dans ses grandes lignes et de vous permettre de mieux cerner les solutions qui peuvent être apportées aux différentes problématiques des développeurs. La suite de cet article sera publiée dans quelques jours. Il permettra de vous donner un premier exemple de création d'un environnement Docker grâce à son Dockerfile.
Une question ? La zone de commentaire ci-dessous est faite pour ça ! N'hésitez pas à nous suivre sur Twitter et sur Facebook pour être averti de la suite de ce billet, premier d'une série de 4.
Commentaires
Stephane
Il y a 10 ans
Ou alors Docker est « juste » un vagrant plus souple ?
Merci d’avance, à bientôt sur votre blog j’espère.
Stéphane
Baptiste DONAUX
Il y a 10 ans
N’hésite pas à laisser un commentaire sur cet article ou sur les deux autres si tu souhaites avoir plus d’informations.
Baptiste
Stéphane
Il y a 10 ans
@+ Stéphane
Baptiste DONAUX
Il y a 10 ans
Vagrant repose sur une VM alors que Docker non. Par conséquent, créer des containers pour chacun de tes sites ne provoquera pas de sur-coût. Personnellement, sur mon serveur privé, j’héberge également une dizaine de sites et de services que j’héberge systématiquement dans des containers dédiés.
Premièrement, cela va te permettre d’optimiser la charge de ton serveur (consommation CPU, RAM) selon la priorité de tes services. Ensuite tu vas pouvoir utiliser des versions spécifiques. Par exemple, tu pourras utiliser des versions postérieures aux versions gérées par ton gestionnaire de paquets. Personnellement, lorsque j’étais sur Debian Wheezy, j’utilisais des containers avec PHP-FPM 5.6 alors que la version en cours était la 5.4.
L’intérêt réside aussi dans les performances (dans une certaine mesure). Pour un container, tu pourras charger uniquement les extensions PHP qui t’intéressent. Exemple : si tu disposes d’un site avec PostgreSQL et un autre avec MariaDB, tu pourras charger uniquement mysqlnd dans un container et pdo_pgsql dans l’autre. En terme d’exécution, cela peut-être un gain non négligeable si tu es soumis à un fort trafic.
Pour finir, l’utilisation de containers pour des sites implique de protéger tes containers. Cela est réalisable facilement. Pour les containers qui binderaient un port de la machine hôte sur un port de ton container, tu peux filtrer les IPs pouvant s’y connecter. Par habitude, on autorise uniquement 127.0.0.1 à se connecter (-p 127.0.0.1:80:80) et on utilise un proxy devant (Nginx par exemple) pour que l’intégralité des connections passent par ce proxy.
Pour vulgariser la chose : Il y a un intérêt à utiliser un container pour chaque site. Et Docker est plus souple mais aussi plus performant que Vagrant. Nous délaissons désormais Vagrant, beaucoup plus gourmand que Docker.
J’espère t’avoir aidé, à bientôt j’espère !
Stéphane
Il y a 10 ans
Super, merci pour l’explication. Les avantages semblent vraiment intéressants ; je n’avais pas du tout soupçonné la possibilité d’installer différentes versions d’un même paquet par exemple ! C’est génial. Pareil pour la priorité des conteneurs, vraiment pas mal.
Du coup je vais continuer à lire tes différents billets pour en savoir plus. Pas sûr que je switch de suite pour la prod, mais en tous cas c’est l’occasion de prendre un petit VPS pour tester tout ça.
Bonne journée et à bientôt ici ou ailleurs. @+ Stéphane
Arthur
Il y a 9 ans
Excellent article, merci :) Le meilleur que j’ai trouve, seulement, quelques points restent un peu flous pour moi.
J’essai actuellement de me renseigner sur le docker pour voir s’il pourrait etre utilise dans mon cas ou non.
Pour decrire un peu le principe, je developpe des VMs qui vont venir presenter les differentes solutions de notre entreprise. Les VMs tournent toutes sous Windows (xp et 7 actuellement).
Si j’ai bien compris, il est prevu que docker soit disponible dans la version Win Server 2016 ?
A partir de ce moment, je pourrais alors creer ma base de Dockers pour remplacer nos VMs et ainsi permettre a nos utilisateurs d’avoir acces plus facilement aux VMs (qui peuvent actuellement atteindre 20Go et etre utilisees dans n’importe quel pays du monde) et en plus celles-ci serait plus performantes qu’actuellement (Je ne me trompe pas ?).
Derniere question pour le moment, si Docker doit tourner sur Win Server 2016, je ne pourrais donc pas creer un Docker sous Win 7 avec mon applicatif ? Donc si un de mes logiciels n’est pas compatible Win Serv 2016, je ne pourrais pas creer de container pour celui-ci ?
Merci d’avance,
PS : Desole, pas d’accents, clavier QWERTY ^^’
Arthur
Baptiste DONAUX
Il y a 9 ans
Pour commencer, merci pour tes encouragements !
Pour répondre à ta question, je vais tenter d’éclaircir quelques points car il me semble que tu mélanges quelques points.
Docker n’est un système de VMs. Il s’agit d’un système permettant de gérer un empilement de layers (couches – physiquement, ce sont des dossiers sur le filesystem) ayant pour finaliser une image complète contenant des exécutables.
Docker existe aujourd’hui uniquement pour Linux (d’où la solution boot2docker – désormais intégré dans le package Docker Toolbox). Windows et Docker ont signé un partenariat dans le but d’aboutir à une solution native de container. Cela implique qu’il ne s’agira plus de container Linux mais de véritable container Windows.
Lorsque cette solution sera disponible, tu pourra en effet utiliser le système d’images, mais cela ne remplacera pas le comportement propre à Windows XP ou 7. De la même manière, qu’une image Docker (Linux) s’exécute de la même manière sur une Debian que sur un Open Suse.
Espérant avoir éclaircit toutes tes interrogations, je t’invite à revenir ici si tu as besoins de plus de détails.
Dockerement, Baptiste
Eric G.
Il y a 9 ans
Une question, comme les containers se partagent l’OS est ce qu’il est possible d’assigner des ressources spécifique à un container (RAM/CPU, HDD) voire même des NIC ( pour faire de la segmentation) ?
Merci d’avance
Cdt,
Eric
Baptiste DONAUX
Il y a 9 ans
En effet, tu peux allouer des ressources selon tes containers via les options –cpu-shares, –cpu-quota, –kernel-memory, –memory-swap (il existe bien évidemment d’autres options, te laisse les voir via la commande docker help run). Tu peux utiliser ces options mais il faudra que tu actives (pas toujours activer par défaut) une option dans ton kernel pour que la management des ressources soit fonctionnelle.
N’hésites pas à revenir vers nous quand tu as aura réussi à configurer au poil tes containers :)
Baptiste
hoggar
Il y a 9 ans
Je suis intéressé par cette solution et je souhaiterai avoir votre retour d’expérience, avez des cas concrets, des exemples sur le process de déploiement applicatifs, merci de votre retour.
Baptiste DONAUX
Il y a 9 ans
Bonjour et merci pour ton retour !
Concernant notre retour d’expérience. Actuellement nous utilisons Docker pour nos développements en local. Cela nous a permis d’améliorer notre code (architecture, garantie d’un code fonctionnel avec la même version de PHP). Nous étudions actuellement la possibilité de déployer nos projets sur une plateforme de dev (c’est-à-dire pour déployer nos projets pre-production). Pour la mise en production via Docker, nous n’en parlons pas encore.
Tout de même, ne priant que par Docker (<3), je l'ai intégralement mis en place sur mon serveur privé. Que ce soit au niveau du front (proxy) que des applications. Aujourd'hui je possède uniquement Docker ce qui me facilite grandement la maintenance de mon serveur (upgrade, dist-upgrade entre autres). Les backups de mes applications sont devenus plus simples avec le partage des volumes. La mise à jour des applications telle GitLab également.
Quant aux déploiements nous ne pouvons effectuer de retour. Nous suivons de très prêt Ansible qui permet de facilement déployer des applications mais cela ne correspond pas totalement à nos attentes. Dans notre cas, Docker est juste un runner et non un package de notre application. Si tu cherches à déployer proprement tes services Docker, nous te le conseillons.
Espérant avoir répondu à tes questions, je t’invite à revenir vers nous pour des compléments d’informations, ou à partager cet article (ou ping nous sur twitter
brazomyna
Il y a 9 ans
article très intéressant, merci.
J’ai un serveur dédié que je compte migrer vers une nouvelle machine physique d’ici quelques temps ; le serveur fait tourner différents ‘services’ visibles publiquement: plusieurs sites web distincts + divers démons sous node, java + quelques services persos (genre backup chiffré de données personnelles), etc…
J’aimerais pouvoir un minimum ‘compartimenter’ ces différents services dans l’espoir d’avoir une meilleure sécurité globale du serveur ; surtout pour éviter qu’une faille dans un des services n’impacte l’ensemble. Et cette migration physique pourrait être l’occasion de mettre en place une solution différente du fourre-tout actuel (docker ? vm ? autre ?).
Dans cette optique, utiliser docker est elle une solution (ie. « parfaite » / « mieux que rien mais pas parfaite » / « pas mieux que pas de docker ») ? Quels sont les avantages / inconvénients ?
Merci d’avance pour la réponse et encore merci pour l’article.
Baptiste DONAUX
Il y a 9 ans
Bonjour et merci pour ta question très intéressante !
Docker nécessite un Kernel 3.10 minimum. Cela implique qu’avec une machine physique sur une Debian 8 tu peux tout-à-fait imaginer utiliser Docker pour isoler tes services (Debian 7 avec un backport aussi).
Dans un premier temps il faut reconnaître les avantages des VMs face à Docker.
– Une VM c’est un environnement parfaitement isolé, jusque dans l’OS utilisé. Pas d’obligation d’utiliser Linux ! Ça peut être un élément déterminant.
– Une VM est en terme de sécurité bien plus fermé. Une fois dans la VM impossible de remonter sur l’hôte.
Versus Docker, voici les éléments qui pourraient te motiver à sauter le pas :
– Pas de surcharge serveur avec un OS complet à faire tourner. Seul le processus métier coûte en mémoire.
– Le système de template (templating d’image) et d’automatisation.
– Faciliter des mises à jour, des installations, des backups, des montages de dossiers, partage de ports, scaling des services (via docker-compose pour utilisation semi-automatisée).
– Coût en espace restreint avec le découpage en layers (layers partagés entre plusieurs images).
– Un lot d’images officielles maintenues par la communauté Docker.
Sur le point de vue sécurité, Docker ne pourra jamais faire MIEUX qu’une VM (il va cependant tendre vers le niveau de fiabilité). Il existe aujourd’hui une ou deux astuces (ce ne sont pas des fails, elles sont même détaillées par Docker !) permettant de remonter d’un container à la machine hôte. Cependant, j’ai déjà entendu lors d’un meetup, une méthode permettant de jouer avec les utilisateurs ayant pour objectif de contrer définitivement ce problème. N’étant pas un expert sécurité, je te conseille de te tourner vers des personnes plus « calées » dans ce domaine (peut-être Julien Simon ?).
Pour ma part je pense que Docker peut-être une bonne solution te concernant. Docker est très actif et les problèmes d’aujourd’hui seront rapidement résolus. Les outils et l’environnement permettent de facilement packager et déployer.
Si tu souhaites détailler un nouveau point, n’hésite pas à revenir vers nous. Si cet article t’a semblé pertinent, n’hésite pas à le partager et à nous suivre sur Twitter
François DELEGLISE
Il y a 9 ans
Ali
Il y a 9 ans
Bonjour Baptiste,
Super, merci pour cet article, je débute sur Vagrant et Docker et j'ai une question importante pour choisir entre les deux
Lorsque j'utilise Docker est possible de travailler avec des versions différentes de logiciel et faire des upgrades de la version Host sans impacté les versions de containers
exp. Version postgresql 9.0 sur host et 9.5 dans le docker
Merci
Baptiste DONAUX
Il y a 9 ans
Bonjour Ali et merci pour ton retour !
En effet il est très simple de lancer des versions différentes d'un même « software » dans la mesure où les binaires contenus dans les images Docker ne sont pas installés sur la machine hôte.
Docker vs Vagrant, Docker n'est pas une VM, il n'y a donc pas le surcoût de la VM (pas d'OS pour la gestion des containers) mais l'utilisation d'une VM est facile à justifier si vous souhaitez isoler au maximum vos applications.
Dans le cas d'un système hôte différent de Linux, il faut savoir qu'il sera nécessaire de lancer une VM avec une micro Linux dedans pour exécuter du Docker. Le surcoût est léger car il s'agit d'une petite VM.
Pour moi, la force de Docker est la facilité à utiliser des « logiciels » rapidement dans des versions différentes.
N'hésites à revenir vers nous si tu as besoin de plus d'informations, sur le blog ou sur Twitter (@Agence_Wanadev) !
Dockerement, Baptiste
Mehmet Pasha
Il y a 9 ans
Merci beaucoup pour cet article enrichissant. Cela m'a permis de comprendre les bases de cette technologie. Ma seule question est la suivante : as-tu des tutoriels sous la main que tu me conseillerais pour continuer à apprendre sur cette nouvelle technologie? Je souhaite me familiariser davantage. Merci par avance et bonne continuation!
Baptiste DONAUX
Il y a 9 ans
Bonjour et merci pour ton retour, cela nous encourage à proposer des articles pouvant servir à toute la communauté.
Concernant ta question, j'ai écris cet article (Docker partie 1) ainsi qu'une partie 2 et une partie 3. La partie 2 (Démarrer avec Docker) est très intéressante car elle montre comment se servir des premières commandes. La partie 3 (Les commandes et Docker) montre comment administrer des engines à distance. c'est une simple introduction au cluster comme Swarm...
Si tu souhaites Dockerizer des applications complètes avec Docker, j'ai également écrit deux articles sur comment utiliser Docker et docker-compose avec un projet Symfony. Cela s'applique d'ailleurs avec de nombreux projets, PHP ou non.
Avec ces articles tu dois avoir une base sur Docker.
N'hésites pas à revenir vers nous, à nous follow sur Twitter (@Agence_Wanadev) ou à partager cet article. ;-)
Thibault
Il y a 8 ans
Bonjour Baptiste,
Je suis actuellement en stage et j'ai pour mission d'étudier Docker, pour l'instant j'arrive à comprendre le fonctionnement et les avantages que Docker octroi, mais n'ayant jamais concrètement travail en collaboration avec des équipes externes au système et réseau (avec des développeurs par exemple), je ne vois pas tous les utilisations possibles, ou du moins les plus intéressantes de Docker, pour une entreprise.
L'exemple de Manu et Baptiste qui travaillent sur diffèrent environnement ne m'a pas vraiment aidé... ^^'
En tout cas merci pour tous ces articles ils sont très bien expliqués et ils m'ont énormément aidé, bon courage !
Thibault
Thibault
Il y a 8 ans
Bonjour Baptiste,
Pas de problème, merci pour cette réponse, je comprends mieux maintenant l'intérêt et je commence à maîtriser ne serait-ce qu'un peu Docker mais l'outil Swarm est compliqué à prendre en main et à comprendre dans son intégralité.
Je retourne me creuser la tête sur cet outil,
Bonne journée, Thibault
Baptiste DONAUX
Il y a 8 ans
Bonjour Thibault,
Dans un premier temps, merci pour tes encouragements et pardon pour le retard à t'envoyer une réponse.
Docker permet de générer et d'exécuter des environnements non-pas en fonction de la machine et des paquets installés mais plutôt d'une image (voir les Dockerfile).
De notre côté, nous nous en servons pour travailler sur les mêmes versions (exemple, la même version de PHP) et de pouvoir utiliser des versions différentes de celle actuellement installée. En conséquence, cela nous permet d'exécuter plusieurs projets en parallèle avec des versions (et même des extensions pour PHP par exemple) différentes.
Bon courage dans tes recherches !
Dockerement, Baptiste
ray
Il y a 8 ans
Bonjour Baptiste,
Merci pour cet article d'introduction, j'ai hâte de lire les autres.
Petite question : lorsque tu parles de containers LXC, on les retrouve aussi sous Proxmox V4.
Du coup, penses-tu que les 2 solutions sont identiques ou du moins sur certains aspects?
J'évoque cette solution de virtu car je suis en pleine étude sur le passage de ma V.3 Proxmox en V.4 avec à la place d'OpenVZ, LXC.
Quoi il en soit, la mise en place d'un pilote sous Docker me tente ne serait-ce que par curiosité.
Ray
Baptiste DONAUX
Il y a 8 ans
Bonjour !
Je vais tenter de répondre à ta question mais étant développeur avec un petit plus Ops, je pense que ma réponse restera probablement partielle comparée à celle que pourrait te fournir un SysAdmin.
Docker ne propose qu'une solution autour des containers tandis que Proxmox est une solution de gestion de VMs et de containers. De plus, il s'agit principalement d'une gestionnaire tandis que Docker se positionne comme une solution embarqué (système de construction d'image, store d'images) ainsi que comme un outils de scaling (SwarmKit). De plus, de nombreuses fonctionnalités intégrées dans Docker ne sont pas présentes dans LXC (volumes, réseaux).
Pour finir, même si un expert de LXC pourrait réaliser toutes les actions mise en place dans Docker, Docker n'en reste pas moins compliqué à utiliser (cli, server, API, orchestration…).
J'espère avoir pu t'apporter une réponse et ne pas avoir commis d'erreur :-)
Cordialement, Baptiste
Stéphane
Il y a 8 ans
Hello Baptiste,
Malgré que l'article est été rédigé il y a 1 an, il m'aide beaucoup sur la compréhension de l'outil :)
J'ai cependant une petite question : est-il jouable de créer un container Docker pour chaque projet ? Par exemple, un projet NodeJS dans /data/www/www.node.lan/ aura son container et donc sa config. Un autre dans le même www/ mais sous Wordpress, avec son container également, et ainsi de suite.
Tout ça à la place d'une config LAMP par exemple, car étant noob en admin sys', je gagnerai énormément de temps :)
Merci à toi :)
Baptiste DONAUX
Il y a 8 ans
Bonjour Stéphane et désolé pour le temps de réponse !
En effet, je te conseille de créer un container par projet ou plusieurs par projet. L'idée première du container est d'isoler les environnements. Il est dont préférable de distinguer chaque projet dans des environnements Docker différents. Chez nous, nous utilisons docker-compose (of course !) pour lancer nos projets. Cela nous permet de lancer tous les services d'un projet (NGinx, PHP-FPM, PostgreSQL, NodeJS…) et ce pour chaque projet que nous avons.
Nous avons choisi de stocker dans un dossier docker dans chaque projet, la configuration relative à un projet. Tu peux retrouver plus d'informations sur un autre article que j'ai écris (et aussi cet article).
Espérant avoir répondu à tes questions, n'hésites pas à revenir vers nous et à nous follow sur Twitter
Quentin
Il y a 8 ans
Hello,
Je m'intéresse à Docker depuis peu, et un grand merci pour cet article qui aide à mieux comprendre Docker.
Je n'ai pas encore tout les clés en main et je n'ai pas encore tout compris sur Docker, mais je vais continuer de me renseigner sur cette techno !
Merci pour le partage d'informations ! :)
Baptiste DONAUX
Il y a 8 ans
Bonjour et merci pour tes encouragements ! N'hésites pas à revenir vers nous si tu as besoin d'aide.
Dockerement, Baptiste
Afwa
Il y a 8 ans
Merci pour cet article, très bien expliqué!
Je suis intéressé par cette solution et je souhaiterai savoir comment peut on sécurisé un espace d'hébergement dédié via?
merci
Baptiste DONAUX
Il y a 8 ans
Bonjour et merci !
Il existe plusieurs éléments mais voici les plus simples.
- Ne pas ouvrir le port 2375/3375 qui permettrait à n'importe qui d'accéder à ton instance.
- Ne pas donner les droits à n'importe quel utilisateur (cela permettrait à n'importe quel utilisateur de créer des containers en montant tout le disque et de potentiellement supprimer les données).
- Prendre soin de bien choisir les applications que tu installes. En effet, les containers ne peuvent être totalement isolés et il est techniquement possible d'attaquer un autre container.
Il existe de plusieurs moyens d'attaquer une machine avec des containers (tout comme sur une machine classique) mais il est techniquement plus compliqué d'exploiter ces problèmes.
En gros, faire attention à ce que tu fais/installes et prendre de simple précautions permettre de s'assurer dans un premier temps de ne pas subir de revers.
Cordialement, Baptiste
Afwa
Il y a 8 ans
Merci pour votre explication.
J'aimerai savoir en fait s'il est possible d'installer Docker sur Backtrack pour essayer de faire des tests visant la sécurité et si c'est possible pourriez-vous me renseigner sur un guide d'installation.
merci :)
Amira
Il y a 8 ans
merci pour cet article très enrichissant . pour mon PFE j'ai opté pour Docker (mise en place d'un plate forme IMS dans un environnement de virtualisation Docker et dans un reseau IPv6) je vais donc utiliser la solution openIMSCORE alors comment pourrai-je procéder ? télécharcher l'image de openIMSCORE ou bien une image ubuntu et refaire toute la configuration ? vos conseils seront les bienvenus :)
Baptiste DONAUX
Il y a 8 ans
Bonjour Amira,
Content que cet article est pu t'aider ! Je n'ai pas de connaissance concernant les IMS. Il existe une image openIMScore sur Store Docker mais celle-ci ne semble pas encore totalement poussée.
Je te conseille de construire ta propre image en partant d'une image de base officielle (type Debian, Ubuntu, CentOS). Une fois l'image compilée tu peux la publier sur le Store Docker avec une belle documentation pour en faire profiter la communauté. Ensuite tu n'auras plus qu'a déployer un container à partir de cette image.
L'utilisation des variables d'environnements est fortement conseillé pour générer la configuration du binaire. Tu peux t'aider de la documentation de Docker sur comment créer une image officielle.
Dockerement, Baptiste
sam
Il y a 7 ans
Bonjour,
Merci pour l'article. J'ai une question : je dois faire une application que je dois déployer sur plusieurs serveurs mais avec des configurations différentes (base de donnée...) est ce que l'utilisation des containers le permet? est ce que c'est possible de faire de l'intégration contenu et un déploiement contenu sur docker ?
Merci d’avance,
sam
Baptiste DONAUX
Il y a 7 ans
Bonjour Sam !
Biensûr ! Les méthodes sont différentes mais on peut répondre aux mêmes problématiques. Concernant les configurations, tu peux passer des variables d'environnements à tes containers pour configurer tes services.
Pour tout ce qui est CI, aucun problème à condition de persister tes données dans des volumes de manière à ne pas perdre tes bases de données et autres.
Pour le CD, c'est un peu plus sensible car il faut déployer des nouveaux containers (avec la nouvelle version de ton code), tout en gardant les containers de ton ancienne version et ainsi switcher lorsque les containers sont prêts. Il s'agit d'une opération beaucoup plus délicate qu'avec un déploiement classique. L'utilisation de plusieurs containers pour un même service (scale) et l'utilisation d'un orchestrator type (Kubernetes, Rancher ou Swarm) sera obligatoire.
En espérant avoir pu répondre à toutes tes questions sans t'avoir perdu :-)
Baptiste