letsencrypt - nginx ssl docker compose

Docker Networking-nginx: host[emerg] no encontrado en el flujo ascendente

Question

Recientemente comencé a migrar a Docker 1.9 y a las funciones de red de Docker-Compose 1.5 para reemplazar el uso de enlaces.

Hasta ahora, con los enlaces, no había problemas con la conexión de nginx a mi servidor php5-fpm fastcgi ubicado en un servidor diferente en un grupo a través de docker-compose. Sin embargo, cuando ejecuto docker-compose --x-networking up mis contenedores php-fpm, mongo y nginx, sin embargo, nginx se cierra de inmediato con [emerg] 1#1: host not found in upstream "waapi_php_1" in /etc/nginx/conf.d/default.conf:16

Sin embargo, si ejecuto el comando docker-compose nuevamente mientras se ejecutan los contenedores php y mongo (nginx salido), nginx se inicia y funciona bien a partir de ese momento.

Este es mi archivo docker-compose.yml :

nginx:
  image: nginx
  ports:
    - "42080:80"
  volumes:
    - ./config/docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro

php:
  build: config/docker/php
  ports:
    - "42022:22"
  volumes:
    - .:/var/www/html
  env_file: config/docker/php/.env.development

mongo:
  image: mongo
  ports:
    - "42017:27017"
  volumes:
    - /var/mongodata/wa-api:/data/db
  command: --smallfiles

Este es mi default.conf para nginx:

