Bottle + Ubuntu + Apache2

[dd0815]

Ja, so wie es funktioniert wäre der Servername überflüssig, das stimmt...

Aber eigentlich hätte ich schon gern die Möglichkeit verschiedene Anwendungen einzeln anzusprechen, daher ja auch die Mühe mit den Serverblöcken... Dass es so alternativ funktioniert beweist ja nun, dass meine Pfade stimmen und nur irgendwas mit dem Servernamen nicht funktioniert.

Das hier steht als Beispiel im default-Serverblock von nginx drin, wie man eigene Serverblöcke definiert:

Code: Alles auswählen

#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

Ich versuche das mal in Einklang mit Deinem Post zu bringen:

Also, in der Config-Datei steht `server_name mserp;`, der Block gilt also nur für Anfragen, die genau an diesen Host (mserp) gerichtet werden, nicht SRMS004 oder sonstwas.
`root /var/www/mserp;` bedeutet, dass alles relativ zum Pfad /var/www/mserp gesucht wird, im Browser /mserp bedeutet also entweder /var/www/mserp/mserp oder wegen Index /var/www/mserp/mserp/index.html
Keine der beide Dateien existiert.

Jaaaa, habe jetzt daraufhin auch mal: root /var/www versucht. Nach Deiner Aussage müsste nginx jetzt den Pfad /var/www/mserp draus machen, oder??? Geht leider auch nicht...

[dd0815]

Wenn es verschiedene Anwendungen auf dem selben Host gibt, die über die Pfade unterschieden werden, dann brauchst Du einen reverse-Proxy (also nginx), der die URL parst und je nach erstem Verzeichnis unterschiedliche Anwendungen anspricht.

Na genau das versuchen wir doch hier die ganze Zeit, oder?

[dd0815]

Hier nochmal die funktionierende Konfiguration mit dem geänderten Port in Gänze, ich mach jetzt erstmal Feierabend, bin fertig mit dem Tag :

Code: Alles auswählen

server {
        listen 8080;
        listen [::]:8080;

        server_name _;

        root /var/www/mserp/html/;
        index index.html;

        location / {
                try_files $uri $uri/ =404;
        }
}

[Sirius3]

Also der wesentliche Unterschied ist, dass Du jetzt den falschen server_name durch den catch-all-Wert _ ersetzt hast. Dass Du zusätzlich den Port geändert hat, führt zu Deiner Vodoo-Annahme, damit hättest Du irgend etwas repariert.

[dd0815]

Hallo Sirius3,

aber ich hab doch gar nicht angenommen, dass ich etwas repariert habe - schon gar nicht mit Vodoo , das ist nur grade die einzige funktionierende Lösung. Wie gesagt, ich würde gern einen separaten Serverblock haben. Aber bis jetzt kann mir leider keiner von Euch sagen, was ich in der nginx-Serverblockkonfigurationsdatei bei Servernamen & Pfad eintragen muss, damit ich in der Browser-Adresszeile Server/Applikation eingebe und ich meine Test-index.html sehe - mittlerweile wisst Ihr alle nginx-Pfade sowie Dateien samt Konfiguration.

Ich hatte gestern auch mal den default-Pfad geändert, so dass er auf mein Verzeichnis zeigt. Heute komischerweise funktioniert dieser Pfad, gestern tat er es trotz nginx-Neustart nicht. Hm, vielleicht sollte ich mal alles nochmal eintragen und ein Tag warten & den Rechner komplett runterfahren, vielleicht gehts dann (mit etwas Vodoo) . Ich arbeite jetzt erstmal mit dem Default-Pfad weiter, aber wenn jemand noch eine Idee hat, dann immer raus damit...

So, widmen wir uns mal wieder dem gunicorn. Ich habe das gunicorn so gestartet (testApp.py heißt meine Datei = modulname, Aufruf erfolgte direkt im Verzeichnis, daher ohne Pfad):

