La fondation Raspberry Pi vient d'annoncer que l'installation de Docker était désormais grandement simplifiée sur Raspbian Jessie. Cette opération se fait en effet via une seule ligne de commande.
Docker est un outil relativement prisé permettant de créer des conteneurs logiciels. Il est disponible sur de nombreuses plateformes, y compris sur certains NAS. On peut également l'installer sur un Raspberry Pi, mais il fallait alors passer par des systèmes alternatifs comme HypriotOS, ou bien mettre les mains dans le cambouis. Désormais, l'installation est prise en charge nativement par Raspbian Jessie.
Pour rappel, Raspbian est un système d'exploitation basé sur Debian (8.0 pour Raspbian Jessie) et spécialement conçu pour le micro-ordinateur de poche. Comme l'explique la fondation sur son blog, « vous pouvez maintenant installer le client Docker sur votre Raspberry Pi via une seule commande » :
curl -sSL get.docker.com | sh
Ensuite, vous pouvez créer vos propres conteneurs, ou bien en télécharger des déjà existants. Une des possibilités mises en avant par la fondation est d'utiliser le mode Swarm introduit avec la version 1.12 de Docker.
Pour rappel, cette fonctionnalité permet à Docker de créer des applications utilisant des conteneurs multiples répartis sur plusieurs systèmes hôtes, tout en pouvant les gérer sans logiciel supplémentaire. Vous pouvez ainsi construire facilement un « cluster » de Raspberry Pi, ce qui peut être utile pour certaines applications gourmandes.
Alex Ellis, développeur chez ADP et « Docker Captain », donne quelques exemples d'utilisations et de mise en place sur son blog. Il a également publié une vidéo sur l'utilisation du mode Swarm de Docker avec plusieurs Raspberry Pi :
Commentaires (74)
#1
Appeler sh/bash après un curl, ça reste quand même hyper laid/pas secure comme mode d’install
" />
#2
le micro-ordinateur de proche.
" />
C’est une machine spécialisée dans les rencontres ?
#3
Rien ne t’empêche de télécharger, lire le script et l’exécuter dans la foulée. Mais pour un environnement de test rapide ou pour 99,9999% des situations, le serveur n’est pas vérolé et ça suffit amplement.
#4
Exactement ce à quoi je pensais….
rm -rf /
#5
C’est pas vraiment le seul installeur dans ce cas !
" />
Confère l’installation de OhMyZsh pour remplacer sh/bash
#6
C’est pour les Raspberry Pi 3, vu que Docker ne passe qu’en 64 bits côté host, non?
#7
Pour ceux qui ont la flemme d’importer une clé, ajouter un dépôt, faire un apt-get install ?? La base quand t’es admin quoi. Docker c’est bien mais on le vend comme un truc accessible aux débiles et c’est pas forcément un bon point.
#8
Docker c’est la connerie pour déployer des applications avec ses dépendances au lieu d’utiliser les binaires systèmes à jours pour les dites dépendances histoire de se taper définitivement une vieille version de OpenSLL ou tout autre librairie critique, j’ai bon ?
#9
C’est pas parce que tu es admin que tu ne veux pas une solution clés en main.
#10
#11
#12
Docker, c’est le truc pour simplifier l’installation, mais pour les updates bah… quelles updates ? C’est destinés aux applis qui ont une espérance de vie de moins de 3 mois 
" />
#13
On parle de RPi là, des environnements de dev dédiés aux tests rapides. On s’en fout de savoir si c’est pérenne ou si ça respecte la mentalité de la distro ou quoi que ce soit.
Tout ce qui compte, c’est que ça soit rapide et que ça marche, ce qui est le cas.
#14
#15
Il existe des démonstrations via un sleep dans le .sh, où le serveur en face en fonction du comportement (bash va faire un sleep, curl non), te retourne tel ou tel fichier.
Curl : dl direct -> fichier “normal”.
Bash : dl en partie puis sleep -> malware
Très très fourbe….
#16
#17
un rm -Rf / ne fonctionne plus sur Debian :)
#18
Ah bon ? Bouge pas j’essaye…
" /> 
" />
#19
#20
Désolé, je bosse avec du sun et du unix et j’évite de taper cette commande. :-)
#21
Le problème c’est que, trop souvent, le test du dev se retrouve en prod car ‘ça marche en dev’….
#22
Et pourtant :
–no-preserve-root
do not treat ‘/’ specially
–preserve-root
do not remove ‘/’ (default)
#23
Je vais essayer de faire une réponse constructive.
J’aime bien Docker, j’ai écrit des Dockerfiles, j’ai des fichiers compose, je vois le potentiel lorsque c’est bien utilisé.
En revanche je regrette qu’on vende cette technologie comme une révolution qui nous permettra bientôt de ne plus “ s’encombrer ” avec les habitudes existantes. Un sysadmin c’est pas un branlot qui ne fait que des apt-get install toute la journée. Il faut connaitre les outils et les logiciels, prévoir, réparer, car c’est toi qu’on appelle à 3h du matin lorsque la prod est en rade, pas celui qui écrit le Dockerfile.
Quand on rend certaines choses trop accessibles on se retrouve avec des bêtises, par exemple des SGBD sans mot de passe accessibles sur internet (“oh ? j’ai juste fait un docker run, ça marchait, je me suis pas posé de question”).
Voilà pourquoi j’aime pas cet aspect “débilisant” du marketing de Docker. Oui c’est un outil génial, on peut en faire n’importe quoi, mais il ne faut pas faire n’importe quoi.
#24
L’éternel débat prod versus dev… :-)
#25
Bah c’est dommage d’avoir un système de base qui gère les dépendances, le versioning, les updates, et tout, et pour Docker, qui est censé “simplifier” la vie des admins justement, de réinventer la roue, mais en moins bien. C’était si difficile de faire un paquet raspbian ?
#26
Oui ils on changé le comportement par défaut et c’est je pense une bonne chose ! J’avais fait le test sur une VM a un moment, et même si ca ne marche plus, c’est le genre de commande que j’évite d’entrer dans mon terminal ! (Par prudence !)
#27
#28
Peu être mais en attendant c’est toujours les admin qui essuient les plâtres des dev… et cela h24…
#29
#30
#31
C’est trivial mais c’est à toi de le faire.
D’un côté, tu fais un apt-get upgrade régulièrement, qui fait l’upgrade ou te dit que c’est bon ; d’un autre côté, tu sais quels sont les trucs qu’il y a dans ton image, tu sais ce qui doit être mis à jour, et tu fais une nouvelle image trivialement.
L’un des deux systèmes me semble quand même plus fiable pour s’assurer que les mise à jour de sécurité soient faites rapidement.
#32
Suis sysadmin, faut pas tenter de me convaincre…
#33
#34
C’est aussi:
Le coup du “oh ? j’ai juste fait un docker run, ça marchait, je me suis pas posé de question” se produit quand le ‘sysadmin’ fait pas son boulot correctement. Et même avec des choses peu accessibles, on a les mêmes problèmes car les gens récupèrent juste un script déjà tout fait sur des forums pour configurer leur trucs automatiquement.
#35
Mec c’est une install sur un raspberry, tout le monde n’est pas un arrogant sysadmin.
#36
Non c’était pour remuer le couteau… dans la plaie bien sur !
" />
#37
Dev ops, c’est pas vraiment fait pour réconcilier les deux. On fait un shift left des problèmes…
Partout, c’est DEV ops ou dev OPS. On atteint un point où il serait bon que les sysadmin sachent faire du dev et les dev du sysadmin…. Trop de spécialisation tue le bon sens au nom de la ségrégation des tâches (pcq la sécurité de l’information qui s’en mêle, c’est rigolo aussi…)
#38
#39
Si ca avait pas été changé, sans le mode verbose tu te serais dit “tiens c’est long a s’exécuter…”
" />
toujours vérifier ses rm et dd 18 fois avant de valider !!
#40
#41
A - “Vous avez fait des tests de charge ?”
B - “Des quoi ?”
A - “Bah des tests de charge, voir comment on supporte de transaction à la seconde et si sur la durée on a pas des fuites de ressources”
B - “Ah, on vend ce type de prestation aussi ? On peut facturer ça combien tu crois ?”
A - “Ca dépend, tu payerais combien pour qu’un mec essaye la 2cv que tu viens d’acheter au prix d’une ferrari ?”
Conversation que j’ai eu avec un CP après que le client râle qu’on dépasse pas les 1tps alors qu’on lui a vendu du rêve à plus de 100tps …
#42
Ça fait partie du boulot pourtant.
#43
#44
#45
Oui mais il faut aussi des outils comme ça pour les gens comme moi, qui testent parfois des solutions sur un environnement ou la sécurité n’est pas un problème et où on veut juste “que ça marche”.
Le bon sysadmin doit bien lire la doc et connaître l’environnement, je suis tout à fait d’accord avec toi, mais là le problème c’est la personne, pas l’outil.
#46
Utiliser un gestionnaire de paquets qui tient la route n’empêche pas d’utiliser puppet. C’est complémentaire.
#47
#48
Question pour les spécialistes de Docker.
Vu que TeamSpeak ne veut pas sortir de version ARM du serveur, est-ce que docker permettrait de lancer facilement teamspeak-server sur le rasp 3 ?
#49
Si vous n’aimez pas Docker ou si vous n’en avez pas besoin, ne l’installez pas.
Ceci dit, apt-get et docker n’ont pas le même objectif.
apt-get sert a installer/mettre à jour des programmes sur un système.
docker sert a exécuter des programmes sur un système.
En particulier docker permet:
Le fait que toutes les dépendances soient incluent dans le programme c’est une contrainte technique qu’on peut voir comme un avantage (pas de dll-hell) ou un inconvénient (duplication). Mais c’est un petit prix a payer pour avoir les fonctionnalités offertes par docker.
#50
#51
#52
#53
Synology ne permet d’utiliser docker que sur du x86.
J’avais compris que c’était parce que les conteneurs en général sont fait pour du x86.
Ca veut dire que ceux qui veulent utiliser docker sur rpi vont devoir trouver/faire des conteneurs arm ?
#54
oui, il faut que l’image soit compilée pour l’architecture ARM.
Il y a déjà pas mal d’image pour ARM, et même des spécifiques pour RPI:
https://hub.docker.com/search/?q=RPI
#55
non mais avant ça marchais sans problème ^^
tiens faudrait que je test aussi avec un chmod -R / vu le nombre de fois que des admins m’ont fait le coup :/
#56
Juste pour dire, swarm existait déjà avant la 1.12. C’était juste horrible à utiliser et la 1.12 l’a intégré au moteur, rendant la mise en cluster accessible à tous.
#57
Salut tout le monde! My French is a bit rusty so I wanted to say it’s great to see so many comments and questions. Please can you post them on my blog post or at Twitter @alexellisuk? curl|sh is the standard Docker installation method because most distributions run with stable, old packages. Arch Linux for ARM has a Docker 1.12.1 package if you want to try it. This works on Pi Zero, Pi 2 and Pi 3, probably even Pi 1. Looking forward to hearing from you. Alex
#58
#59
Toujours pas compris ce qu’est Docker et à quoi ça sert. Pas faute d’avoir lu des articles sur le sujet pourtant. Si quelqu’un a un lien du genre Docker pour les nuls, j’aimerai bien comprendre (je suis dev au passage).
#60
Dans la vie y’a 2 types d’admin sys :
- ceux qui ont déjà fait une grosse connerie en root
- ceux qui vont bientot en faire une
Sinon, perso j’utilise Alpine au lieu de Raspbian sur mon rpi3 avec Docker..
#61
Oh que oui. J’ai déjà vampirisé 95% du CPU d’une box physique de prod (qui faisait tourner des LPAR virtuels ofc) avec un script de monitoring.
" />
#62
#63
Donc avec cette ligne, tu casses potentiellement ton appli à chaque nouveau déploiement et si tu veux étendre un cluster, tu n’auras pas les mêmes versions pour chaque membre.
Je crois pas que tu apportes réellement une solution..
#64
#65
J’exécute 3 versions de PHP différentes sans utiliser docker, avec des paquets propres prit en charge par le gestionnaire de paquets de ma distro.
C’est pas compliqué de changer un numéro dans le fichier PKGBUILD et re-générer le paquet. Même ça si tu as la flemme sur AUR tu as des types qui partagent leurs PKGBUILD, t’as juste à taper sur yaourt.
Chaque version a son propre fichier de config, puisque le fichier de config a le numéro de la version dessus, tranquille.
Le type qui veut une version précise peut préciser dans ses scripts ce qu’il veut ou changer le PATH pour exposer uniquement la version souhaitée, ceux qui précisent pas utilisent la dernière version qui ne porte pas de numéro d’identification.
Tu peux isoler les différentes instances des programmes avec apparmor, Selinux, Grsecurity, tomoyo, et surtout éviter de faire tourner des trucs en root. (php tourne en tant que le compte utilisateur du gars qui a le site, nginx tourne en tant que nginx).
Passer d’une version à l’autre d’un logiciel revient à changer la cible du lien du nom du bin, un numéro à changer, chaque utilisateur peut choisir la version de son logiciel.
On peut activer/désactiver les versions de services avec systemctl.
Avec ça, quel(s) avantage(s) reste-il à Docker ?
Par contre, aucun des désavantages n’a disparût, surtout les problèmes de sécurité.
Il n’y a pas de “dll-hell” sous linux, tu ne fais pas des bin statics, les logiciels vont utiliser la dernière version de ta librairie et c’est tout, à moins de remplacer OpenSSL par LibreSLL par exemple, tu ne vas pas casser quelque chose comme ça, à moins de jouer à l’apprenti sorcier avec les options de compilation.
Pour juste exécuter un logiciel il suffit de “./nomdubin”, docker est sensé simplifier ça ? Ça semble déjà assez simple.
#66
C’est valable si c’est toi qui fait le conteneur, pas si tu le télécharges et l’installes.
#67
Ca reste un problème. Tu n’as pas fait une image, tu as fait un script qui installera chaque fois les dernières versions..
Donc si je déploie en janvier 2016 une application pilote qui est tellement utilisée que je dois en déployer de nouveaux clones en février, mars et juin 2016, j’ai un risque d’avoir entre une et quatre versions différentes de ton image en production.
Ton dockerfile est un risque pour tout environnement opérationnel vu qu’il n’est pas susceptible de donner deux fois le même résultat pour une même exécution.
De plus le release management est horrible vu qu’il n’y a aucun versionning et on ne contrôle absolument pas ce qui est poussé en prod.
Ma remarque est également valable si tu déploies ton dockerfile en qualification en janvier et le même dockerfile en mars ou avril en production.
Bref, ton empressement à trouver une solution à un vrai problème de docker t’amène à créer d’autres problèmes bien plus graves.
#68
#69
#70
Tu cherches juste à avoir le dernier mot, tu as volontairement évité le reste de mon commentaire.
Je ne casse pas du sucre sur docker, un problème de celui-ci est posé, tu arrives avec tes grands sabots et tu donnes une fausse bonne idée.
Si tu es aveuglé par ton fanboyisme, soit… Essaye juste de rester objectif.
Perso, j’ai rien contre docker, ça ne me fait ni chaud ni froid.
#71
#72
Allez, je te le laisse le dernier mot, tu ne débats pas, tu es insultant.
On en reste là.
#73
News qui tombe à pic merci ! Juste quand je me plonge dans Docker pour remplacer mon bataillon de VM’s. Pour le Raspi j’imaginais même pas que c’était possible, vu l’architecture ARM.
(Docker ne tourne même pas sur un vieux core 2 duo sans Intel VT par exemple, alors un proco 32bits, j’y songeais même pas…)
j’avais déjà jeté un œil à Hypriot mais je voulais rester sur Raspbian où j’ai mes marques :)
#74
Le dockerfile, c’est pour créer l’image.
" />
Après tu la pousses dans un repo (avec version et tutti quanti), et c’est à partir de ça que tu déploies.
PS : ah zut, j’avais pas vu les dates.. J’espère relancer un peu le débat quand même