Concepts de base

Introduction

Les exercices du chapitre précédent ont permis de prendre en main le portail de gestion et de créer et d’organiser des raccourcis, afin de faciliter la navigation dans les menus. C’est une toute première étape.

Dans ce chapitre, le point de départ est la notion d’organisation et de gouvernance dans Azure. Tous les concepts, quels qu’ils soient, sont adossés à cette notion de gouvernance. Tout le début du chapitre est consacré à ce sujet majeur, au cœur de toute l’infrastructure Azure. Puis viennent la présentation et l’explication de la convention de nommage des ressources puis de la politique d’étiquettes. Enfin, il va être temps de créer une première ressource.

Dans la suite du chapitre, les concepts de base sont expliqués : comment mieux protéger ses ressources et éviter une suppression accidentelle ? Que sont les RBAC (contrôle d’accès basé sur un rôle) et que permettent-ils ? Ou même comment choisir sa région d’appartenance, la région sur laquelle déployer ses ressources Azure ?

Puis le chapitre se poursuit par une simulation de calcul des coûts engendrés par le déploiement d’une ressource ou d’un service (ensemble de ressources par exemple).

Le sujet...

Gouvernance

La gouvernance Azure désigne l’ensemble des stratégies, des méthodes et de l’organisation qui permettent de gérer les ressources, la sécurité et la conformité dans l’environnement Azure. C’est une définition assez générique. Derrière cette définition, il y a une organisation assez cadrée et que l’on retrouve souvent sous le terme CAF ou Cloud Adoption Framework (cadre d’adoption du cloud). Le terme est assez rarement utilisé en Français. Il faut donc retenir ce terme de CAF !

Le CAF, c’est un ensemble de bonnes pratiques et de recommandations qu’il faut essayer d’adapter (et d’adopter) dans le cadre de l’entreprise. Lorsque l’on arrive sur le cloud, c’est la partie la plus facile, rien n’existe, respecter les bonnes pratiques dès le départ est une règle de bon sens. Lorsque l’on est déjà sur le cloud et que l’on n’a pas forcément respecté les recommandations, c’est un peu plus difficile, voire beaucoup plus difficile. Plus le temps passé hors d’une implémentation conforme au CAF est élevé, plus les charges de remédiation vont l’être également. Mais la bonne pratique à la cible, c’est qu’il faut essayer de se rapprocher le plus possible de ce Framework.

Ce n’est pas une notion purement technique, mais plutôt un cadre organisationnel. Il y a assez peu de composants pour déployer ce socle de base de la gouvernance. Sous sa forme la plus simple, on retrouve des groupes de managements appelés groupe de gestion (ou Management groups), des abonnements (ou subscriptions). Ce sont deux types de conteneurs organisationnels qui ne sont pas à proprement parler des ressources Azure. Ces conteneurs ne sont pas facturés, ils servent à organiser (gouverner) les environnements.

Si au départ, ce n’est pas un point technique, ne pas s’appuyer sur l’arborescence de ces conteneurs rend l’utilisation d’Azure beaucoup plus compliquée. Il n’est pas inutile de le dire plusieurs fois tellement ce point est structurant Avec...

Convention de nommage

Ce point sur la convention de nommage ainsi que la section suivante consacrée à l’étiquetage des ressources sont des sujets sur lesquels on ne passe pas assez de temps lorsque l’on découvre Azure. Pourtant, ils sont au centre de l’organisation des ressources et apportent beaucoup.

Il faut être exigeant sur le sujet. Le cloud offre des mécanismes de délégation et étant donné la facilité des déploiements, il permet de déléguer rapidement des opérations. Une convention de nommage doit être proposée pour garantir une plus grande homogénéité et rendre l’identification d’un composant plus facile.

Les propositions faites dans ce lien...

Étiquettes

L’étiquette vient en renfort de la convention de nommage mais son utilité est différente. Elle est composée de deux parties : son nom et sa valeur. Par exemple, l’étiquette nommée Environnement peut être de valeur Prod, Dev ou Test.