server {
    listen  80;

    root /var/www/test;

    error_log /dev/stdout debug;
    access_log /dev/stdout;

    location / {
        # try to serve file directly, fallback to app.php
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/.+/.php(/|$) {
        # Referencing the php service host (Docker)
        fastcgi_pass waapi_php_1:9000;

        fastcgi_split_path_info ^(.+/.php)(/.*)$;
        include fastcgi_params;

        # We must reference the document_root of the external server ourselves here.
        fastcgi_param SCRIPT_FILENAME /var/www/html/public$fastcgi_script_name;

        fastcgi_param HTTPS off;
    }
}

¿Cómo puedo hacer que nginx funcione con una sola llamada de docker-compose?

Answer 1

(nuevo en nginx) En mi caso, el nombre de la carpeta era incorrecto

Para config

upstream serv {
    server ex2_app_1:3000;
}

asegúrese de que la carpeta de la aplicación esté en la carpeta ex2:

ex2 / app / ...

Answer 2

Agregue la sección de links a su configuración de contenedor nginx.

Tienes que hacer visible el contenedor php contenedor nginx .

nginx:
  image: nginx
  ports:
    - "42080:80"
  volumes:
    - ./config/docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
  links:
    - php:waapi_php_1

Answer 3

Así es como lo supero, la mejor manera en que puedo pensar.

ADD root /

RUN cp /etc/hosts /etc/hosts.tmp && /
    echo -e "/
127.0.0.1 code_gogs_1 /n/
127.0.0.1 pm_zentao_1 /n/
127.0.0.1 ci_drone_1 /n/
    " >> /etc/hosts && /
    nginx -t && /
# mv: can''t rename ''/etc/hosts.tmp'': Resource busy
# mv /etc/hosts.tmp /etc/hosts
    cat /etc/hosts.tmp > /etc/hosts && /
    rm /etc/hosts.tmp

Answer 4

Con los enlaces, se aplica un orden de inicio del contenedor. Sin enlaces, los contenedores pueden comenzar en cualquier orden (o realmente todos a la vez).

Creo que la configuración anterior podría haber tenido el mismo problema si el contenedor waapi_php_1 tardara en iniciarse.

Creo que para que funcione, podría crear un script de punto de entrada nginx que sondee y espere a que el contenedor php se inicie y esté listo.

No estoy seguro de si nginx tiene alguna forma de volver a intentar la conexión al flujo ascendente automáticamente, pero si lo hace, esa sería una mejor opción.

Answer 5

Creo que Nginx no tiene en cuenta el Docker resolver (127.0.0.11), así que, por favor, ¿puede intentar agregar:

resolver 127.0.0.11

en su archivo de configuración nginx?

Answer 6

Debe usar algo como docker-gen para actualizar dinámicamente la configuración de nginx cuando su back-end está activo.

Ver:

• https://hub.docker.com/r/jwilder/docker-gen/
• https://github.com/jwilder/nginx-proxy

Creo que Nginx + (versión premium) también contiene un parámetro de resolución ( http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream )

Answer 7

Dos cosas que vale la pena mencionar:

• Usando el mismo puente de red
• Uso de links para agregar hosts resol

Mi ejemplo:

version: ''3''
services:
  mysql:
    image: mysql:5.7
    restart: always
    container_name: mysql
    volumes:
      - ./mysql-data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: tima@123
    network_mode: bridge
  ghost:
    image: ghost:2
    restart: always
    container_name: ghost
    depends_on:
      - mysql
    links:
      - mysql
    environment:
      database__client: mysql
      database__connection__host: mysql
      database__connection__user: root
      database__connection__password: xxxxxxxxx
      database__connection__database: ghost
      url: https://www.itsfun.tk
    volumes:
      - ./ghost-data:/var/lib/ghost/content
    network_mode: bridge
  nginx:
    image: nginx
    restart: always
    container_name: nginx
    depends_on:
      - ghost
    links:
      - ghost
    ports:
      - "80:80"
      - "443:443"
    volumes:
       - ./nginx/nginx.conf:/etc/nginx/nginx.conf
       - ./nginx/conf.d:/etc/nginx/conf.d
       - ./nginx/letsencrypt:/etc/letsencrypt
    network_mode: bridge

Si no especifica un puente de red especial, todos usarán el mismo puente predeterminado.

Answer 8

Esto se puede resolver con la directiva depends_on mencionada ya que se implementa ahora (2016):

version: ''2''
  services:
    nginx:
      image: nginx
      ports:
        - "42080:80"
      volumes:
        - ./config/docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
      depends_on:
        - php

    php:
      build: config/docker/php
      ports:
        - "42022:22"
      volumes:
        - .:/var/www/html
      env_file: config/docker/php/.env.development
      depends_on:
        - mongo

    mongo:
      image: mongo
      ports:
        - "42017:27017"
      volumes:
        - /var/mongodata/wa-api:/data/db
      command: --smallfiles

Probado con éxito con:

$ docker-compose version
docker-compose version 1.8.0, build f3628c7

Encuentra más detalles en la documentation .

También hay un artículo muy interesante dedicado a este tema: Control del orden de inicio en Compose

Answer 9

Existe la posibilidad de utilizar "volume_from" como solución alternativa hasta que se introduzca la función dependen_on (que se describe a continuación). Todo lo que tiene que hacer es cambiar su archivo docker-compose de la siguiente manera:

nginx:
  image: nginx
  ports:
    - "42080:80"
  volumes:
    - ./config/docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
  volumes_from:
    - php

php:
  build: config/docker/php
  ports:
    - "42022:22"
  volumes:
    - .:/var/www/html
  env_file: config/docker/php/.env.development

mongo:
  image: mongo
  ports:
    - "42017:27017"
  volumes:
    - /var/mongodata/wa-api:/data/db
  command: --smallfiles

Una gran advertencia en el enfoque anterior es que los volúmenes de php están expuestos a nginx, lo que no se desea. Pero en este momento, esta es una solución alternativa específica para el acoplador que podría usarse.

depende de la característica Esto probablemente sería una respuesta futurista. Debido a que la funcionalidad aún no está implementada en Docker (a partir de 1.9)

Hay una propuesta para introducir "depede_on" en la nueva función de red presentada por Docker. Pero hay un largo debate sobre el mismo @ https://github.com/docker/compose/issues/374 Por lo tanto, una vez que se implementa, la función depende_on podría usarse para ordenar el inicio del contenedor, pero en el momento, tendría que recurrir a uno de los siguientes:

1. vuelva a intentar nginx hasta que el servidor php esté activo; preferiría este
2. use volums_from solución alternativa como se describió anteriormente: evitaría usar esto, debido a la pérdida de volumen en contenedores innecesarios.

Answer 10

Mi solución (después de mucho ensayo y error):

• Para solucionar este problema, tuve que obtener el nombre completo del contenedor Docker ''ascendente'', que se encuentra ejecutando docker network inspect my-special-docker-network y obteniendo la propiedad de name completo del contenedor ascendente como tal:

  "Containers": {
       "39ad8199184f34585b556d7480dd47de965bc7b38ac03fc0746992f39afac338": {
            "Name": "my_upstream_container_name_1_2478f2b3aca0",

• Luego usé esto en el archivo NGINX my-network.local.conf en el bloque de location de la propiedad proxy_pass : (Tenga en cuenta la adición del GUID al nombre del contenedor):

  location / {
      proxy_pass http://my_upsteam_container_name_1_2478f2b3aca0:3000;

A diferencia de lo que funcionaba anteriormente, pero ahora roto:

    location / {
        proxy_pass http://my_upstream_container_name_1:3000

La causa más probable es un cambio reciente en Docker Compose, en su esquema de nomenclatura predeterminado para contenedores, como se enumera here .

Esto parece estar sucediendo para mí y mi equipo en el trabajo, con las últimas versiones de la imagen Docker nginx :

• He abierto problemas con ellos en la ventana acoplable / componer GitHub here

Answer 11

Puede establecer las directivas max_fails y fail_timeout de nginx para indicar que nginx debe reintentar el número x de solicitudes de conexión al contenedor antes de fallar en la falta de disponibilidad del servidor ascendente.

Puede ajustar estos dos números según su infraestructura y la velocidad a la que se presenta toda la configuración. Puede leer más detalles sobre la sección de comprobaciones de estado de la siguiente URL: http://nginx.org/en/docs/http/load_balancing.html

Lo siguiente es el extracto de http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server max_fails=number

establece el número de intentos fallidos de comunicarse con el servidor que debería suceder en la duración establecida por el parámetro fail_timeout para considerar que el servidor no está disponible durante una duración también establecida por el parámetro fail_timeout. De forma predeterminada, el número de intentos fallidos se establece en 1. El valor cero desactiva la contabilidad de los intentos. Lo que se considera un intento fallido está definido por las directivas proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream y memcached_next_upstream.

fail_timeout=time

establece el tiempo durante el cual el número especificado de intentos fallidos de comunicarse con el servidor debe considerarse que el servidor no está disponible; y el período de tiempo que el servidor se considerará no disponible. Por defecto, el parámetro se establece en 10 segundos.

Para ser precisos, su archivo de configuración nginx modificado debe ser el siguiente (este script asume que todos los contenedores están activos por al menos 25 segundos, de lo contrario, cambie el fail_timeout o max_fails en la sección aguas abajo): Nota: no lo hice probar el guión yo mismo, para que puedas probarlo.

upstream phpupstream {
   waapi_php_1:9000 fail_timeout=5s max_fails=5;
}
server {
    listen  80;

    root /var/www/test;

    error_log /dev/stdout debug;
    access_log /dev/stdout;

    location / {
        # try to serve file directly, fallback to app.php
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/.+/.php(/|$) {
        # Referencing the php service host (Docker)
        fastcgi_pass phpupstream;

        fastcgi_split_path_info ^(.+/.php)(/.*)$;
        include fastcgi_params;

        # We must reference the document_root of the external server ourselves here.
        fastcgi_param SCRIPT_FILENAME /var/www/html/public$fastcgi_script_name;

        fastcgi_param HTTPS off;
    }
}

Además, según la siguiente Nota de Docker ( https://github.com/docker/compose/blob/master/docs/networking.md ), es evidente que la lógica de reintento para verificar el estado de los otros contenedores no es la responsabilidad del acoplador y, más bien, los contenedores deben hacer el chequeo de salud ellos mismos

Actualizando contenedores

Si realiza un cambio de configuración en un servicio y ejecuta docker-compose para actualizarlo, se eliminará el contenedor antiguo y el nuevo se unirá a la red con una dirección IP diferente pero con el mismo nombre. Los contenedores en ejecución podrán buscar ese nombre y conectarse a la nueva dirección, pero la dirección anterior dejará de funcionar.

Si alguno de los contenedores tiene conexiones abiertas al contenedor anterior, se cerrarán. Es responsabilidad del contenedor detectar esta condición, buscar el nombre nuevamente y volver a conectarse.

Answer 12

Quizás la mejor opción para evitar problemas de vinculación de contenedores son las funciones de red de Docker

Pero para que esto funcione, Docker crea entradas en / etc / hosts para cada contenedor a partir de los nombres asignados a cada contenedor.

con docker-compose --x-networking -up es algo así como [docker_compose_folder] - [service] - [incremental_number]

Para no depender de cambios inesperados en estos nombres, debe usar el parámetro

nombre_contenedor

en su docker-compose.yml de la siguiente manera:

php:
      container_name: waapi_php_1
      build: config/docker/php
      ports:
        - "42022:22"
      volumes:
        - .:/var/www/html
      env_file: config/docker/php/.env.development

Asegurándose de que sea el mismo nombre asignado en su archivo de configuración para este servicio. Estoy bastante seguro de que hay mejores formas de hacerlo, pero es un buen enfoque para comenzar.

Answer 13

Si estás tan perdido por leer el último comentario. He llegado a otra solución.

El principal problema es la forma en que nombró los nombres de los servicios.

En este caso, si en su docker-compose.yml , el servicio para php se llama "api" o algo así, debe asegurarse de que en el archivo nginx.conf la línea que comienza con fastcgi_pass tenga el mismo nombre que php Servicio. es decir, fastcgi_pass api:9000;

Answer 14

Tuve el mismo problema porque había dos redes definidas en mi docker-compose.yml : una de back-end y una de frontend.
Cuando cambié eso para ejecutar contenedores en la misma red predeterminada, todo comenzó a funcionar bien.

Answer 15

Tuve el mismo problema y lo resolvió. Agregue la siguiente línea a la sección docker-compose.yml nginx:

links:
  - php:waapi_php_1

El host en la sección nginx config fastcgi_pass debe estar vinculado dentro de la configuración nginx de docker-compose.yml.