El problema: una imagen que funciona no es un servicio en ejecucion
Tener una API que se construye limpiamente en una imagen de contenedor es el 20 por ciento facil; llevarla a produccion es el otro 80. Tradicionalmente eso significa alquilar una VM, instalar un runtime, configurar un reverse proxy, obtener y renovar certificados TLS, abrir los puertos correctos, agregar un process manager para que la app reinicie tras un crash, conectar la recoleccion de logs, y montar guardia contra atacantes que encuentran la caja horas despues de que este en linea. Cada uno de esos pasos es trabajo de infraestructura indiferenciado que no tiene nada que ver con el trabajo real de tu API, y cada uno es un lugar para equivocarse sutilmente en seguridad o confiabilidad. Container Apps existe para colapsar toda esa lista en unos pocos campos.
Como lo resuelve cdn.com.tr: contenedores administrados detras del edge
Le das a la plataforma una imagen, un puerto, y un healthcheck, y ella corre el contenedor, enruta trafico hacia el a traves del edge, y lo mantiene vivo. El TLS lo maneja Auto SSL, el punto de entrada publico es la ruta edge en lugar del contenedor crudo, y el WAF filtra trafico malicioso antes de que llegue a tu servicio. La configuracion llega como variables de entorno y secrets inyectados en tiempo de ejecucion, el escalado es un numero de replicas que defines, y los logs y el status se muestran en el panel. El resultado es que lo unico de lo que eres responsable es de tu imagen de aplicacion; las preocupaciones de servidor, proxy, certificado, y firewall las absorbe la plataforma.
Healthchecks: la red de seguridad del deploy
El healthcheck es lo que convierte un deploy de una esperanza en una operacion controlada. Cuando lanzas una version nueva, la plataforma arranca el contenedor y sondea tu endpoint de salud, y solo enruta trafico a la instancia nueva una vez que ese endpoint reporta saludable. Un build que crashea al arrancar, no puede alcanzar su base de datos, o le falta un secret requerido falla la verificacion y no se pone en rotacion, asi que un deploy roto se atrapa en el rollout en lugar de en tus usuarios. Por eso el healthcheck deberia verificar disponibilidad real — dependencias alcanzables, configuracion presente — en lugar de simplemente devolver 200 incondicionalmente. Un healthcheck significativo es la diferencia entre redeploys seguros y interrupciones silenciosas.
Entorno vs. secrets: configuracion sin fugas
Las APIs necesitan configuracion — URLs de base de datos, claves de terceros, feature flags — y la forma incorrecta de proveerla es hornearla en la imagen o comitearla al repositorio, donde vive para siempre en capas e historial. La plataforma separa las variables de entorno simples de los secrets: la configuracion no sensible entra como entorno, mientras que contraseñas, tokens, y API keys se almacenan como secrets y se inyectan en tiempo de ejecucion por clave, nunca se muestran de vuelta ni se escriben en tu build. Esto significa que la misma imagen puede moverse entre entornos con configuracion diferente, tus credenciales se mantienen fuera del control de versiones, y rotar un secret es una accion de plataforma en lugar de una carrera de rebuild-y-redeploy.
Escalado, logs, y el ciclo operativo
Una vez que la API esta en vivo, correrla es cuestion de unos pocos controles en lugar de administracion de servidor. Eliges un plan de recursos y defines cuantas replicas correr, escalando hacia arriba para un lanzamiento o un pico de trafico y hacia abajo despues. Los logs se transmiten en el panel para que puedas rastrear una solicitud, depurar un 500, o confirmar que un deploy realmente se aplico, y el status te muestra si el servicio esta saludable y cuando se reinicio por ultima vez. Cada redeploy pasa por la misma verificacion de healthcheck, asi que lanzar un build nuevo es una accion repetible y observable — subes la imagen, observas que la verificacion pase, y confirmas en los logs, sin nunca hacer SSH a nada.
Conectando storage y datos
La mayoria de las APIs necesitan algun lugar para guardar estado, y el servicio compone limpiamente con el resto de la plataforma para eso. Puedes conectar un bucket de Object Storage al contenedor como variables de entorno para que lea y escriba medios o documentos directamente, y puedes conectar una base de datos administrada o Redis para que el servicio tenga persistencia y cache sin que tampoco operes esos. Como estos se conectan a traves de la plataforma y se entregan como configuracion inyectada, la API se mantiene como una imagen sin estado que se puede escalar y redesplegar libremente mientras sus datos viven en servicios administrados a su lado.
Como configurarlo, paso a paso
Apunta a tu imagen
En el panel crea una Container App y referencia tu imagen prearmada (por ejemplo myorg/api:1.4) desde un registry publico o privado. Para imagenes privadas, agrega una credencial de registry una vez para que la plataforma pueda extraerla. Define el puerto en el que escucha tu API para que el edge sepa a donde enviar el trafico.
Define el healthcheck
Dale a la app una ruta de healthcheck como /health o /ready que devuelva 200 solo cuando el servicio realmente pueda servir. Esto es lo que la plataforma usa para decidir si un deploy nuevo esta saludable antes de que reciba trafico, asi que hazlo verificar las cosas que realmente importan, como la conectividad a la base de datos.
Define entorno y secrets
Agrega configuracion no sensible como variables de entorno y valores sensibles — API keys, contraseñas de base de datos, tokens — como secrets, para que se inyecten en tiempo de ejecucion en lugar de hornearse en la imagen o comitearse a tu repositorio. Los valores de secrets se almacenan de forma segura y se referencian por clave, nunca se vuelven a mostrar.
Despliega y observa el healthcheck
Dispara el deploy desde el panel o con cdnctl. El contenedor se inicia, el healthcheck se sondea, y el servicio se marca listo — y solo se pone en rotacion — una vez que pasa, asi que un build roto no toma trafico silenciosamente.
Conecta un dominio con Auto SSL y WAF
Expon el servicio para obtener una URL gratuita name.cdn.com.tr con HTTPS automatico, o conecta tu propio dominio y deja que Auto SSL emita el certificado. Activa el WAF para que la API se ubique detras del filtrado edge, y el contenedor origin solo es accesible a traves de esa ruta edge.
Escala y observa
Ajusta el plan de recursos y el numero de replicas para la carga que esperas, y usa logs y status para observar deploys, reinicios, y comportamiento en tiempo de ejecucion. Los redeploys siguen el mismo camino controlado por healthcheck, asi que lanzar una version nueva es una operacion rutinaria y observable.
Escenarios de ejemplo
Una API JSON se publica desde su imagen detras de un dominio con Auto SSL y WAF, dandole al frontend un endpoint HTTPS estable y asegurado sin ningun servidor que mantener.
Un receptor de webhooks, un procesador de imagenes, o un servicio de auth corre de forma aislada con su propio escalado y secrets, desplegado y redesplegado independientemente de todo lo demas.
Un equipo de producto levanta un contenedor desde un tag de imagen para obtener una URL HTTPS compartible para una demo, y luego lo desmantela o redespliega a medida que avanza el build.
Preguntas frecuentes
La plataforma construye mi imagen, o yo traigo una?
Traes una imagen prearmada de un registry. Container Apps corre y enruta la imagen que proporcionas; si es privada, agregas una credencial de registry una vez para que la plataforma pueda extraerla durante el deploy.
Que pasa si mi deploy nuevo esta roto?
Falla el healthcheck y no se pone en rotacion, asi que el trafico sigue yendo a la version que funciona. Un contenedor que crashea al arrancar o no puede alcanzar sus dependencias se atrapa en el rollout en lugar de servir errores a tus usuarios.
Como mantengo las API keys y contraseñas de base de datos fuera de mi codigo?
Guardalas como secrets, que se inyectan en el contenedor en tiempo de ejecucion por clave y nunca se hornean en la imagen ni se comitean a tu repositorio. La configuracion no sensible entra como variables de entorno simples, asi que la misma imagen corre en entornos diferentes con configuracion diferente.
Mi API puede alcanzar una base de datos o un bucket de Object Storage?
Si. Puedes conectar un bucket de Object Storage al contenedor como variables de entorno y conectar una base de datos administrada o Redis, asi que el servicio tiene storage, persistencia, y cache mientras se mantiene como una imagen sin estado y redesplegable.
Como manejo un pico de trafico?
Sube el numero de replicas y, si hace falta, el plan de recursos de la app. Como el trafico entra a traves del edge y los contenedores se ubican detras de el, escalas el numero de instancias para ajustar a la carga y vuelves a escalar hacia abajo despues.
Puedo desplegar desde la linea de comandos en lugar del panel?
Si. cdnctl maneja las mismas operaciones de contenedores desde tu terminal — desplegar, redesplegar, escalar, e inspeccionar — asi que puedes scriptear deploys o correrlos desde CI obteniendo el mismo comportamiento controlado por healthcheck que el panel.