Le Blog Utux

HTTP 200 GET /

J'aime le libre

Rédigé par uTux 24 commentaires

J'écris cet article pour combattre une idée que je vois revenir souvent dans la blogosphère (française), qui dit que dans l'univers du logiciel libre c'est le bordel, c'est la guerre, trop de choix, des distributions qui se combattent au lieu de s'unir, et des développeurs qui se moquent de leurs utilisateurs.

J'ai un problème avec ça car le libre c'est mon métier. Je suis ingénieur systèmes Linux et si j'en suis arrivé là, c'est parce que je baigne dans un univers où on partage les connaissances, où on peut lire le code, où on peut poser des questions, et où globalement les logiciels marchent bien. Il y a 20 ans encore l'informatique c'était très majoritairement du Microsoft, un monde payant dans lequel il fallait des diplômes, des livres, des certifications, c'était quand même assez fermé et peu accessible. Aujourd'hui les produits libres en vogue tels que Docker ou Ansible publient leur documentation, des howto, des quickstart, un repo github, et si on ajoute stackoverfow/stackexchange on peut s'auto-former en quelques semaines. Bien sûr l'expérience en production est importante et ce n'est qu'après quelques mois voire années qu'on peut se vendre comme "expert" sur cette technologie, mais au moins c'est possible. Allez essayer de vous auto-former avec un Windows Server et un Exchange, outre les spécifications matérielles très élevées, hors programme MSDNA c'est juste impossible à cause du coût des licences.

Le libre c'est aussi la culture Devops dont je fais partie et où Microsoft a bien du mal à se positionner. On automatise, on industrialise, on code, on pousse sur le repo git, les tests unitaires et l'intégration sont déclenchés tout seuls, et on s'amuse. Merci au libre de nous avoir montré qu'on peut faire autre chose qu'installer des .exe à la main ou avec des logiciels très cher tels que SCCM.

Donc au final quand je tombe sur des articles présentant le monde du logiciel libre comme game of thrones, je me dis que ce n'est que la vision desktop, les 1% de parts de marché pour lesquels j'ai abandonné tout espoir. On oublie la culture qu'il y a derrière et moi j'aime travailler avec le libre, pas pour les raisons extrémistes de RMS et la FSF, mais pour l'efficacité, le partage, les compétences, l'accessibilité.

Proxmox VE

Rédigé par uTux 4 commentaires

Proxmox VE fait partie de ces projets cool à vocation commerciale mais libre et distribué gratuitement avec toutes les fonctionalités (comme FreeNAS). Il s'agit d'une solution de virtualisation basée sur Linux-KVM + LXC, le tout avec un web-ui plutôt bien fichu. Aperçu des fonctionnalités:

  • Cluster simili-HA (non testé)
  • Web-ui HTML5
  • Multiples backend de stockage: local, LVM, iSCSi, Ceph, Gluster, ZFS
  • Snapshots à chaud
  • Backups à chaud
  • Ajout CPU/RAM/disk à chaud (pas testé)
  • Console Web noVNC (pas de plugin à installer!)

J'ai installé Proxmox 5.1 sur mon NUC et l'utilise actuellement pour propulser mes services privés @home répartis sur 6 machines virtuelles debian.

Proxmox VE

Par le passé, l'un des points les plus gênants de Proxmox VE à mon sens était la console VNC qui nécessitait l'installation d'un plugin navigateur avec les inconvénients que l'on connait: problèmes de clavier, temps de chargement du plugin (on rate le grub!!!), latence... et j'ai été très content de constater que tout se fait maintenant en HTML5 avec noVNC, merci Proxmox!

Je rédige cet article car tout comme FreeNAS j'ai ressenti un effet "wow" (en positif). On côtoie beaucoup de logiciels dans notre métier, libres ou pas, parfois mauvais, parfois passables, mais rarement très bons. Proxmox devrait être plus connu.

Virtualisation

KVM:

Proxmox utilise KVM pour la virtualisation, avec des périphériques virtio si le système invité le supporte (Linux + BSD family). Il est possible d'allouer une quantité fixe de RAM ou un provisionnement dynamique ce qui revient en fait techniquement à autoriser le ballooning. L'installation se fait à l'aide de la console noVNC en HTML5 et d'une ISO que l'on peut uploader via le web-ui.

Proxmox active également la fonctionnalité KSM qui permet de partager entre les VM les pages de mémoire similaires par mesure d'économie. L'ensemble est donc plutôt bien pensé.

On retrouve cependant les éternels bugs communs aux solutions KVM, tels que les VM qui ne veulent parfois pas s'arrêter, il faut se connecter en SSH et forcer l'extinction car le web-ui n'y parvient pas. Dommage.

LXC:

