Pour être honnête avec vous, j'ai regarder uniquement le chapitre sur la haute disponibilité (2ème chapitre). Il est complet.
hafedh n- Livres et vidéos
- Haute disponibilité sous Linux - De l'infrastructure à l'orchestration de services (Heartbeat, Docker, Ansible, Kubernetes...) (2e édition)
Haute disponibilité sous Linux De l'infrastructure à l'orchestration de services (Heartbeat, Docker, Ansible, Kubernetes...) (2e édition)
1 avis
Plus que jamais, dans un monde ultraconnecté où tant de choses dépendent de l’informatique et d’Internet, il est primordial de disposer d’environnements hautement disponibles, redondants et fiables. L’objectif de ce livre est de fournir aux ingénieurs système toutes les bases permettant de construire des environnements de Haute Disponibilité, tant du point de vue de l’infrastructure que du point de vue des services, basés sur le système d’exploitation Linux. Selon les principes et les outils...
Consulter des extraits du livre en ligne
Aperçu du livre papier
- Niveau Expert
- Nombre de pages 468 pages
- Parution novembre 2024
- Niveau Expert
- Parution novembre 2024
Plus que jamais, dans un monde ultraconnecté où tant de choses dépendent de l’informatique et d’Internet, il est primordial de disposer d’environnements hautement disponibles, redondants et fiables. L’objectif de ce livre est de fournir aux ingénieurs système toutes les bases permettant de construire des environnements de Haute Disponibilité, tant du point de vue de l’infrastructure que du point de vue des services, basés sur le système d’exploitation Linux.
Selon les principes et les outils DevOps, les auteurs présentent un exemple d’application fil rouge permettant d’étudier la façon de faire évoluer de concert une application et l’infrastructure sous-jacente, pour les rendre les plus fiables et les plus accessibles possibles, en s’appuyant sur les dernières technologies.
Tous les éléments de conception d’une plateforme et d’une application redondantes sont ainsi abordés.
Le lecteur peut ainsi appréhender concrètement la définition d’une application écrite en Java et tournant sous Tomcat, la mise en place d’une architecture matérielle fonctionnelle pour la supporter, la redondance des services système et réseau de base (RAID, agrégats réseau, DNS…), l’automatisation de la construction et du déploiement des images de l’application avec Docker et Ansible ou encore la haute disponibilité du réseau, des répartiteurs de charge et des adresses IP avec NGINX, HAProxy, le protocole VRRP et Quagga.
Dans la suite du livre, les auteurs décrivent le passage à l’orchestration avec un cluster Kubernetes, le déploiement d’un cluster avec une solution de stockage réseau redondant basée sur un cluster NFS et XFS, ainsi que la création de clusters de bases de données MariaDB et les affinités de sessions.
Chaque chapitre du livre est agrémenté d’exemples pratiques dont l’ensemble du code est proposé en téléchargement sur l’espace GitHub des auteurs
Selon les principes et les outils DevOps, les auteurs présentent un exemple d’application fil rouge permettant d’étudier la façon de faire évoluer de concert une application et l’infrastructure sous-jacente, pour les rendre les plus fiables et les plus accessibles possibles, en s’appuyant sur les dernières technologies.
Tous les éléments de conception d’une plateforme et d’une application redondantes sont ainsi abordés.
Le lecteur peut ainsi appréhender concrètement la définition d’une application écrite en Java et tournant sous Tomcat, la mise en place d’une architecture matérielle fonctionnelle pour la supporter, la redondance des services système et réseau de base (RAID, agrégats réseau, DNS…), l’automatisation de la construction et du déploiement des images de l’application avec Docker et Ansible ou encore la haute disponibilité du réseau, des répartiteurs de charge et des adresses IP avec NGINX, HAProxy, le protocole VRRP et Quagga.
Dans la suite du livre, les auteurs décrivent le passage à l’orchestration avec un cluster Kubernetes, le déploiement d’un cluster avec une solution de stockage réseau redondant basée sur un cluster NFS et XFS, ainsi que la création de clusters de bases de données MariaDB et les affinités de sessions.
Chaque chapitre du livre est agrémenté d’exemples pratiques dont l’ensemble du code est proposé en téléchargement sur l’espace GitHub des auteurs
Téléchargements
Avant-propos
- Introduction
- Contenu de ce livre
Application standalone
- L’application fil rouge
- 1. L’architecture de l’application web
- 2. Le code
- a. L’objet TodoItem
- b. Les noms des classes
- c. Le modèle MVC
- d. La gestion des fichiers téléchargés
- e. La configuration (Spring profile)
- 1. Installation de l’application
- a. Apache Tomcat
- b. MariaDB
- c. Construction de l’application
- 1. Partage des ressources
- 2. Configuration hardware non optimale
- 3. Tous ses œufs dans le même panier
Infrastructure et services de base
- Qu'est-ce que la haute disponibilité ?
- 1. Tolérance aux pannes
- 2. Taux de disponibilité
- 3. Éléments à prendre en compte
- 4. Rôles et responsabilités
- Infrastructure en haute disponibilité
- 1. Exemple d’architecture
- 2. Caractéristiques matérielles d’unserveur
- 3. Répartition des serveurs
- 4. Serveurs physiques ou virtuels
- 5. Tester sans serveurs
- 6. Besoins et plan d’adressage
- a. Serveurs
- b. Réseau
- c. Détails
- 1. Réseau VirtualBox
- 2. Réseau Hyper-V
- 3. UTM
- 4. Installation standard
- a. Image Ubuntu
- b. Disques
- c. Réseau Netplan
- d. Utilisateurs
- e. Installation d’Ansible
- 1. Vitesse et tolérance aux pannes
- 2. Considérations matérielles
- 3. Modes de fonctionnement
- 4. Configuration
- a. Configuration manuelle
- b. Utiliser Netplan
- c. État de l’agrégat
- 1. Comment Linux résout-il les adresses ?
- 2. DNS primaires et secondaires
- 3. Configuration
- a. DNS primaire
- b. DNS secondaire
- c. Test
- d. Resolver Systemd
- e. Automatisation
Les containers
- Cahier des charges
- Isolation et container
- 1. Principe
- 2. Container et machine virtuelle
- 3. Namespace
- 4. cgroup
- 5. Montage en union
- 6. Image applicative
- 7. Couches d’images
- 8. Docker
- 9. Le projet OCI
- Préparer l'environnement
- 1. Installer Docker
- 2. Installer un registry Docker
- a. Créer le stockage
- b. Obtenir une clé et un certificat
- c. Démarrer le registry
- d. Tester
- e. Automatiser
- 1. Adaptation du code
- 2. Dockerfiles
- a. Builder
- b. Tomcat
- c. Image applicative
- a. Image pour MariaDB
- b. Image h2
- 1. MariaDB
- a. Stockage
- b. Démarrage
- a. Emplacement des fichiers téléchargés
- b. Démarrage manuel
- a. Configuration YAML
- b. Déploiement
Exposition et répartition
- Exposer ses services
- 1. Problématique
- 2. Architecture de base
- Reverse proxy
- 1. Pourquoi utiliser un reverse proxy ?
- 2. Choix du reverse proxy
- 3. Installation
- 4. Configuration
- a. nginx.conf
- b. Certificats
- 5. Automatisation
- a. Configuration YAML
- b. Certificats
- c. Déploiement
- d. Test
- e. Reboot
- 1. Présentation
- 2. Objectifs
- 3. Architecture en haute disponibilité
- 1. Choix des produits
- 2. HAProxy
- a. Présentation
- b. Architecture
- c. Exemple
- a. Présentation de Keepalived
- b. Présentation de VRRP
- c. Exemple
- a. Installation des packages
- b. Paramétrer le noyau et les limites
- c. Configuration du pare-feu
- a. Installation et paramétrage des composants
- b. Vérification des arborescences
- c. Contrôle des services
- d. Configuration des VIP
- e. Test final
- 1. Implémentation
- 2. Installation et configuration
- 3. Test
- 4. Automatisation
Orchestration
- Introduction
- Abstractions d’orchestration
- 1. Abstraction du serveur
- 2. Abstraction de l’application
- 3. Abstraction du réseau
- 4. Abstraction du stockage
- 5. Rappel à la réalité
- Automatisation ou orchestration ?
- Bataille des orchestrateurs
- Mécanismes des environnements distribués
- 1. Consensus
- 2. Paxos
- 3. Raft
- Scheduler
- Premiers pas avec Kubernetes
- 1. Architecture
- 2. Version allégée : Minikube
- a. Installation
- b. Add-ons
- c. minikube dashboard
- d. minikube docker-env
- e. minikube logs
- f. minikube IP
- g. minikube service
- h. minikube update-context
- 1. kubectl
- 2. Appels à l’API
- 3. Configuration du client
- 4. Manipulation des ressources
- 5. Traces du pod
Déploiement avec Kubernetes
- Introduction
- Du pod aux déploiements
- 1. Pod
- a. Sondes et contrôle de santé
- b. Classes de qualité de service, limits etrequests
- 1. Pod
- 2. ReplicaSet
- 3. Déploiement
- 1. Service de type ClusterIP
- 2. Service de type NodePort
- 3. Endpoints
- 1. Monter des ConfigMaps et des secrets
- 2. Utilisation des ConfigMap et Secret dans les variables d’environnement
- 1. Le contrôleur des flux entrant (ingress controller)
- 2. Objet ingress
Stockage en haute disponibilité
- Disponibilité du stockage
- 1. Problématique
- 2. Cahier des charges
- 3. Solution
- 4. Architecture
- a. DRBD et cluster
- b. XFS, quotas et NFSv4
- 1. Principe
- 2. RAID matériel vs RAID logiciel
- 3. RAID-0, RAID-1 et RAID-5
- 4. Manipulation d’un RAID-5
- 1. Installation des packages
- 2. Configuration du réseau
- 3. Création du cluster
- 4. Vérification
- 5. Configuration du stockage
- a. LVM
- b. DRBD
- c. Agrandir le volume DRBD
- a. DRBD
- b. LVM
- c. Système de fichiers
- d. NFS
- e. Adresse IP
- 1. Ajout manuel
- 2. Test NFS
- 3. Split-brain
- 4. Automatisation
Mise en place d’un cluster Kubernetes
- Introduction
- Topologie
- 1. Composants de base
- 2. Choix d’un runtime
- 3. Répartition
- a. Quorum et performances
- b. Control-plane ou masters
- c. Workers ou nodes
- d. Positionnement
- e. Topologie pour eni-todo
- 1. Rappels
- 2. HAProxy
- 3. Préparation des serveurs
- a. Configuration système
- b. Configuration du pare-feu
- c. Automatisation
- 1. Images de Kubernetes
- 2. Premier master
- a. Bootstrap
- b. Flannel
- c. Lister les containers
- d. Vérifier ETCD
- a. Premier déploiement
- b. Première exposition
- c. Ajout des pods
- d. Résolution DNS interne
- a. Principe
- b. Installation
- c. Premier ingress
- d. Mode host network
- 1. Crash ou arrêt sale d’un node
- 2. Arrêt propre d’un node
- 3. Destruction d’un cluster
Intégration finale
- Introduction
- Volumes persistants
- 1. Cluster NFS-HA
- 2. Approvisionner des volumes persistants
- Registry Docker
- 1. Architecture
- 2. Génération d’un secret
- 3. Déploiement
- a. Demande de volume persistant
- b. Création d’un déploiement
- c. Création d’un service
- 4. Exposition
- a. Ajout d’une route ingress
- b. Exposition via HAProxy
- c. Test
- 5. Configuration des workers pour le registry
- 1. Problématique
- 2. Galera
- 3. Déploiement
- 4. Accès à db-todo
- 1. Adaptations
- 2. Construction de l’image
- 3. Création d’un compte de service
- 4. Déploiement
- a. Demande de volume persistant
- b. Création du service
- c. Déploiement
- a. Affinité et persistance
- b. Création d’une configuration ingress
- c. Configuration de HAProxy
Aller plus loin
- Introduction
- Plan de reprise d'activité
- 1. Quand le désastre arrive
- 2. Définition
- 3. Mesures
- 4. Pratiques DevOps
- Sauvegardes
- 1. Redondance vs sauvegarde
- 2. Que sauvegarder ?
- 3. GitOps
- 4. SaaS
- Sécurité
- 1. Container et root
- a. Exemple d’exploit
- b. Solutions
- c. Le contexte de sécurité (securityContext)
- 1. Container et root
- 2. Réseau Kubernetes
- 3. Utilisateurs et droits
- a. RBAC
- b. Utilisateurs
- 4. Mises à jour
- 5. Firewalls, proxies, routeurs, segmentation
- 6. Applications
- 1. Métriques
- 2. Traces
Charles SABOURDIN
Diplômé d’un BBA Essec, d’un Master sécurité (MSSIS) à l’ESIEA et de plusieurs certifications, dont la CKA (Certified Kubernetes Administrator), Charles Sabourdin réalise des missions de Stratégie, d’Urbanisme et d’Architecture des Systèmes d’Information ainsi que des missions très opérationnelles autour de Java, Linux, Ansible et Kubernetes, lui permettant de rester pragmatique dans la mise en œuvre de ses conseils. Grand utilisateur de logiciels libres, il partage depuis 20 ans son expérience en organisant ou participant à de nombreuses conférences et évènements (les Soirées ParisJug, JChateau, Devoxx France).
En savoir plusSébastien ROHAUT
Diplômé de l'ESGI, ingénieur DPE, après plusieurs années passées sur des missions d'ingénierie système, Sébastien ROHAUT a été responsable technique d'une équipe DevOps au sein d'un grand groupe français. Il est aujourd'hui responsable technique des migrations vers le Cloud (MttC Tech Lead) et reconnu « Security Champion » dans ce même groupe. Il a également enseigné pendant près de 11 ans à des classes préparatoires et d'ingénieurs et dispose d'une riche expérience technique et pédagogique pour le plus grand bénéfice des lecteurs de ses livres.
En savoir plus