Étiquette : hébergement

Publié le

Articles non publiés 2018 – 2020

Durant la période 2018 – 2020 je me suis mis à délaisser la publications d’articles sur ce site. Pour autant je n’avais pas arrêté de regarder la presse et mettre de côté les articles intéressants.

Honte à moi, pendant cette période j’ai utilisé google keep pour conserver ces articles. Alors voilà, à ce jour j’ai un élan de remise dans le droit chemin et j’ai supprimé google keep. Néanmoins, comme prévu notre ami google n’a pas vraiment fourni de moyen d’export simple et efficace. Par exemple de quoi partager tout via mail ou autre.

Donc le mieux que j’ai pu faire c’est tout exporter dans un google document et reformater un peu le contenu pour pouvoir le mettre sur mon wiki. Pourquoi le wiki me direz vous ? Et bien parce que notre ami wordpress n’a pas supporté la création d’un article avec plusieurs centaines de liens…

En conclusion si vous voulez voir les articles que j’ai conservé pendant tout ce temps vous pouvez aller sur le lien suivant : https://wiki.montaigu.io/doku.php?id=article:articles_non_publies_2018-2020

Bonne chance.

Publié le

Second retour sur la nouvelle infra alban.montaigu.io

Cet aticle fait suite au Premiers retours sur la nouvelle infra alban.montaigu.io.

Pour ce second retour je serai sans doute assez succinct sur certains aspects. Pour autant il est assez significatif: j’ai tout recommencé ! Alors que j’expliquais dans le précédent article que j’avais utilisé kubernetes, rancher, etc, le tout hébergé chez Scaleway, aujourd’hui je peux dire que j’ai tout supprimé 🙂

Finalement, je suis revenu sur une infra dans ce qu’il y a de plus classique. Même des choses que j’ai faite il y a 10 ou 15 ans…

  • Une simple VM, General purpose XS (pour avoir du SLA 99,99 et assez de CPU/RAM) chez scaleway.
  • Un operating system Debian 10 (retour aux racines…)
  • Une configuration à l’ancienne faite en mode shell et par l’usage de tutoriels triés sur le volet
  • Des outils aidant à l’administration en mode user friendly, le principal étant ISPConfig (Merci Olivier R. pour le conseil :))
  • Un bon vieux apache 2 (peut être moins performant dans certains cas, mais tellement mieux intégré partout avec tellement d’options pour faciliter la vie et surtout open)
  • Des déploiements de l’ensemble de mes sites sur la même machine et finalement front / middle / back sur la même VM.

C’est un gros revirement me direz vous. So why ? Pourquoi revenir à quelque chose que finalement je faisais déjà il y a 10 ans ? Eh bien les raisons sont multiples. Peut-être que c’est l’âge qui parle. Je me fais vieux. En veillissant j’ai le sentiment qu’on cherche de plus en plus la simplicité et l’efficacité.

Le fait est que pour l’infra basée sur Kubernetes, j’ai passé un certain temps (assez long, trop long) pour apprendre et surmonter toutes les problématiques juste pour redéployer mon blog. Avec parfois à la clé des choix cornéliens à faire sans parler de toutes les contraintes liées à l’architecture et son administration.

Le fait est que à chaque fois que je voulais ajouter un nouveau service ou avais une chose comme un upgrade à faire, je perdais des choses ou passait un temps bien trop long à traiter la chose / faire fonctionner. Parfois même en devant encore retoucher l’infra bas niveau voire en refaisant tout dans certains cas…

Le fait est que pour avoir un cluster kubernetes qui fonctionne avec des applications qui tournent sans se faire OOMKill je dois déployer des serveurs / noeuds supplémentaires qui me coutent cher (la mutualisation des ressources est bien plus délicate sur Kubernetes).

Alors oui, ou bout d’un moment, cela fatigue. Oui Kubernetes, Helm & co c’est hyper puissant. Oui j’ai réussi à faire des choses assez sexy. Mais voilà, à un moment, il faut en revenir au besoin : déployer un blog et quelques sites. Faire en sorte que ce soit simple que cela fonctionne efficacement et pour un cout modéré. L’état de l’art avec des déploiement n-tiers ? Pourquoi quand il s’agit d’avoir des sites à faible traffic sans SLA. L’état de l’art Kubernetes ? Pourquoi quand il s’agit de passer un minimum de temps d’administration et donc avoir une infra simple.

La conclusion s’impose alors d’elle même. Une VM à l’ancienne, un système entièrement configurable à un seul endroit avec des commandes simples connues depuis la nuit des temps. Pas de serveurs et de configuration dans tous les sens avec des 10aines d’outils et des commandes. Quand il s’agit de sauvegarder: snapshot & backup la VM. Quand il s’agit de restaurer, créer une vm depuis le snapshot & backup. Quand il s’agit de monitorer, utiliser des outils simples et connus depuis toujours. Pas d’orchestration complexe…

