Menu

Gestion de la configuration dans les pratiques DevOps

  • Principal
  • Autre
  • Gestion de la configuration dans les pratiques DevOps

configuration management devops practices

Essayez Notre Instrument Pour Éliminer Les Problèmes

Qu'est-ce que la gestion de la configuration dans les pratiques DevOps?

Concept de Test continu dans DevOps a été expliqué en détail dans notre précédent tutoriel.

Le point fort de la gestion de la configuration dans DevOps est de fournir,

  1. Infrastructure en tant que code
  2. Configuration sous forme de code

Doit lire => Série de didacticiels DevOps exclusifs

webservices en java interview questions et réponses

Gestion de la configuration dans les pratiques DevOps

Il existe de nombreux avantages de «Infrastructure as a code» et «Configuration as a code» dans la pratique DevOps.

    • Les configurations sont contrôlées par version
    • Automatisé et standardisé
    • Supprime la dépendance
    • Configurations infra sans erreur
    • Renforce la collaboration entre l'équipe des opérations et du développement
    • Correction de la dérive de configuration
    • Traiter l'infrastructure comme une ressource flexible
    • Mise à l'échelle automatisée de l'infrastructure
    • Maintenir la cohérence dans les configurations

VIDEO Partie 4 Bloc 1: Gestion de la configuration- 23 minutes 7 secondes

Transcription:

Dans cette partie, nous allons découvrir Gestion de la configuration, gestion des versions et surveillance des performances des applications dans DevOps.

Ici, dans le bloc 1, nous allons nous concentrer sur la gestion de la configuration et comprendre ce qu'est la gestion de la configuration et en quoi est-elle différente dans DevOps et les méthodes traditionnelles.

Pour commencer, laissez-nous savoir Qu'est-ce que la gestion de la configuration?

La gestion de la configuration, comme son nom l'explique, n'est rien d'autre que la gestion de toutes les configurations des environnements sur lesquels l'application logicielle héberge.

Comme nous le savons, nous avons différents environnements tout au long du SDLC dans DevOps, à commencer par les tests unitaires, les tests d'intégration, les tests système, les tests d'acceptation et les tests utilisateur final.

Et j’ai également expliqué dans mes tutoriels précédents que l’environnement mis en place pour ces tests deviendrait progressivement plus complexe au fur et à mesure qu’il évoluait vers un environnement de pré-production et de production.

Donc, fondamentalement, la gestion de la configuration est le processus automatisé pour gérer toutes les configurations de chacun de ces environnements.

Alors, quelle est la différence entre la gestion de la configuration traditionnelle et la gestion de la configuration DevOps?

Dans nos méthodes traditionnelles de gestion de la configuration, l'équipe avait l'habitude de gérer ces configurations d'environnements divers via une documentation formelle dans laquelle chacune des configurations était enregistrée dans les documents et l'équipe de configuration ou le gestionnaire utilisé pour gérer le contrôle de version de ces documents.

Et au fur et à mesure de ses évolutions, il prendrait également la responsabilité de mettre en place l'environnement et de gérer les configurations manuellement

Désormais, dans DevOps, généralement, tous ces processus de gestion de la configuration sont plutôt bien automatisés et les configurations sont encapsulées sous forme de code ou de scripts et contrôlées via l'outil de contrôle de version.

Dans ce contexte, nous pouvons appeler que l'équipe des opérations est intégrée au développement dans la gestion des environnements via l'outil de contrôle de version unique.

Ainsi, le point fort de la gestion de la configuration dans DevOps est de fournir,

      1. Infrastructure en tant que code
      2. Configuration sous forme de code

Que signifie réellement «Infrastructure en tant que code»? Il définit l'ensemble de la définition de l'environnement sous forme de code ou de script au lieu d'enregistrer dans un document formel.

Alors que comprend la définition de l'environnement? La définition de l'environnement comprend généralement la mise en place de serveurs, la configuration des réseaux et la mise en place d'autres ressources informatiques, qui font partie de l'infrastructure informatique mise en place. Ainsi, tous ces détails seraient écrits sous forme de fichier ou sous forme de code et archivés dans l'outil de contrôle de version.

Ce script ou code, qui est archivé dans le contrôle de version, deviendrait la source unique de définition de l'environnement ou même de mise à jour de ces environnements.

Juste pour donner un simple Exemple , si nous devons ajouter un serveur à l'environnement spécifique, tout ce que nous ferions est de mettre à jour ces informations dans les scripts d'environnement et d'exécuter le pipeline de livraison, au lieu de lancer manuellement un nouvel environnement avec le serveur ajouté ou de rechercher l'aide des administrateurs système pour ce faire.

Donc, la beauté ici est que le développeur ou le testeur n'a pas besoin d'être un expert en administration système pour configurer ses serveurs pour l'activité de développement ou de test.

