Mejri Issam

Tester les manifestes Kubernetes pour se prévenir des erreurs de configuration avant de déployer sur un cluster de production est l’une des étapes cruciales après les tests applicatifs. Automatiser ces tests à travers un pipeline GitLab-CI et assurer un Continuous Delivery via Argo CD est le scénario parfait pour la mise en œuvre d’une démarche DevOps/GitOps. C’est ce que nous allons découvrir dans cet article.

Le DevOps est l’un des concepts d’agilité et d’automatisation les plus utilisés depuis maintenant quelques années et précisément depuis que Patrick Debois a introduit ce terme à l’occasion du DevopsDays à Gand en Belgique en 2009. Aujourd’hui, un autre concept fait son apparition, qui est en phase avec le DevOps : c’est le GitOps. Le GitOps est la continuité de la démarche DevOps, son point fort est d’assurer la fiabilité et la sécurité du Continuous Delivery en se focalisant sur le code de l’infrastructure et d’applications. Vous trouverez tous les détails de ce concept dans cet article avec un exemple mis en pratique vous permettant de vous convertir au GitOps sereinement.

La conteneurisation d’une application est aujourd’hui un standard dans le monde du développement, mais orchestrer des applications conteneurisées c’est encore mieux. Automatiser la construction de l’application ainsi que son déploiement est bénéfique pour l’accélération du cycle du développement logiciel. L’automatisation est réalisable par des pipelines de CI/CD et en reposant sur des plateformes de conteneurisation. Dans cet article, on démontrera étape par étape comment automatiser le build et le déploiement d’un exemple d’application Node.js en mettant en œuvre les outils : OpenShift, GitHub et Jenkins.

Livrer rapidement les applications et accélérer le cycle de développement logiciel est l’un des objectifs principaux de tout développeur qui souhaite se focaliser sur le développement et la conception de son code, sans avoir à se soucier des infrastructures sous-jacentes. Dans cet article, nous évoquons la plateforme Redhat OpenShift Container Platform, et nous détaillons comment déployer rapidement des applications conteneurisées de façon simple, rapide et automatisée.

Aujourd’hui, le terme DevOps est au cœur de la transformation digitale. En effet, lorsqu’on évoque l’agilité dans le cycle de vie de développement logiciel, on est amené à pratiquer des méthodologies permettant d’accélérer d’une part le processus de développement et de fiabiliser la production logicielle d’un autre côté. Parmi ces méthodologies (Scrum, Kanban…), le DevOps est certainement celle qui a été adopté par la plupart des entreprises ayant comme activité principale ou annexe, la digitalisation de leur système d’information pour faire face au défi que représente l’essor des technologies numériques. Dans cet article, nous ferons un premier tour d’horizon de la partie outillage du DevOps. Il existe une panoplie d’outils et il est impossible de les évoquer tous dans un seul article, car chaque outil nécessiterait un ouvrage à part entière.

La mise en place d'un processus d'intégration continue et de déploiement continu nécessite une réflexion sérieuse avant de la concrétiser dans la vraie vie d'une organisation. La diversité des méthodes agiles, la panoplie des outils DevOps disponible sur le marché et le choix de l'infrastructure sous-jacente pour créer vos projets nécessitent de prendre du recul avant de se lancer. Découvrez dans cet article comment créer un CI/CD.

Lorsqu’on supervise des services statiques, tel qu’un serveur apache ou un serveur de base de données, on se concentre sur le bon fonctionnement de ces derniers (réponse aux requêtes, état : démarré ou non...) et donc un outil de supervision est nécessaire pour évaluer le statut du service en question. Un outil comme Nagios est destiné à ce type de supervision. Mais si nos services sont susceptibles de disparaître à tout moment et sont remplacés par de nouvelles instances, comment pourra-t-on les superviser ? S’ils ne sont pas déployés sur leurs hôtes d’origine, comment peut-on les localiser dans ce cas ? Et si ces services sont sous forme de conteneurs, comment alors superviser les processus à l’intérieur de ces conteneurs ? Et enfin, si ces services sont déployés dans un orchestrateur à l’instar de Kubernetes, et donc sous forme de pod, comment superviser l’ensemble de ces pods repartis sur différents nœuds ? Dans cet article, nous répondons à toutes ces questions avec des cas pratiques. Mais voici déjà un indice concernant la réponse : Prometheus.

Dans cet article, on aura l'occasion de plonger en profondeur dans la configuration réseau des machines sous CentOS 7 / RHEL 7. Let's get started !

Préserver ses données à l'abri de toute menace ou perte est une priorité de chacun d'entre nous d'autant plus lorsqu'il s'agit de données critiques qui auront des conséquences néfastes si elles étaient altérées ou victimes d'une intrusion. En tant qu'administrateur système, vous êtes le premier responsable de tout incident de ce type.