Contactez-nous
Image de René Okouya

René Okouya

René est tourné vers les architectures haute disponibilité du SI et les plateformes Cloud. Domaines de prédilections : automatisation, monitoring, DevOps, Cloud. Son credo : Design, Operate, Optimize.

  • Ansible & KitchenCI
    Infrastructure Craftsmanship

    Ansible & KitchenCI : Infrastructure As Code guidée par les Tests Part II

    (String: <p>Tester son code Ansible et de manière plus générale le code<br>d’infrastructure (IaC), présente quelques avantages notamment<br>lorsqu’on est bien outillé. <a href="https://blog.wescale.fr/2018/07/26/ansible-kitchenci-infrastructure-as-code-oriente-par-les-tests-part-i">La première partie de cet article</a> en dévoile quelques usages et pose les bases de l’outillage nécessaire à cette pratique dans une architecture d’infrastructure à large échelle: du développement, où les tests peuvent être utilisés pour mieux comprendre l’impact des modifications et explorer des cas particuliers, à la documentation des cas critiques et leur comportement, en passant par la création d’une confiance partagée dans la base de code d’infrastructure. Le principe est le même pour d’autres outils qu’ansible, par exemple cet article &nbsp;à lire ou à relire <a href="https://blog.wescale.fr/2016/02/23/tests-dintegration-saltstack-avec-docker/">Tests d’intégration SaltStack avec docker</a>, de Séven Le Mesle notre CEO, traite des mêmes idées générales appliquées à SaltStack.</p>)
    Tester son code Ansible et de manière plus générale le code d’infrastructure (IaC), présente quelques avantages notamment lorsqu’on est bien outillé. La première partie de cet article en dévoile quelques usages et pose les bases de l’outillage nécessaire à cette pratique dans une architecture d’infrastructure à large échelle: du développement, où les tests peuvent être utilisés pour mieux comprendre l’impact des modifications et explorer des cas particuliers, à la documentation des cas critiques et leur comportement, en passant par la création d’une confiance partagée dans la base de code d’infrastructure. Le principe est le même pour d’autres outils qu’ansible, par exemple cet article à lire ou à relire Tests d’intégration SaltStack avec docker, de Séven Le Mesle notre CEO, traite des mêmes idées générales appliquées à SaltStack.

    Lire la suite

  • Ansible & KitchenCI : Infrastructure As Code guidée par les Tests
    Infrastructure Craftsmanship

    Ansible & KitchenCI : Infrastructure As Code guidée par les Tests - Part I

    (String: <p>En effet, il permet entre autres d'éliminer l’effet "snowflake server", vous savez, ce serveur présent dans le data center, assez unique en son genre et pas vraiment reproductible pour x raisons historiques que personne ne saurait vraiment expliquer. On parle alors "d’Infrastructure as Code" car le code Ansible permet d’envisager l’infrastructure comme une stack logicielle avec un cycle de vie propre et une évolution itérative.<br>Peut-on, par conséquent, appliquer certaines méthodes de l’usine logicielle au développement du code d’infrastructure Ansible ? C’est ce que nous verrons dans cette série d’article en deux parties.<br>Le focus du présent billet concerne la mise en place de tous les composants nécessaires à l’écriture, la validation et l'exécution des tests.</p>)

    Ansible est un outil qui a fait ses preuves dans la chaîne d’outillage DevOps, tant pour faire du "configuration management" que pour l’automatisation des installations des stacks serveurs, au même titre que Puppet, Chef, etc …​

    Lire la suite

  • Installer un cluster kubernetes avec ansible. Yakel est un Lab kubernetes pour Spinnaker.
    Cloud Native

    Spinnaker : Cluster Kubernetes Façonnable. Concevoir son Lab en 10min avec YaKEL

    (String: <figure class="kg-card kg-image-card"></figure> <p>&nbsp;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 &nbsp;à 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.&nbsp;</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.

    Lire la suite

  • Spinnaker : Cloud Native Continuous Delivery Pipeline
    Cloud Native

    Spinnaker : Cloud Native Continuous Delivery Pipeline

    (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.

    Lire la suite