Spinnaker : Cluster Kubernetes Façonnable. Concevoir son Lab en 10min avec YaKEL
(String: <figure class="kg-card kg-image-card"></figure>
<p> Le focus du présent billet concerne l’installation du cluster. Kubernetes sera notre terrain de jeu, et afin de partir du même pied, je vous propose "YaKEL". <a href="https://github.com/jamroks/yakel">YaKEL</a> (Yet Another Kubernetes Environment Lab) est un projet à base de playbook Ansible léger pour l’installation rapide (moins de 10 minutes) d’un cluster Kubernetes de 3 noeuds pouvant tenir sur un laptop, que j’ai réalisé pour mes propres besoins d’expérimentation. </p>)
Dans un précédent article "Spinnaker : Cloud native continuous delivery pipeline" j’avais présenté une vue d’ensemble du déploiement continu dans le cloud selon Spinnaker. Nous allons maintenant passer à la mise en pratique dans une série de billets qui nous mèneront de l’installation en local de Spinnaker, jusqu’au déploiement multi-cloud.
RETEX : comment transformer un monolithe en NodeJS en une application résiliente et scalable ?
(String: <p> </p>)
Il y a quelques temps, on m’a demandé de mettre en production une application retrouvée “dans les cartons” qui correspondait à un besoin de WeScale. L’objectif étant de faire un “quick win” : de mettre en production avec un coût bas, un SLA non critique et surtout peu d’opérations de production. Quelques changements fonctionnels mineurs étaient également nécessaires
Kubernetes devient incontournable en terme d'orchestration de conteneurs. On s'intéresse donc aujourd’hui au déploiement d’applications dans Kubernetes, et plus particulièrement comment simplifier cette tâche grâce à Helm.
Parmi les solutions de SDN existantes on trouve Flannel, de CoreOS. Cette solution est couramment utilisée de concert avec Kubernetes. Dans cet article, nous allons mettre en place un POC pour voir comment Flannel fonctionne et mettre en perspective ce fonctionnement avec la théorie relative au SDN et aux réseaux d’overlay.
Les réseaux d'overlay : principes et fonctionnement
(String: <p>Nous verrons dans cet article que le panorama des solutions permettant le cloisonnement réseau a bien changé et permet de répondre aux besoins d’une <a href="https://www.wescale.fr/cloud-native" rel="noopener">infrastructure Cloud</a>.</p>)
Toute infrastructure hébergeant plusieurs projets ou clients nécessite une isolation réseau réelle. Avant la démocratisation des outils, fournisseurs et méthodes liées au cloud, la méthode couramment utilisée pour proposer cette isolation en datacenter était l’utilisation des VLANs (norme 802.1Q) qui étaient configurés directement sur les équipements réseau de l’infrastructure.
Tutoriel : architecture serverless avec AWS Lambda et Terraform
(String: <h2 id="objectifs">Objectifs</h2>
<p>Il y a des modes en informatique et l’utilisation de “BuzzWord” est fréquente. Dans les derniers de ceux-ci, un terme revient souvent : “serverless”. Celui-ci n’est pas juste un concept abstrait ou une idée. En effet, certains fournisseurs de Cloud l’ont développé il y a quelques années. Qu’est-ce que c’est ? Est-ce une bonne chose ? Dois-je l’utiliser dans mon infrastructure ?</p>)
Voici comment déployer une architecture serverless avec AWS Lambda et Terraform.
Simuler une installation d'un cluster OpenShift prod-ready en 30 minutes
(String: <p>Si vous désirez utiliser OpenShift dans un cadre de production, son installation nécessite une réflexion pointue sur plusieurs sujets notamment : implémentation (on premise versus cloud), stockage, réseau, ressources nécessaires, authentification et autorisation, monitoring…<br>Cette installation avancée utilise les playbooks ansible que vous trouverez dans <a href="https://github.com/openshift/openshift-ansible">Github</a>.<br>L’objectif de cet article est de simuler une installation avancée dans une infrastructure de production “on premise” ou en cloud privé de production.</p>)
Dans une précédente suite d’articles OpenShift (OpenShift 3 le B.A BA, Construire votre application et Déployer votre application), j’ai préconisé la méthode d’installation rapide avec minishift pour pouvoir se lancer rapidement dans son utilisation et tester l’ensemble des fonctionnalités que j’ai décrites.
(String: <p>Spinnaker est une plateforme complète de “continuous delivery” multicloud développée par Netflix qui part à l’abordage des problématiques de stabilité, de multicloud, de vélocité, d’immutabilité, de rollback, de stratégie de déploiement et de multiparadigme. En bref, une consolidation d’un certain nombre de bonnes pratiques, de l’intégration continue (CI) jusqu’au déploiement continu (CD). En bonus, Spinnaker élimine le “configuration drift” afin d’éviter que la configuration ne parte à la dérive.</p>)
Lorsque le vent du cloud souffle sur l’équipage DevOps, le jeu consiste à l’utiliser au mieux. Pour en tirer le meilleur profit, nous avons la solution : “SPINNAKER”. La migration et notamment le déploiement d’applications vers le cloud peut s’avérer être une tâche complexe et nécessite une excellente communication au sein des équipes impliquées.