Aktualizacja II

Jest teraz 16 lipca 2015 roku i wszystko się zmieniło. Odkryłem ten automagiczny pojemnik od Jasona Wildera : https://github.com/jwilder/nginx-proxyi rozwiązuje ten problem w tak długim czasie, jak zajmuje docker runto pojemnik. To jest teraz rozwiązanie, którego używam do rozwiązania tego problemu.

Aktualizacja

Teraz jest lipiec 2015 r. I sytuacja uległa drastycznej zmianie w odniesieniu do sieci kontenerów Docker. Obecnie istnieje wiele różnych ofert, które rozwiązują ten problem (na różne sposoby).

Powinieneś użyć tego posta, aby uzyskać podstawową wiedzę na temat docker --linkpodejścia do odkrywania usług, które jest tak podstawowe, jak to tylko możliwe, działa bardzo dobrze i faktycznie wymaga mniej wymyślnego tańca niż większość innych rozwiązań. Jest ograniczony, ponieważ dość trudno jest połączyć w sieć kontenery na oddzielnych hostach w dowolnym klastrze, a kontenerów nie można ponownie uruchomić po podłączeniu do sieci, ale oferuje szybki i stosunkowo łatwy sposób na sieciowe kontenery na tym samym hoście. To dobry sposób, aby zorientować się, jakie oprogramowanie, którego będziesz prawdopodobnie używać do rozwiązania tego problemu, faktycznie robi pod maską.

Ponadto prawdopodobnie będziesz chciał również sprawdzić powstające Docker network, Hashicorp's consul, Weaveworks weave, Jeff Lindsay's progrium/consul&gliderlabs/registrator i Google Kubernetes.

Istnieje również CoreOS ofiary, które wykorzystują etcd, fleetoraz flannel.

A jeśli naprawdę chcesz zorganizować imprezę, możesz uruchomić klaster Mesosphere, lub Deis, lub Flynn.

Jeśli jesteś nowy w sieci (tak jak ja), powinieneś wyjąć okulary do czytania, pop „Paint The Sky With Stars - The Best of Enya” na Wi-Hi-Fi i wypić piwo - to będzie chwilę, zanim naprawdę dokładnie zrozumiesz, co próbujesz zrobić. Podpowiedź: próbujesz zaimplementować Service Discovery Layerw swoim Cluster Control Plane. To bardzo fajny sposób na spędzenie sobotniej nocy.

To świetna zabawa, ale żałuję, że nie poświęciłem czasu na lepszą edukację w zakresie sieciowania w ogóle, zanim zacząłem od razu nurkować. W końcu znalazłem kilka postów od życzliwych bogów Digital Ocean Tutorial: Introduction to Networking Terminologyi Understanding ... Networking. Proponuję najpierw przeczytać je kilka razy przed zanurzeniem się.

Baw się dobrze!

Oryginalny post

Nie mogę pojąć mapowania portów dla Dockerkontenerów. W szczególności, jak przekazywać żądania z Nginx do innego kontenera, nasłuchując na innym porcie, na tym samym serwerze.

Mam plik Dockerfile dla kontenera Nginx w następujący sposób:

FROM ubuntu:14.04
MAINTAINER Me <[email protected]>

RUN apt-get update && apt-get install -y htop git nginx

ADD sites-enabled/api.myapp.com /etc/nginx/sites-enabled/api.myapp.com
ADD sites-enabled/app.myapp.com /etc/nginx/sites-enabled/app.myapp.com
ADD nginx.conf /etc/nginx/nginx.conf

RUN echo "daemon off;" >> /etc/nginx/nginx.conf

EXPOSE 80 443

CMD ["service", "nginx", "start"]

A potem api.myapp.complik konfiguracyjny wygląda tak:

upstream api_upstream{

    server 0.0.0.0:3333;

}


server {

    listen 80;
    server_name api.myapp.com;
    return 301 https://api.myapp.com/$request_uri;

}


server {

    listen 443;
    server_name api.mypp.com;

    location / {

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
        proxy_pass http://api_upstream;

    }

}

A potem jeszcze jeden dla app.myapp.com.

A potem biegnę:

sudo docker run -p 80:80 -p 443:443 -d --name Nginx myusername/nginx

I wszystko działa dobrze, ale żądania nie są przekazywane do innych kontenerów / portów. A kiedy ssh do kontenera Nginx i sprawdzam logi, nie widzę żadnych błędów.

Jakaś pomoc?