Ainsi, l'infrastructure mise en place dans DevOps sera complètement automatisée et suivra essentiellement le script qui est enregistré pour le contrôle de version à partir de l'installation des serveurs, de leur configuration, de l'installation du système d'exploitation, jusqu'à ce que les canaux de communication de ces instances soient établis avec le déploiement. Logiciel.

Quelle est la configuration sous forme de code?

La configuration en tant que code n'est rien d'autre que la définition de toutes les configurations des serveurs ou de toute autre ressource sous forme de code ou de script et leur vérification dans le contrôle de version.

Ces scripts de configuration qui sont archivés dans le contrôle de version sont exécutés dans le cadre du pipeline de déploiement afin de configurer l'infrastructure et ses configurations de manière automatisée.

Eh bien, la définition des configurations comprend des paramètres qui définissent les paramètres recommandés pour que le logiciel s'exécute correctement. Ou un ensemble de commandes à exécuter initialement pour configurer l'application logicielle. Ou même il peut s'agir de configurations de chacun des composants du logiciel à définir, ou de rôles d'utilisateurs spécifiques, de privilèges d'utilisateurs, etc.,

Simple Exemple serait de définir les bascules de fonctionnalité, où les valeurs par défaut sont définies dans le cadre du paramètre de configuration.

Ajouter un autre port à un pare-feu en serait une autre Exemple , qui peuvent être mis à jour dans le script et ultérieurement, ces scripts sont exécutés dans le cadre du pipeline de livraison.

Plusieurs outils sont disponibles pour réaliser l'automatisation des infrastructures sur le marché. Peu d'entre eux sont Chef, Puppet, Terraform, etc., Chef et Puppet sont des outils de gestion de configuration basés sur Ruby, alors que Terraform est un outil de provisioning.

De plus, ces jours-ci, comme presque toutes les applications seront hébergées sur le cloud, AWS, elles fournissent elles-mêmes des RESTAPI, qui peuvent être exploités à cette fin.

J'ai une liste énorme d'avantages de la gestion de la configuration dans DevOps, plutôt que de définir l'infrastructure et les configurations sous forme de code.

Passons en revue un par un.

Toutes les configurations et tous les détails de l'infrastructure sont contrôlés par version, ce qui est un gros avantage dans la mise en œuvre DevOps.

#1) Cela aide l'équipe à gérer les modifications des serveurs et de la configuration de manière automatisée et aide à déboguer rapidement si quelque chose échoue, dans un court laps de temps et permet également de revenir rapidement à la version précédente, sans provoquer d'interruptions pour les clients.

#deux) Étant donné que ces scripts sont situés sur le serveur central et que tout le monde dans l'équipe sait ce qu'il y a dans chacun de ces scripts et quelles sont les modifications apportées à chacune de ces versions. Cela permet également à l'équipe de revenir à l'ancienne version en cas de problème dans les dernières versions.

Imaginez, en cas de panne du serveur, combien de temps il aurait fallu pour le restaurer manuellement. Et maintenant, en définissant l'infrastructure comme un script et un contrôle de version, nous pouvons immédiatement restaurer en allant à la version antérieure.

# 3) La gestion des configurations sous forme de code empêche également quelqu'un d'apporter des modifications au système accidentellement et empêche tout dommage causé plus tard dans la production.

La gestion de la configuration étant totalement automatisée, les interventions manuelles pour la configuration ou la mise à jour sont complètement éliminées.

Imaginez l'impact sur le coût, la qualité et le temps quand auparavant, les gens dépendaient des ressources humaines pour effectuer ces configurations manuellement et lorsque certaines configurations sont manquées ou ne sont pas définies comme requis.

Ainsi, l'automatisation de la gestion de la configuration a non seulement permis de gagner du temps, mais également d'éliminer ces erreurs humaines et d'améliorer la qualité. En outre, la norme de codage a aidé l'équipe à suivre la norme spécifiée en matière de codage et d'automatisation au lieu de suivre le fantasme de chaque personne qui rédige le guide de configuration.

Comme indiqué précédemment, les configurations livrées sous forme de code ont supprimé la dépendance à une seule personne ou à une équipe appelée config manager ou config team. L'équipe de développement n'a pas besoin d'attendre que l'équipe de configuration vienne résoudre tout problème d'infra ou de configuration.

Ou même pour la mise en place des infra et des configurations, qui sont entièrement automatisées et contrôlées par version. Ainsi, n'importe qui dans l'équipe, qu'il s'agisse d'un développeur ou d'un testeur, peut faire tourner un serveur et effectuer les configurations à des fins de développement et de test. Par conséquent, la configuration du serveur et des configurations est devenue indépendante de la personne.