C’est simple, ça fonctionne, c’est à un seul endroit, c’est pas cher cela répond au besoin et c’est tout. Oui on peut faire plus à l’état de l’art technologique. Oui on peut faire des infra plus chiadées avec du n-tiers du cluster, de la réplication. Mais pourquoi faire quelque chose de si compliqué quand le service n’est pas critique ? Pourquoi introduire une complexité inutile ? Il y à un coût financier et humain à tout…

Finalemement je suis peut être juste trop vieux ou alors juste Kubernetes répond à des besoins de déploiement fréquents, de « workflows from dev to prod  » avec de la répétabilité et de l’automatisation à 100% à large échelle. Le tout quand on a une team conséquente avec des profils parfaitements formés / adaptés / nombreux.

Pour le reste, pour moi en tous cas, la mode « à l’ancienne » répond bien mieux au besoin. Finalement, pourquoi succomber à autre chose ? Bon ok je reste un peu geek, donc j’ai bien aimé découvrir et jouer. Mais voilà à un moment fini le jeu et le temps / les ressources sont comptées :).

Just Keep It simple, just KISS.

La suite au prochain épisode 🙂

Publié le

Premiers retours sur la nouvelle infra alban.montaigu.io

Comme j’ai un peu de temps ce soir, il est temps pour moi de considérer un petit feedback sur mes aventures autour de la mouture 2020 de l’architecture de mes services notamment ce blog personnel désormais sur https://alban.montaigu.io.

Le moins qu’on puisse dire c’est que l’aventure commence à être longue. Depuis déjà longtemps je sais que mon ancienne infra vivihome.net tournant sur rancher 1.x et de simple nodes scaleway avec un docker engine antédiluvien mérite d’être refaite. Le moins que l’on puisse dire d’ailleurs c’est que je manie l’euphémisme avec bonheur en disant cela comme ça. En vrai même wordpress commençait à me dire qu’il est temps de mettre à jour l’infra :).

Le plan de départ était donc de refaire quelque chose dans l’air du temps avec en plus un nouveau domaine. Comme j’étais déjà orienté docker sur l’ancienne infrastructure, la suite logique en cette époque de mai 2020 était bien entendu kubernetes.

Kubernetes, c’est une infra très complexe et un peu pénible à déployer / gérer. Donc scaleway (mon hébergeur), comme de nombreux autres, l’a bien compris et a décidé de proposer quelque chose à la mode : un service de kubernetes managé baptisé « kapsule ». La promesse : toute la puissance de kubernetes sans la complexité de sa gestion.

Je reviendrai peut être la dessus plus en détail plus tard (car ce n’est pas mon point de ce jour) mais en résumé kapsule, c’est sympa et ca marche pas mal. On a un cluster kubernetes rapidement sans se compliquer la vie. De même les indispensables (pour moi) sont aussi là et pas trop mal intégrés : le stockage bloc et le loadbalancer.

Maintenant j’en viens à l’essentiel. Alors cette expérience kubernetes ça donne quoi pour le néophyte que je suis ? Hey bien, heu, le moins qu’on puisse dire c’est que c’est mitigé.

Ce qui est sûr de mon point de vue très subjectif, c’est que la courbe d’apprentissage est assez raide et longue. On ne va pas se le cacher, il y a vraiment de nombreuses choses à apprendre et dans tous les domaines : réseau, stockage, traitement, termes et pratiques kubernetes… Pour une application qui fonctionne on doit maitriser une quantité énorme de paramètres…

Et bien que depuis quelques temps, la complexité commence à s’arranger (en vrai se dissimuler) grâce a helm et ses nombreux « packages » préparés à l’avance dans des catalogues, une application en production et la maintenir reste (de mon point de vue) un vrai challenge surtout pour le néophyte.

En vrai les fonctions et les possibilités sont infinies. Il faut l’admettre. On peut faire quasi tout ce que l’on veut et de manière automatisée. Ceci étant dit, lorsqu’on raisonne avec des besoins simples comme « déployer un wordpress » le chemin pour y arriver est loin d’être simple… Du moins quand on aime s ce que l’on fait et maitriser un minimum.

