Voy al grano: Azure Cosmos DB for MongoDB vCore es MongoDB real en Azure, con arquitectura vCore (CPU + RAM) que escala vertical y horizontalmente sin downtime. Soporte nativo para vector search (DiskANN), sharding automático y 99.99% SLA con HA activado. Ideal para lift & shift de aplicaciones MongoDB existentes o nuevas apps que necesiten queries complejas, aggregations y transacciones distribuidas.
Voy al grano: Azure Event Hubs soporta el protocolo Kafka de forma nativa. Puedes apuntar tus aplicaciones Kafka existentes al endpoint de Event Hubs cambiando solo el connection string. Sin gestionar Zookeeper, sin actualizar brokers, sin parches de seguridad. Totalmente gestionado con auto-inflate, geo-replication y 99.99% SLA.
Retrieval Augmented Generation (RAG) es el patrón que permite a modelos como GPT-4 responder preguntas basándose en tus datos corporativos. Voy al grano: combinar Azure OpenAI con Azure AI Search te permite crear chatbots que conocen tu documentación, productos o políticas internas sin tener que reentrenar modelos.
Voy al grano: Azure Virtual Network Manager (AVNM) centraliza la gestión de conectividad y seguridad de cientos o miles de VNets desde un solo panel. Creas topologías hub-spoke o mesh con clicks, defines security admin rules que se evalúan antes que los NSGs, y despliegas cambios por regiones de forma controlada. Sin scripts custom, sin gestionar peerings manualmente.
Voy al grano: Azure Deployment Environments es el reemplazo de DevTest Labs, diseñado para que equipos de desarrollo creen entornos completos (App Service + Cosmos + Key Vault + Storage) desde un catálogo de plantillas IaC sin esperar a Platform Engineering. Dev Centers centralizan la gobernanza, Projects definen permisos, y developers despliegan con CLI/Portal. Zero acceso a subscriptions de producción.
Azure AI Foundry (antes Azure AI Studio) es la plataforma unificada de Microsoft para desarrollar, desplegar y gestionar aplicaciones de IA generativa. Con acceso a 1900+ modelos (GPT-4o, o1, DeepSeek, Llama...), un entorno colaborativo tipo MLOps, y herramientas para RAG, evaluación y monitorización, todo en un portal integrado.
Si trabajas con Azure OpenAI, LangChain, o quieres construir copilots/agents, este es tu punto de partida.
Azure Container Apps ha evolucionado significativamente desde su lanzamiento en 2022. Este artículo actualizado explora las capacidades actuales del servicio, las novedades incorporadas en 2024-2025, y cómo se posiciona como la solución ideal para ejecutar aplicaciones nativas de la nube sin la complejidad de gestionar Kubernetes directamente.
«Necesito ejecutar aplicaciones Cloud Native en contenedores, pero no quiero la complejidad operativa de Kubernetes, OpenShift, etc.»
Esta es una necesidad recurrente en equipos de desarrollo que quieren aprovechar las ventajas de los contenedores y arquitecturas de microservicios sin dedicar recursos a:
Azure Container Apps es un servicio gestionado serverless que permite ejecutar contenedores sin preocuparse por la infraestructura subyacente. Lanzado inicialmente en 2022 y con mejoras continuas, se ha convertido en una opción madura para desplegar aplicaciones modernas.
Aunque no gestionas directamente Kubernetes, bajo el telón Azure Container Apps funciona sobre:
flowchart TB
subgraph Internet["Internet / Usuarios"]
USER["Cliente HTTP/API"]
end
subgraph ACA["Azure Container Apps Environment"]
INGRESS["Ingress (Envoy)"]
APP1["Container App 1"]
APP2["Container App 2"]
APP3["Container App 3"]
DAPR["Dapr Sidecar"]
KEDA["KEDA Scaler"]
end
subgraph Backend["Servicios Backend"]
STORAGE["Azure Storage"]
COSMOSDB["Cosmos DB"]
SERVICEBUS["Service Bus"]
end
USER --> INGRESS
INGRESS --> APP1
INGRESS --> APP2
INGRESS --> APP3
APP1 --> DAPR
APP2 --> DAPR
DAPR --> STORAGE
DAPR --> COSMOSDB
SERVICEBUS --> KEDA
KEDA --> APP3
Azure Container Apps se diferencia de otras soluciones de contenedores en Azure por:
Optimización para microservicios: diseñado específicamente para aplicaciones que abarcan múltiples contenedores desplegados como servicios independientes
Tecnologías open-source integradas:
Envoy: balanceo de carga y observabilidad
Arquitecturas event-driven: escalado basado en:
Escalado a cero para reducir costes
Soporte para cargas de larga duración: procesos background, jobs y tareas programadas
Desde el post original de 2022, Azure Container Apps ha incorporado capacidades empresariales significativas:
Serverless GPUs disponibles en regiones West US 3, Australia East y Sweden Central:
Dedicated GPU workload profiles:
# Ejemplo: Crear environment con GPU serverless
az containerapp env create \
--name my-gpu-environment \
--resource-group my-rg \
--location westus3 \
--enable-workload-profiles
# Desplegar app con GPU T4
az containerapp create \
--name my-ai-app \
--resource-group my-rg \
--environment my-gpu-environment \
--image myregistry.azurecr.io/ml-inference:latest \
--cpu 8 --memory 56Gi \
--workload-profile-name Consumption-GPU-NC8as-T4 \
--target-port 8080 \
--ingress external
Ejecución segura y aislada de código generado por IA, ideal para:
Características:
Despliegue de Azure Functions como contenedores dentro de Container Apps:
# Crear Function App optimizada para Container Apps
az containerapp create \
--name my-function-app \
--resource-group my-rg \
--environment my-environment \
--image myregistry.azurecr.io/my-functions:latest \
--kind functionapp \
--ingress external \
--target-port 80
Consumption Profile (por defecto): - Escalado automático - Pago solo por uso activo - Hasta 4 vCPU / 8 GiB memoria por réplica
Dedicated Profiles (opcionales): - General purpose (D4, D8, D16, D32) - Memory optimized (E4, E8, E16, E32) - GPU enabled (NC24-A100, NC48-A100, NC96-A100)
Para aplicaciones Spring:
| Servicio | Caso de Uso Ideal |
|---|---|
| Azure Container Apps | Microservicios, APIs, event-driven apps, cargas AI/ML serverless, aplicaciones con escalado a cero |
| Azure Kubernetes Service (AKS) | Control total de Kubernetes API, workloads complejos con requisitos específicos de K8s |
| Azure Red Hat OpenShift | Despliegue OpenShift gestionado, migración desde on-premises OpenShift |
| Azure Functions | Funciones FaaS puras, integraciones rápidas con triggers Azure, sin contenedores |
| Web App for Containers | Aplicaciones web en contenedores Windows/Linux, migración lift-and-shift |
| Container Instances | Contenedores de corta duración, batch jobs simples, aislamiento por hipervisor |
| Service Fabric | Aplicaciones distribuidas legacy, necesidad de reliable services/actors |
| Container Registry | Almacenamiento, gestión y replicación de imágenes de contenedor |
flowchart TD
START["¿Necesitas ejecutar contenedores?"]
START --> K8S_API{"¿Necesitas acceso directo a Kubernetes API?"}
K8S_API -->|Sí| AKS["Azure Kubernetes Service (AKS)"]
K8S_API -->|No| SERVERLESS{"¿Prefieres serverless con escalado a cero?"}
SERVERLESS -->|Sí| MICROSERVICES{"¿Es una arquitectura de microservicios / API?"}
SERVERLESS -->|No| DEDICATED{"¿Necesitas hardware dedicado/GPU?"}
MICROSERVICES -->|Sí| ACA["✅ Azure Container Apps"]
MICROSERVICES -->|No| FUNCTIONS{"¿Solo funciones event-driven?"}
FUNCTIONS -->|Sí| AZFUNC["Azure Functions"]
FUNCTIONS -->|No| ACA2["✅ Azure Container Apps"]
DEDICATED -->|Sí| ACA_DEDICATED["✅ Azure Container Apps
(Dedicated Workload Profiles)"]
DEDICATED -->|No| WEBAPP["Web App for Containers"]
Implementar un chatbot con Retrieval Augmented Generation:
Pipeline de procesamiento de telemetría:
Arquitectura de e-commerce:
Comunicación via Dapr service invocation, state management en Redis/Cosmos DB, pub/sub con Service Bus.
# Variables
RESOURCE_GROUP="my-container-apps-rg"
LOCATION="westeurope"
ENVIRONMENT="my-environment"
APP_NAME="my-api"
# Crear resource group
az group create --name $RESOURCE_GROUP --location $LOCATION
# Crear environment
az containerapp env create \
--name $ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--location $LOCATION
# Desplegar desde imagen pública
az containerapp create \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--environment $ENVIRONMENT \
--image mcr.microsoft.com/k8se/quickstart:latest \
--target-port 80 \
--ingress external \
--min-replicas 0 \
--max-replicas 10
param location string = resourceGroup().location
param environmentName string = 'my-environment'
param containerAppName string = 'my-api'
param containerImage string = 'mcr.microsoft.com/k8se/quickstart:latest'
resource environment 'Microsoft.App/managedEnvironments@2023-05-01' = {
name: environmentName
location: location
properties: {
appLogsConfiguration: {
destination: 'log-analytics'
logAnalyticsConfiguration: {
customerId: logAnalytics.properties.customerId
sharedKey: logAnalytics.listKeys().primarySharedKey
}
}
}
}
resource containerApp 'Microsoft.App/containerApps@2023-05-01' = {
name: containerAppName
location: location
properties: {
managedEnvironmentId: environment.id
configuration: {
ingress: {
external: true
targetPort: 80
transport: 'auto'
}
}
template: {
containers: [
{
name: 'main'
image: containerImage
resources: {
cpu: json('0.5')
memory: '1Gi'
}
}
]
scale: {
minReplicas: 0
maxReplicas: 10
rules: [
{
name: 'http-rule'
http: {
metadata: {
concurrentRequests: '100'
}
}
}
]
}
}
}
}
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
name: '${environmentName}-logs'
location: location
properties: {
sku: {
name: 'PerGB2018'
}
}
}
# Crear app con Dapr
az containerapp create \
--name order-service \
--resource-group $RESOURCE_GROUP \
--environment $ENVIRONMENT \
--image myregistry.azurecr.io/order-service:v1 \
--target-port 3000 \
--ingress internal \
--min-replicas 1 \
--enable-dapr \
--dapr-app-id order-service \
--dapr-app-port 3000 \
--dapr-app-protocol http
# Invocar otro servicio via Dapr
# Desde código: http://localhost:3500/v1.0/invoke/inventory-service/method/check-stock
Una de las características más potentes de Container Apps son las revisiones (revisions):
# Desplegar revisión "blue" (producción actual)
az containerapp create \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--environment $ENVIRONMENT \
--image myregistry.azurecr.io/myapp:v1.0 \
--revision-suffix blue \
--ingress external \
--target-port 80 \
--revisions-mode multiple
# Fijar 100% tráfico a blue
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--revision-weight $APP_NAME--blue=100
# Asignar label "blue"
az containerapp revision label add \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--label blue \
--revision $APP_NAME--blue
# Desplegar revisión "green" (nueva versión)
az containerapp update \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--image myregistry.azurecr.io/myapp:v2.0 \
--revision-suffix green
# Probar green en URL específica: https://my-app---green.<environment-domain>
# Traffic splitting progresivo: 80% blue, 20% green
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--revision-weight $APP_NAME--blue=80 $APP_NAME--green=20
# Si green funciona bien, cambiar 100% a green
az containerapp ingress traffic set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--revision-weight $APP_NAME--green=100
# Desactivar revisión blue
az containerapp revision deactivate \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--revision $APP_NAME--blue
# Crear environment con VNet personalizada
az containerapp env create \
--name $ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--location $LOCATION \
--infrastructure-subnet-resource-id /subscriptions/.../subnets/aca-subnet \
--internal-only false
# Subnet mínimo: /27 (para workload profiles)
# Subnet mínimo: /23 (para consumption only)
# Crear environment con private endpoint
az containerapp env create \
--name $ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--location $LOCATION \
--enable-workload-profiles \
--public-network-access Disabled
# Crear private endpoint
az network private-endpoint create \
--name my-private-endpoint \
--resource-group $RESOURCE_GROUP \
--vnet-name my-vnet \
--subnet my-subnet \
--private-connection-resource-id /subscriptions/.../managedEnvironments/$ENVIRONMENT \
--group-id managedEnvironment \
--connection-name my-connection
Container Apps se integra automáticamente con:
# Habilitar Application Insights
az containerapp env create \
--name $ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--location $LOCATION \
--logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
--logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>
// Logs de aplicación
ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "my-api"
| where TimeGenerated > ago(1h)
| project TimeGenerated, Log_s
| order by TimeGenerated desc
// Métricas de réplicas
ContainerAppSystemLogs_CL
| where Category == "ContainerAppScaling"
| where ContainerAppName_s == "my-api"
| project TimeGenerated, ReplicaCount_d
| render timechart
# Habilitar agente OpenTelemetry
az containerapp env telemetry app-insights set \
--name $ENVIRONMENT \
--resource-group $RESOURCE_GROUP \
--connection-string "InstrumentationKey=...;IngestionEndpoint=..."
# Las apps envían automáticamente traces, metrics y logs a App Insights
Consumption Plan:
Dedicated Plan (workload profiles):
minReplicas: 0 para apps con tráfico intermitente# Configurar escalado a cero
az containerapp update \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--min-replicas 0 \
--max-replicas 10 \
--scale-rule-name http-rule \
--scale-rule-type http \
--scale-rule-metadata concurrentRequests=50
# Habilitar system-assigned identity
az containerapp identity assign \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--system-assigned
# Asignar rol para acceder a Key Vault
IDENTITY_ID=$(az containerapp identity show \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--query principalId -o tsv)
az keyvault set-policy \
--name my-keyvault \
--object-id $IDENTITY_ID \
--secret-permissions get list
# Añadir secreto
az containerapp secret set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--secrets db-connection="Server=...;Password=..."
# Referenciar en variable de entorno
az containerapp update \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--set-env-vars "DB_CONNECTION=secretref:db-connection"
# Habilitar autenticación con Entra ID
az containerapp auth update \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--enable \
--action RequireAuthentication \
--aad-tenant-id <TENANT_ID> \
--aad-client-id <CLIENT_ID> \
--aad-client-secret <CLIENT_SECRET>
# Limitar acceso por IP
az containerapp ingress access-restriction set \
--name $APP_NAME \
--resource-group $RESOURCE_GROUP \
--rule-name office-network \
--ip-address 203.0.113.0/24 \
--action Allow
Azure Container Apps en 2025 es una plataforma madura y completa para ejecutar aplicaciones Cloud Native sin la complejidad de gestionar Kubernetes directamente. Con las incorporaciones de 2024-2025, se ha convertido en una opción viable para:
✅ Sí, si:
❌ No, si:
En resumen: si no necesitas acceso directo a Kubernetes API y trabajas con aplicaciones Cloud Native, Azure Container Apps es tu servicio en Azure.
Artículo actualizado en octubre de 2025. Para la versión original de 2022, ver Introducción a Azure Container Apps (Keepler Blog).
Al intentar hacer git pull, te encuentras con el siguiente error:
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
Este mensaje indica que tu rama local y la rama remota han divergido: ambas tienen commits únicos que la otra no tiene. Git necesita que decidas cómo combinar estos cambios.
La divergencia sucede cuando:
mainEjemplo visual:
Local: A---B---C---L1
^(tu commit local)
Remote: A---B---C---R1---R2---R3
^(commits del remoto vía PR)
Antes de resolver, es crucial entender qué ha divergido.
Este comando descarga los cambios del remoto sin fusionarlos.
Verifica qué commits están únicamente en cada lado:
# Commits que tienes localmente pero no están en el remoto
git log origin/main..main --oneline
# Commits que están en el remoto pero no tienes localmente
git log main..origin/main --oneline
# Ver el commit actual local
git rev-parse HEAD
# Ver el commit actual remoto
git rev-parse origin/main
En nuestro caso, obtuvimos:
--- Commits en local, no en remoto ---
81e3b93 feat: add new feature for data processing
--- Commits en remoto, no en local ---
9d3e3e9 Merge pull request #42 from team/feature/update-docs
285a538 Complete documentation review - all documents validated
000b9cb Fix configuration and add new parameters
a7694d3 Initial implementation plan
Interpretación: El remoto tiene un PR fusionado con 4 commits que no tenemos localmente, y nosotros tenemos 1 commit local que el remoto no tiene.
Existen tres estrategias principales:
Cuándo usarlo: Cuando trabajas con un equipo y quieres preservar toda la historia, incluyendo los merge commits de PRs.
Ventajas: - ✅ Preserva la historia completa (incluidos merge commits) - ✅ Muestra claramente cuándo se integraron features - ✅ Más seguro: no reescribe historia
Desventajas: - ⚠️ Crea un commit de merge adicional - ⚠️ Historia no completamente lineal
Comando:
Si prefieres revisar/editar el mensaje de merge:
Cuándo usarlo: Cuando trabajas solo o en una feature branch que aún no has compartido públicamente.
Ventajas:
- ✅ Historia completamente lineal
- ✅ Más limpia para revisar con git log
Desventajas: - ⚠️ Reescribe commits locales (cambian sus SHAs) - ⚠️ Puede causar problemas si ya compartiste estos commits - ⚠️ Pierdes el contexto de cuándo se integró el PR remoto
Comando:
Cuándo usarlo: Cuando quieres asegurarte de que solo hagas pull si no hay divergencia.
Comando:
Si hay divergencia, fallará y tendrás que decidir merge o rebase manualmente.
# Sincronizar con remoto
git fetch origin main --tags
# Ver divergencias
echo "--- Commits locales únicos ---"
git log origin/main..main --oneline
echo "--- Commits remotos únicos ---"
git log main..origin/main --oneline
Para equipos colaborativos con PRs, merge es la opción más segura:
Si hay conflictos, Git te lo indicará:
Auto-merging some-file.md
CONFLICT (content): Merge conflict in some-file.md
Automatic merge failed; fix conflicts and then commit the result.
Pasos para resolver:
a) Abre el archivo con conflictos:
b) Edita manualmente para quedarte con el contenido correcto
c) Marca como resuelto:
d) Completa el merge:
Deberías ver algo como:
* 3e1ed57 (HEAD -> main) Merge remote-tracking branch 'origin/main' into main
|\
| * 9d3e3e9 (origin/main) Merge pull request #42
| * 285a538 Complete documentation review
| * 000b9cb Fix configuration parameters
| * a7694d3 Initial implementation plan
* | 81e3b93 feat: add new feature for data processing
|/
* d140dce feat: improved monthly workflow
Salida esperada:
Enumerating objects: 15, done.
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.08 KiB | 1.08 MiB/s, done.
Total 7 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), completed with 4 local objects.
To https://github.com/tu-usuario/tu-repositorio.git
9d3e3e9..3e1ed57 main -> main
Si tienes workflows de CI/CD u otros archivos críticos, verifica su integridad:
# Buscar un patrón específico en un archivo
grep -n "specific_pattern" .github/workflows/deploy.yml
# O leer el archivo completo
cat .github/workflows/deploy.yml
Si quieres establecer una estrategia por defecto para futuros git pull:
Añade --global:
Esto te mantiene informado de cambios remotos sin afectar tu trabajo local.
En lugar de trabajar directamente en main:
git checkout -b feature/my-feature
# ... hacer commits ...
git push origin feature/my-feature
# Abrir PR en GitHub
Esto evita divergencias en main.
git fetch origin
git status
# Si hay cambios remotos, decide merge o rebase
git pull
# Ahora puedes pushear
git push
# ❌ NUNCA en main compartido
git push --force origin main
# ✅ OK solo en tus feature branches
git push --force origin feature/my-feature
# Ver el reflog (historial de cambios de HEAD)
git reflog
# Volver a un estado anterior
git reset --hard HEAD@{2}
# Guardar cambios temporalmente
git stash
# Sincronizar con remoto
git pull
# Recuperar tus cambios
git stash pop
git fetch origin main --tagsgit log origin/main..main --oneline y git log main..origin/main --onelinegit merge origin/main o git rebase origin/maingit log --graph --oneline -10git push origin mainLa divergencia de ramas es un escenario común en equipos colaborativos. La clave está en:
git log)En entornos colaborativos con Pull Requests, merge es generalmente la opción más segura ya que preserva la historia completa y evita reescribir commits que otros pueden estar usando como base.
Esta entrada explica de forma práctica qué es el Power BI On-Premises Data Gateway Standard, su arquitectura básica, y cómo realizar una instalación estándar y configurarlo para refrescos y conexiones seguras desde el servicio de Power BI. Está orientada a administradores y responsables de plataforma que necesiten conectar fuentes de datos locales a Power BI sin usar soluciones de red avanzadas (no cubre la instalación en Virtual Network Data Gateway ni escenarios sovereign).
El On-Premises Data Gateway es un componente que actúa como puente entre los servicios cloud de Microsoft (por ejemplo, Power BI, Power Automate, Power Apps) y tus datos que residen en la red local o en entornos no accesibles públicamente. Proporciona un canal saliente seguro (TLS) para permitir conexiones desde la nube hacia los orígenes de datos on‑premises sin abrir puertos entrantes en tu red.
Principales funciones: - Habilitar refrescos programados de datasets de Power BI. - Soportar consultas en vivo (DirectQuery/Live Connection) hacia orígenes compatibles. - Permitir que flujos y aplicaciones en cloud accedan a bases de datos y servicios internos.
flowchart LR
PB["Power BI Service"]
AZ["Azure Relay / Service Bus"]
GW["On-Premises Gateway"]
DB["Origen de datos"]
DB --> GW
GW --> | TLS saliente | AZ
AZ --> PB
flowchart LR
subgraph Cloud["Servicio Cloud"]
PB["Power BI Service"]
end
subgraph Cluster["Cluster de Gateways (HA)"]
GW1["Gateway - Nodo 1"]
GW2["Gateway - Nodo 2"]
GW3["Gateway - Nodo N"]
end
subgraph OnPrem["Red On-Premises"]
DB["(Origen de datos)"]
end
AZ["Azure Relay / Service Bus"]
GW1 --- GW2
GW2 --- GW3
AZ --> PB
Cluster --> | TLS saliente | AZ
DB --> Cluster
Note
Físicamente el Gateway establece conexiones salientes TLS hacia los servicios de Azure (Azure Service Bus / Azure Relay). Las solicitudes brokered se mantienen gracias a las conexiones salientes iniciadas por el gateway.
Los pasos siguientes describen una instalación típica y segura de un Gateway estándar:
Descargar el instalador del gateway desde el sitio oficial de Microsoft.
Ejecutar el instalador en el servidor destinado
Acepta los términos y elige la instalación estándar cuando se solicite.
Iniciar sesión y registrar el gateway
Registra el gateway en tu tenant y proporciona un nombre descriptivo para el gateway.
Definir la clave de recuperación
El asistente pedirá que crees una "recovery key". Guárdala en un lugar seguro: es necesaria para migrar o restaurar el gateway.
Elegir cuenta de servicio (opcional)
Puedes ejecutar el servicio con la cuenta de sistema local por defecto o configurar una cuenta de dominio/service account con los permisos mínimos necesarios para acceder a los orígenes de datos.
Verificar conectividad
Asegúrate de que el servidor puede establecer conexiones TLS salientes a los endpoints de Microsoft (comprobar reglas de firewall/proxy si existen).
(Opcional) Agregar nodos al cluster
Consejos prácticos: - Centraliza la definición de data sources para facilitar el mantenimiento. - Usa credenciales de tipo "service principal" o cuentas administradas cuando el origen lo permita y por seguridad.
EPAC tiene una opción muy útil llamada "Document All Assignments" que genera Markdown y CSV con todas las asignaciones de policy. Pero hay dos detalles importantes que conviene saber:
1) Antes no se podían excluir tipos enteros de scope (por ejemplo: todas las
subscriptions o resourceGroups) desde la configuración.
2) He subido una PR para solucionarlo: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056
Aquí lo que cambia, rápido y claro.
Si usas documentAllAssignments y quieres evitar documentar todo lo que hay a
nivel de suscripción o de resource groups, la versión anterior obligaba a
listar cada id con skipPolicyAssignments o a procesar el CSV resultante.
En entornos grandes eso resulta muy tedioso y genera mucho ruido en los
informes.
excludeScopeTypes en la configuración de documentAllAssignments.
Con esto se puede indicar que no se documenten assignments que estén en
subscriptions o en resourceGroups.StrictMode (switch) en los scripts. Por defecto está activado. Si lo
desactivas (-StrictMode:$false) el script no aborta cuando falta alguna
definición; registra avisos y continúa. Útil en pipelines de prueba.skipPolicyAssignments/skipPolicyDefinitions
(funcionan mejor con arrays u objetos) y corrige bugs menores (p. ej.
convertir markdownMaxParameterLength a entero).PR: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056
Antes tenías que usar algo así:
{
"documentAssignments": {
"documentAllAssignments": [
{
"pacEnvironment": "EPAC-Prod",
"skipPolicyAssignments": [],
"skipPolicyDefinitions": ["/providers/.../policySetDefinitions/..."]
}
]
}
}
Después basta con añadir excludeScopeTypes:
{
"documentAssignments": {
"documentAllAssignments": [
{
"pacEnvironment": "EPAC-Prod",
"excludeScopeTypes": ["subscriptions", "resourceGroups"],
"skipPolicyAssignments": [],
"skipPolicyDefinitions": ["/providers/.../policySetDefinitions/..."]
}
]
}
}
Y si quieres pruebas rápidas sin que el pipeline falle por referencias rotas:
excludeScopeTypes para reducir ruido cuando necesites una vista global.excludeScopeTypes con exemptions: esto solo evita que se
documente; no evita que la policy se aplique. Para eso usa exemptions.StrictMode activado en producción (ayuda a detectar referencias rotas).skipPolicyAssignments para exclusiones puntuales que conozcas por id.La mejora es pequeña pero práctica: menos limpieza manual, informes más útiles. Si quieres puedo:
PR de referencia: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056