NPM Docker 502 Bad Gateway

sascha-sphw

Member
Hallo zusammen,

nach einer Empfehlung hier im Forum bin ich gerade dabei mir mal den Nginx Proxy Manger anzuschauen. Jetzt habe ich zum testen mal folgendes aufgebaut.

docker
- portainer
- npm (https://nginxproxymanager.com/setup/#mysql-database)

Jetzt wollte ich einfach mal anstatt localhost:9000 -> portainer.local verwenden.
In Windows hosts habe ich folgendes eingefügt.
Code:
127.0.0.1 portainer.local

In NPM einen proxy host eingerichtet
1623231873537.png


Leider bekomme ich beim Aufruf von http://portainer.local dann leider einen 502 Bad Gateway und im log ist folgendes zu finden.
Code:
2021/06/09 09:07:48 [error] 3348#3348: *826 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: portainer.local, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:9000/", host: "portainer.local"
2021/06/09 09:07:49 [error] 3348#3348: *826 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: portainer.local, request: "GET /favicon.ico HTTP/1.1", upstream: "http://127.0.0.1:9000/favicon.ico", host: "portainer.local", referrer: "http://portainer.local/"

Mit Apache habe ich das immer so gemacht, was super funktioniert hat.
Code:
ProxyPass "/" "http://127.0.0.1:9000"
ProxyPassReverse "/" "http://127.0.0.1:9000"

Was habe ich übersehe/vergessen?

Edit: portainer ist über 127.0.0.1:9000 ganz normal zu erreichen.
 

Thunderbyte

Moderator
Staff member
Das mag ich gewesen sein, der Dir das empfohlen hat. Versuchen wir doch nochmal das aufzudröseln. Da brauchts noch einige Infos dazu.
Auf welchem Rechner laufen Docker mit Portainer und NPM? Welcher Rechner ist der "Windows" Rechner?

127.0.0.1 ist als IP Adresse immer der localhost, also der Rechner selbst. In NPM sollte man lieber mit Containernamen arbeiten, es gibt eine Docker-interne DNS Auflösung.

Zwei Container sollten im gleichen Docker-Network sein, um sich zu sehen (also Portainer und NPM z.B. im Netzwerk "proxy_network", dies kann man mit entsprechende run Befehlen oder Einträgen in eine compose Datei erreichen.

Du solltest mit NPM schon echte, existente FQDNs verwenden und keine lokalen Namen. Zumindest sollte der lokale DNS Server diese Namen auflösen können (Pi-Hole hat z.B. dafür eine Option). Dann brauchst Du auch den hosts Eintrag nicht.

TLDR: da brauchen wir noch einige weitere Infos und so ganz richtig oder sinnvoll ist die bisherige Konfiguration noch nicht.
 

sascha-sphw

Member
127.0.0.1 ist als IP Adresse immer der localhost, also der Rechner selbst.
Haha, ich trottelt! Jetzt ist der Knoten geplatzt! Im container ist 127.0.0.1 / localhost ja der container, und nicht der host.
Ersetzt man den loopback einfach mit host.docker.internal, schon Zeigt er da hin wo ich hin will.
Ein Test mit dem container namen im selben Netzwerk hat ebenfalls funktioniert.

Danke vielmals!

So, jetzt will ich Dir aber noch verraten was ich eigentlich vor habe.

Ich bin Softwareentwickler und es kommt immer wieder vor, dass ich mir zum testen einen Proxy anlegen möchte (Bequemlichkeit, Cross Domain Policies, https auf http usw.) Dazu hatte ich bisher immer XAMPP auf meinem Lokalen Rechner installiert (Apache hätte auch gereicht, aber ich habe mariadb usw. auch hin und wieder verwendet). Nachdem ich aber Docker kennengelernt habe und gemerkt habe, wie schnell und unkompliziert man hier Test Environments aufziehen, löschen oder einfach verschieben kann will ich selbstverständlich mehr und mehr damit machen. Nachdem Du mir dann NPM empfohlen hast (eigentlich für Produktion, hier nutze ich aktuell noch Apache) dachte ich mir warum nicht auch für meine Lokalen Tests, die Oberfläche ist super, viel schneller / besser als in den Apache config files einen neuen virtual host einstellen. Außerdem zum Austesten und lernen um einiges sicherer :).

Das ganze läuft über Docker Desktop auf Windows 10 (WSL) und ist wie gesagt, nur zum spielen/entwickeln.
Portainer:
Bash:
docker run -d -p 8000:8000 -p 9000:9000 --name portainer -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce
Nginx starte ich über portainer stack:
Code:
version: "3"

volumes:
  db_data:
    driver: local
  nginx_data:
    driver: local
  nginx_cert:
    driver: local

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    environment:
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"
    volumes:
      - nginx_data:/data
      - nginx_cert:/etc/letsencrypt
    depends_on:
      - db
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: 'npm'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm'
    volumes:
      - db_data:/var/lib/mysql
 

Thunderbyte

Moderator
Staff member
Jep. 172.0.0.1 ist immer der Container selbst, ansonsten werden die dockerinternen IPs verwendet (meist 172.0.X.0/16). Diese können sich jedoch für die Container auch ändern (außer man fixiert die IP, was auch geht) daher besser den Containernamen verwenden.
zu 172.0.0.1 muss ich immer an http://www.lustigestories.de/stories/irc_hacker.php denken ;)

Portainer Stack kann man machen, ich habe von einem Freund einen anderen Trick abgeschaut: alle Docker Sachen (dockerfiles, compose Files, etc), die man selbst schreibt, in einem eigenen, privaten Github Repo ablegen und sich dann das ganze Paket auf den Host runterklonen. So hat man auch gleich nochmal eine Absicherung und Du kannst die gleichen Konfigs überall wo Du sie haben willst garantiert gleich runterziehen. Wenn Du Dir z.B. ein Containersetup für zu Hause gebaut hast und es funktioniert, kannst Dus nach dem Entwickeln gleich auch auf einem (mit den gleichen File/Ordnerpfaden arbeitenden) Internet Docker Host für den Produktivbetrieb starten. Du musst lediglich noch die herausgelegten Files rüberSSHen. Dabei wäre es aber auch gleich wichtig, nicht default Passwörter zu verwenden, sondern gleich lange Randomzeichenfolgen zu verwenden.

Die ganze Geschichte kann man sehr gut mit https://code.visualstudio.com/ editieren, da gibt es auch Dockerplugins.
 

sascha-sphw

Member
Jep. 172.0.0.1 ist immer der Container selbst, ansonsten werden die dockerinternen IPs verwendet (meist 172.0.X.0/16). Diese können sich jedoch für die Container auch ändern (außer man fixiert die IP, was auch geht) daher besser den Containernamen verwenden.
zu 172.0.0.1 muss ich immer an http://www.lustigestories.de/stories/irc_hacker.php denken ;)
Ja, die Geschichte kenne ich. Ein Klassiker! Da gibt's auch T-Shirts dazu. :D
Portainer Stack kann man machen, ich habe von einem Freund einen anderen Trick abgeschaut: alle Docker Sachen (dockerfiles, compose Files, etc), die man selbst schreibt, in einem eigenen, privaten Github Repo ablegen und sich dann das ganze Paket auf den Host runterklonen. So hat man auch gleich nochmal eine Absicherung und Du kannst die gleichen Konfigs überall wo Du sie haben willst garantiert gleich runterziehen. Wenn Du Dir z.B. ein Containersetup für zu Hause gebaut hast und es funktioniert, kannst Dus nach dem Entwickeln gleich auch auf einem (mit den gleichen File/Ordnerpfaden arbeitenden) Internet Docker Host für den Produktivbetrieb starten. Du musst lediglich noch die herausgelegten Files rüberSSHen. Dabei wäre es aber auch gleich wichtig, nicht default Passwörter zu verwenden, sondern gleich lange Randomzeichenfolgen zu verwenden.
Ja, sobald ich compose files habe, die ich später wiederverwenden möchte, hatte ich das dann vor. Aber Du musst die gar vorher selber clonen, das macht Portainer für Dich (vorausgesetzt Du möchtest das). Noch interessanter wird es dann hiermit. https://github.com/portainer/portainer/issues/1753
1623345116531.png

Die ganze Geschichte kann man sehr gut mit https://code.visualstudio.com/ editieren, da gibt es auch Dockerplugins.
Ja... da bin ich etwas verwöhnt. ;)
 

Thunderbyte

Moderator
Staff member
Ah, nice. Dann haben die das von Github ziehen echt schon eingebaut, inklusive Authentication. Sehr nett. Muss ich beim nächsten (eigenen) Container mal ausprobieren. Danke.
 
Top