Los pipelines dejan de ser código en el momento en que necesitan una dirección o un registro. Micetro expone el DNS, el DHCP y el IPAM (DDI) a través de una API REST y una colección de Ansible, de modo que las operaciones con direcciones y registros se convierten en pasos versionados y revisables, en lugar de tickets.
· 01 — DONDE LAS PIPELINES SE INTERRUMPEN POR DIRECCIÓN Y NOMBRE
¿Por qué se bloquea una canalización automatizada cuando necesita una dirección IP o un nombre DNS?
Dado que las zonas DNS, el espacio de direcciones IP y los ámbitos DHCP suelen gestionarse desde una consola o un servicio de asistencia técnica, en lugar de a través de una API.
Las plataformas automatizadas necesitan respuestas a la velocidad de una máquina, y un paso manual de back-office o una hoja de cálculo con direcciones se convierte en la parte más lenta de una implementación que, por lo demás, está automatizada.
El problema subyacente es la fragmentación. La gestión de DNS, DHCP y direcciones IP suele estar repartida entre sistemas aislados con consolas, permisos y registros de auditoría independientes, lo que impide que exista un único lugar al que un proceso pueda solicitar una dirección o validar un registro. Cada entorno desarrolla entonces su propia solución provisional, y es en esas soluciones donde residen los pasos manuales.
El requisito no es solo la precisión. Una capa DDI debe proporcionar el aprovisionamiento a la velocidad para la que se diseñó el proceso y actuar como una única fuente fidedigna de información sobre direcciones y ámbitos. La gestión descentralizada, o una hoja de cálculo de direcciones IP, genera solapamientos de espacio y entradas obsoletas que la automatización propaga a gran escala.
52 %
52 %
Más de la mitad de las organizaciones señalan la complejidad de la red como uno de sus mayores retos a la hora de gestionar el DNS, el DHCP y las direcciones IP.
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
5 min·Blog
Más información →
· 02 — LA API COMO PLANO DE CONTROL
¿Qué aporta a un equipo de automatización un plano de control de DDI basado en una API?
Asigna a cada objeto de DNS, DHCP e IPAM una ruta de recurso que los métodos HTTP estándar pueden crear, leer, actualizar y eliminar.
Esto convierte las operaciones de registros y direcciones en pasos de un flujo de trabajo, y la documentación interactiva de Swagger permite a un ingeniero comprobar cada llamada manualmente antes de que se ejecute de forma desatendida.”,”_paths_2_description”:”field_bct
Existe una diferencia entre una plataforma que cuenta con una API y otra que da prioridad a la API, y Ronny Wolf, de BlueCat, lo explicó con detalle en el podcast «Heavy Strategy» de Packet Pushers. Cuando las funciones se desarrollan para la interfaz de usuario y posteriormente se añade un punto final, la cobertura es desigual, la autenticación varía de un módulo a otro y la integración prometida durante el ciclo de ventas acaba traduciéndose en soluciones provisionales o en un contrato de consultoría una vez que el producto se ha implementado. Cuando cada función es una API y la interfaz no es más que un consumidor de la misma, no hay nada accesible desde la consola que no lo sea también mediante un token.
Micetro se ha diseñado siguiendo el segundo enfoque. Casi toda la funcionalidad DDI se expone a través de puntos finales REST que abarcan Microsoft, BIND, Kea, Cisco, plataformas en la nube y dispositivos, y la interfaz del navegador se ejecuta en la misma API que llamaría un playbook. Empieza por la documentación interactiva de Swagger con la identidad que el pipeline va a tener realmente, en lugar de una cuenta de administrador, ya que una llamada exploratoria que tenga éxito con privilegios de administrador completo puede fallar más adelante bajo el rol de automatización. Los tokens de portador basados en sesión son la vía de autenticación recomendada, con roles de privilegios mínimos, tokens de corta duración y credenciales extraídas de variables de entorno o de un almacén de secretos, en lugar de estar codificadas de forma estática.
Open platforms and API-first architecture enable intelligent network operations, automation, and AI-driven workflows across hybrid enterprises.
27 min·Blog
Más información →
· 03 — ANSIBLE COMO CAPA DE EJECUCIÓN
¿Cómo se configura Ansible para gestionar tareas de DNS, DHCP e IPAM?
Ejecute Ansible en una máquina de control Linux, instale la colección Micetro desde Ansible Galaxy y, a continuación, configure Ansible para que acceda a la API de DDI a través de un complemento de inventario en lugar de un archivo de hosts estático.
A partir de ahí, los guiones de actuación llevan a cabo acciones reales de IPAM, como reclamar la siguiente dirección disponible.
Una máquina de control con Linux es la base de referencia más práctica, ya que ejecutar Ansible en Windows a través del subsistema para Linux resulta complicado. La instalación de la colección Micetro integra los complementos y módulos necesarios para acceder a las API de Micetro, y estos amplían la funcionalidad básica de Ansible en lugar de sustituirla. Comprueba el nombre actual de la colección y las versiones compatibles de Ansible y Python en la documentación del producto antes de compilar, ya que ambas varían con el ciclo de lanzamientos.
La configuración se reduce a tres archivos: un archivo group_vars que contiene la URL del proveedor y las credenciales de la cuenta de automatización; un archivo ansible.cfg que habilita el complemento de inventario de Micetro y apunta al archivo de inventario; y el propio archivo de inventario. Cifra esas credenciales con Ansible Vault o obténlas de un almacén de secretos en lugar de dejarlas en texto plano, asigna a la cuenta el mismo rol de privilegios mínimos que le darías a cualquier usuario de la API REST y, a continuación, ejecuta un primer playbook, como reclamar una dirección IP, y confirma el resultado en Micetro.
The BlueCat Micetro REST API provides a unified, standards-based interface to automate and integrate DNS, DHCP, and IP address management across Microsoft,…
14 min·Blog
Más información →
· 04 — QUÉ APORTA GIT UNA VEZ QUE DDI ES PROGRAMABLE
¿Qué ventajas ofrece realmente incluir los cambios de DNS e IPAM en Git?
Convierte los cambios de DNS y de direcciones de una simple solicitud en un elemento revisable.
El manual de procedimientos o la tarea que crea una zona, un registro o una reserva se almacena en un repositorio, por lo que el cambio cuenta con un informe de diferencias, un autor, una aprobación y una ruta de reversión antes de llegar a la red.
El patrón es el mismo que se aplica a los servidores y a las reglas de cortafuegos. El estado deseado se declara en un archivo, este se revisa como cualquier otro cambio de código y el proceso de integración lo aplica. Dado que la capa DDI expone cada objeto como un recurso, la tarea que valida un registro es lo suficientemente pequeña como para leerse en una solicitud de incorporación de cambios, lo que hace que la revisión sea significativa y no meramente formal.
Git registra la intención, no el resultado, y esa distinción es importante en DDI. Una confirmación fusionada indica lo que el equipo pretendía cambiar. Los puntos finales del historial de eventos de la plataforma indican lo que realmente cambió, incluyendo cualquier cosa aplicada fuera del proceso, y las propiedades personalizadas, como el propietario, el entorno y el centro de costes, permiten que ese historial incluya el contexto de la propiedad. Los equipos que se toman en serio la automatización concilian ambos aspectos y tratan cualquier diferencia entre ellos como una desviación que hay que investigar, en lugar de como ruido.”
Create consistent DDI (DNS, DHCP & IPAM) automation workflows using one REST API, no matter where your workloads currently reside or will reside in the…
8 min·Blog
Más información →
· 05 — REGULACIÓN DE QUIÉN Y QUÉ PUEDE MODIFICAR EL PROCESO"
¿Cómo se mantienen los cambios automatizados de DNS y DHCP bajo control de acceso?
Delimite el alcance de la cuenta de automatización mediante el control de acceso basado en roles en la capa DDI, no en cada consola individual.
Los roles granulares sobre DNS y DHCP permiten que un flujo de trabajo disponga exactamente de los derechos que necesitan sus tareas y nada más, vinculados a las identidades de directorio existentes.”
La gestión del acceso a los entornos de DNS y DHCP de Microsoft resulta más sencilla cuando los permisos se centralizan en un único lugar, en lugar de tener que reconfigurarse por cada servidor y cada consola. El control de acceso basado en roles en la capa de orquestación se aplica tanto a los administradores humanos como a las identidades de automatización, y puede delegarse a grupos de Active Directory o de Entra ID.
Esto cobra especial importancia cuando es el código el que realiza los cambios. Un rol con privilegios mínimos marca la diferencia entre un playbook que puede crear un registro en una zona y otro que puede reescribir el espacio de nombres, y se configura una sola vez en lugar de negociarse en cada solicitud.
BlueCat Micetro simplifies managing access to Microsoft DNS and DHCP environments with robust Role-Based Access Control.
1 min·Blog
Más información →
· 06 — QUÉ SE DEBE EXIGIR A LA PLATAFORMA
¿Qué deben buscar los equipos en una plataforma DDI para flujos de trabajo de infraestructura como código basados enAnsible y Git?
Se requiere una API que exponga casi toda la funcionalidad de DDI como recursos, autenticación basada en tokens con roles de privilegios mínimos, puntos finales masivos filtrables y paginables, historial de cambios consultable y una colección de automatizaciones actualizada.
Cada uno de ellos es la inversa de un modo de fallo que aparece una vez que los flujos comienzan a escribir en DNS, DHCP e IPAM.”
La cobertura es lo primero: un plano de control REST basado en recursos que abarca Microsoft, BIND, Kea, Cisco, plataformas en la nube y dispositivos, de modo que una única interfaz da servicio a todo el entorno. A continuación, se amplían los controles, incluyendo filtrado, ordenación, paginación con desplazamiento y límite, y puntos finales masivos que aceptan cargas útiles por lotes y devuelven el éxito o el fallo por objeto, en lugar de un único «aprobado» o «fallido».
A continuación, la gobernanza: definiciones de propiedades personalizadas para metadatos como el propietario, el entorno y el centro de costes; un estricto control de acceso basado en roles; gestión estructurada de errores con registro completo de solicitudes y respuestas; credenciales de servicio rotativas; y puntos finales de historial para la auditoría. La compatibilidad práctica con herramientas como Postman, PowerShell y Python es lo que hace que el resto sea utilizable en el día a día.
100registros por bloque
100 registros por bloque
Los conjuntos de resultados de gran tamaño y los trabajos masivos deben paginarse y procesarse en bloques; se recomienda empezar con unos 100 registros cada vez como punto de partida para evitar fallos de memoria y de tiempo de espera en la automatización desatendida.”
Today’s enterprise networks span data centers, cloud environments, and distributed edge systems. DNS, DHCP, and IP address management (together known as…
13 min·Blog
Más información →
Trabajamos con entornos híbridos de DNS de Microsoft, equipos de TI reducidos que se modernizan sin necesidad de sustituir todo el sistema y programas de consolidación de DDI, incluidos equipos que incorporan por primera vez el DNS, el DHCP y el IPAM a Ansible y Git.
· 07 — AUTOMATIZACIÓN DE DNS Y DHCP DE MICROSOFT SIN CAMBIAR LA INFRAESTRUCTURA ACTUAL
¿Cómo consiguen los equipos «lean» que los servicios DNS y DHCP de Microsoft existentes estén preparados para el pipeline sin sustituirlos?
Superpónlos. Micetro se conecta sin agentes a los servidores DNS y DHCP de Microsoft existentes, así como a los sitios y subredes de Active Directory, y presenta zonas, registros,
ámbitos y concesiones a través de una única interfaz de gestión y API, de modo que la automatización dispone de una única superficie programable sobre la infraestructura que el equipo ya gestiona.”
Las consolas nativas no se diseñaron para esto. Los administradores dependen de consolas de gestión independientes para el DNS, el DHCP, los sitios y las subredes; los permisos se asignan de forma diferente en cada una de ellas y los registros de auditoría están separados, lo que dificulta la resolución de problemas y la reversión de los cambios. Gestionar manualmente cientos o miles de registros y concesiones en distintos sitios no es ni sostenible ni escalable.
La superposición añade lo que necesita la automatización y Active Directory permanece intacto. El control de acceso basado en roles delega en identidades del directorio o de Entra ID, la visibilidad multibosque reúne los datos de DNS y DHCP de varios bosques en una única vista, y el registro de auditoría completo abarca tanto los cambios impulsados por el flujo de trabajo como los cambios manuales. No es necesario migrar nada para que la API se convierta en la forma de trabajar.
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
5 min·Page
Ver Micetro →
· 08 — Rutas de avance
¿Qué vía de automatización de DDI se adapta mejor a su proceso actual?
Tres vías cubren la mayoría de las situaciones, diferenciadas en función de qué parte del entorno ya es programable y de cuántos cambios manuales sigue gestionando el equipo. Cada una de ellas se basa en la misma interfaz API, por lo que empezar poco a poco no implica tener que volver a trabajar más adelante.
PATH 01
Aún no se ha implantado ninguna automatización y no hay disposición al riesgo
Pruebe primero la API en un entorno de pruebas
Utilice la documentación interactiva de Swagger para crear registros, rangos y ámbitos manualmente en puntos finales reales, utilizando la misma cuenta que utilizará la automatización. Confirme el modelo de objetos y el formato de la respuesta y, a continuación, utilice esas llamadas como base para las tareas versionadas. Nada se ejecuta de forma desatendida hasta que no se haya ejecutado manualmente.
Las compilaciones ya están basadas en código, salvo en lo que respecta al DNS y a la asignación de direcciones IP
Traslade los pasos de direcciones y registros a Ansible y Git
Configure una máquina de control Linux, instale la colección Micetro y gestione el inventario a través del complemento de la API en lugar de un archivo de hosts estático. Empiece con una única acción de IPAM, como reclamar una dirección, confirme el playbook para que el cambio se someta a una comparación de diferencias y a una revisión, y amplíe a partir de ahí.
Infraestructura dependiente de Microsoft, equipo reducido, sin presupuesto para la migración
Superponer los servicios DNS y DHCP de Microsoft para crear una superficie programable única
Reúna los datos existentes de DNS, DHCP, sitios y subredes de Microsoft en una única interfaz de gestión y API sin necesidad de sustituir los servidores. De este modo, los roles con privilegios mínimos, el historial de auditoría unificado y la reversión se aplican tanto a los cambios automatizados como a los manuales.”,”_paths_2_description”:”field_bct
Preguntas frecuentes de los equipos que someten el DNS, el DHCP y el IPAM a control de versiones.”
No es recomendable. Una máquina de control con Linux es la opción básica más práctica, ya que ejecutar Ansible en Windows a través del subsistema para Linux resulta complicado de configurar y mantener. Consulta las versiones actuales compatibles de Ansible y Python en la documentación del producto, ya que los requisitos mínimos cambian con cada lanzamiento de la colección.
No. La automatización mediante una API DDI funciona de manera diferente: en lugar de crear una lista de inventario de nodos gestionados, Ansible utiliza el complemento de inventario de la colección Micetro, configurado a través de ansible.cfg y un archivo de inventario que contiene la URL y las credenciales de la API de Micetro, de modo que el propio espacio de direcciones es la fuente del inventario.
Nunca los codifique de forma fija. Utilice tokens de portador basados en sesión para la automatización, guárdelos en variables de entorno o en un almacén de secretos, mantenga los tokens con una vida útil corta y renuévelos periódicamente, y asigne roles con privilegios mínimos a las cuentas de la API. Los intentos de autenticación deben auditarse a través del historial de eventos.
Revisión previa al cambio y una ruta de reversión. El repositorio contiene el cambio propuesto, las diferencias, el responsable de la aprobación y la versión anterior. El historial de eventos de la plataforma recoge lo que realmente se ha implementado. Juntos muestran la intención y el resultado, y cualquier diferencia entre ambos apunta a un cambio realizado fuera del proceso.
Sí. Los puntos finales del historial de eventos de Micetro permiten a un equipo consultar todos los cambios realizados en un recurso y auditar las acciones de los usuarios a lo largo del tiempo. Las definiciones de propiedades personalizadas pueden adjuntar metadatos como el propietario, el entorno y el centro de costes, de modo que los cambios automatizados incluyan el contexto de propiedad.
Sí. Micetro se conecta sin agentes a los servidores DNS y DHCP de Microsoft existentes, así como a los sitios y subredes de Active Directory, actuando como una capa de orquestación, y presenta zonas, registros, ámbitos y concesiones a través de una única interfaz y una API REST. Los servicios de Microsoft siguen funcionando tal y como están y Active Directory permanece intacto.
¿Todavía tienes dudas?
Obtén respuestas reales de un representante de BlueCat.
We’re using cookies on this website to improve your experience. Cookies help us learn how you interact with our website and remember you when you come back so we can tailor it to your interests.
To learn more about cookies and how we use them, read our cookie notice.
Some cookies are essential, while others help us to improve your experience by giving us insight into how you are using our website. You may adjust your preferences for non-essential cookies below.
To learn more about cookies and how we use them, read our cookie notice. You can also review our privacy policy for more details on the personal data we collect, use, hold, and disclose when you visit our website or use our products and services.
Functional cookies
Functional cookies are essential cookies that allow us to remember choices or changes you have made (such as to language settings or your choices regarding the use of cookies). These cookies cannot be turned off since they are essential for the operation of our Websites.
Analytics cookies
Analytics cookies are non-essential cookies that collect information on how visitors use our Websites. We use this information with your consent to measure the number of visitors to our Websites, determine whether specific content or communication has been viewed, and to help us improve our Websites and communication. These cookies can be turned off.
Personalisation Storage
Personalisation cookies are non-essential cookies that collect information when you fill out a form on this website. We only use this information with your consent to pre-fill other forms on the site. These cookies can be turned off.
Marketing cookies
Marketing cookies are cookies that are placed by third parties to collect information about your visits and actions on our Websites so that they or we can deliver ads to you later, such as when you are on certain third-party sites or platforms. These cookies may be used by those third parties to build a profile of your interests and show you relevant ads on other websites. These cookies also enable visitors to our Websites to share content on social networks and to enable and evaluate interactions with our communication and social media tools. These cookies can be turned off.
Article 