Odpowiedź @ T0xicCode jest prawidłowa, ale pomyślałem, że omówię szczegóły, ponieważ w końcu wdrożenie działającego rozwiązania zajęło mi około 20 godzin.

Jeśli chcesz uruchomić Nginx we własnym kontenerze i używać go jako odwrotnego serwera proxy do równoważenia obciążenia wielu aplikacji na tej samej instancji serwera, kroki, które musisz wykonać, są następujące:

Połącz swoje pojemniki

Kiedy używasz docker runkontenerów, zazwyczaj wprowadzając do nich skrypt powłoki User Data, możesz zadeklarować linki do innych działających kontenerów. Oznacza to, że musisz uruchomić swoje kontenery w odpowiedniej kolejności i tylko te ostatnie mogą łączyć się z pierwszymi. Tak jak to:

#!/bin/bash
sudo docker run -p 3000:3000 --name API mydockerhub/api
sudo docker run -p 3001:3001 --link API:API --name App mydockerhub/app
sudo docker run -p 80:80 -p 443:443 --link API:API --link App:App --name Nginx mydockerhub/nginx

Tak więc w tym przykładzie, APIpojemnik nie jest związana z żadnym innym, ale Apppojemnik jest powiązana APIi Nginxjest powiązana zarówno APIi App.

Wynikiem tego są zmiany w envzmiennych i /etc/hostsplikach, które znajdują się w kontenerach APIi App. Wyniki wyglądają tak:

/ etc / hosts

Uruchomienie cat /etc/hostsw Twoim Nginxkontenerze spowoduje:

172.17.0.5  0fd9a40ab5ec
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3  App
172.17.0.2  API

ENV Vars

Uruchomienie envw Twoim Nginxkontenerze spowoduje:

API_PORT=tcp://172.17.0.2:3000
API_PORT_3000_TCP_PROTO=tcp
API_PORT_3000_TCP_PORT=3000
API_PORT_3000_TCP_ADDR=172.17.0.2

APP_PORT=tcp://172.17.0.3:3001
APP_PORT_3001_TCP_PROTO=tcp
APP_PORT_3001_TCP_PORT=3001
APP_PORT_3001_TCP_ADDR=172.17.0.3

Obcięłem wiele rzeczywistych zmiennych, ale powyższe są kluczowymi wartościami potrzebnymi do proxy ruchu do kontenerów.

Aby uzyskać powłokę do uruchamiania powyższych poleceń w działającym kontenerze, użyj następującego:

sudo docker exec -i -t Nginx bash

Możesz zobaczyć, że masz teraz zarówno /etc/hostswpisy w plikach, jak i envzmienne, które zawierają lokalny adres IP dowolnego z połączonych kontenerów. O ile wiem, to wszystko, co dzieje się, gdy uruchamiasz kontenery z zadeklarowanymi opcjami linków. Ale teraz możesz użyć tych informacji do konfiguracji nginxw swoim Nginxkontenerze.

Konfigurowanie Nginx

To jest trochę trudne i jest kilka opcji. Możesz skonfigurować swoje witryny tak, aby wskazywały wpis w utworzonym /etc/hostspliku docker, lub możesz użyć ENVvars i uruchomić zamianę ciągu (użyłem sed) na swoim nginx.confi wszelkich innych plikach conf, które mogą znajdować się w twoim /etc/nginx/sites-enabledfolderze, aby wstawić adres IP wartości.

OPCJA A: Skonfiguruj Nginx przy użyciu zmiennych ENV

Jest to opcja, z której skorzystałem, ponieważ nie mogłem uruchomić /etc/hostsopcji pliku. Wkrótce spróbuję Opcji B i zaktualizuję ten post o wszelkie ustalenia.

Kluczową różnicą między tą opcją a użyciem /etc/hostsopcji file jest sposób, w jaki piszesz, Dockerfileaby używał skryptu powłoki jako CMDargumentu, który z kolei obsługuje zamianę ciągu w celu skopiowania wartości IP z ENVdo pliku (ów) conf.

Oto zestaw plików konfiguracyjnych, z którymi skończyłem:

Dockerfile

FROM ubuntu:14.04
MAINTAINER Your Name <[email protected]>

RUN apt-get update && apt-get install -y nano htop git nginx

ADD nginx.conf /etc/nginx/nginx.conf
ADD api.myapp.conf /etc/nginx/sites-enabled/api.myapp.conf
ADD app.myapp.conf /etc/nginx/sites-enabled/app.myapp.conf
ADD Nginx-Startup.sh /etc/nginx/Nginx-Startup.sh

