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 🙂

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 !

Mirantis acquiert Docker Enterprise et Docker lève 35 millions dollars, mais le service restera une entreprise indépendante, d'après Mirantis

La journée de mercredi a été chargée de nouvelles pour Docker. L’entreprise, qui avait déjà recueilli plus de 272 millions de dollars avant les dernières nouvelles, a annoncé hier qu’elle a reçu un investissement de 35 millions de dollars des investisseurs existants. Docker a également obtenu un nouveau PDG, Scott Johnston, chef de la direction des produits, en remplacement de Rob Bearden. Mais un grand changement pour la firme a été annoncé un plus tôt dans la journée par Mirantis : l’acquisition des activités et de l’équipe de Docker Enterprise Technology par la société de services d’informatique cloud B2B.
L’ensemble des mouvements du mercredi sont pour le moins curieux, mais donne le coup d’envoi de la révolution du conteneur. En effet, le nouveau CEO de Docker a dit qu’il y voit une opportunité pour l’entreprise d’aider les développeurs à utiliser Docker, le moteur de conteneurisation populaire qui a eu du mal à trouver un modèle économique. Docker, est réputée pour ne pas avoir su tirer profit de sa technologie, jusqu’à ce que Mirantis, une importante société d’OpenStack, Kubernetes et de cloud computing, ait annoncé l’acquisition de la ligne de produits Docker Enterprise. Docker a déclaré qu’il continuera à se concentrer sur les outils qui feront progresser les flux de travail des développeurs et Mirantis maintiendra la marque Docker Enterprise indépendante.

Source : Mirantis acquiert Docker Enterprise et Docker lève 35 millions dollars, mais le service restera une entreprise indépendante, d’après Mirantis
Une page se tourne… L’histoire des conteneurs va continuer mais de mon point de vue cela signe la mort de docker, moribon depuis déjà un moment. Dommage.

Au revoir

Today I’m announcing my departure from Docker, the company I helped create ten years ago and have been building ever since. A founder’s departure is usually seen as a dramatic event. Sadly, I must report that reality is far less exciting in this case. I’ve had many roles at Docker over the years, and today I have a new, final one – as an active board member, a major shareholder and, I expect, a high maintenance Docker user. But I will no longer be part of day-to-day operations. Instead, after obsessing for so many years over my own ideas, I am rediscovering the joys of putting myself at the service of others – my friends, my family, and the brilliant entrepreneurs I’ve been lucky enough to advise and invest in over the years. Over the coming months I plan to use…

Source : Au revoir
Alors ça c’est surprenant. Je ne sais pas ce que cela va donner. C’est beau, à 34 ans il a le courage de quitter une compagnie qu’il a créé et qui dépasse le milliard de valorisation. Respect…

[MISC n°95] Références de l’article « Docker : les bons réflexes à adopter » | Le Blog MISC


Retrouvez ci-dessous la liste des références qui accompagnent l’article « Docker : les bons réflexes à adopter », publié dans MISC n°95 :
[HUB] https://hub.docker.com/
[DISTROLESS] https://github.com/GoogleCloudPlatform/distroless
[GO] https://hub.docker.com/_/golang/
[COMPOSE] https://github.com/docker/compose/releases
[ROOT] https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
[10] https://github.com/docker/docker-bench-security
[DBLOG] https://blog.docker.com/
Référence externe :
[Docker security] https://docs.docker.com/engine/security/security/
Source : https://www.miscmag.com/misc-n95-references-de-larticle-docker-les-bons-reflexes-a-adopter/
Merci ça peut toujours servir 🙂