Une ressource bien nommée n’aura pas besoin d’être "surchargée" par une étiquette, en revanche elle aura besoin d’être complétée d’autres informations. L’exemple suivant vient clarifier cette notion de surcharge inutile mais explique aussi comment une étiquette vient ajouter des informations utiles et complémentaires.

Nom de la ressource : Vmsqlcluster001. Soit une machine virtuelle 001 avec SQL dans un cluster. Étiqueter cette ressource de la manière suivante est inutile : Type:VMSQL.

Nul besoin de repréciser que cette VM est de type SQL puisque la convention de nommage...

Groupes de ressources

Avant de pouvoir créer une ressource Azure, il est obligatoire de créer un conteneur pour héberger cette ressource. Ce conteneur est appelé Groupe de ressources. C’est une ressource très particulière qui ne sert qu’à regrouper d’autres ressources.

Si le groupe de ressources n’est pas créé en prérequis au déploiement, la ressource en cours de création propose de le faire avant de pouvoir continuer. Il ne sera pas possible de valider et de terminer les actions sans cela.

Il est pourtant préférable de le faire avant de démarrer un nouveau déploiement. Il y a quelques bonnes pratiques à respecter sur le sujet. Ce conteneur permettra de regrouper les ressources, par exemple, un groupe de ressources pour une application de production. Toutes les ressources de l’application sont dans ce conteneur. Cela permet ensuite de positionner les droits d’administration sur ce même conteneur.

La création ne demande que très peu de paramètres.

Verrous

Une ressource créée sera supprimée si elle ne sert plus. La suppression et une action simple mais avec un écran de double validation. C’est un premier niveau de sécurité.

Entrez le nom du compte de stockage pour confirmer la suppression

Sur le modèle de la section Groupes de ressources de ce chapitre, il faut créer un nouveau groupe de ressources nommé rg-formation-eni-supp.

Puis il faut supprimer ce groupe de ressources.

C’est une action anodine mais il peut y avoir une mauvaise interprétation de ce qui est demandé, une erreur ou une mauvaise manipulation. La double validation n’est pas toujours suffisante, l’administrateur en charge de l’action peut se tromper.

Ici, ce n’est plus anodin. La suppression du conteneur (le groupe de ressources) supprime l’ensemble des éléments contenus à l’intérieur, par exemple une application critique pour l’entreprise. Pour éviter cette catastrophe, il faut utiliser...

Région Azure

Une région est l’endroit où sont positionnés les bâtiments qui hébergent les machines du centre de données, c’est-à-dire l’emplacement physique. À la date de l’écriture de cet ouvrage, il existe plus de soixante régions Azure et une feuille de route qui prévoit d’autres ouvertures de régions. C’est une répartition à l’échelle mondiale.

Pour la France, il existe deux régions : Azure France Centre et France Sud.

Lors du choix de la région, quatre règles au moins sont à prendre en compte. Elles permettent de faire un choix cohérent qui répondra au mieux aux besoins de l’entreprise.

Calculatrice Azure

Le chapitre Les coûts sera consacré à la maîtrise et à l’optimisation des coûts. Cependant, à partir du chapitre suivant, pour accompagner la partie théorique, le déploiement de ressources sera la base de tous les exercices. Il est important de comprendre comment ces déploiements vont impacter les coûts.

La calculatrice Azure est l’outil indispensable pour cette estimation, disponible à cette adresse : https://azure.microsoft.com/fr-fr/pricing/calculator/

Elle permet d’estimer facilement le coût d’une ressource unitaire et de ressources liées. Une machine virtuelle plus des disques de données attachés.

Voici quelques exemples d’estimations et de la façon dont il est possible d’influer sur les prix.

Redondance

La redondance est une solution pour améliorer la disponibilité des services et ressources Azure. En s’assurant qu’il n’y a pas (ou le moins possible) de points de défaillance uniques. Voici quelques exemples et bonnes pratiques pour éviter ce genre de situation :

Ce ne sont que quelques-unes des possibilités offertes par le cloud. Évidemment, ces choix seront guidés par des critères de criticité. Redonder ses composants, c’est augmenter ses coûts d’exploitation. S’il y a un intérêt certain à géorépliquer une base de données sensible, ce n’est pas nécessaire sur une base...