Preguntas Frecuentes sobre la Integración de ServBay y Docker (FAQ)

Al desarrollar sitios web de forma local con ServBay, es posible que desees aprovechar Docker para crear entornos de desarrollo con contenedores. Este FAQ aclara las dudas habituales al combinar ServBay y Docker en macOS y Windows, abordando el acceso desde Docker a servicios gestionados por ServBay y el uso de ServBay como proxy inverso para aplicaciones dentro del contenedor.

P1: ¿Por qué ServBay modifica el archivo `hosts` de mi sistema? ¿Puedo evitarlo?

ServBay agrega entradas al archivo hosts del sistema (por ejemplo, mysite.servbay.demo 127.0.0.1) para que puedas acceder a tus sitios locales a través de dominios personalizados como mysite.servbay.demo. Estos sitios se ejecutan realmente en la dirección 127.0.0.1 de tu máquina.

Sin embargo, debido al funcionamiento de Docker, este lee el archivo hosts del sistema anfitrión (macOS o Windows), haciendo que mysite.servbay.demo se resuelva como 127.0.0.1. Así, Docker termina accediendo al servicio incorrecto: el interior del propio contenedor.

Fundamento principal:

Cuando creas un nuevo sitio en ServBay y le asignas un dominio (por ejemplo, example.servbay.demo), ServBay lo apunta automáticamente a 127.0.0.1.
Este método facilita el acceso a los sitios locales con un nombre amigable. Si no se modifica el archivo hosts, solo podrías acceder por direcciones como http://127.0.0.1:PUERTO, sin poder usar dominios personalizados.

¿Es posible evitarlo?

En teoría, podrías eliminar manualmente las entradas que ServBay añade al archivo hosts, pero ya no podrías acceder a los sitios locales mediante el dominio configurado, lo cual contradice el propósito de ServBay: ofrecer una experiencia sencilla y eficiente de desarrollo local. Una de sus funciones clave es simplificar la creación y el acceso a sitios en tu máquina. Si prefieres que ServBay no gestione el registro de un dominio específico en el archivo hosts, lo más lógico es no crear ese sitio en ServBay.

En la mayoría de escenarios de desarrollo local, es recomendable dejar que ServBay gestione de forma automática el archivo hosts, ya que eso agiliza considerablemente el proceso.

P2: ¿Cómo accede mi contenedor Docker a un sitio web gestionado por ServBay en la máquina anfitriona (por ejemplo, `mysite.servbay.demo`) usando el dominio correcto?

Es una necesidad común, pero requiere ajustes específicos. Cuando ServBay ejecuta un sitio en la máquina anfitriona (mysite.servbay.demo, que se resuelve como 127.0.0.1 en el sistema), dentro del contenedor Docker, 127.0.0.1 apunta al contenedor mismo, no al sistema anfitrión.

Lo que NO debes hacer: acceder al sitio ServBay usando host.docker.internal en la URL

Aunque Docker Desktop para Mac y Windows proporciona el DNS especial host.docker.internal, NO RECOMENDAMOS accesar directamente los sitios web de ServBay usando este hostname en la URL (por ejemplo, esperar que http://host.docker.internal/ resuelva correctamente el dominio mysite.servbay.demo).

Esto sucede porque la cabecera HTTP Host será host.docker.internal y no mysite.servbay.demo. El servidor web de ServBay (Caddy o Nginx) utiliza dicha cabecera para decidir a qué sitio reencaminar la petición, y si no es la esperada, no podrá identificar el sitio correcto. Además, si el acceso es por HTTPS, ocurrirá un error SNI (Server Name Indication) porque el certificado fue emitido para mysite.servbay.demo, no para host.docker.internal.

Solución recomendada: Agregar la entrada con extra_hosts al iniciar el contenedor Docker

Para que las aplicaciones dentro de Docker envíen la petición al dominio original (mysite.servbay.demo), añade una entrada en el archivo /etc/hosts del contenedor, apuntando el dominio al IP del sistema anfitrión. Esto puede hacerse con extra_hosts (en docker-compose.yml) o --add-host (con docker run), usando host.docker.internal o, mejor aún, host-gateway.

Ejemplo usando docker run:
bash
```
docker run --add-host=mysite.servbay.demo:host-gateway ... your_image
```
1
(host-gateway es un valor especial que Docker sustituye por la IP interna del anfitrión. En Docker 20.10+ suele corresponder al alias más profundo de host.docker.internal.)

Ejemplo en docker-compose.yml:

yaml

version: '3.8' # o más reciente
services:
  myapp:
    image: your_image
    extra_hosts:
      - "mysite.servbay.demo:host-gateway" # o "mysite.servbay.demo:host.docker.internal"
    # ... otras configuraciones

Con esta configuración, dentro del contenedor Docker:

Cuando la app accede a http://mysite.servbay.demo o https://mysite.servbay.demo, el archivo /etc/hosts del contenedor resuelve el dominio a la IP del anfitrión (Mac/Windows).
La petición se envía al servidor web de ServBay en la máquina anfitriona.
La cabecera HTTP Host será mysite.servbay.demo, permitiendo que ServBay enrute correctamente la solicitud y proporcione el certificado SSL adecuado (si corresponde).

P3: ¿Cómo conecta mi contenedor Docker a una base de datos gestionada por ServBay (MySQL, PostgreSQL), o a otro servicio TCP no basado en HTTP?

A diferencia del acceso a sitios web (donde el dominio y SNI importan), para conectarse a una base de datos u otros servicios TCP sin SNI desde Docker, usar host.docker.internal como hostname es simple y recomendable.

Pasos:

Asegúrate de que el software de la base de datos (o servicio) en ServBay está activo y permite conexiones desde el anfitrión (por defecto suele estar listo para desarrollo local).
Al configurar la conexión en el contenedor Docker:
- Hostname/Servidor: host.docker.internal.
- Puerto: Usa el puerto configurado para el servicio en ServBay (MySQL por defecto: 3306, PostgreSQL: 5432, etc.).
- Usuario y clave: Usa las credenciales asignadas en ServBay.

Ejemplo de conexión a MySQL gestionado por ServBay: Si MySQL se ejecuta en el puerto estándar, configura tu app dentro del contenedor con:

Host: host.docker.internal
Puerto: 3306
Usuario: your_db_user
Contraseña: your_db_password

P4: ¿Cómo puedo hacer que mi contenedor Docker confíe en los certificados de ServBay User CA al acceder por HTTPS a sitios ServBay (con dominio y `extra_hosts`)?

Supón que seguiste la recomendación anterior, usando extra_hosts o --add-host para que secure.servbay.demo apunte a host-gateway. Si secure.servbay.demo utiliza un certificado emitido por ServBay User CA, tu contenedor Docker, por defecto, no confiará en ese CA y la negociación SSL fallará.

Ubicación de los certificados ServBay CA:

Certificado raíz de ServBay User CA:
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt
Archivo PEM con ServBay User CA, Public CA y raíces Mozilla:
- macOS (ARM): /Applications/ServBay/package/common/openssl/3.2/cacert.pem
- macOS (Intel): /Applications/ServBay/package/common/openssl/1.1.1u/cacert.pem
- Windows: C:\ServBay\package\common\openssl\3.3\cacert.pem

Resumen de soluciones:

Hay varios métodos para que el contenedor Docker confíe en ServBay User CA:

Método 1: Confianza a nivel de sistema durante construcción de la imagen (Dockerfile) – Lo recomendable si necesitas confianza global del sistema y puedes personalizar la imagen.
Método 2: Confianza solo a nivel de aplicación en tiempo de ejecución (volumen + variable de entorno) – Útil si sólo la aplicación específica debe confiar y no deseas modificar la imagen.
Método 3: Confianza a nivel de sistema en tiempo de ejecución (volumen + comando de inicio personalizado) – Ideal si quieres confianza del sistema pero no deseas una imagen personalizada.

Método 1: Confianza de sistema al construir la imagen (Dockerfile)

Integra el CA en el almacén de certificados confiables al construir la imagen.

Prepara el archivo CA: Copia el certificado raíz de ServBay User CA al contexto de construcción de tu imagen Docker.
- macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
- Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt

Dockerfile ejemplo (Debian/Ubuntu):

dockerfile

# Dockerfile
FROM ubuntu:latest
COPY ServBay-Private-CA-ECC-Root.crt /usr/local/share/ca-certificates/ServBay-User-CA.crt
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && \
    update-ca-certificates && \
    rm -rf /var/lib/apt/lists/*

Dockerfile ejemplo (Alpine):

dockerfile

# Dockerfile
FROM alpine:latest
COPY ServBay-Private-CA-ECC-Root.crt /usr/local/share/ca-certificates/ServBay-User-CA.crt
RUN apk add --no-cache ca-certificates && update-ca-certificates

Docker Compose para construir:

yaml

# docker-compose.yml
version: '3.8'
services:
  myapp:
    build:
      context: ./app_service # Incluye Dockerfile y ServBay-Private-CA-ECC-Root.crt
      dockerfile: Dockerfile
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Método 2: Confianza a nivel de aplicación en tiempo de ejecución (volumen + variable de entorno)

Monta el archivo CA en el contenedor y configura tu app para usarlo mediante una env var.

docker-compose.yml ejemplo:

yaml

version: '3.8'
services:
  myapp:
    image: some-base-image
    volumes:
      # Ejemplo macOS
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
      # Ejemplo Windows (ajusta la ruta según el SO)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/etc/ssl/certs/MyCustomCA.crt:ro
    environment:
      # Para Node.js:
      - NODE_EXTRA_CA_CERTS=/etc/ssl/certs/MyCustomCA.crt
      # Para Python (requests):
      # - REQUESTS_CA_BUNDLE=/etc/ssl/certs/MyCustomCA.crt
      # De forma genérica:
      # - SSL_CERT_FILE=/etc/ssl/certs/MyCustomCA.crt
    extra_hosts: ["secure.servbay.demo:host-gateway"]

Consulta la documentación de tu aplicación para el env var adecuado.

Método 3: Confianza de sistema en tiempo de ejecución (volumen + comando personalizado de inicio)

Montas el CA y ejecutas comando para actualizar el almacén de certificados al arrancar el contenedor. No hace falta una imagen personalizada, pero complica el comando de inicio.

docker-compose.yml ejemplo (imagen Debian/Ubuntu):

yaml

version: '3.8'
services:
  myapp:
    image: ubuntu:latest # O alguna que implemente update-ca-certificates
    volumes:
      # Monta el CA en el sitio esperado por el sistema
      # Ejemplo macOS
      - /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
      # Ejemplo Windows (ajusta ruta)
      # - C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt:/usr/local/share/ca-certificates/ServBay-User-CA.crt:ro
    # Sobreescribe el comando de inicio para actualizar CA y arrancar la app
    # Asegúrate de que el contenedor ejecute update-ca-certificates con permisos suficientes
    command: >
      sh -c "
        echo 'Intentando actualizar los certificados de CA...' &&
        if command -v update-ca-certificates > /dev/null; then
          if [ ! -f /usr/bin/update-ca-certificates ]; then apt-get update && apt-get install -y --no-install-recommends ca-certificates; fi &&
          update-ca-certificates &&
          echo 'Certificados CA actualizados.'
        else
          echo 'No se encontró update-ca-certificates, se omite la actualización.'
        fi &&
        echo 'Iniciando aplicación...' &&
        exec your_original_application_command_here # Sustituye por el CMD o script original de tu imagen
      "
    extra_hosts: ["secure.servbay.demo:host-gateway"]
    # Si necesitas permisos root para la actualización pero tu app corre como usuario normal, necesitarás ajustar el entrypoint
    # user: root # Para ejecutar como root temporalmente, o maneja los permisos en tu entrypoint

Notas:

Complejidad: Modificar command o entrypoint puede ser tedioso, especialmente en imágenes oficiales con lógica de inicio compleja. Debes asegurar que se ejecute el comando de tu app correctamente.
Permisos: update-ca-certificates requiere permisos de root. Si el contenedor usa usuario normal, este método puede fallar o requerir elevar permisos.
Dependencias: Deben existir los paquetes/dependencias necesarias (ca-certificates, el propio comando de actualización). El ejemplo intenta instalarlo si falta y el SO lo permite.
Tiempo de inicio: Este proceso aumenta el tiempo de arranque del contenedor.
Alpine Linux: En Alpine, usa: apk add --no-cache ca-certificates && update-ca-certificates.

¿Qué método elegir?

Si puedes construir tu propia imagen y quieres que el CA sea confiado por todo el sistema, lo ideal es método 1.
Si prefieres no modificar la imagen y sólo tu app confíe en el CA, método 2 es práctico.
Si necesitas confianza a nivel sistema pero no deseas una imagen personalizada, método 3 es lo más adecuado.

Para certificados emitidos por CA pública (Let's Encrypt): Si usas un certificado obtenido por protocolo ACME de un CA público (ejemplo, Let's Encrypt), las imágenes Docker suelen confiar en ellos por defecto y no se requiere configuración adicional.

P5: ¿Cómo configurar ServBay para asignar un dominio y hacer de proxy inverso para una aplicación corriendo dentro del contenedor Docker?

Supón que ejecutas una aplicación en Docker (por ejemplo Node.js en el puerto 3000 del contenedor) y deseas acceder a ella desde el navegador a través de un dominio amigable (como myapp.servbay.demo) y gestionando el SSL con ServBay.

Pasos:

Ejecuta el contenedor Docker mapeando el puerto a 127.0.0.1 del anfitrión: Asegúrate que el puerto de la app se expone únicamente al localhost del sistema anfitrión, así evitas accesos externos no deseados.
bash
```
# Ejemplo: la app escucha como 3000 en el contenedor, mapeas a 127.0.0.1:3001 en el anfitrión
docker run -d -p 127.0.0.1:3001:3000 your-docker-app-image
```
1
2
Así, tu aplicación interna es accesible vía http://127.0.0.1:3001 desde el anfitrión.
Configura nuevo sitio en ServBay como proxy inverso:
- Accede al panel de gestión de ServBay.
- Haz clic en “Agregar sitio”.
- Dominio: Introduce el dominio deseado, por ejemplo myapp.servbay.demo.
- Tipo de sitio: Selecciona “Proxy inverso”.
- Dirección IP: Coloca 127.0.0.1.
- Puerto: Usa el puerto mapeado, ejemplo, 3001.
- Haz clic en “Guardar” o “Agregar”.
(Opcional) Configura SSL: Una vez que has agregado el sitio, puedes habilitar SSL desde las opciones. ServBay soporta la obtención automática de certificados de CA públicas como Let's Encrypt vía ACME, o puedes usar ServBay User CA/Public CA. ServBay gestiona la terminación SSL y la comunicación con el contenedor puede ser HTTP plano (http://127.0.0.1:3001).
Prueba el acceso: Tras guardar, deberías poder acceder por navegador a http://myapp.servbay.demo o https://myapp.servbay.demo (según config SSL). ServBay retransmitirá la petición a la app del contenedor Docker.

Flujo de trabajo: Navegador del usuario -> https://myapp.servbay.demo -> ServBay (gestiona SSL, busca la regla proxy) -> http://127.0.0.1:3001 (en el anfitrión) -> aplicación dentro del contenedor Docker.

Resumen

ServBay facilita enormemente el desarrollo web local en macOS y Windows. Cuando lo usas junto con Docker:

Para acceder desde Docker a sitios web ServBay, usa extra_hosts o --add-host para apuntar el dominio a host-gateway, asegurando que la cabecera Host sea correcta y evitando errores SNI.
Para acceder a bases de datos o servicios no HTTP gestionados por ServBay, configura el hostname como host.docker.internal, sencillo y efectivo.
Para que Docker confíe en los certificados SSL emitidos por ServBay User CA, deberás copiar el CA a la imagen y actualizar el almacén de certificados.
Para usar ServBay como proxy inverso de apps en Docker, configura un sitio tipo “Proxy inverso” en ServBay apuntando al puerto mapeado en 127.0.0.1 del anfitrión.

Asegúrate siempre de que los softwares involucrados (servidor web, BD, etc.) y tus contenedores Docker estén correctamente configurados y ejecutándose.

Preguntas Frecuentes sobre la Integración de ServBay y Docker (FAQ) ​

P1: ¿Por qué ServBay modifica el archivo hosts de mi sistema? ¿Puedo evitarlo? ​

P2: ¿Cómo accede mi contenedor Docker a un sitio web gestionado por ServBay en la máquina anfitriona (por ejemplo, mysite.servbay.demo) usando el dominio correcto? ​

P3: ¿Cómo conecta mi contenedor Docker a una base de datos gestionada por ServBay (MySQL, PostgreSQL), o a otro servicio TCP no basado en HTTP? ​

P4: ¿Cómo puedo hacer que mi contenedor Docker confíe en los certificados de ServBay User CA al acceder por HTTPS a sitios ServBay (con dominio y extra_hosts)? ​

Método 1: Confianza de sistema al construir la imagen (Dockerfile) ​

Método 2: Confianza a nivel de aplicación en tiempo de ejecución (volumen + variable de entorno) ​

Método 3: Confianza de sistema en tiempo de ejecución (volumen + comando personalizado de inicio) ​

P5: ¿Cómo configurar ServBay para asignar un dominio y hacer de proxy inverso para una aplicación corriendo dentro del contenedor Docker? ​

Resumen ​

Preguntas Frecuentes sobre la Integración de ServBay y Docker (FAQ)

P1: ¿Por qué ServBay modifica el archivo `hosts` de mi sistema? ¿Puedo evitarlo?

P2: ¿Cómo accede mi contenedor Docker a un sitio web gestionado por ServBay en la máquina anfitriona (por ejemplo, `mysite.servbay.demo`) usando el dominio correcto?

P3: ¿Cómo conecta mi contenedor Docker a una base de datos gestionada por ServBay (MySQL, PostgreSQL), o a otro servicio TCP no basado en HTTP?

P4: ¿Cómo puedo hacer que mi contenedor Docker confíe en los certificados de ServBay User CA al acceder por HTTPS a sitios ServBay (con dominio y `extra_hosts`)?

Método 1: Confianza de sistema al construir la imagen (Dockerfile)

Método 2: Confianza a nivel de aplicación en tiempo de ejecución (volumen + variable de entorno)

Método 3: Confianza de sistema en tiempo de ejecución (volumen + comando personalizado de inicio)

P5: ¿Cómo configurar ServBay para asignar un dominio y hacer de proxy inverso para una aplicación corriendo dentro del contenedor Docker?

Resumen