Xylos brands

Prise en main d’Azure

Vous avez décidé d’utiliser un cloud public. Mais par où commencer exactement ? En fait, c’est très simple : il suffit de créer un compte d’essai, de vous connecter au portail Azure et de créer une machine virtuelle (VM). Et le tour est joué ! Vous avez envoyé votre première machine dans le cloud. Passionnant ! Mais que faire ensuite ?

Naturellement, vous souhaitez également tester les centaines de services différents d’Azure, comme les solutions IoT, travailler sans serveur avec Azure Functions ou utiliser un chatbot très tendance. Ou vous souhaitez peut-être créer votre propre application à l’aide de microservices dans des conteneurs Docker, gérés via le service Azure Kubernetes ?

1.Le cloud : avez-vous encore une vue d’ensemble ?

Tout ça semble très beau sur papier… Mais vous serez très vite confrontés aux mêmes questions que celles que vous vous posiez lors de l’installation de votre centre de données sur site : « Qu’en est-il de la connectivité de cette solution ? Mes dossiers sont-ils en sécurité ? Quel est le SLA de ce service ? Ai-je un plan de reprise après sinistre ? Comment mettre en œuvre quelque chose dans Azure ? » Azure offre des possibilités infinies. Impressionné par son ampleur, vous n’oserez peut-être pas poursuivre votre découverte avant d’obtenir une réponse claire à vos questions. Avez-vous encore une vue d’ensemble ?

Xylos a regroupé les questions les plus fréquemment posées par nos clients et les a réparties en catégories logiques. Elle a également rationalisé le processus de déploiement du cloud. C’est ce que nous appelons le « Centre de données virtuel Azure » (Azure Virtual Datacenter) : l’outil par excellence qui vous donne la confiance nécessaire pour faire vos premiers pas avec le cloud public. De nombreux sujets y sont abordés : gouvernance, stockage, sauvegarde et enregistrement des données, réseaux et connectivité. Aujourd’hui, nous nous penchons sur un sujet important : Infrastructure-as-Code.

2. Par Infrastructure-as-Code, n’entendez-vous pas simplement DevOps ?

Pas vraiment. Le terme « DevOps » est utilisé trop souvent à tort et à travers. Demandez à cinq personnes ce qu’elles entendent par DevOps et vous aurez cinq réponses différentes. DevOps est un élément culturel : il met en place une culture collaborative basée sur la confiance et dans laquelle vous pouvez déployer rapidement et souvent de nouveaux logiciels et des mises à jour. Avec DevOps, vous créez une culture dans laquelle personne n’est pointé du doigt et dans laquelle les échecs sont même célébrés. Les processus sont optimisés pour limiter la quantité de travail en cours. Et pour rendre tout cela possible, les entreprises doivent souvent adapter leur structure d’entreprise.

Dans ce billet de blog, nous nous concentrons sur un aspect de DevOps : Infrastructure-as-Code. Pourquoi est-ce si important ? N’oubliez pas que nous voulons déployer de nouveaux éléments souvent et rapidement. Par « déploiement », nous entendons le processus qui démarre lorsque quelqu’un demande une certaine application ou un certain service, et se termine lorsque cette application ou ce service sont opérationnels. En général, au moins huit interventions humaines sont nécessaires au cours de ce processus :

  • validation fonctionnelle de la demande,
  • validation technique de la demande,
  • demande d’une adresse IP,
  • démarrage manuel du déploiement du serveur,
  • demande des règles de pare-feu et de la configuration de l’équilibreur de charge,
  • définition des paramètres par défaut et des agents, configuration de la sauvegarde,
  • définition des rôles de serveur spécifiques (par ex. : IIS, SQL, etc.),
  • mise en œuvre d’interfaces binaires d’application.

3. Parfait, on peut donc travailler plus efficacement. Mais comment ?

Nous souhaitons automatiser au maximum le processus de déploiement et Azure s’avère très pratique dans ce contexte. Il n’existe en effet qu’une seule norme générale pour le déploiement des ressources dans Azure : Azure Resource Manager. À titre de comparaison : avec un réseau sur site, nous devrions travailler avec des composants de différents fournisseurs de services, qui ont chacun leur propre API. Mais commençons par un peu de terminologie.

3.1 Contrôle de la source et intégration continue

À l’instar des simples projets de développement, nous utilisons le contrôle de la source. Ainsi, nous avons un emplacement de stockage centralisé pour la configuration, les modèles de script et tous les codes que nous avons déjà écrits pour déployer le logiciel. En outre, grâce au contrôle de la source, vous pouvez sauvegarder plusieurs versions et revenir à une version précédente à tout moment. En veillant à ce que les équipes utilisent des référentiels partagés, nous nous développons en tant qu’entreprise. En outre, nous ne risquons pas que la connaissance de notre environnement soit limitée à quelques individualités. Chez Xylos, nous aimons travailler avec Azure DevOps, l’accès à DevOps se faisant via un protocole git.

3.2 Infrastructure inchangée

Lorsque nous déployons une nouvelle version d’une application, nous le faisons sans mettre à niveau les implémentations existantes. Nous déployons toujours le logiciel sur une nouvelle infrastructure. Cette approche présente plusieurs avantages :

  • le déploiement est entièrement documenté tout au long du cycle de vie de l’environnement ;
  • à chaque fois que vous déployez à nouveau la même version d’une application, vous pouvez vous attendre au même résultat ;
  • vous pouvez tester plusieurs versions d’une application, quand vous le souhaitez ;
  • vous pouvez restaurer le logiciel à une version précédente ;
  • vous pouvez tester les dépendances avec d’autres composants ;
  • en cas de scénarios catastrophes, vous pouvez rapidement restaurer votre environnement.

3.3 Approvisionnement déclaratif

Chez Xylos, nous utilisons volontiers des outils tels que PowerShell DSC ou Ansible. Ils nous permettent de créer des « configurations souhaitées » : nous décrivons ce dont nous avons besoin, les outils l’exécutent. En pratique, cela signifie que nous n’écrivons aucun script de procédure dans lequel les lignes de code sont exécutées séquentiellement, mais que nous utilisons des outils qui permettent de configurer une plateforme de manière optimale en fonction des objectifs poursuivis.

4. Le résultat

Le résultat est un déploiement entièrement automatisé de vos ressources Azure. Vous pouvez même déployer un tout nouveau centre virtuel de données en moins de 7 minutes et vous pouvez être sûr qu’il répond à vos besoins en matière de configuration.

Figure 1 -Exemple d’un pipeline Infra-as-Code sur Azure

Partager cet article de blog

Laissez une réponse

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués.