Ejecutando el Servidor de Construcción

El servidor de construcción que impulsa los lanzamientos automatizados se incluye con el producto — no hay nada extra que instalar o licenciar.

Iniciándolo

cd docker
cp build.env.example build.env
docker compose --profile build up -d build-agent build-dind
./build/bootstrap-sandbox-image.sh

El script de arranque construye la imagen del sandbox y la carga en el demonio de construcción aislado — ejecútalo una vez después de iniciar los contenedores, y nuevamente cada vez que cambie la imagen del sandbox.

Configurando Claves

Establece dos claves en docker/build.env:

RELEASE_RUNNER_KEY
RELEASE_RUNNER_CALLBACK_KEY

Ambas deben coincidir exactamente con las propias variables de entorno RELEASE_RUNNER_* de la aplicación. El agente de construcción solo carga este archivo — nunca ve la base de datos, caché o credenciales de firma de licencia de tu aplicación, solo estas dos claves.

Dos Contenedores, Dos Redes

build-agent — recibe solicitudes de construcción firmadas de la aplicación y controla el demonio de Docker aislado. Se encuentra en la red de la aplicación y en la red de construcción.
build-dind — un demonio aislado de Docker-in-Docker donde realmente se ejecutan todos los sandboxes. Nunca se une a la red de la aplicación y no publica puertos.

Ejecutándose en un Host Separado

El servidor de construcción no tiene que compartir una máquina con el resto de la plataforma. Despliega el mismo docker/ compose en un host separado con solo el perfil build habilitado, luego apunta la RELEASE_RUNNER_URL de la aplicación a ese host — no se requieren cambios de código.

Ejecutando el Servidor de Construcción