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.

Dans ce chapitre, après la présentation et l’explication de la convention de nommage des ressources puis de la politique d’étiquettes, 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 ?

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 important de la redondance vient clore ce chapitre.

Ces sujets doivent être abordés afin de passer sereinement à la suite. Ce chapitre est dense et aborde de nombreuses notions essentielles utiles pour le démarrage. Il demande une bonne lecture pour être assimilé. Il se prête assez peu aux exercices, il faudra passer du temps sur ces points théoriques.

Ces concepts de base ne sont pas les points les plus techniques...

La 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...

Les é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...

Les 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.

Les 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. Sur le modèle de la section Les 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 les verrous. Le verrou est un mécanisme supplémentaire de protection. Il existe deux niveaux pour les verrous :...

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.

La 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...