paulez a écrit 387 commentaires

  • [^] # Re: Sans problème

    Posté par  (site web personnel) . En réponse au message Transfert d'un SSD système Linux Mint d'un ordinateur vers un autre ordinateur. Évalué à 1.

    Attention quand même si le SSD est un 2,5", certains nouveaux modèles n'acceptent que des SSD M.2, dans ce cas il n'est pas possible de transférer le SSD.

    Il est toujours possible de transférer le système dans ce cas là, mais c'est un poil plus compliqué. Il faut pouvoir brancher l'ancien SSD au nouveau système. Pour ça j'utilise un boîtier compatible SSD 2,5" avec un connecteur USB.

    On peut ensuite:
    - booter un live-CD Linux
    - créer la table de partition et les systèmes de fichier sur le disque local
    - copier les données depuis l'ancien disque avec rsync -a
    - faire un chroot dans le système ainsi créé
    - installer et configurer le boot loader (grub-install)

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Possible en effet, je vais essayer aussi avec Docker pour voir comment je m’en sors. Merci pour les pistes !

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 2.

    J’ai la prétention de savoir un peu ce que je fais, ça fait 15 ans que j‘héberge ces services. En ce moment c’est dans EC2, avant c’était ailleurs.

    Je connais très bien AWS pour des raisons professionnelles, c’est pour ça que je l’utilise.

    Ça n’empêche pas de demander des conseils pour tester d’autres approches !

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 2.

    EXT4 est tout à fait capable de gérer une coupure de courant (journalisation, write barrier et tout le toutim). Ce qu'il ne fait pas (mais aucun FS ne fait) est de récupérer magiquement les données sur lesquelles il n'y a pas eu de fsync.
    Je ne connais pas bien ZFS, mais je ne vois pas pourquoi ça serait différent à ce niveau là. Pouvoir récupérer les données sur lesquelles il n'y a eu de fsync implique d'écrire de manière synchrone sur le disque en permanence ce qui est ingérable niveau performance sur un disque rotatif.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Pour l'instant ça tourne dans une VM EC2, maintenant que j'ai la fibre je veux déplacer certains services chez moi temporairement. Je vais bientôt déménager, donc je veux pouvoir déplacer de nouveau le service ailleurs quand je déménage. Aussi je veux facilement pouvoir changer d'hébergeur en fonction des prix.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    OK donc dans ce cas je "monte" la configuration dans le docker. Donc je dois faire des backups du point de montage de la configuration et des données séparément. C'est bien un conteneur "applicatif" dans le sens où le conteneur ne se suffit pas à lui-même, il faut lui adjoindre la configuration et les données.

    Ici l'intérêt de Docker se limite à isoler la partie applicative, car je sais qu'elle va fonctionner partout, mais ça ne m'aide pas avec le reste.

    J'essaie d'imaginer un fonctionnement plus similaire à une VM, où je peux gérer l'application, la configuration et les données d'un seul bloc, comme ça je n'ai qu'une seule chose à sauvegarder.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Le job du FS est de conserver sa cohérence. Dans le cas de ton application qui meurt inopinément, en effet ton appli doit gérer la cohérence à son niveau.

    Dans ton cas d'une appli qui écrit un simple fichier, une manière de faire est la suivante:

    1. Créer un fichier temporaire et écrire dedans.
    2. Appeler fsync() sur le fichier temporaire.
    3. Renommer le fichier temporaire vers le fichier final.

    Avec cette méthode, tu ne retrouves pas avec un fichier final à moitié écrit, seul le fichier temporaire peut se retrouver dans cet état. Le fichier final est soit la version précédente (avant le renommage) soit la version après le renommage.

    C'est beaucoup plus compliqué avec des bases de données. Une bonne partie de la complexité des gestionnaires de base de données vient de là, comment pouvoir repartir correctement après une coupure de courant.

    Il y a plusieurs manières d'écrire sur le disque dans MySQL, plus ou moins sûres et moins ou plus performantes, par exemple innodb_flush_log_at_trx_commit

    Il y a des commandes SQL pour rendre ça moins douloureux, mais ça doit pouvoir marcher sans.

    En théorie si système de snapshot est cohérent, tu dois pouvoir restaurer ta base de données dans un état cohérent avec un snapshot fait sans précaution particulière, mais tu peux perdre quelques transactions si tu utilises innodb_flush_log_at_trx_commit différent de 1. C'est en gros équivalent à une perte de courant sur ton serveur, qui est cas que ton SGBD doit pouvoir redémarrer depuis.

    En pratique il y a des cas où ça ne marche pas en fonction des limitations du SGBD. Par exemple avec MySQL avant la version 8, si tu fais un DDL (modification de la définition d'une table) et que MySQL crashe ou que ton serveur crashe, tu as de fortes chances de ne pas pouvoir relancer la base de donnée.

    Pour éviter de perdre certaines transaction et éviter de tomber dans les cas d'où le SGBD ne sait pas redémarrer, il faut flusher les tables sur le disque d'abord avec une requête du type:

    FLUSH TABLES WITH READ LOCK
    Si ton système de snapshot n'est pas cohérent (par exemple tu fais un tar ou un rsync), là il faut flusher les tables et mettre un lock en écriture le temps de toute la procédure.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Ca aussi ça n'existe pas, c'est ce que je reproche à la magie du "cloud" ça te fait croire que ça tourne partout et nul part, non c'est au chaud dans des datacenters géolocalisés quelque part sur des CPU et des disques bien physiques derrière des routeurs bien réels.

    Des datacenters oui, mais aussi énormément de logiciel pour rendre tout ça transparent pour les utilisateurs. C'est ça la magie du cloud, c'est du logiciel. Je ne regrette pas l'époque où je devais attendre 3 mois pour avoir un serveur.

    Mais si tu veux fait tu veux tout, tout de suite sans t'investir dans le projet, ca n'existe pas navré, enfin si pour les commerciaux qui vendent de la bullshit aux clients ça existe certainement.

    L'informatique c'est un outil, il y a des outils plus ou moins simples à utiliser. Choisir le bon outil c'est assez primordial pour être efficace.

    Je fais déjà tourner mes services. Je veux les convertir petit à petit vers des conteneurs pour pouvoir les déplacer en fonction des besoins. Je veux en mettre certains chez moi pour économiser les coûts d'hébergement, mais pouvoir les déplacer rapidement chez un hébergeur quand ma freebox tombe en panne ou que je déménage.

    Je passe maximum quelques heures par mois à gérer tout ça, et ça marche bien. Je ne suis pas intéressé par jeter tout ça et utiliser un fournisseur tiers à la place.

    Par contre je cherche le bon outil pour faire évoluer mon système comme décrit plus haut. Au début j'étais assez enthousiaste pour tester les jails de FreeBSD, mais tes messages semblent indiquer que cela nécessite un investissement en temps conséquent, donc ça me refroidit pas mal.

    Je vais commencer par regarder LXC plus en détails, merci pour les infos.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Tu fusionne la donnée et l'exécution ?

    À voir, je cherche la meilleure approche pour moi.

    J'héberge quelques services: web, mail, nextcloud, jabber, ldap, etc. Il y a les données, l'exécution (tel binaire qui dépend de telle librairie), mais aussi la configuration.
    Ça m'arrive souvent d'avoir un léger problème que je peux régler en modifiant la configuration d'un service.
    Si j'ai bien compris dans le modèle Docker, je dois modifier la configuration utilisée pour générer l'image, régénérer l'image, relancer le conteneur avec la nouvelle image. C'est beaucoup trop lourd pour moi, surtout que souvent je dois modifier plusieurs fois la configuration avant de trouver ce qui convient le mieux.
    C'est pour ça que je trouve que ce concept est plus adapté pour des conteneur déployés de nombreuses fois, mais pas pour un conteneur déployé une seule fois (la complexité ajoutée ne vaut pas le coup).
    Est-ce qu'il y a une meilleure plus simple d'utiliser Docker sans avoir à redéployer un conteneur pour un changemeet de configuration ?

    qu'est-ce qui garanti que ma donnée est correct ? Lors d'un crash de ton contenaire est-ce que tu risque de perdre la totalité de tes données et indexes associé ?

    Justement je cherche une solution qui me permettent de faire des sauvegardes cohérentes. Si j'ai bien compris LXC + btrfs me permettent de faire ça, je fais un snapshot du conteneur, puis je l'exporte.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Donc maquette, test, casse, remonte, maquette, test, casse, remonte … etc jusqu’à temps d'être hyper à l'aise avec la techno : oui ça demande du temps et de l'investissement.

    Je veux bien mais je n'ai pas un temps infini, je préfère donc avoir une shortlist d'outils à tester.

    Temps indispensable à prévoir : étudier la politique de backup.

    Je veux pouvoir faire des dumps de mes conteneurs, les stocker dans S3, et pouvoir les restaurer sur un autre système.

    Personnellement je suis un aficionados du minimaliste donc pour faire tourner des service je m'oriente vers UFS qui est extrêmement performant sur un SSD ça bombarde, avec ce genre de FS tu pourras faire tourner FreeBSD sur des bécanes ridiculement petite et donc remonter tes services absolument partout, type ARM et consort sans aucun soucis.

    Je suppose que comme tu parles de remonter le conteneur sur du ARM (une archi différente) tu ne sauvegardes pas le conteneur en entier pour pouvoir le relancer ailleurs, mais la conf pour pouvoir reconstruire le conteneur c'est bien ça ?

    Ensuite le cloud ça ne veut rien dire c'est un buzzword marketing

    Un buzzword marketing peut-être, mais qui me permet de manger depuis pas mal d'années déjà :-)

    Quand je parle d'une VM cloud, c'est une VM que je peux démarrer à l'instant où je veux.

    Par exemple pour l'instant j'ai des machines virtuelles EC2 à Dublin. Je veux migrer des services vers des conteneurs, pouvoir les déplacer chez moi, puis ensuite dans une VM en France, après dans une VM aux États-Unis, etc. Tout ça en ayant juste à démarrer une machine quelque part et y exporter le conteneur.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 1.

    Justement je lisais un peu sur le sujet, et il m’a semblé qu’il y avait plusieurs outils de gestion des jails (ezjail, iocage, bastille, …) dont certains me semblaient ne plus être maintenus. Je m’inquiète donc de choisir une solution qui ne sera pas forcément maintenue dans le temps. Qu’est-ce que tu recommandes ? Et UFS contre ZFS, lequel correspond à quel besoin ?

    Par exemple mettons que je veuille pouvoir facilement exporter une jail de chez moi vers une VM dans le cloud et inversement, plus faire des sauvegardes de mes jails dans S3. Quelle est la meilleure solution à base de jails pour faire ça ?

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 2.

    J’ai déjà un peu joué avec LXC, je vais aussi essayer les jails. Ces deux là correspondent bien à ce que je veux faire, je me demandais s’il y avait aussi d’autres solutions de ce style.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 6.

    Je pense qu’au sens strictement sémantique le terme conteneur contient tout ce qui permet d’isoler des composants du reste du système. On peut même considérer une machine virtuelle ou chroot comme des conteneurs. La notion d’immutabilité est spécifique à certains types de conteneurs. Une terminologie que je trouve pas mal est de parler de conteneur logiciel (type Docker) ou conteneur système (type LXC). D’où la question, étant donné que je ne veux pas utiliser un conteneur logiciel immuable. Mais je ne veux pas non plus utiliser une machine virtuelle.

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 2.

    En gros je veux avoir quelque chose qui ressemble à une VM, mais sans la surcharge liée à la VM.
    Je veux avoir des "pets": je n'ai pas envie d'écrire un script ansible alors que je n'ai qu'une seule VM ou un seul conteneur qui gère mes mails. Par contre je veux pouvoir facilement le ou la sauvegarder et transférer vers un autre serveur.
    En gros je veux un séparateur logique (un conteneur) dans lequel je bidouille à l'ancienne. Mais je veux avoir une séparation logique pour résoudre les problèmes de compatibilité: par exemple je veux mettre à jour mon conteneur de mail vers Debian 12 mais garder mon conteneur LDAP sur Debian 9. Tout ça sans la lourdeur de KVM (allocation de mémoire et disque fixe, I/O lentes à cause de VirtIO, etc).

  • [^] # Re: Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 3.

    Si par exemple je veux un conteneur "serveur de mail" qui contient un postfix, dovecot et antispam, Docker n'a pas l'air d'être la bonne solution puisque son concept est d'avoir une app par conteneur (un "entry point" par conteneur).
    Je veux pouvoir faire des conteneurs système, pas un conteneur par application. Est-ce que Docker est fait pour ça ? Je n'en ai pas l'impression.

  • # Bétail vs animal de compagnie (pets vs cattle)

    Posté par  (site web personnel) . En réponse au journal L'Écosystème containeurs. Évalué à 2.

    Dans mon esprit Docker et compagnie c'est bien pour gérer du "bétail", aka déployer les conteneurs construits par une équipe de dev par centaines sur des nœuds géographiquement répartis, chaque conteneur contenant idéalement un seul composant d'un système complexe, qu'on peut déplacer et multiplier à l'envi.

    Si je veux m'occuper des mes animaux de compagnie (mon serveur de mail et mon serveur web par exemple), quel est la meilleure solution à base de conteneur ? Qui me permette d'avoir des systèmes isolés et faciles à sauvegarder. LXC ? Podman ? Les jails de FreeBSD ?

  • # Remote

    Posté par  (site web personnel) . En réponse au message [annonce supprimée]. Évalué à 2.

    Est-ce que c'est ouvert au remote ? La localisation est un peu vague.

  • [^] # Re: Cloud

    Posté par  (site web personnel) . En réponse au journal Les distributions GNU/Linux, un petit monde en voie d’extinction ?. Évalué à 1.

    Il faudrait les porter, ça doit être une tâche très conséquente.

  • [^] # Re: Cloud

    Posté par  (site web personnel) . En réponse au journal Les distributions GNU/Linux, un petit monde en voie d’extinction ?. Évalué à 7.

    Intéressant que tu parles de cet aspect là. La version 5.1 de Linux a vu des contributions de 1707 personnes et 230 entreprises d'après ces statistiques. Est-ce que tu peux me citer beaucoup de produits ou entreprises qui ont plus de 1000 développeurs sur un même projet ?

  • [^] # Re: Cloud

    Posté par  (site web personnel) . En réponse au journal Les distributions GNU/Linux, un petit monde en voie d’extinction ?. Évalué à 6.

    Richard Stallman n'a pas démissionné du projet GNU mais de la FSF. Ça montre une forte propension à mélanger les choux et les carottes !

    Ça serait beaucoup de boulot de faire un système Linux sans GNU. Une liste de composants assez essentiels qui proviennent de GNU sont bien sûr gcc, glibc et bash, mais aussi les coreutils (ls, cp, etc.), grep, diff, gzip, cpio, find, screen, readline, GRUB, tar…

    Après on doit pouvoir en remplacer seulement quelques uns pour pouvoir s'appeler autrement que GNU/Linux, au grand dam de Stallman.

  • # Cloud

    Posté par  (site web personnel) . En réponse au journal Les distributions GNU/Linux, un petit monde en voie d’extinction ?. Évalué à 6.

    GNU/Linux tourne sur 90% du cloud public.
    On peut installer Linux dans Windows, car Microsoft essaie de garder les développeurs qui déploient dans le Cloud qui veulent pouvoir tester localement.
    C'est pas la fin de GNU/Linux, c'est plutôt la fin de ses concurrents.

  • # Postfix FTW

    Posté par  (site web personnel) . En réponse au message Recherche serveur mail. Évalué à 4.

    J'utilise Postfix + Amavis + Spamassassin + Clamav niveau MTA, et Dovecot + Managesieve niveau MDA.

  • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

    Posté par  (site web personnel) . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 2.

    J'ai lu tes commentaires, et au départ j'essayais simplement de te conseiller sur quels paramètres changer.
    J'ai administré des bases de données MySQL dans des serveurs allant de 600 MiB de mémoire à des centaines de GiB. Je trouve qu'un avantage de MySQL et MariaDB est leur versatilité, capable de fonctionner dans des environnements très différents en terme d'usage.
    Par contre ça reste un SGBD complexe à configurer, on est d'accord, mais tous les SGBD le sont, c'est pour ça que ces formations sont utiles. La doc existe, mais est complexe, mais c'est le cas pour tous les SGBD actuels.

  • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

    Posté par  (site web personnel) . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 1.

    Peut-être que le choix de MariaDB est souvent orienté par sa popularité, mais il faut quand même reconnaître qu'il est capable de fonctionner dans des environnements variés.
    Après j'ai l’impression que ton problème vient premièrement du fait que tu as désactivé l'overcommit et pas de MariaDB lui-même, ce qui est un nid à problème en soit :-)

  • [^] # Re: s’attaquer à la pénurie de compétences avancées sur les bases de données

    Posté par  (site web personnel) . En réponse à la dépêche Appel à contributions de la Fondation MariaDB auprès des universités. Évalué à 1.

    De mon expérience les paramètres les plus utiles pour limiter la connexion mémoire:

    • innodb_buffer_pool_size: taille du cache global InnoDB, le plus gros consommateur de mémoire
    • max_connections: chaque connexion va utiliser un thread, donc un large nombre de connexion va augmenter la consommation mémoire. Cela peut nécessiter de changer les clients pour limiter le nombre de connexions.

    Mysql/MariaDB c'est pas forcément le SGDB de meilleur qualité ou le mieux documenté, mais c'est clairement le plus populaire.