EXPOSE 80 443

CMD ["/bin/bash","/etc/nginx/Nginx-Startup.sh"]

nginx.conf

daemon off;
user www-data;
pid /var/run/nginx.pid;
worker_processes 1;


events {
    worker_connections 1024;
}


http {

    # Basic Settings

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 33;
    types_hash_max_size 2048;

    server_tokens off;
    server_names_hash_bucket_size 64;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;


    # Logging Settings
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;


    # Gzip Settings

gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 3;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/xml text/css application/x-javascript application/json;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    # Virtual Host Configs  
    include /etc/nginx/sites-enabled/*;

    # Error Page Config
    #error_page 403 404 500 502 /srv/Splash;


}

UWAGA: Ważne jest, aby to daemon off;w nginx.confpliku, aby zapewnić, że pojemnik nie wyjść natychmiast po uruchomieniu.

api.myapp.conf

upstream api_upstream{
    server APP_IP:3000;
}

server {
    listen 80;
    server_name api.myapp.com;
    return 301 https://api.myapp.com/$request_uri;
}

server {
    listen 443;
    server_name api.myapp.com;

    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
        proxy_pass http://api_upstream;
    }

}

Nginx-Startup.sh

#!/bin/bash
sed -i 's/APP_IP/'"$API_PORT_3000_TCP_ADDR"'/g' /etc/nginx/sites-enabled/api.myapp.com
sed -i 's/APP_IP/'"$APP_PORT_3001_TCP_ADDR"'/g' /etc/nginx/sites-enabled/app.myapp.com

service nginx start

Zostawię ci zadanie domowe z większością treści nginx.confi api.myapp.conf.

Magia dzieje się wtedy, Nginx-Startup.shgdy używamy seddo zamiany ciągu znaków w APP_IPsymbolu zastępczym, który zapisaliśmy w upstreambloku naszych api.myapp.confi app.myapp.confplików.

To pytanie ask.ubuntu.com bardzo ładnie to wyjaśnia: znajdź i zamień tekst w pliku za pomocą poleceń

GOTCHA W OSX sedinaczej obsługuje opcje, -iszczególnie flaga. W Ubuntu -iflaga obsłuży zastąpienie „na miejscu”; otworzy plik, zmieni tekst, a następnie „zapisze” ten sam plik. W systemie OSX -iflaga wymaga rozszerzenia pliku, które ma mieć plik wynikowy. Jeśli pracujesz z plikiem, który nie ma rozszerzenia, musisz wprowadzić „” jako wartość -iflagi.

GOTCHA Aby użyć zmiennej ENV w wyrażeniu regularnym używanymsed do znalezienia ciągu, który chcesz zastąpić, musisz umieścić zmienną w cudzysłowach. Tak więc poprawna, choć niewyraźnie wyglądająca, składnia jest taka, jak powyżej.

Dlatego docker uruchomił nasz kontener i uruchomił Nginx-Startup.shskrypt, który sedzmienił wartość APP_IPna odpowiednią ENVzmienną, którą podaliśmy w sedpoleceniu. Mamy teraz pliki conf w naszym /etc/nginx/sites-enabledkatalogu, które mają adresy IP ze ENVzmiennych ustawionych przez docker podczas uruchamiania kontenera. W api.myapp.confpliku zobaczysz, że upstreamblok zmienił się na ten:

upstream api_upstream{
    server 172.0.0.2:3000;
}

Adres IP, który widzisz, może być inny, ale zauważyłem, że zwykle 172.0.0.x.

Powinieneś teraz mieć wszystko poprawnie routowane.

GOTCHA Po uruchomieniu pierwszego uruchomienia instancji nie można zrestartować / ponownie uruchomić żadnych kontenerów. Docker zapewnia każdemu kontenerowi nowy adres IP po uruchomieniu i nie wydaje się ponownie używać tego, który był wcześniej używany. Tak więc api.myapp.comza pierwszym razem otrzyma 172.0.0.2, ale następnym razem otrzyma 172.0.0.4. Ale Nginxjuż ustawił pierwszy adres IP w swoich plikach conf lub w swoim /etc/hostspliku, więc nie będzie w stanie określić nowego adresu IP dla api.myapp.com. Rozwiązanie tego najprawdopodobniej będzie używane CoreOSi jego etcdusługa, która, w moim ograniczonym rozumieniu, działa jak wspólna ENVdla wszystkich maszyn zarejestrowanych w tym samym CoreOSklastrze. To kolejna zabawka, którą będę się bawił przy ustawianiu.

OPCJA B: Użyj /etc/hostswpisów pliku

To powinien być szybszy i łatwiejszy sposób na zrobienie tego, ale nie mogłem zmusić go do pracy. Pozornie po prostu wprowadzasz wartość /etc/hostswpisu do swoich plików api.myapp.confi app.myapp.conf, ale nie mogłem uruchomić tej metody.

UPDATE: Zobacz odpowiedź @Wes Tod, aby uzyskać instrukcje, jak sprawić, by ta metoda działała.

Oto próba, którą podjąłem api.myapp.conf:

upstream api_upstream{
    server API:3000;
}

Biorąc pod uwagę, że w moim /etc/hostspliku jest taki wpis: 172.0.0.2 APIpomyślałem, że po prostu ściągnie wartość, ale wygląda na to, że tak nie jest.

Miałem również kilka dodatkowych problemów z Elastic Load Balancerpozyskiwaniem ze wszystkich AZ, więc mógł to być problem, gdy próbowałem tej trasy. Zamiast tego musiałem nauczyć się radzić sobie z zastępowaniem ciągów w Linuksie, więc to było zabawne. Spróbuję za chwilę i zobaczę, jak to działa.

Próbowałem użyć popularnego odwrotnego proxy Jasona Wildera, który magicznie działa dla każdego, i dowiedziałem się, że nie działa dla wszystkich (tj. Dla mnie). Jestem zupełnie nowy w NGINX i nie podobało mi się, że nie rozumiem technologii, których próbowałem użyć.

Chciałem dodać moje 2 centy, ponieważ powyższa dyskusja na temat linkingkontenerów jest teraz przestarzała, ponieważ jest to przestarzała funkcja. Oto wyjaśnienie, jak to zrobić za pomocą networks. Ta odpowiedź jest pełnym przykładem konfigurowania nginx jako zwrotnego serwera proxy do statycznie stronicowanej witryny internetowej przy użyciu Docker Composei konfiguracji nginx.

TL; DR;

Dodaj usługi, które muszą komunikować się ze sobą, do predefiniowanej sieci. Aby omówić krok po kroku sieci Dockera, dowiedziałem się tutaj kilku rzeczy: https://technologyconversations.com/2016/04/25/docker-networking-and-dns-the-good-the-bad-and- brzydki /

Zdefiniuj sieć

Przede wszystkim potrzebujemy sieci, w której mogą rozmawiać wszystkie Twoje usługi backendu. Zadzwoniłem do mnie, webale to może być cokolwiek zechcesz.

docker network create web

Zbuduj aplikację

Zrobimy po prostu prostą aplikację internetową. Witryna jest prostą stroną index.html obsługiwaną przez kontener nginx. Zawartość jest woluminem zamontowanym na hoście w folderzecontent

DockerFile:

FROM nginx
COPY default.conf /etc/nginx/conf.d/default.conf

default.conf

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /var/www/html;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

docker-compose.yml

version: "2"

networks:
  mynetwork:
    external:
      name: web

services:
  nginx:
    container_name: sample-site
    build: .
    expose:
      - "80"
    volumes:
      - "./content/:/var/www/html/"
    networks:
      default: {}
      mynetwork:
        aliases:
          - sample-site

Zauważ, że nie potrzebujemy już tutaj mapowania portów. Po prostu eksponujemy port 80. Jest to przydatne, aby uniknąć kolizji portów.

Uruchom aplikację

Uruchom tę witrynę za pomocą

docker-compose up -d

Kilka zabawnych sprawdzeń dotyczących mapowania DNS dla twojego kontenera:

docker exec -it sample-site bash
ping sample-site

Ten ping powinien działać wewnątrz kontenera.

Zbuduj proxy

Odwrotny serwer proxy Nginx:

Dockerfile

FROM nginx

RUN rm /etc/nginx/conf.d/*

Zresetowaliśmy całą konfigurację hosta wirtualnego, ponieważ zamierzamy ją dostosować.

docker-compose.yml

version: "2"

networks:
  mynetwork:
    external:
      name: web


services:
  nginx:
    container_name: nginx-proxy
    build: .
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf.d/:/etc/nginx/conf.d/:ro
      - ./sites/:/var/www/
    networks:
      default: {}
      mynetwork:
        aliases:
          - nginx-proxy

Uruchom serwer proxy

Uruchom proxy za pomocą naszego zaufanego

docker-compose up -d

Zakładając, że nie ma żadnych problemów, masz uruchomione dwa kontenery, które mogą rozmawiać ze sobą, używając swoich nazw. Przetestujmy to.

docker exec -it nginx-proxy bash
ping sample-site
ping nginx-proxy

Skonfiguruj wirtualnego hosta

Ostatnim szczegółem jest skonfigurowanie wirtualnego pliku hostingu, aby serwer proxy mógł kierować ruch w zależności od tego, jak chcesz skonfigurować dopasowanie:

sample-site.conf dla naszej konfiguracji wirtualnego hostingu:

  server {
    listen 80;
    listen [::]:80;

    server_name my.domain.com;

    location / {
      proxy_pass http://sample-site;
    }

  }

W zależności od tego, jak skonfigurowano serwer proxy, będziesz potrzebować tego pliku przechowywanego w conf.dfolderze lokalnym, który zamontowaliśmy za pomocą volumesdeklaracji w docker-composepliku.

Wreszcie, powiedz nginx, aby przeładował swoją konfigurację.

docker exec nginx-proxy service nginx reload

Ta sekwencja kroków jest kulminacją godzin pełnych bólu głowy, kiedy zmagałem się z zawsze bolesnym błędem 502 Bad Gateway i uczyłem się nginx po raz pierwszy, ponieważ większość mojego doświadczenia dotyczyła Apache.

Ta odpowiedź ma na celu zademonstrowanie, jak usunąć błąd złej bramy 502, który wynika z braku możliwości komunikacji między kontenerami.

Mam nadzieję, że ta odpowiedź zaoszczędzi komuś wiele godzin bólu, ponieważ z jakiegoś powodu trudno było znaleźć pojemniki do rozmowy, mimo że spodziewałem się, że będzie to oczywisty przypadek użycia. Ale z drugiej strony, ja głupi. Daj mi znać, jak mogę ulepszyć to podejście.

Korzystając z linków docker , możesz połączyć kontener nadrzędny z kontenerem nginx. Dodatkową funkcją jest to, że docker zarządza plikiem hosta, co oznacza, że ​​będziesz mógł odwoływać się do połączonego kontenera za pomocą nazwy, a nie potencjalnie losowego adresu IP.

„Opcja B” AJB może zostać uruchomiona przy użyciu podstawowego obrazu Ubuntu i samodzielnego skonfigurowania nginx. (To nie zadziałało, gdy użyłem obrazu Nginx z Docker Hub.)

Oto plik Docker, którego użyłem:

FROM ubuntu
RUN apt-get update && apt-get install -y nginx
RUN ln -sf /dev/stdout /var/log/nginx/access.log
RUN ln -sf /dev/stderr /var/log/nginx/error.log
RUN rm -rf /etc/nginx/sites-enabled/default
EXPOSE 80 443
COPY conf/mysite.com /etc/nginx/sites-enabled/mysite.com
CMD ["nginx", "-g", "daemon off;"]

Moja konfiguracja nginx (aka: conf / mysite.com):

server {
    listen 80 default;
    server_name mysite.com;

    location / {
        proxy_pass http://website;
    }
}

upstream website {
    server website:3000;
}

I wreszcie, jak zaczynam moje kontenery:

$ docker run -dP --name website website
$ docker run -dP --name nginx --link website:website nginx

To sprawiło, że zacząłem działać, więc mój nginx skierował w górę do drugiego kontenera docker, który ujawnił port 3000.

Odpowiedź @ gdbj to świetne wyjaśnienie i najbardziej aktualna odpowiedź. Oto jednak prostsze podejście.

Więc jeśli chcesz przekierować cały ruch z nasłuchiwania nginx 80do innego ujawniającego kontenera 8080, minimalna konfiguracja może wynosić tylko:

nginx.conf:

server {
    listen 80;

    location / {
        proxy_pass http://client:8080; # this one here
        proxy_redirect off;
    }

}

docker-compose.yml

version: "2"
services:
  entrypoint:
    image: some-image-with-nginx
    ports:
      - "80:80"
    links:
      - client  # will use this one here

  client:
    image: some-image-with-api
    ports:
      - "8080:8080"

Docker docs

Właśnie znalazłem artykuł od Ananda Mani Sankara, który pokazuje prosty sposób korzystania z serwera proxy Nginx w połączeniu z docker composer.

Zasadniczo należy skonfigurować łączenie instancji i porty w pliku docker-compose i odpowiednio zaktualizować nadrzędne w nginx.conf.