J'ai eu la chance de découvrir un FabLab à 10 min à pied de chez moi l'année dernière et depuis j'ai rejoint l'équipe IT :-) Notre sujet du moment est de migrer vers un nouveau serveur en Stretch et de rationaliser les outils utilisés.
Pour la gestion des matériels informatiques, GLPI + FusionInventory remplissent leur office(*)
Nous avions un dokuwiki (un peu cassé dernièrement) pour permettre aux membres de documenter leurs réalisations sous licence CC-by-SA ; nous nous orientons plutôt vers wikifab basé sur mediawiki et assez joli :
- il simplifie l'interface pour les membres (pas de connaissance spécifique de mediawiki et guide pour remplir une page de documentation de son projet, taggué selon les technologies et rattaché à un groupe
- capacité à l'instancier sur notre serveur, ce qui évite de transmettre l'intégralité de notre base d'adhérents à un service centralisé
- il conserve les avantages de mediawiki et il y a des outils de migration de dokuwiki vers mediawiki
- il n'y a pas de forum communautaire mais notre contact avec les développeurs à la Maker Faire de la Villette en Juin 2017 nous a encouragé à travailler avec eux
Le site web principal a été migré sur le nouveau serveur, en conservant wordpress :
- l'agenda par défaut est peu pratique pour les événements récurrents chaque semaine (il faut créer tous les événements plutôt que donner une période et un jour)
- l'utilisation d'une carte openstreetmap reste à mettre en place (le greffon googlemaps a été utilisé par défaut o_O)
- des greffons telegram ou plutôt mastodonte seraient nécessaires
- les greffons facebook et twitter ne demandent qu'à être remplacés
- un greffon meetup pourrait être utile (et une autre plateforme plus pratique)
Notre migration de owncloud vers nextcloud a fonctionné :
- tous les documents sont disponibles et la synchro est opérationnelle
- nous regardons l'ajout de l'agenda au besoin, plutôt que dans wordpress
- le greffon pour les photos nous évitera de remettre en place un piwigo (nous souhaitons à l'IT diminuer le nombre de logiciels utilisés si un existant fait le taf')
(*) pour GLPI, ce sont de l'ordre de 60 portables / PC fixes sur 2 sites qui sont actuellement gérés :
- déjà un recensement de l'existant, affecté à des groupes : ateliers, utilisation au FabLab, spécifique matériel (découpe laser, CNC, graveuse laser, ateliers scratch ou arduino) mais cela fonctionne pour les matériels complets ayant démarré et installés, moins bien pour le matos qui a des glitchs (manque disque dur, écran défaillant, mémoire défaillante) et qui devrait être rentré manuellement + mettre une action pour améliorer la situation
- les fonctions de réservation de matériel pourraient être intéressantes :
- recenser les matériels pouvant être réservés, déléguer la gestion des réservations (à tester), gérer les matériels non informatique pouvant être prêtés
- inventaire manuel à tester
- reste à tester l'interface avec de vrais utilisateurs (GLPI étant par nature très orienté IT…), surtout pour l'aspect réservation et complétude de ce qui est disponible par atelier (groupe ?)
- nous souhaitons éviter FabManager côté IT :
- intéressant fonctionnellement (réservation de ressource, gestion des membres, contacts entre membres),
- mais c'est un docker (difficulté de mise à jour) et c'est la foire aux logiciels à gérer (aussi complexe qu'un mailman 3 que nous avons déjà)
- GLPI à rendre plus joli : la migration en 9.2 va rénover le 0.84 de debian jessie déployé actuellement et utilisé uniquement par 2 personnes…
- si vous avez un retour d'expérience ou des exemples utilisables par le commun des mortels, je suis preneur :D Sur stretch idéalement.
Pour la gestion des membres :
- grisbi côté comptabilité
- fusiondirectory pour la gestion de l'authentification et des droits utilisateur
- mailing-lists via mailman 3 (améliorable, pour traduction en français, gestion des spams, conso mémoire on a passé la VM à 4 Go de RAM pour s'éviter l'OOMK :D).
Et vous, vous avez un FabLab près de chez vous ?
# mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 02 novembre 2017 à 20:51.
C'est un peu curieux comme remarque et ça semble dénoter une grosses méconnaissance des principes des containers puisque c'est justement un de ces points forts. L'idée c'est justement de ne pas avoir à faire de mises à jours proprement dites mais de lancer un nouveau container à la place ce qui avoue le est bien plus rapide, reproductible et facilite le retour arrière si besoin.
[^] # Re: mises à jours et docker
Posté par freem . Évalué à 5.
Hum… en quoi les paquets apt seraient-ils lents, non-reproductibles ou empêcheraient le retour en arrière?
Je suis curieux de voir tes références, parce que j'ai personnellement fait pas mal joujou avec l'apt-pinning et le yoyo entre une stable et une unstable/sid, en passant par testing, et sans problèmes particuliers.
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 0.
Ça tombe bien je n'ai pas dis ça. Tu te prends pour Zénitram à vouloir inventer des dire aux gens ?
[^] # Re: mises à jours et docker
Posté par freem . Évalué à 6.
Je suppose que je t'ai mal compris dans ce cas, ou que je me suis mal exprimé. Je vais développer un peu plus, en citant de manière plus ciblée:
Comparé aux gestionnaires de paquets traditionnels, dont apt, non? Ou alors, comparé à quoi?
Pour moi, relancer juste un service après une MàJ, c'est plus rapide que relancer un service ET ses dépendances… du coup, en quoi, par exemple, apt serait-il plus lent que docker?
Ici, je veux bien t'accorder le bénéfice du doute, dans le cas que je connais le mieux (apt), un paquet foireux pourrait effectivement n'être pas reproductible et donc ne pas faciliter le retour en arrière.
Sauf que, en pratique, j'ai fait suffisamment de va-et-viens entre les diverses versions de Debian (avec un peu d'apt-pinning et quelques repos externes, dont 1 non-free, au passage, pour bien essayer de foutre la merde) pour savoir que les paquets Debian sont solides, très solides.
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à -3.
Cesse de me parler d'apt, c'est hors-sujet et tu es le seul à le faire rentrer dans l'équation.
[^] # Re: mises à jours et docker
Posté par claudex . Évalué à 7.
Il faut comprendre que Docker, ce n'est pas fait pour déployé un Apache HTTPD ou un Nginx et servir des fichiers statiques. Le but, c'est déployé une application un peu complexe (avec plusieurs dépendances). Imagine une mise à jour où tu dois non seulement changer les binaires, mais aussi changer les droits sur les fichiers, en ajouter certains, en déplacer d'autre, etc. Dans un cas classique, il faut bien faire les opérations de mise à jour en preprod, valider que ça fonctionne, et bien faire les mêmes en prod sans se planter. Si on a loupé une étape (ou si les tests étaient mal faits) et qu'il faut revenir en arrière, il faut bien défaire ce qu'on a fait (de nouveaux sans se planter).
Avec docker, du déploie une image en preprod, si ça marche, tu déploie la même image en prod et tu es bien sûr que c'est exactement la même. S'il faut revenir en arrière, tu peux simplement reprendre l'image précédente.
(il est évidemment possible d'avoir une solution intermédiaire avec un système d'automatisation, mais tu reviens moins facilement en arrière)
Évidemment, dans ce cas, on ne parle que de la mise à jour du code. On ne va pas pouvoir facilement revenir en arrière si on foire le changement de schéma de base de données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: mises à jours et docker
Posté par Michaël (site web personnel) . Évalué à 7.
Faire des va et viens a l'inconvénient que c'est une excellente recette pour fabriquer des “serveurs flocon de neige” (les flocons de neige sont tous différents les uns des autres) alors que les solutions à la docker permettent d'implémenter facilement la méthode du serveur constant (immutable server pattern en vo), ce qui signifie qu'au lieu de faire des va et viens on jette tout et on repart sur du neuf. La méthode du serveur constant a l'intérêt qu'elle qu'elle aide à maintenir l'homogénéité d'un parc et à garantir la reproductibilité d'un environnement. Le cas “à la docker” est particulièrement intéressant pour déployer un grand nombre de copies de la même application ou bien pour faire coïncider le plus possible l'environnement de développement avec celui de la production.
Docker et APT, ou tout autre gestionnaire de version de paquets ont en principe des fonctionnalités presqu'orthogonales.
[^] # Re: mises à jours et docker
Posté par freem . Évalué à 3.
Merci pour l'explication (et merci aussi à Xavier, mais comme on ne peux pas répondre à 2 messages d'un coup…)
[^] # Re: mises à jours et docker
Posté par BAud (site web personnel) . Évalué à 1.
au contraire ;-)
pour moi ça semble prendre en compte un je m'enfoutisme des développeurs des mises à jour de l'OS, justement.
vers la poubelle pour moi (et quelques collègues aussi, un peu plus compétents que moi en plus, même si ce n'était pas suffisant pour me conforter dans cette opinion)
Soit les développeurs font l'effort d'intégrer leur solution à la distro dont j'ai l'habitude, soit je fais le boulot… j'assume le choix…
pour mailman3 on avait une VM à 2 Go de RAM, l'OOMK est passé par là, on l'a passé à 4 Go
Pour un truc en docker, nous avons encore moins confiance…
c'est une question de point de vue, je suis entièrement d'accord avec toi ;-)
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 8.
Une vm et un container ça n'a pas grand chose à voir. Je ne vois pas vraiment en quoi ton exemple du mailman soit pertinent.
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 4.
Après je ne suis pas nécessairement quelqu'un qui va pousser à utiliser docker à tir larigot. Pour moi si on me fournit juste une image monolithique "boite noire" avec un gros mélange (backend/frontend) dedans ça ne m'intéresse pas. Si par contre j'ai accès aux dockerfiles et éventuellement compose mais surtout une doc bien écrite Docker peut être une techno pertinente.
L'idée c'était juste de réagir à ta remarque comme quoi des maj seraient compliquées avec Docker alors qu'une maj se résume à peu près à 3 commandes docker build / docker stop / docker run et que t'as accès à tout instant à "l'ancien environnement" si tu as un problème en stoppant le nouveau container et relançant l'ancien.
[^] # Re: mises à jours et docker
Posté par BAud (site web personnel) . Évalué à 2.
moui, je suis assez d'accord avec toi.
Pour du dév' c'est très efficace
Cela promeut les mises à jour en plus, pour avérer qu'en prod' cela pourrait fonctionner. Pour autant, je ne l'ai pas vu :/
D'un point de vue ops, je ne suis pas convaincu :-) (et pour autant je promeus la démarche devops, docker n'étant pas dans mes solutions préférées pour diverses raisons)
je puis élaborer.
Donc, bon, docker je ne suis pas convaincu. Bref, ce n'est pas le sujet qui est de réduire l'empreinte des logiciels demandés pour un fablab :-)
[^] # Re: mises à jours et docker
Posté par freem . Évalué à 4.
Du coup, c'est quoi tes solutions préférées? Par pure curiosité.
Allons allons, ce n'est pas comme si c'était la première fois que des digressions arrivent sur linuxfr, et en plus, il a posté un jeudi soir, le moment idéal pour avoir un journal exposé au trolldi dès le matin à la 1ère heure :p
[^] # Re: mises à jours et docker
Posté par Kerro . Évalué à 4.
Les données et la configuration se trouvent en dehors du container ? Sinon on perd tout à chaque mise à jour.
[^] # Re: mises à jours et docker
Posté par SauronDeMordor (site web personnel) . Évalué à 7.
pour les techno de conteneur il n y a pas que docker, lxc est très bien, en mode UTS par exemple ou alors, ce que je préfère c est l'utilisation de systemd-nspawn.
l avantage des conteneur type UTS, je vais prendre LXC comme support, tu te fais un template ou tu en prend 1 de base fourni par lxc, tu démarre un conteneur, et ensuite tu install tes soft dedans comme si c’était une machine réelle, ou une VM, c'est l utilisation du conteneur en temps que machine, un peu comme une VM, mais a moindre coup car si tu ne fait rien, la ram ou le cpu ne sont pas utilisées.
avantage, si tu a un soft uniquement pour une vielle version de debian, et bien tu peu upgrader la machine, mettre un conteneur de vielle debian, et mettre ton soft. les données sont persistantes.
ensuite si tu veux tester un upgrade d os, ou de version de soft, tu clone ton conteneur, puis fait ta procédure d upgrade, si ça déconne, tu trash le clone, et tu n'as rien perdu
et quand on parle de reproductibilité, c est qu il n y a pas un humain derrière qui fait des modif dans la machine, donc que cela soit docker, lxc, nspawn, cela s'inscrit dans une démarche d'industrialisation et d automatisation (pour éviter de dire devops).
perso je fait cela aussi souvent que possible, même sur les machine perso, comme ça lancer un nouveau service, c'est un conteneur, un setup/config (via puppet,ansible ou salt), que la seule variable c'est le type de service. et si un jour 1 service devient trop gros, et bien je le déplace sur une machine plus grosse
a la conf kernel recipes, on a vu un conférencier qui lançait des conteneurs sur une machine type x86 pour lancer des conteneurs arm64, l environnement du conteneur était en arm64, et l exécution de code faite par qemu-system-arm, c'est une utilisation détournée, mais plutôt sympa.
je pourrais continuer longtemps sur les bienfaits des conteneurs…donc je m arrête là :)
[^] # Re: mises à jours et docker
Posté par Kerro . Évalué à 4.
Tu n'as pas répondu à la question.
Les avantages que tu cites sont les mêmes que pour n'importe quelle solution de virtualisation : c'est très intéressant, et il y en a bien d'autres.
Mais ces avantages ne sont pas convaincants pour moi (pour moi, j'insiste) tant que la configuration et les données sont dépendantes du container. S'il faut tout reconfigurer à chaque mise à jour, et perdre les données, poubelle.
[^] # Re: mises à jours et docker
Posté par Michaël (site web personnel) . Évalué à 3.
C'est très juste, qu'on parle de virtualisation lourde par exemple via VirtualBox ou VMWare ou bien de virtualisation plus légère via des conteneurs ou des jails FreeBSD, on retrouve à peu près les mêmes avantages: c'est technologies et ces méthodes de travail n'ont, à bien y regarder, rien de très nouveau ou de très révolutionnaire: la première fois que j'ai utilisé VM Ware c'était en 2001 et les jails de FreeBSD existent depuis 2000 (FreeBSD 4.0).
Là où toutes ces possibilités se distinguent, c'est la communauté d'utilisateurs, y compris les utilisateurs industriels, et l'outillage disponible… et bien-sûr dans une certain mesure les effets de mode. En pratique c'est plus facile de travailler avec des conteneurs qu'avec des machines virtuelles, tout simplement parcequ'on a une couche en moins et que les outils s'occupent de la création du réseau etc.
Je travaille beaucoup avec docker et ce qui pêche le plus à mon avis c'est d'une part la commande
docker buildutilisée pour préparer les images, qui ne propose pas du tout la bonne interface: si on veut travailler efficacement il faut manier la commandedocker buildà travers un script qui s'occupe de plein de petits détails. Ensuite la documentation est plutôt mauvaise: très fouilli, mal organisée, la présentation est dégueu ce qui rend la lecture difficile, le rédacteur change tout le temps d'avis sur le type de document qu'il écrit (référence, matériel d'introduction, exemples)…Bien évidemment on peut avoir des données persistant indépendamment des conteneurs. Dans le langage de docker il s'agit des volumes. Cependant, à cause des limitations de la commande
docker build(limitations qui ont par ailleurs de bonne raisons d'être!) la préparation de l'image dans certains cas demande des soins particuliers.[^] # Re: mises à jours et docker
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
quand tu lance un VM, tu dédie des morceau de CPU; de RAM a ta VM, ce n est pas le cas des containers, c est un avantage, mais aussi un inconvénient car si un container par en sucette, les autre font être lourdement impacté (sauf si tu met des limites en ressources)
pour les données, justement tu ne les détruits pas forcement, avec un lxc.mount.entry qui permet de partager des subtree dans un LXC.
ensuite avec lxc, tu peux lancer des container en tant que user, sans les droits root, il y a un remaping du user root dans le container (uid + 100000 par défaut), ce qui est pas mal pour tester des choses en mode quick and dirty sans pourir une machine ou installer une VM.(je pense au installation du style curl http://…../truc.sh | bash)
avec le container, cela permet aussi de lancer plein de services sur un systèmes sans que ceux ci interagissent entre eux.
pour la config, je fais un salt ou un puppet ou un ansible qui met au carré la machine, mais cela reste valable pour les containers ou les machines virtuelles ou les réelles.
des que tu a plus de 3 ou 4 machines, investir dans un setup géré par l un de ces systèmes est un gain de temps. si tu ne connais pas, ansible sera peut être le plus abordable. parfois pour gagner du temps il faut en perdre un peu.
si tu vas gérer un parc machine, je te conseil vivement d utiliser cela. car tu ne vas quand même pas aller sur chaque PC et d éditer a la main les configs, ou même faire un scp sur tous ??
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 03 novembre 2017 à 22:52.
Oui l'idée est bien de séparer données et code. Ça peut être fait de différentes façons, montage de filesystem du host vers les containers, container dédiés au stockage, plugins qui permettent d'interagir directement avec une baie de stockage, des trucs comme flocker, etc.
[^] # Re: mises à jours et docker
Posté par Kerro . Évalué à 2.
Et dans la réalité, cette séparation existe ?
Perso = jamais rencontré sur les quelques tests que j'ai fait. Donc zéro utilité.
[^] # Re: mises à jours et docker
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 04 novembre 2017 à 20:54.
Bien sûr que oui elle existe. Et c'est pas un truc que tu rencontres, c'est un truc que tu décides.
Genre tu prends les images de docker pour des bases comme postgresql ou mariadb ils te montrent des exemples pour monter un volume hébergeant les données :
postgres:
mysql:
Et comme ce sont des paramètres que toute personne utilisant docker plus de 2 minuts connait, ce n'est pas forcément précisé dans les readme de toutes les images fournies par les projets upstream.
[^] # Re: mises à jours et docker
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
et oui cela existe, comme dis juste avant, c est quelque chose que tu decide.
opérer une telle séparation fait que tu vas maîtriser mieux tes données et tes configs. que tu poura donc faire des updates des maintenances, et des migration beaucoup plus facilement.
et surtout que a chaque modif, ou évolution qu on te demandera tu sera plus à même de dire si c est faisable, possible et du temps que cela peu prendre
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.