Docker Networking - nginx: host [emerg] non trovato in upstream

Di recente ho iniziato la migrazione alle funzionalità di rete di Docker 1.9 e Docker-Compose 1.5 per sostituire utilizzando i collegamenti.

Finora con i collegamenti non ci sono stati problemi con nginx che si connette al mio server php5-fpm fastcgi situato in un server diverso in un gruppo tramite docker-compose. Di recente però quando docker-compose --x-networking upeseguo i miei contenitori php-fpm, mongo e nginx si avviano, tuttavia nginx si chiude immediatamente con[emerg] 1#1: host not found in upstream "waapi_php_1" in /etc/nginx/conf.d/default.conf:16

Tuttavia, se eseguo nuovamente il comando docker-compose mentre i contenitori php e mongo sono in esecuzione (uscita da nginx), nginx si avvia e da quel momento in poi funziona correttamente.

Questo è il mio docker-compose.ymlfile:

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

Questo è il mio default.confper 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;
    }
}

Come posso far funzionare nginx con una sola chiamata docker-compose?

C'è la possibilità di utilizzare "volumi_from" come soluzione alternativa fino a quando non viene introdotta la funzione depend_on (discussa di seguito). Tutto quello che devi fare è cambiare il tuo file docker-compose come di seguito:

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

Un grande avvertimento nell'approccio di cui sopra è che i volumi di php sono esposti a nginx, il che non è desiderato. Ma al momento questa è una soluzione alternativa specifica per finestra mobile che potrebbe essere utilizzata.

Funzionalità dipende_on Questa probabilmente sarebbe una risposta futuristica. Perché la funzionalità non è ancora implementata in Docker (a partire dalla 1.9)

C'è una proposta per introdurre "depend_on" nella nuova funzionalità di rete introdotta da Docker. Ma c'è un lungo dibattito sullo stesso @ https://github.com/docker/compose/issues/374 Quindi, una volta implementata, la funzione depend_on potrebbe essere usata per ordinare l'avvio del container, ma al momento, dovresti ricorrere a uno dei seguenti:

1. fai riprovare nginx fino a quando il server php non è attivo - preferirei questo
2. utilizzare volums_from soluzione alternativa come descritto sopra: eviterei di usarlo, a causa della perdita di volume in contenitori non necessari.

Questo può essere risolto con la depends_ondirettiva citata poiché è implementata ora (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

Testato con successo con:

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

Trova maggiori dettagli nella documentazione .

C'è anche un articolo molto interessante dedicato a questo argomento: Controllo dell'ordine di avvio in Compose

È possibile impostare le direttive max_fails e fail_timeout di nginx per indicare che nginx deve ritentare il numero x di richieste di connessione al contenitore prima di fallire sull'indisponibilità del server upstream.

Puoi regolare questi due numeri in base alla tua infrastruttura e alla velocità con cui l'intera configurazione sta arrivando. Puoi leggere maggiori dettagli sulla sezione dei controlli di integrità dell'URL seguente: http://nginx.org/en/docs/http/load_balancing.html

Di seguito è riportato l'estratto da http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server max_fails=number

imposta il numero di tentativi di comunicazione con il server non riusciti che dovrebbero verificarsi nella durata impostata dal parametro fail_timeout per considerare il server non disponibile per una durata impostata anche dal parametro fail_timeout. Per impostazione predefinita, il numero di tentativi non riusciti è impostato su 1. Il valore zero disabilita la contabilità dei tentativi. Ciò che è considerato un tentativo non riuscito è definito dalle direttive proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream e memcached_next_upstream.

fail_timeout=time

imposta il tempo durante il quale il numero specificato di tentativi di comunicazione con il server non riusciti dovrebbe accadere per considerare il server non disponibile; e il periodo di tempo in cui il server sarà considerato non disponibile. Per impostazione predefinita, il parametro è impostato su 10 secondi.

Per essere precisi, il tuo file di configurazione nginx modificato dovrebbe essere il seguente (questo script presume che tutti i contenitori siano attivi di almeno 25 secondi, in caso contrario, modifica fail_timeout o max_fails nella sezione a monte sotto): Nota: non l'ho fatto prova personalmente lo script, così potresti provarlo!

upstream phpupstream {
   server 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;
    }
}

Inoltre, come da nota seguente da docker ( https://github.com/docker/docker.github.io/blob/master/compose/networking.md#update-containers ), è evidente che la logica di ripetizione del controllo lo stato di salute degli altri container non è responsabilità del dock e piuttosto i container dovrebbero fare il controllo di integrità da soli.

Aggiornamento dei contenitori

Se apporti una modifica alla configurazione di un servizio ed esegui docker-compose per aggiornarlo, il vecchio contenitore verrà rimosso e il nuovo si unirà alla rete con un indirizzo IP diverso ma con lo stesso nome. I contenitori in esecuzione potranno cercare quel nome e connettersi al nuovo indirizzo, ma il vecchio indirizzo smetterà di funzionare.

Se alcuni contenitori hanno connessioni aperte al vecchio contenitore, verranno chiusi. È responsabilità del container rilevare questa condizione, cercare di nuovo il nome e ricollegarsi.

Credo che Nginx non prenda in considerazione il resolver Docker (127.0.0.11), quindi per favore, puoi provare ad aggiungere:

resolver 127.0.0.11

nel file di configurazione di nginx?

Se sei così perso per leggere l'ultimo commento. Ho raggiunto un'altra soluzione.

Il problema principale è il modo in cui hai chiamato i nomi dei servizi.

In questo caso, se nel tuo docker-compose.yml, i servizi per php sono chiamati "api" o qualcosa del genere, devi assicurarti che nel file nginx.confla riga che inizia con fastcgi_passabbia lo stesso nome del servizio php. cioèfastcgi_pass api:9000;

Ho avuto lo stesso problema perché c'erano due reti definite nel mio docker-compose.yml: una backend e una frontend.
Quando l'ho modificato per eseguire i contenitori sulla stessa rete predefinita, tutto ha iniziato a funzionare correttamente.

Ho avuto lo stesso problema e l'ho risolto. Aggiungi la seguente riga alla sezione docker-compose.yml nginx:

links:
  - php:waapi_php_1

L'host nella sezione fastcgi_pass di configurazione nginx dovrebbe essere collegato all'interno della configurazione docker-compose.yml nginx.

Due cose che vale la pena menzionare:

• Utilizzando lo stesso bridge di rete
• Utilizzo linksper aggiungere host resol

Il mio esempio:

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

Se non specifichi un bridge di rete speciale, tutti useranno lo stesso predefinito.

A prima vista, mi sono perso il fatto che il mio servizio "web" non fosse effettivamente avviato, quindi è per questo che nginx non è riuscito a trovare alcun host

web_1    | python3: can't open file '/var/www/app/app/app.py': [Errno 2] No such file or directory
web_1 exited with code 2
nginx_1  | [emerg] 1#1: host not found in upstream "web:4044" in /etc/nginx/conf.d/nginx.conf:2

Con i collegamenti viene applicato un ordine di avvio del contenitore. Senza collegamenti i contenitori possono iniziare in qualsiasi ordine (o davvero tutti in una volta).

Penso che la vecchia configurazione avrebbe potuto riscontrare lo stesso problema, se il waapi_php_1contenitore fosse lento all'avvio.

Penso che per farlo funzionare, potresti creare uno script entrypoint nginx che esegue il polling e attende che il contenitore php sia avviato e pronto.

Non sono sicuro che nginx abbia un modo per ritentare automaticamente la connessione all'upstream, ma se lo fa, sarebbe un'opzione migliore.

Devi usare qualcosa come docker-gen per aggiornare dinamicamente la configurazione di nginx quando il tuo backend è attivo.

Vedere:

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

Credo che Nginx + (versione premium) contenga anche un parametro di risoluzione ( http://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream )

Forse la scelta migliore per evitare problemi di collegamento dei contenitori è il collegamento in rete funzionalità di

Ma per far funzionare questo, docker crea voci in / etc / hosts per ogni contenitore dai nomi assegnati a ciascun contenitore.

con docker-compose --x-networking -up è qualcosa come [docker_compose_folder] - [service] - [incremental_number]

Per non dipendere da modifiche impreviste in questi nomi è necessario utilizzare il parametro

nome_contenitore

nel tuo docker-compose.yml come segue:

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

Assicurati che sia lo stesso nome assegnato nel tuo file di configurazione per questo servizio. Sono abbastanza sicuro che ci siano modi migliori per farlo, ma è un buon approccio per iniziare.

La mia soluzione alternativa (dopo molte prove ed errori):

• Per aggirare questo problema, ho dovuto ottenere il nome completo del container Docker 'upstream', trovato eseguendo docker network inspect my-special-docker-networke ottenendo la nameproprietà completa del container upstream in quanto tale:

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

• Quindi ha usato questo nel my-network.local.conffile NGINX nel locationblocco della proxy_passproprietà: (Nota l'aggiunta del GUID al nome del contenitore):

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

A differenza del precedente funzionante, ma ora rotto:

    location / {
        proxy_pass http://my_upstream_container_name_1:3000

La causa più probabile è una recente modifica a Docker Compose, nel loro schema di denominazione predefinito per i contenitori, come elencato qui .

Questo sembra accadere per me e il mio team al lavoro, con le ultime versioni nginxdell'immagine Docker :

• Ho aperto problemi con loro nella finestra mobile / componi GitHub qui

(nuovo di nginx) Nel mio caso il nome della cartella era sbagliato

Per config

upstream serv {
    server ex2_app_1:3000;
}

assicurati che la cartella dell'app sia nella cartella ex2:

ex2 / app / ...

questo errore mi è apparso perché la mia php-fpmimmagine è abilitata crone non ho idea del perché

Il mio problema era che mi ero dimenticato di specificare l'alias di rete in docker-compose.yml in php-fpm

    networks:
      - u-online

Funziona bene!

version: "3"
services:

  php-fpm:
    image: php:7.2-fpm
    container_name: php-fpm
    volumes:           
      - ./src:/var/www/basic/public_html
    ports:
      - 9000:9000
    networks:
      - u-online
      
  nginx: 
    image: nginx:1.19.2
    container_name: nginx   
    depends_on:
      - php-fpm       
    ports:
      - "80:8080"
      - "443:443"
    volumes:
      - ./docker/data/etc/nginx/conf.d/default.conf:/etc/nginx/conf.d/default.conf
      - ./docker/data/etc/nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./src:/var/www/basic/public_html
    networks:
      - u-online

#Docker Networks
networks:
  u-online:
    driver: bridge

Aggiungi la sezione dei collegamenti alla configurazione del tuo contenitore nginx.

Devi rendere visibile il phpcontenitore al nginxcontenitore.

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