Primeros pasos
Conceptos básicos
Codara organiza todo en cinco niveles, unos dentro de otros. En cuanto entiendes la jerarquía, el resto del producto se deduce de ella.
La jerarquía
Organization Acme Inc.└── Workspace Customer apps └── Project website └── Environment production ├── Service web ├── Service api ├── Database main-db └── Job nightly-reportTodo lo que está dentro de un mismo entorno se ejecuta en el mismo sitio y puede comunicarse de forma privada. Todo lo que queda fuera está aislado.
Una nota sobre los nombres
client y app. Los ejemplos de comandos usan exactamente esos nombres de la API.Organización
El ámbito de la cuenta que agrupa a las personas, las invitaciones, los roles, la facturación y la propiedad. Cada persona inicia sesión con su propia identidad y se une a una organización mediante una invitación.
Espacio de trabajo
Un ámbito dentro de una organización al que pertenecen proyectos, datos de contacto, controles de gasto e historial de costes. Un espacio de trabajo puede representar a un cliente, a un departamento de una empresa o a productos internos. Internal es un espacio de trabajo, no un cliente.
En la API y la CLI actuales, los espacios de trabajo aparecen como clients. El slug es único a nivel global y forma parte de las URL por defecto de los servicios, así que puede verlo quien use tus apps.
Proyecto
Un grupo de servicios relacionados dentro de un espacio de trabajo. Al crear una cuenta de cliente se crea un espacio de trabajo por defecto, vacío. Los proyectos son independientes: crea uno directamente en ese espacio de trabajo por defecto, o añade otro espacio de trabajo vacío (opcional) cuando necesites un ámbito organizativo aparte.
Un proyecto por producto, y normalmente un repositorio
Cuando vayas a añadir un servicio, la respuesta por defecto es crear un proyecto nuevo para él. Añádelo a uno existente solo si el nuevo servicio pertenece de verdad a ese mismo producto: por ejemplo, un worker para su cola o sus jobs programados.
Codara lo exige en lugar de adivinar. Si un espacio de trabajo tiene más de un proyecto y no dices cuál usar, la petición se rechaza y muestra los candidatos en vez de elegir uno. Nada acaba en un proyecto por accidente.
Los slugs de proyecto tienen hasta 32 caracteres y son únicos dentro de su espacio de trabajo. Los nombres default e internal están reservados. Un proyecto solo se puede eliminar cuando ya no tiene apps ni bases de datos.
Entorno
Un destino de deploy dentro de un proyecto: production, staging, etc. Todos los proyectos empiezan con un entorno production.
Los entornos son el límite de aislamiento. Dos entornos del mismo proyecto tienen apps, bases de datos y variables de entorno separadas. Promover una release de uno a otro es una operación nativa que reutiliza exactamente la misma imagen en lugar de volver a hacer el build; consulta Entornos.
Hay dos tipos de entorno: los persistentes, que creas tú, y los de preview, que se pueden crear automáticamente para cada pull request si el proyecto lo activa.
App
Un servicio en marcha: una imagen de contenedor, sus réplicas, su puerto, sus variables de entorno y sus dominios. Una app pertenece exactamente a un entorno.
El mismo servicio lógico suele existir una vez por entorno: una app web en production y otra en staging. Codara las agrupa bajo un servicio compartido, que es al que se asocian las variables compartidas de todo el entorno.
Los nombres de las apps tienen hasta 63 caracteres, en minúsculas, separados por guiones y únicos dentro de su entorno.
Deploy
Un intento de build y release de una app. Los deploys solo se añaden, nunca se modifican: hacer rollback o promover crea un deploy nuevo que apunta a una imagen anterior en lugar de reescribir el historial, así que la línea de tiempo siempre refleja lo que pasó de verdad.
| Estado | Significado |
|---|---|
| queued | Esperando un hueco para el build. |
| cloning | Descargando tu repositorio en el commit de destino. |
| building | Generando la imagen de contenedor. |
| pushing | Subiendo la imagen al registro. |
| deploying | La imagen está lista; la nueva versión se está desplegando. |
| running | En marcha y sirviendo tráfico. |
| failed | Ha fallado el build o el rollout. La release anterior sigue sirviendo tráfico. |
| cancelled | Se detuvo antes de promoverse. |
| skipped | Un push que no coincidía con ninguna ruta vigilada. |
Que el build termine no significa que esté en marcha
running únicamente cuando los pods nuevos se han desplegado de verdad y están sanos. Un rollout que nunca llega a estar sano se marca como fallido, y tu versión anterior sigue sirviendo tráfico sin que nada la toque.Otros recursos
Base de datos
Una instancia gestionada de Postgres, MySQL, MariaDB, MongoDB o Redis que vive en un entorno. Al conectarla a una app, sus credenciales se inyectan como variables de entorno. Consulta Bases de datos.
Volumen
Un disco persistente montado en una ruta de una app, para el estado que tiene que sobrevivir a los reinicios. Una app con volumen funciona con una sola réplica. Consulta Almacenamiento.
Bucket
Almacenamiento de objetos compatible con S3 para los archivos que suben tus usuarios y otros blobs. Ningún plan de autoservicio incluye buckets; están disponibles mediante un acuerdo aparte. Consulta Almacenamiento.
Job
Una tarea que se ejecuta hasta terminar en lugar de servir tráfico, ya sea una sola vez o según una programación cron. Consulta Jobs y cron.
Reglas de nombres
| Recurso | Longitud | Reglas |
|---|---|---|
| Slug del espacio de trabajo | 2–63 | Único a nivel global. Letras minúsculas, dígitos y guiones. Se convierte en un nombre DNS. |
| Slug del proyecto | 1–32 | Único en cada espacio de trabajo. default e internal están reservados. |
| Slug del entorno | 1–32 | Único en cada proyecto. default está reservado. |
| Nombre de la app | 1–63 | Único en cada entorno. |
La longitud combinada está limitada a 63 caracteres
Cómo se indica cada recurso
La mayoría de los comandos de la CLI y de las llamadas a la API necesitan saber a qué espacio de trabajo, proyecto y entorno te refieres. Si no los indicas, Codara usa tu espacio de trabajo por defecto y el entorno production. El flag de compatibilidad se sigue llamando --client.
# Explicit$ codaracloud apps list --client my-workspace # Scope flags where a command supports them$ codaracloud apps update web --client my-workspace --project website --env staging --port 3000Los flags de ámbito no están disponibles en todas partes
env, domains, logs, metrics y apps get) no aceptan ningún flag de ámbito y siempre usan tu espacio de trabajo por defecto y el entorno production. Si tienes el mismo nombre de app en más de un entorno, usa la consola o indica el ámbito en los comandos que lo permiten. Tampoco hay forma de guardar un espacio de trabajo o entorno «actual» entre una ejecución y otra.Red privada
Las apps del mismo entorno pueden comunicarse entre sí por la red interna sin pasar por internet. Cada app recibe su dirección privada como variable de entorno:
CODARA_PRIVATE_URL: la URL interna completa.CODARA_PRIVATE_DOMAIN: el hostname interno.
El tráfico entre entornos, proyectos o espacios de trabajo está bloqueado por defecto.
El tráfico privado no despierta una app dormida
Última actualización: