Infrastructure as code

Archi & techno

Pulumi par la pratique : Kubernetes

Grâce au premier article de la série, le fonctionnement interne de Pulumi n'a plus de secret pour nous. Il est désormais temps de s’intéresser à son utilisation au travers d’un premier exemple concret. Nous allons découvrir comment Pulumi peut à la fois faciliter le déploiement d’un cluster Kubernetes mais aussi le déploiement des ressources à l’intérieur d’un cluster. Nous serons donc dans une approche plutôt orientée infrastructure pure.

Lire la suite
Archi & techno

Découvrir les Cloud Native Languages avec Pulumi

Le déploiement dans le cloud des multiples briques distribuées qui constituent une application cloud native est une tâche complexe. Les Cloud Native Languages dont fait partie Pulumi existent avant tout pour faciliter les déploiements dans le cloud. Cet article permet de découvrir de quelle manière Pulumi amène la force des langages de programmation dans le monde de l’Infrastructure as Code.

Lire la suite
Infrastructure et opérations

Terraform et comptes multiples dans AWS

Disclaimer : Cet article est assez technique et peut nécessiter des connaissances sur le fonctionnement de la gestion des accès et des droits dans AWS. Pour plus d’informations sur le sujet, la documentation AWS est très complète et permet d’avoir une connaissance minimale pour aborder cet article. Que ce soit pour des raisons de sécurité ou pour de la gestion administrative, il est possible dans AWS de créer plusieurs comptes AWS (visible dans AWS organization) reliés à un même compte maître. Un exemple simple, vous…

Lire la suite
Infrastructure et opérations

Créer des instances AWS qui ont accès à Internet sans IP publique avec Terraform

Il nous est souvent demandé : Comment est-ce que je fais pour créer des instances AWS qui ont accès à internet mais sans IP publique ? Tout d’abord, qu’est ce qu’une IP publique? Une IP publique est une adresse IP joignable sur internet. A contrario des adresses IP privées (décrites dans la RFC 1918) qui elles ne sont pas visibles de l’extérieur du réseau.   L’architecture Amazon à mettre en place       Tout d’abord nous avons besoin d’un VPC (Virtual Private Cloud) (1)…

Lire la suite
Archi & techno

Circuit breaker, un pattern pour fiabiliser vos systèmes distribués (ou microservices) : partie 4

Nous voilà à la fin de cette série d'articles (disponibles ici, ici et ici) sur le circuit breaker. Comment superviser le circuit breaker en production ? Notre application a passé tous les tests et il est temps de passer en production. Si l’on reste sur Hystrix, il existe beaucoup de métriques. La liste est disponible sur le site officiel. Une des difficultés d’une bonne supervision est de réussir à obtenir des tableaux de bord où, avec un simple coup d’oeil, on peut obtenir le maximum d’information.…

Lire la suite
Archi & techno

Circuit breaker, un pattern pour fiabiliser vos systèmes distribués (ou microservices) : partie 3

Maintenant que nous avons vu la théorie sur les précédents articles disponibles ici et ici, penchons-nous sur la pratique. Comment l’implémenter ? Plusieurs solutions sont possibles pour l’implémenter. Par exemple en Java il existe des librairies qui le font pour nous comme : Spring Cloud Netflix Netflix Hystrix breakr Focalisons-nous sur Netflix Hystrix.

Lire la suite
Archi & techno

Circuit breaker, un pattern pour fiabiliser vos systèmes distribués (ou microservices) : partie 2

Lors de l'article précédent, nous avons vu quelques solutions possibles pour résoudre la gestion des dépendances (externe ou interne) qui peuvent (et le seront tôt ou tard) défaillantes lors de l’exécution de notre application. Regardons d'un peu plus près le design pattern circuit breaker. Une solution possible : le design pattern circuit breaker ? Le circuit breaker permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l'échec. Pour cela, en fonction d’un certain nombre de critères d’erreur…

Lire la suite
Archi & techno

Circuit breaker, un pattern pour fiabiliser vos systèmes distribués (ou microservices) : partie 1

L'évolution des besoins (réductions des coûts et du time to market, concept d'ATAWAD (AnyTime, AnyWhere, AnyDevice)...) a mis en avant certaines architectures (architecture  applicative cloud ready, architecture microservices, architecture distribuée…). Cela a engendré de nouvelles problématiques, en particulier l’augmentation du nombre de dépendances et donc potentiellement soumise au réseau. C’est à ce moment qu'apparaissent à nouveau les “Illusions de l'informatique distribuée” : Le réseau est fiable. Le temps de latence est nul. La bande passante est infinie. Le réseau est sûr. La topologie du réseau…

Lire la suite