Dans des articles précédents, j’avais réalisé un focus sur Fission, une plateforme permettant d’initier des fonctions à courte durée de vie dans n’importe quel langage et permettant de les associer à des requêtes HTTP (ou à d’autres déclencheurs d’événements). Avec Fission on aborde donc le domaine du Serverless Computing, un modèle de conception cloud natif, basé sur une architecture ne nécessitant pas de gestion de serveurs pour créer et exécuter des applications.
Dans la lignée des services Cloud visant à faciliter le recours à des services innovants en limitant les investissements de capital, le serverless est un vrai choix stratégique, avec des enjeux liés à la stratégie fournisseur et au service rendu aux utilisateurs.
On peut donc déployer des fonctions instantanément avec une seule commande. Il n’y a pas de conteneurs à construire, ni de registres Docker à gérer …
Je pars donc d’un serveur à la demande sur la plateforme Equinix Metal comme base de départ :
Installation de Rancher RKE2 pour initier un cluster Kubernetes sur ce serveur. En rappel, RKE2, également connue sous le nom de RKE Government, est la distribution Kubernetes de nouvelle génération de Rancher.
Il s’agit d’une distribution Kubernetes entièrement conforme qui se concentre sur la sécurité et la conformité au sein du secteur du gouvernement fédéral américain.
et installation du client Kubectl pour interagir avec ce cluster en fonctionnement localement sur ce serveur :
Par la suite, j’installer Nginx en tant qu’Ingress Controller sur ce cluster :
ainsi que Cert-Manager chargé de la gestion des certificats X.509 pour un cluster Kubernetes :
Il est alors possible d’installer le serveur Rancher 2.6.X sur ce cluster pour pouvoir le manager plus simplement. Pour cela installation de Helm3 :
Le serveur Rancher est disponible via le domaine Wild Card défini avec l’installation du Chart :
avec des informations de base sur le cluster Kubernetes en exécution :
voire détaillée :
Activation du monitoring du cluster via Prometheus et Grafana dans le Marketplace fourni au sein du serveur Rancher :
Je peux donc passer à l’étape suivante correspondante à l’installation de Fission :
La plateforme Fission est disponible et le client Fission est téléchargé depuis son dépôt sur GitHub :
Lancement à ce niveau d’un container comme une fonction dans Fission :
Pour que ce container soit accessible depuis Nginx Ingress Controller, je crée la route correspondante :
Et effectivement, le container qui expose un site web de démo sur le port TCP 80 via Nginx et l’adresse IP publique du serveur physique, est accessible sur
http://136.144.48.141/website :
Autre démonstration via le sempiternel démonstrateur FC :
Naturellement, via Grafana et Prometheus je dispose des infos de monitoring sur l’ensemble de la plateforme installée ici :
Le tout pour une consommation plus que raisonnable sur ce serveur physique …
Il a donc été possible de tenter de mimer des plateformes comme Google Cloud Run via ces outils Open Source sur son propre serveur physique …
D’autres dispositifs d’observabilité sont possibles avec Fission comme Linkerd :
Selon Forrester, le pourcentage de développeurs déclarant que leur organisation utilise des conteneurs est passé de 33 % en 2020 à 42 % en 2021. Dans le même temps, l’utilisation du serverless est passée de 26 % en 2020 à 32 % en 2021.
Selon ses prévisions, en 2022, plus de la moitié des entreprises déclareront avoir adopté des développements « cloud-native ».
Mais pour Forrester, « plus important encore, les entreprises vont bien davantage pratiquer « replatforming » et « refactoring » pour fonder leurs stratégies sur le cloud-native plutôt que de le superposer à leurs plans existants ».
Mais cette utilisation du Serverless ne se fera probablement pas sans containers 😉 …
À suivre !