Historiquement, Proxmox VE se basait sur OpenVZ pour les containers. Désormais c'est LXC qui est utilisé, pour cause de souplesse si on en croit ce post sur le forum Proxmox. J'ai toujours trouvé OpenVZ supérieur en terme d'isolation et d'outils d'administration, mais ce projet n'est pas upstream et a longtemps été bloqué au kernel 2.6.32 et il semble que ce soit encore le cas aujourd'hui.

Donc le passage à LXC est une bonne chose d'autant que LXCFS semble présent! Pour rappel, LXCFS permet à un container de ne voir que la quantité de RAM qui lui est alloué (via top ou htop) idem pour l'espace disque avec df ce qui améliore l'isolation.

L'installation d'un container LXC se fait à partir de templates que l'on peut télécharger chez Proxmox et il est possible de choisir si on veut le faire fonctionner en mode unprivileged ou pas, pour plus de sécurité. Je n'utilise pas de containers LXC, je privilégie KVM pour plus de souplesse. En effet avec LXC il n'y a pas de migration de stockage possible et il n'est pas possible d'activer ou désactiver le mode unprivileged, il faut recréer le container. Cette implémentation semble donc un peu moins mure que celle de KVM.

Stockage, snapshots, backups

Le support des snapshots dépend du backend de stockage. Par défaut c'est un stockage local LVM-thin et ils sont supportés. Idem sur du stockage local qcow2. Les snapshots se font et se suppriment à chaud, rien à dire là dessus à part que ça marche bien. En revanche pour les backups c'est une autre histoire. Proxmox dispose d'une planificateur de sauvegardes qui non seulement ne supporte que du full, mais en plus ne permet pas de définir une durée de rétention. C'est extrêmement basique, limite pas utilisable en l'état, je passe par du backuppc.

Pour revenir sur les backend de stockage (dont la liste est disponible ici) je ne suis pas parvenu à faire fonctionner Zfs over iScsi, il semble que cela nécessite une connexion SSH avec le NAS, un choix de conception étrange. Donc je me contente du local (LVM-thin) et d'un datastore NFS.

Il faut noter que l'on peut uploader des iso directement depuis le web-ui pour les mettre dans un datastore, et c'est super.

Conclusion

Proxmox constitue une bonne alternative à ESXi pour un labo @home ou pour une infra de virtualisation maitrisée de A à Z. Espérons que le produit continuera à mûrir sur les containers et la partie sauvegarde, en tous cas merci!

Cherche alternative à backuppc

Rédigé par uTux 5 commentaires

J'adore Backuppc. Les sauvegardes passent par SSH, pas d'agent à installer, interface et fonctionnement simples. Mais bon sang c'est une plaie à installer, surtout quand on sort de Debian qui nous facilite la vie.

Donc je cherche une alternative à Backuppc:

  • Webui
  • Pas d'agent à installer sur les serveurs
  • Moderne

J'ai acheté un NUC NUC6CAYH

Rédigé par uTux 8 commentaires

Un seul serveur n'était pas suffisant pour moi, j'en ai donc acheté un deuxième. J'ai choisi un NUC6CAYH à 122€. Pour ce tarif on a droit à un mini-PC équipé d'un Intel Celeron J3455 (4@1,5GHz) sans RAM ni disque dur.

NUC

J'ai ajouté 8GB de RAM (Kingston KVR16LS11/8 pour 72€) et un disque dur 2,5" de 500GB que je stockais dans un placard. A propos de la RAM, attention car le NUC ne supporte que 8GB maximum et il faut respecter la QVL sous peine d'avoir un warning impossible à désactiver à chaque boot.

Matériel

Comme indiqué précédemment, ce NUC vient avec un Intel Celeron J3455, avec 4 vrais coeurs à 1,5GHz et un turbo boost à 2,3GHz. Le tout contenu dans un TDP de 10W, gravé en 14nm et avec les instructions de virtualisation et quelques features telles que AES-NI. Pour ce prix, et pour un usage modéré, c'est très intéressant. L'ensemble n'est pas fanless, mais grandement silencieux à l'usage.

NUC front

Peut-on se risquer à parler d'un Raspberry Pi killer? Certainement pas, étant donné la gamme de prix et de matériel complètement différents. Mais il faut constater qu'un usage serveur @home est bien plus envisageable avec ce NUC qu'avec une framboise.

NUC rear

Le boîtier peut s'ouvrir par le dessus ou par le dessous, en retirant 4 grosses vis très accessibles, excellent point :) Par le dessous on accède à la cage du disque dur (2,5") ainsi qu'aux 2 slots de RAM

Il faut aussi noter qu'un kit de fixation vertical est fourni, par exemple pour fixer le NUC derrière un écran. Autre chose, ce mini-PC est assez lourd, vu ses dimensions je m'attendais à quelque chose de plus léger, mais ce n'est pas bien grave.

