[Partie 1] Le nommage des ressources Azure

Contexte

Dans la majorité des démos et tutoriels concernant Azure (et pas uniquement) vous trouverez une diversité de ressources provisionnées en mode « rapide / léger », c’est-à-dire sans être hyper rigoureux sur des notions comme le nommage des artefacts. « WebApp1 », « maVM », « MonRG » sont des noms couramment trouvés dans les démonstrations voire même les « Proof-of-Concepts » (qui sont censées être bien plus que des démos basiques).

Pas de souci particulier à se faire à ce stade, nous sommes censés être focalisés sur les principes et concepts de la démo en cause. Mais quid de ce sujet de nommage des artefacts Azure quand on se positionne vers un vrai projet ou une application à mettre en production ? Comment on s’assure que les noms qu’on choisit seront bien en phase avec le contexte complexe d’architecture, environnement, sécurité, exploitation de cette application, projet ou système ?

Le nommage dans les projets informatiques

D’abord, cette notion de nommage rigoureux n’est pas spécifique à Azure. Chaque projet informatique devrait suivre un set de règles de nommage, règles qui aideront à bien structurer son projet, retrouver facilement les termes qu’on connaissait déjà avant, voire même pouvoir identifier des ressources qui sont exposées dans des listes pas toujours structurées. Les règles de nommage sont présentes dans chaque langage de programmation, dans chaque provisionnement d’infrastructure.

Ceci dit, il y a des notions spécifiques au cloud (voire spécifique à Azure) qui devront compléter les notions déjà existantes. Il faudra d’abord cataloguer cette liste d’aspects de nommage qui est applicable pour notre organisation, notre projet et notre cloud.

Principes importants :

Aujourd’hui, qui dit cloud, dit esprit agile. Le cloud en soi (et celui public en particulier) est agile par sa vitesse de provisionnement, son élasticité à la mise à l’échelle, et surtout son rythme effréné de mises à jour et nouvelles fonctionnalités. Pour respecter cet esprit, les règles doivent accepter la flexibilité. On ne devrait pas être bloqué à déployer un environnement de prototypage parce que, par exemple, le nom du projet n’a pas été défini clairement, ou bien le type de ressource or artefact est tout frais dans le cloud… En revanche, même dans ce cas-là, on devrait pouvoir facilement comprendre à posteriori dans quel contexte cela a été provisionné (si ce n’est que pour déprovisionner l’environnement pour éviter la consommation Azure).

Cet article n’essayera pas, du coup, d’imposer un set de règles comme universelles, mais plutôt vous guider à définir votre propre set de règles et ensuite l’appliquer. Ceci dit, on essayera tout de même de donner des exemples très concrets (et pour ceux qui percevront l’exemple très proche de leur cas, l’appliquer directement dans l’état).

Enfin, dernier « disclaimer », l’esprit dynamique de l’Azure fera qu’il est possible que certaines règles ou contraintes ne s’appliquent plus (ou soient différentes) au moment ou vous lisez cette article. Dans ce cas-là, un retour de votre part sera très utile pour permettre la mise à jour de cet article.

Qu’est-ce que le nom d’une ressource Azure ?

Partons de la base : le nom d’une ressource Azure représente une chaîne de caractères qui permet l’identification unique de la ressource Azure.

La vision très généraliste de cette définition s’arrête ici :

• le nom lui-même peut représenter un simple « code » unique, ou bien peut correspondre à un « espace de nom » (ex. Azure Service Bus), à un « nom de compte » (ex. Azure Storage), à un « nom de machine » (ex. Azure VM) ou bien autre signification spécifique au type de ressource
• Identification unique, où ? Les noms peuvent avoir un contexte (scope) public global (ex. basé sur un sous-domaine Azure, comme les espaces de nom Azure Service Bus, les comptes Azure Storage etc .), local à la souscription (ex. Azure VNET), ou bien local à la ressource parent (ex. les noms des blobs ou fichiers dans un container Azure Blob Storage)

Pour complexifier encore la tâche, certains types de ressources ont des règles de nommages différentes pour des typologies différentes à l’intérieur du même type (trop compliqué à comprendre ? voici l’exemple : les Azure VMs ont des contraintes plus fortes – 15 caractère maximum – pour les VMs basées sur Windows que pour celles sur Linux. Problème historique, bien sûr, venue du monde infrastructure à demeure, mais qui se répercute dans le nommage cloud).

• Les caractères acceptés dans les noms varient également, mais on pourra identifier quelques sets de caractères applicables comme ci-dessous (mais pas limité à) :
  • Alphanumériques (chiffres et lettres)
  • Alphanumériques, plus underscore et tiret
  • Alphanumériques, plus underscore, tiret et point
  • Tout caractère accepté dans une URI
  • Tout caractère
• La majorité des noms ne peuvent pas commencer ou finir avec un tiret ou un underscore
• Egalement, un point particulier à retenir est la variabilité de sensibilité à la casse :
  • Noms sensibles à la casse (ex. les noms de blobs dans un container Azure Storage)
  • Noms insensibles à la casse (ex. les groupes de ressource)
  • Noms en minuscules obligatoirement (ex. les comptes Azure Storage)
• Les contraintes de longueur sont largement variables – ainsi à la limite inférieure qu’à celle supérieure. Certains noms requièrent entre 1-64 caractères, autres entre 1-80, 2-80, 1-1024 etc. Très, très variable, donc, pas de repère précis.

Sur l’ensemble, malheureusement il n’y a pas une vision globale (Azure ici, mais AWS souffre des mêmes peines, par ailleurs), pas de vision globale de règles consolidées et (plus) uniformes sur le nommage des artefacts et ressources.

D’où encore une fois l’importance de cette tâche de structuration du nommage. Il n’est pas rare que vous commencez par des règles que vous considérez suffisantes (pour les types de ressources que vous traitez au moment donné) et qui se relèvent bloquantes pour le nommage de la nouvelle ressource dont vous avez besoin dans votre projet.

Contraintes de nommage des ressources Azure

Pour vous donner une référence plus précise et centralisée de ces contraintes, les voici (compilées ici depuis la documentation Azure ainsi que en suivant les contraintes exposées lors de la création d’une ressource) :

[table id=4 /]

A suivre

Ce premier article sur le sujet du nommage des ressources et artefacts Azure sera suivi prochainement par d’autres articles, qui comprendront des détails sur les aspects ou particules incluses dans les noms, des tableaux de référence des particules, les règles de composition ainsi que les bonnes pratiques.

Note : vous trouverez la version anglaise de cet article à http://blog.lecampusazure.net/2016/07/naming-of-azure-resources-part-1.html.