Dockerfile y después escribes un manifiesto que apunta a esa imagen y declara su puerto, memoria, healthcheck y preguntas. En este tutorial empaquetas una pequeña aplicación web que guarda un contador de visitas en el disco persistente y terminas con una plantilla privada que cualquiera de tu cuenta puede desplegar en unos pocos clics.
Usa una plantilla de imagen cuando la aplicación necesite otro lenguaje o versión, paquetes del sistema, su propio proceso de arranque, o cuando empaquetes software ya hecho. Si basta con código fuente simple, una plantilla de código es más sencillo y no usa un cupo de imagen.
Antes de empezar
La CLI de Vertra con la sesión iniciada con una clave de API que tenga los scopes
templates:read, templates:write y templates:deploy, además de los scopes que compilan imágenes.Un plan que pueda crear imágenes Docker y plantillas privadas (consulta Planes y límites). Cada cuenta mantiene hasta 5 plantillas privadas.
Conoces las reglas de las imágenes Docker personalizadas: rutas escribibles, usuario
1000:1000, la variable PORT y lo que rechaza el build.Cada imagen en uso ocupa un cupo de imagen en la cuenta que la usa, sin importar cuántas aplicaciones se ejecuten a partir de ella. Cuando despliegas tu propia plantilla, la imagen ya es tuya; quienes la reciben mediante un enlace obtienen su propia copia y usan un cupo cada uno.
Paso a paso
1
Escribe una aplicación que siga las reglas de la plataforma
Una imagen se ejecuta con el mismo aislamiento que cualquier aplicación: el sistema de archivos raíz es de solo lectura, el usuario es siempre El
1000:1000, /app es el único disco persistente y el servidor debe escuchar en la variable PORT. Crea esta carpeta:server.js sirve la página, cuenta las visitas en un archivo dentro de /app/data y responde a /healthz para el healthcheck:server.js
Dockerfile mantiene el programa fuera de /app (todo lo que la imagen ponga en /app queda oculto por el disco persistente cuando se ejecuta la aplicación) y no usa USER, VOLUME ni HEALTHCHECK, que la plataforma ignora o rechaza:Dockerfile
2
Compila la imagen en la plataforma
La plantilla no lleva el Encuentra el id de la imagen con
Dockerfile: hace referencia a una imagen que ya existe en tu cuenta. Compílala desde la carpeta:vertra image list. Espera a que el build esté en success; si falla, el motivo aparece en el log. Los archivos .env* se eliminan del contexto y se respeta .dockerignore. Cada build correcto se convierte en una nueva versión de la misma imagen, con el mismo id.3
Escribe el manifiesto
Crea Los campos que difieren de una plantilla de código:
vertracloud.template.yaml. El valor de source.image es el id de tu imagen; sustituye el id de ejemplo por el tuyo:vertracloud.template.yaml
source.context y los digests de imagen (@sha256:...) pertenecen a las plantillas del catálogo público, donde la imagen se fija por digest y se compila desde la carpeta de la plantilla. En una plantilla privada, la fuente es la imagen de tu cuenta. El último tutorial muestra cómo una plantilla privada pasa a ser una del catálogo.4
Valida
validate no puede ver, como una imagen que no es tuya (IMAGE_NOT_FOUND) o que aún no se ha compilado (IMAGE_NOT_READY).5
Crea la plantilla y despliégala
/healthz e imprime los outputs. Abre la dirección y recarga: el contador debe subir. Reinicia la aplicación desde el panel y recarga de nuevo: el número se conserva, porque /app es persistente.6
Lanza una versión nueva
Cambia el código, ejecuta
vertra image rebuild <image-id> --context ., espera a success, sube version en el manifiesto y ejecuta vertra template create --template hello-counter --changelog "Describe the change". La nueva versión de la plantilla fija la nueva versión de la imagen. Las aplicaciones creadas a partir de la plantilla ven “Nueva versión disponible” y se actualizan cuando su propietario lo decide, con un snapshot de seguridad previo.Solución de problemas
Próximos pasos
- Requisitos y plan: cómo
ram,weby la imagen determinan el plan y los cupos necesarios. - Ajustes de despliegue: cuándo bloquear el blue-green y exigir rollback con datos.
- Buenas prácticas: dónde van los datos, la raíz de solo lectura, el usuario 1000 y el puerto.
- Referencia del manifiesto: todos los campos de un servicio de aplicación.
- Imágenes Docker personalizadas: las reglas de build, las versiones y el rollback de la propia imagen.
- Siguiente tutorial: un stack con Postgres y Redis.