Cela garantit également que les mêmes serveurs ne sont pas utilisés à la fois par les équipes de développement et d'assurance qualité pour leurs activités, ce qui était généralement le cas auparavant.

L’infrastructure et les configurations définies comme un code commun ainsi que l’automatisation et le contrôle de version standardisent tous les environnements et les configurations. Ainsi, cela facilite non seulement la tâche de débogage pour les développeurs, mais élimine également les erreurs humaines entraînant des configurations infra sans erreur, sinon ce qui causerait d'énormes dommages, s'il n'est pas détecté tôt.

Ici, nous pouvons clairement voir la collaboration claire entre le Dev et l'Ops, où les deux s'appuient sur une seule source pour effectuer la configuration de l'infra et les deux équipes sont activement impliquées dans l'automatisation et la mise en place de l'ensemble de la gestion de la configuration.

Cette collaboration pour atteindre un objectif commun renforce la collaboration entre les équipes, le développement et les opérations.

Correction de la dérive de configuration

Qu'est-ce que la dérive de configuration?

Les petites différences et incohérences entre les serveurs, qui se produisent parfois en raison de la mise à jour manuelle, qui s'accumule sur une période de temps, sont appelées dérive de configuration.

Ce n'est pas une bonne situation, car cette incohérence dans les serveurs laisse certains fichiers de programme comme manifest, playbook ne pas fonctionner de manière fiable sur tous les serveurs et conduit donc à un échec de l'automatisation. Donc, cela doit être évité pour que l'équipe utilise efficacement l'automatisation des configurations.

La gestion de l'infra et de la configuration sous forme de code et de contrôle de version a aidé l'équipe à éviter ou à corriger tout type de dérive de configuration entre divers environnements ou entre les configurations de développement et de production en maintenant systématiquement les configurations sur tous les serveurs.

Ainsi, une équipe peut être mieux assurée d'avoir des configurations de configuration similaires sur le développement mis en place comme en production. Cela les aide également à simuler les problèmes de production sur l'environnement de développement.

Ainsi, cela permet d'éviter tout type de changement inattendu que l'un des membres de l'équipe pourrait essayer de faire sur l'infra, ce qui pourrait interrompre la configuration et également obliger l'équipe à ne faire aucune modification à la configuration à moins qu'elle ne soit connectée en tant que un code vers le référentiel.

Fournir une infrastructure et sa configuration sous forme de code a permis à l'équipe de la gérer comme une ressource flexible pour répondre aux besoins commerciaux dynamiques du client.

C'est une sorte de plug and play maintenant. Une équipe peut spécifiquement accéder au serveur ou au réseau particulier et y apporter les modifications. Il peut s'agir simplement de mettre à jour le serveur de provisioning ou d'ajouter ou de modifier le stockage dans un réseau particulier, ou même de mettre à jour le système d'exploitation, et tout peut être mis à jour indépendamment en tant que ressource flexible.

Auparavant, pour changer un paramètre de configuration, cela prenait beaucoup de temps, en particulier lorsqu'il était nécessaire de mettre à jour tous les serveurs, mais maintenant c'est juste une seule fois. Mettez à jour le script et téléchargez-le dans l'outil de contrôle de version et tout est terminé.

Il y a une certaine flexibilité pour supprimer complètement l'infrastructure existante et en créer une autre. Ainsi, la gestion de l'infrastructure et des configurations est devenue assez facile maintenant. Eh bien, les solutions basées sur le cloud ont permis à l'infrastructure de s'étendre automatiquement en ajoutant les ressources informatiques ou de stockage supplémentaires selon les besoins et en diminuant leur capacité lorsqu'elles ne sont pas nécessaires.

Cela a permis l'optimisation de l'utilisation des ressources en fonction de la demande. Si nous voulons étendre l'infrastructure en augmentant la taille de la machine, nous pouvons le faire immédiatement. De même, si nous voulons évoluer ou ajouter une autre configuration, ou ajouter plus de frontaux, nous pouvons simplement le faire en quelques secondes en le mettant simplement à jour dans le code et en exécutant le pipeline automatisé.

Dernière, mais non des moindres, l'infrastructure, délivrée sous forme de code dans un environnement contrôlé, contribue à maintenir la cohérence des environnements dans diverses configurations. Cela aide également à déboguer le problème. Ce point que j’ai abordé plus tôt aussi dans une certaine mesure en parlant de la dérive de configuration.

C’est tout et ceci complète notre exposé sur la gestion de la configuration dans DevOps, sur ce qu’est l’infrastructure et les configurations en tant que code et quels sont ses avantages.

Dans notre prochain tutoriel, nous discuterons les aspects Release Management dans DevOps.

Tutoriel PREV | Tutoriel SUIVANT

lecture recommandée

^