Para todos los que tenemos que trabajar en el día a día con Azure, creando y gestionando recursos a través del portal, de powershell, az cli o el SDK, lo de poner nombres puede llegar a ser una broma bastante pesada.
Esto es porque varían bastantes los límites de longitud máxima y mínima, los caracteres admitidos o la distinción entre mayúsculas y minúsculas, de acuerdo al tipo de recurso construido. Y, para más dificultad, en la mayoría de los casos esta nomenclatura no se puede modificar una vez creados los mismos.
Menos mal que la documentación de Microsoft me ayuda bastante.
Buenas prácticas y límites
En esta página de la documentación de Azure en la Web, Microsoft me descubre las buenas prácticas recomendadas, y las limitaciones y características que deben cumplir los nombres para ser utilizados; y aún hay más detalles en la guía de nombrado publicada en el repositorio de GitHub.
Si tuviera que resaltar dos cosas, la primera sería que las máquinas virtuales tienen un nombre de host (es decir el que voy a utilizar como nombre público en internet) y otro del recurso que es bastante menos restrictivo.
Y segundo, el nombre de hasta 1024 caracteres que soportan las URL de los endpoint de los blob de las cuentas de almacenamiento.
Espero que esté artículo sea de utilidad, en especial al alumno que me hizo la pregunta y me motivó a investigar y escribir este artículo.
2 comentarios
A parte del naming, cómo organizar los Resources group, si se tienen varios Entornos (PrE y PRO) a nivel de desarrollo. Además, hay elementos de red.
Hay todos estos tipos distintos de recursos, y la mayoría están asociados a un único resource group.
Almacen de claves
App Service
App Service (ranura)
Application Insights
Area de trabajo de Log Analytics
Base de datos SQL
Conexión
Cuenta de almacenamiento
Dirección IP pública
Disco
Grupo de seguridad de red
Interfaz de red
Network Watcher
Plan de App Service
Prefijo de dirección IP pública
Puerta de enlace de red local
Puerta de enlace de red virtual
Punto de conexión privado
Red virtual
SQL Server
SignalR
Tabla de rutas
Zona DNS privada
Por ejemplo, hay varios AppService para Pre y PRO, lo mismo para
Almacén de claves
App Service
Application Insights
Base de datos SQL
Base de datos SQL
Conexión
Cuenta de almacenamiento
Dirección IP pública
Grupo de seguridad de red
Interfaz de red
Plan de App Service
Puerta de enlace de red local
Punto de conexión privado
SQL Server
Tabla de rutas
Zona DNS privada
Cuál sería la buena práctica al usar recursos y resources groups?
Perdóname Carlos.
Me leen tan poquísimas personas, que no me he dado cuenta de tu pregunta.
La respuesta es: DEPENDE. En cada caso se agrupa de forma distinta.
Lo puedes hacer por proyecto, por seguridad, por ciclo de vida, por costes, por equipos, por contextos, etc.