Buenas prácticas y límites al nombrar recursos en Azure

Sitio dedicado a Microsoft Azure y otras tecnologías Cloud

Fichas de letras del juego scrabble

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

  1. carlos dice:

    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?

    • Administrador dice:

      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.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.