Servicios

Cada proyecto en Swisblade se compone de uno o mas servicios. Un servicio es una aplicacion que compilas desde codigo fuente (type: "app") o una imagen Docker pre-compilada (type: "custom").

Servicios de aplicacion

Los servicios de aplicacion se compilan desde tu repositorio Git. Swisblade clona el repo, construye una imagen Docker y la ejecuta.

{
  "api": {
    "source": { "repo": "github.com/you/api.git", "ref": "main" },
    "type": "app",
    "runtime": "node",
    "port": 3000,
    "public": true,
    "needs": ["postgres"]
  }
}

Proceso de compilacion

1. Swisblade clona tu repositorio en el ref especificado (branch, tag o commit SHA).
2. Si existe un Dockerfile en la raiz del repo, se usa para compilar la imagen.
3. Si no hay Dockerfile, Swisblade usa Nixpacks para detectar automaticamente tu stack tecnologico y generar uno.

Runtimes soportados

Runtime	Valor de runtime	Auto-instrumentacion
Node.js	"node"	OpenTelemetry para Express, Fastify, Hono, etc.
Python	"python"	OpenTelemetry para Flask, FastAPI, Django, etc.
Java	"java"	OpenTelemetry Java agent

El campo runtime habilita la instrumentacion automatica de observabilidad. Tu aplicacion envia trazas y metricas sin ningun cambio en el codigo.

Versionado con ref

El campo ref controla que version de tu codigo se despliega:

"source": { "repo": "github.com/you/api.git", "ref": "main" }

Puedes usar:

• Nombres de branch: "main", "develop" — despliega el ultimo commit en ese branch.
• Tags: "v1.2.0", "release-2024-01" — fija una version especifica.
• Commit SHAs: "a1b2c3d" — fija un commit exacto.

Fija versiones en produccion

Usa tags o commit SHAs para despliegues en produccion. Los nombres de branch despliegan el ultimo commit, que puede cambiar entre despliegues.

Servicios custom

Los servicios custom ejecutan imagenes Docker pre-compiladas. Usalos para herramientas de terceros, bases de datos o cualquier servicio que no compiles tu mismo.

{
  "search": {
    "type": "custom",
    "image": "elasticsearch:8.12.0",
    "port": 9200
  }
}

Campo	Descripcion
image	Imagen y tag de Docker Hub (por ejemplo, rabbitmq:3-management)
port	El puerto en el que escucha el servicio dentro del contenedor
protocol	Protocolo para URLs generadas (default: "http", usa "amqp" para colas de mensajes, etc.)

Ejemplos

RabbitMQ con UI de administracion:

{
  "mq": {
    "type": "custom",
    "image": "rabbitmq:3-management",
    "protocol": "amqp",
    "port": 5672
  }
}

MongoDB:

{
  "mongo": {
    "type": "custom",
    "image": "mongo:7",
    "port": 27017
  }
}

Conexiones entre servicios

connects_to

Cuando un servicio necesita comunicarse con otro, declaralo en connects_to:

{
  "api": {
    "type": "app",
    "connects_to": ["worker", "search"]
  },
  "worker": { "type": "app", "port": 8080 },
  "search": { "type": "custom", "image": "elasticsearch:8.12.0", "port": 9200 }
}

El servicio API recibe:

• WORKER_URL=http://worker:8080
• SEARCH_URL=http://search:9200

needs

Para bases de datos e infraestructura gestionada, usa needs en su lugar. Ver Bases de Datos.

{
  "api": {
    "needs": ["postgres", "redis"]
  }
}

El servicio API recibe:

• DATABASE_URL=postgresql://proj_xxx:password@platform-postgres:5432/proj_xxx
• REDIS_URL=redis://proj_xxx:password@platform-redis:6379/0
• REDIS_KEY_PREFIX=proj_xxx:

Networking

Los servicios dentro del mismo proyecto pueden comunicarse usando sus nombres de servicio como hostnames (por ejemplo, http://worker:8080). Esto funciona a traves del DNS interno de Docker.

Los servicios de diferentes proyectos estan aislados entre si: no pueden comunicarse directamente.