Code: Alles auswählen

gunicorn -w 4 testApp:app

Das hat funktioniert:

Code: Alles auswählen

[2019-10-02 06:31:40 +0000] [26505] [INFO] Starting gunicorn 19.7.1
[2019-10-02 06:31:40 +0000] [26505] [INFO] Listening at: http://127.0.0.1:8000 (                   26505)
[2019-10-02 06:31:40 +0000] [26505] [INFO] Using worker: sync
[2019-10-02 06:31:40 +0000] [26509] [INFO] Booting worker with pid: 26509
[2019-10-02 06:31:40 +0000] [26510] [INFO] Booting worker with pid: 26510
[2019-10-02 06:31:40 +0000] [26511] [INFO] Booting worker with pid: 26511
[2019-10-02 06:31:40 +0000] [26512] [INFO] Booting worker with pid: 26512
[2019-10-02 06:33:01 +0000] [26505] [INFO] Handling signal: winch

Wie Ihr seht, schaut gunicorn aber noch auf die falsche Adresse (127.0.0.1:8000). Wo kann ich das einstellen?

Hier nochmal die testApp.py:

Code: Alles auswählen

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

#from bottle import route, run, template
import bottle
from bottle import route, run, Response

# a basic URL route to test whether Bottle is responding properly
@route('/')
def index():
    return Response("It works!")

# these two lines are only used for python app.py
if __name__ == '__main__':
    run(host='0.0.0.0', port=8080, debug=True, reloader=True)

# this is the hook for Gunicorn to run Bottle
app = bottle.default_app()

Viele Grüße,
dd0815

[dd0815]

Hallo nochmal,

hiermit soll das wohl funktionieren:

Code: Alles auswählen

gunicorn --bind 127.0.0.0:8080 -w 4 testApp:app

allerdings beharken sich nun nginx und gunicorn, da sie sich beide auf dasselbe "binden" wollen. Das obige funktioniert nur, wenn nginx gestoppt ist und natürlich bringt dann nginx eine Fehlermeldung, wenn man es wieder starten möchte

[dd0815]

Success:

habe hier eine Anleitung gefunden, wie man den Serverblock konfigurieren muss, damit er nun wirklich als Proxy fungiert:

https://stackoverflow.com/questions/128 ... m-gunicorn

Nun sieht meine Serverblock-Konfigurationsdatei so aus:

Code: Alles auswählen

server {
        listen 8080;
        listen [::]:8080;

        server_name _;

        # declar proxy params and values to forward to your gunicorn webserver
        proxy_pass_request_headers on;
        proxy_pass_request_body on;
        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_read_timeout 120s;

        #root /var/www/mserp/html/;
        #index index.html;

        location / {
                # try_files $uri $uri/ =404;

                # here is where you declare that every request to /
                # should be proxy to 127.0.0.1:8000 (which is where
                # your gunicorn will be running on)
                proxy_pass_header Server;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Scheme $scheme;
                proxy_connect_timeout 10;
                proxy_read_timeout 10;

                proxy_pass http://127.0.0.1:8000/;
                # the actual nginx directive to forward the request
        }
}

Dann wie gehabt gunicorn ohne bind starten (falls Ihr direkt mit der Standard-IP 127.0.0.1:8000 arbeiten wollt bzw. mit einer anderen IP bspw. bei mehreren Applikationen):

Code: Alles auswählen

gunicorn -w 4 testApp:app

Im Gegensatz zum vorherigen Problem ging das jetzt relativ schnell...

[Sirius3]

Bevor man gunicorn an nginx anschließt, sollte man ja wohl einen Funktionierenden Web-Server haben, der statische Daten ausliefern kann, und da haben wir Dir deutlich gesagt, was Du falsch machst. Und Vodoo ist, den Port zu ändern und zu behaupten, dass es deshalb jetzt funktioniert, obwohl der Port gar nichts damit zu tun hatte.