Des exemples en vrac passés sous silence sur de trop nombreux sites :

  • l’ip réelle du client de votre site sur votre wordpress (externalTrafficPolicy Cluster vs Local, L7 vs L3 balancer, la différences des noms d’options selon votre version d’ingress nginx, les incompatibilités de chacune des solutions avec votre install wordpress et les choix cornéliens que vous devriez faire)
  • La difficulté de gérer votre stockage bloc et faire en sorte qu’il soit conservé correctement lors de reboot / d’upgrade
  • La difficulté de corriger vos déploiements / pods lorsque tout se met a redémarrer / crasher dans tous les sens
  • L’impact parfois irrémédiable qu’un simple paramètre helm ou kubernetes manquant ou erroné peut
  • Le nombre de fois incalculable ou vous conclurez que la seule solution de corriger votre souci est de tout effacer et tout recommencer.
  • Le moment ou vous pensez que tout est en place, que vous voyez un upgrade à faire sur votre déploiement helm et que tout saute en essayant de l’appliquer
  • Les choses aussi bêtes que « comment redémarrer mon pod ? » qui trouve une réponse improbable comme « ca n’existe pas, il faut scale down / up » ou au mieux redémarrer votre déploiement.
  • La grande problématique des stack helm qui vous déploient par défaut des loadblancers à 10 euros le mois au lieu d’en mettre un seul et de compléter ses règles.

HOLD ON !

A cette heure du jour ou j’écris ces lignes, somme toute assez tardive, je me dis que je pourrais continuer encore longtemps la liste des problématiques rencontrées ayant mené à au moins 2 semaines de galères et de réinstallations. Néanmoins l’essentiel n’est pas là.

Ma pensée profonde est en fait plus métaphysique. Kubernetes et tout le reste. C’est puissant c’est indéniable. Néanmoins à ce jour je trouve que c’est surtout une extraordinaire usine à gaz. Il y a de quoi se planter mauvaisement à tous les endroits et ils sont nombreux…

Alors en allant toujours plus loin dans le domaine métaphysique, cela m’amène a me poser la question suivante : ai-je ce sentiment parce que je suis trop vieux ? Ai-je atteint la date de péremption ? Pourquoi est-ce que je ne peux m’empêcher de me dire qu’avec un serveur simple sans kubernetes j’aurai installé et déployé mon wordpress seulement en quelques heures et de manière bien mieux maitrisée ? Ou alors est-ce que dans le fond Kubernetes c’est beau mais surtout une usine à gaz…

Affaire à méditer pour moi, la suite dans le prochain épisode :).

Publié le

Adieu vivihome.net, hello alban.montaigu.io !

Après une longue période de vie il est temps pour moi de donner une retraite bien méritée à vivihome.net.

Ce domaine je l’ai pour héberger mes sites personnels quasiment depuis toujours. Je me demande s’il n’a pas atteint ou dépassé les 10 ans, voire 15 ans à vrai dire. Je n’irai pas jusqu’à dire que cela remonte à la préhistoire mais presque.

Il fait référence à des valeurs et des clin d’oeils de ma jeune époque qui n’ont plus vraiment de sens aujourd’hui. Maintenant je suis (plus) vieux alors il est temps de faire quelque chose de plus parlant et simple.

Sans être égo centré, puisque le contenu me concerne, autant faire un montaigu.io et quitte à être visible et entretenir mon identité sur le net autant faire un alban.montaigu.io.
C’est aussi l’occasion pour moi de renouveler totalement l’infrastructure hébergeant ce site, avec des technos dans l’air du temps comme kubernetes :). Il faut dire aussi que l’infra de vivihome.net date d’il y a au moins 5 ans et que je n’y ai pas trop touché depuis (honte à moi).

Après c’est la même histoire que tout le monde connait, le temps passe et la disponibilité fluctue surtout pour des tâches aussi chronophages qu’un renouvellement d’infra. Si j’ai le temps j’essayerai de compiler tout ça dans un petit guide (car le moins qu’on puisse dire c’est qu’il y a à raconter) mais sans doute pas aussi détaillé qu’à la grande époque.

Donc voilà, bye vivihome, hello alban.montaigu.io et hello new infra scaleway, kapsule (kubernetes), loabalancer, block storage, helm, rancher.

Et particulièrement par les temps qui courent aurevoir et prenez soin de vous !

Publié le

Online publie son système d'archivage cloud

C14 est conçu pour stocker longtemps d’énormes volumes de données, tels que vos archives numériques légales, la préservation du patrimoine numérique, stockage de logs informatiques, photos, vidéos, sauvegardes, PRA… Et pourquoi pas sauvegarder totalement un cluster Hadoop pour quelques euros ?

C14 offre le TCO le plus bas du marché ! Vous ne payez qu’à l’usage, en fonction du volume de données, avec un minimum de facturation de 1Go seulement.
Pas de frais caché, une tarification prévisible. Le bande passante et le transfert sont gratuits.

Source : https://online.net/fr/c14

Ahhhh enfin, ca manquait au catalogue les amis, merci d’avoir complété. Ca va m’éviter d’aller chez amazon et passer des heures a passer mes sauvegardes dessus !

C’est un bon complément à un service de type scaleway.