Système d'exploitation

S'agissant d'une plateforme x86_64 avec support uefi et legacy-bios, on peut se faire plaisir. J'ai pour le moment testé 3 systèmes d'exploitation, orientés virtualisation puisque c'est l'usage que je compte faire de ce NUC.

Système d'exploitation
Supporté
Notes
XenServer 7.4
Oui Le support d'installation USB boote correctement mais il faut utiliser un dépôt HTTP. Cela peut être fait assez facilement en décompressant l'ISO sur un autre poste puis en lançant un petit serveur http avec python.
VMware ESXi 6.5
Non Interface réseau non supportée. Il existe certaines astuces pour se construire son propre medium d'installation avec le bon pilote, mais n'étant de toutes manières pas fan de la console HTML5 je ne suis pas allé plus loin.
Proxmox VE 5.1
Oui Parfaitement fonctionnel.

Rien à signer du côté des performances, ni rapide ni lent pour de la virtualisation, surtout avec un stockage sur disque mécanique. Idéal pour un petit labo ou serveur à la maison avec des VM Linux pouvant se contenter de peu de RAM. Je créé autant que possible mes VM avec une allocation dynamique 128/256MB et un stockage 30GB, ce qui permet d'en faire tourner pas mal simultanément.

Conclusion

Pour le moment je suis plutôt satisfait de ce NUC, même si je regrette la limitation à 8GB de RAM. Il offre un bon rapport qualité/prix pour un serveur @home et le Celeron J3455 se comporte plutôt bien avec des containers et de la virtualisation. Ce petit serveur Proxmox VE va se révéler très utile pour compléter mon NAS sous FreeNAS.

EDIT 01/05/2018: Je rencontre des problèmes avec ce NUC. J'ai défini le boot en "legacy" (non uefi) sur le disque, mais il ne détecte pas d'OS au démarrage et je suis obligé, à chaque fois, de brancher un clavier et utilise le menu pour sélectionner mon disque. Ensuite je rencontre des freezes à peu près chaque semaine, c'est très chiant. Je viens de faire une mise à jour du Bios, on va voir si cela résout les problèmes.

EDIT 29/07/2018: Je ne rencontre plus de freezes ni de problèmes de boot depuis que le bios a été mis à jour :)

Docker swarm, publish et scaleway

Rédigé par uTux Aucun commentaire

On dirait le titre d'un WTC mais ce n'est pas le cas, c'est plutôt un bug à la con qui m'a bloqué toute une soirée.

Je fais tourner mon blog et d'autres sites chez Scaleway, sur un VC1S avec Docker (debian 9 + installation custom). Je fais au plus simple avec docker-compose qui jusque là était satisfaisant pour mes besoins. Mais depuis quelques temps je songe à passer à la vitesse supérieure avec swarm, qui me permettra d'ajouter d'autres nodes et former un vrai cluster.

Après avoir mené une phase de tests en VM, j'ai décidé de me lancer et migrer sous swarm. Mais je me suis confronté à un bug énervant, impossible de publier des ports, par exemple:

$ docker network create -d overlay net-web
t1q2kzso3a5fnlkd0s8tvywid

$ docker service create --network net-web --publish 80:80 nginx
xl35ov6bkehabkx4547omrodj
overall progress: 1 out of 1 tasks 
1/1: running   [==================================================>] 
verify: Service converged

$ telnet 127.0.0.1 80
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

Connexion refusée, le port n'est donc pas publié :/

Cela m'a rendu fou car en machine virtuelle VirtualBox ou KVM ça fonctionne du premier coup, et la lecture de documentation ou divers blogs ont confirmé qu'il n'y avait pas plus de manipulations à faire, ça devrait juste marcher !

J'ai commencé à soupçonner Scaleway, et en faisant une recherche avec les bons mots clés je suis tombé sur ce blog et cette issue github.

Ben voilà, c'est bien un problème avec Scaleway, car leur architecture est un peu particulière. Les serveurs ou VM n'ont pas de grub, ce sont des nodes provisionnées à la volée en PXE, avec script de démarrage et kernel maison. Et il s'avère qu'avec ces deux bootscripts, ça ne marche pas:

  • x86_64 4.10.8 std #1
  • x86_64 4.10.8 docker #1

C'est con, car le premier est celui proposé par defaut, le second est celui vers lequel on s'oriente naturellement quand on veut faire fonctionner du Docker.

Voici donc le bon bootscript: x86_64 mainline 4.14.23 rev1.

Proposer un kernel custom est une sale habitude des hébergeurs, mais à 3€/mois le vps, peut-on vraiment se plaindre de Scaleway?

Fil RSS des articles de cette catégorie