NB : après relecture de mon post, je sais qu'il apparaît un peu agressif, c'est mon style, je n'attaque personne ici, je suis parfois peu brut de décoffrage, voilà tout ;)
J'ai testé l'installation et la configuration de GitLab en natif sous ArchLinux (avec l'aide du wiki pourtant).
Bilan : 10 jours à me casser la tête pour régler tout ce qu'il fallait (comprendre : pour que ça fonctionne sans bugs), et c'était loin d'être optimisé au niveau des perfs (c'était même franchement mauvais). Quant aux mises-à-jours, c'était (trèèès) loin d'être fiable (en fait c'était pas fiable du tout).
Puis j'ai décidé d'utiliser l'image Docker. 1 journée complète, avec l'optimisation qui va bien pour des performances dignes d'un truc en prod.
Donc lorsque j'ai installé Nextcloud, je n'ai même pas tenté l'installation native, j'ai tout de suite utilisé l'image Docker. Et j'ai été très content de cela il y a 2 semaines lorsque la montée en version de Nextcloud m'a ramené des erreurs. J'ai downgradé en 2 min, j'ai attendu 2 semaines avant de retenter un upgrade, et cette fois c'était bon.
Alors oui, ce n'est pas la voie royale pour empaqueter des logiciels. Mais au-delà des optimisations qui sont déjà toutes faites par l'équipe de dév, c'est bien plus qu'un simple confort pour l'admin que d'avoir la possibilité de mettre en place des plateformes de ce genre très rapidement : c'est la garantie d'avoir tout le temps un truc qui tourne (on se comprend). Sans compter que ça permet de migrer très facilement et rapidement la plateforme d'une machine à une autre lorsqu'il le faut ; avant j'avais un serveur qui n'avait que des appli en natif et ça a été bien long et chiant lorsque j'ai dû passer de cette machine qui était sous Debian à une autre machine qui était sous ArchLinux.
Pour un serveur perso, on peut se permettre d'avoir un truc en carafe pendant quelques jours, passer quelques nuits dessus, dire à Bobonne et à sa bande de potes que dans 3 jours ils pourront de nouveau accéder à leurs contenus.
En revanche lorsqu'on a une boîte à faire tourner (mon cas), c'est une autre paire de manches. Le client se fout totalement de savoir pourquoi votre serveur est down. Passer 3 jours pour remettre sur pieds un simple serveur est impensable, non seulement pour l'indisponibilité du contenu, mais aussi parce que 3 jours de boulot c'est super long quand on développe sa boîte.
Alors vous allez me dire que c'est de ma faute car j'utilise ArchLinux et donc que c'est à moi de tout gérer et que je n'ai qu'à assumer. Oui mais non, car s'il faut faire 10 jours de config pour faire tourner un logiciel (qui n'est même pas encore optimisé), c'est qu'il y a un problème dans la conception de l'appli. Normalement une appli devrait pouvoir être lancée assez rapidement moyennant quelques paramètres ici et là, et ce indépendamment de la distribution. A charge ensuite à l'admin de passer du temps sur le manuel pour l'optimiser selon ses besoins. Mais quand vous vous retrouvez à balancer des hacks dans la config tellement c'est mal conçu (j'ai eu le cas sous GitLab et Nextcloud), non, non et non. C'est là où Docker permet de s'économiser tout un tas de problèmes. Je suis le premier à défendre la philosophie du logiciel libre, mais il arrive un moment où on ne peut plus se permettre de passer du temps à débugguer encore et encore les appli et à soumettre des patchs, on a besoin que ça tourne et Docker permet de faire ça relativement proprement. Ca n'empêche pas de continuer à soumettre des merges requests, ce que je fais, mais en attendant il faut bien faire avancer le schmilblick et payer les factures !
En conclusion : oui, oui et mille fois oui à un empaquetage natif, voire avec Flatpak (ou autre, je suis pas sectaire). Mais non, non et re-non si ça donne un truc crade à l'arrivée. Je préfère une bonne image Docker qui tourne à un truc natif foireux.
PS : je sais que je vais me faire moinsser par un certain nombre d'ayatolas idéalistes du libre qui verront en moi un salaud de patron et probablement un incompétent notoire, reste que l'argent ne me tombe pas du ciel et que j'essaie de trouver le meilleur compromis pour utiliser du libre partout. J'ai cet idéal du libre, mais il faut aussi être réaliste et voir que cet idéal se confronte à des réalités bassement primaires comme : comment je vais payer mon loyer si mon serveur est down et que mon client me paie seulement le mois prochain ? Ca n'est pas remettre en cause le libre que d'agir de la sorte, c'est au contraire essayer d'utiliser coûte que coûte le libre quitte à devoir hacker un peu certains trucs qui peuvent rendre certains puristes malades.
[^] # Re: Docker fourre-tout ?
Posté par cluxter . En réponse à la dépêche L’application « OnlyOffice pour Nextcloud » est disponible. Évalué à 7.
NB : après relecture de mon post, je sais qu'il apparaît un peu agressif, c'est mon style, je n'attaque personne ici, je suis parfois peu brut de décoffrage, voilà tout ;)
J'ai testé l'installation et la configuration de GitLab en natif sous ArchLinux (avec l'aide du wiki pourtant).
Bilan : 10 jours à me casser la tête pour régler tout ce qu'il fallait (comprendre : pour que ça fonctionne sans bugs), et c'était loin d'être optimisé au niveau des perfs (c'était même franchement mauvais). Quant aux mises-à-jours, c'était (trèèès) loin d'être fiable (en fait c'était pas fiable du tout).
Puis j'ai décidé d'utiliser l'image Docker. 1 journée complète, avec l'optimisation qui va bien pour des performances dignes d'un truc en prod.
Donc lorsque j'ai installé Nextcloud, je n'ai même pas tenté l'installation native, j'ai tout de suite utilisé l'image Docker. Et j'ai été très content de cela il y a 2 semaines lorsque la montée en version de Nextcloud m'a ramené des erreurs. J'ai downgradé en 2 min, j'ai attendu 2 semaines avant de retenter un upgrade, et cette fois c'était bon.
Alors oui, ce n'est pas la voie royale pour empaqueter des logiciels. Mais au-delà des optimisations qui sont déjà toutes faites par l'équipe de dév, c'est bien plus qu'un simple confort pour l'admin que d'avoir la possibilité de mettre en place des plateformes de ce genre très rapidement : c'est la garantie d'avoir tout le temps un truc qui tourne (on se comprend). Sans compter que ça permet de migrer très facilement et rapidement la plateforme d'une machine à une autre lorsqu'il le faut ; avant j'avais un serveur qui n'avait que des appli en natif et ça a été bien long et chiant lorsque j'ai dû passer de cette machine qui était sous Debian à une autre machine qui était sous ArchLinux.
Pour un serveur perso, on peut se permettre d'avoir un truc en carafe pendant quelques jours, passer quelques nuits dessus, dire à Bobonne et à sa bande de potes que dans 3 jours ils pourront de nouveau accéder à leurs contenus.
En revanche lorsqu'on a une boîte à faire tourner (mon cas), c'est une autre paire de manches. Le client se fout totalement de savoir pourquoi votre serveur est down. Passer 3 jours pour remettre sur pieds un simple serveur est impensable, non seulement pour l'indisponibilité du contenu, mais aussi parce que 3 jours de boulot c'est super long quand on développe sa boîte.
Alors vous allez me dire que c'est de ma faute car j'utilise ArchLinux et donc que c'est à moi de tout gérer et que je n'ai qu'à assumer. Oui mais non, car s'il faut faire 10 jours de config pour faire tourner un logiciel (qui n'est même pas encore optimisé), c'est qu'il y a un problème dans la conception de l'appli. Normalement une appli devrait pouvoir être lancée assez rapidement moyennant quelques paramètres ici et là, et ce indépendamment de la distribution. A charge ensuite à l'admin de passer du temps sur le manuel pour l'optimiser selon ses besoins. Mais quand vous vous retrouvez à balancer des hacks dans la config tellement c'est mal conçu (j'ai eu le cas sous GitLab et Nextcloud), non, non et non. C'est là où Docker permet de s'économiser tout un tas de problèmes. Je suis le premier à défendre la philosophie du logiciel libre, mais il arrive un moment où on ne peut plus se permettre de passer du temps à débugguer encore et encore les appli et à soumettre des patchs, on a besoin que ça tourne et Docker permet de faire ça relativement proprement. Ca n'empêche pas de continuer à soumettre des merges requests, ce que je fais, mais en attendant il faut bien faire avancer le schmilblick et payer les factures !
En conclusion : oui, oui et mille fois oui à un empaquetage natif, voire avec Flatpak (ou autre, je suis pas sectaire). Mais non, non et re-non si ça donne un truc crade à l'arrivée. Je préfère une bonne image Docker qui tourne à un truc natif foireux.
PS : je sais que je vais me faire moinsser par un certain nombre d'ayatolas idéalistes du libre qui verront en moi un salaud de patron et probablement un incompétent notoire, reste que l'argent ne me tombe pas du ciel et que j'essaie de trouver le meilleur compromis pour utiliser du libre partout. J'ai cet idéal du libre, mais il faut aussi être réaliste et voir que cet idéal se confronte à des réalités bassement primaires comme : comment je vais payer mon loyer si mon serveur est down et que mon client me paie seulement le mois prochain ? Ca n'est pas remettre en cause le libre que d'agir de la sorte, c'est au contraire essayer d'utiliser coûte que coûte le libre quitte à devoir hacker un peu certains trucs qui peuvent rendre certains puristes malades.