`location /` mußt Du jetzt durch `location /mserp` ersetzen, damit nur alles was zu mserp gehört an Python weitergeleitet wird, und Du noch andere Python-Services unter anderen Namen bedienen kannst.
Dann fehlt noch ein root, damit Du die Auslieferung von statischen Daten von den dynamischen trennen kannst.

[dd0815]

Hallo Sirius3,

also wenn Ihr mir deutlich gesagt habt, was ich falsch gemacht habe, dann hab ich es anscheinend nicht verstanden und konnte es somit nicht umsetzen - sonst hätte ich wohl nicht permanent nachgefragt, was ich denn nun wohin schreiben muss... Aus meiner Anfängersicht war da eben gar nichts klar. Und nach der Portänderung habe ich wirklich das allererste Mal meine index.html angezeigt bekommen, insofern ist das keine Vodoo-Behauptung, sondern einfach nur eine Tatsache... Ich habe auch langsam das Gefühl, dass sich die noch vorhandene default- und meine mserp-Konfigurationsdateien beharken (siehe unten)

Ach, an die Location kann ich was ranschreiben? Warum rückst Du denn jetzt erst damit raus, das hab ich doch die ganze Zeit gesucht (bzw. war mir nicht klar) - in den ganzen Beispielen im Internet steht da nie etwas dran, da hätten wir uns viele Posts sparen können Nun funktioniert auch mein von Anfang an nachfragter Aufruf Server/Applikation (172.21.3.4:8080/mserp). Aber warum das ganze nicht ohne den separaten Port funktioniert, erschließt sich mir immer noch nicht (genauso wie der Eintrag server_name )

mserp-Serverblockdatei im Verzeichnis sites-available:

Code: Alles auswählen

server {
	listen 8080;
	listen [::]:8080;

	server_name _;

	# declar proxy params and values to forward to your gunicorn webserver
	proxy_pass_request_headers on;
	proxy_pass_request_body on;
	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_read_timeout 120s;

	# 
	location /mserp {
		# try_files $uri $uri/ =404;
		
		# statische Daten	
		root /var/www/mserp/;
		
		# here is where you declare that every request to /
		# should be proxy to 127.0.0.1:8000 (which is where
		# your gunicorn will be running on)
		proxy_pass_header Server;
		proxy_set_header Host $http_host;
		proxy_redirect off;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Scheme $scheme;
		proxy_connect_timeout 10;
		proxy_read_timeout 10;

		# the actual nginx directive to forward the request
		proxy_pass http://127.0.0.1:8000/;

	}
}

default-Serverblockdatei im Verzeichnis sites-available:

Code: Alles auswählen

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

	# SSL configuration
	#
	# listen 443 ssl default_server;
	# listen [::]:443 ssl default_server;
	#
	# Note: You should disable gzip for SSL traffic.
	# See: https://bugs.debian.org/773332
	#
	# Read up on ssl_ciphers to ensure a secure configuration.
	# See: https://bugs.debian.org/765782
	#
	# Self signed certs generated by the ssl-cert package
	# Don't use them in a production server!
	#
	# include snippets/snakeoil.conf;

	root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html index.php;

	server_name _;

	location / {
		# First attempt to serve request as file, then
		# as directory, then fall back to displaying a 404.
		try_files $uri $uri/ =404;
	}

	# pass PHP scripts to FastCGI server
	#
	#location ~ \.php$ {
	#	include snippets/fastcgi-php.conf;
	#
	#	# With php-fpm (or other unix sockets):
	#	fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
	#	# With php-cgi (or other tcp sockets):
	#	fastcgi_pass 127.0.0.1:9000;
	#}

	# deny access to .htaccess files, if Apache's document root
	# concurs with nginx's one
	#
	#location ~ /\.ht {
	#	deny all;
	#}
}

Jedenfalls allen Beteiligten und Dir vielen Dank für die Hilfe
dd0815