Ich habe versucht, eine Instanz aus tokio region (die übrigens normal funktioniert) nach sao paulo region zu verlegen, dann folgte ich diese grundlegenden Schritte durchzuführen, aber wenn ich die Instanz von der generierten AMI starte und anschalte, zeigt es mir " 502 Bad Gateway " Nachricht im Browser.
Die Hauptkomponenten auf diesem verschobenen Server sind: nginx, uwsgi, django, Supervisor, neues Relikt.
Alle Konfigurationen sind für diesen verschobenen Server gleich, also habe ich alle Dienste neu gestartet, es scheint, dass nginx gut funktioniert, aber es hat ein Detail, um die nächste Konfiguration anzuwenden, die die Konfigurationsdatei meiner Seite ist:
nginx / sites-available / mysite :
%Vor%Um ehrlich zu sein, ich habe erwartet, dass es normal funktioniert, da Ссылка funktioniert aber ich verstehe das nicht Grund, warum Nginx Conexion ist gebrochen, brauche ich etwas Hilfe, damit ich ein wenig mehr erforschen kann. was vergesse ich sonst noch?
UPDATE:
Nun ... Nach dem Vorschlag von @Michael - sqlbot überprüfte ich die Protokolldateien gemäß dieser Datei:
/var/log/nginx/site_error.log
%Vor%Mit dem werde ich nochmal die conexion verifizieren und es zeigt mir:
%Vor%Und dann habe ich es mit curl probiert und nach ungefähr 30 Sekunden druckt es folgendes:
%Vor%Ich habe diesen merkwürdigen Fehler, was bedeutet das wirklich?
UPDATE 2:
Es gibt Konfigurationsdatei von mysite auf uwsgi und ihre Protokolldatei, aber es ist die gleiche Art von Nachrichten des Servers auf tokio (die normal funktioniert) , so verwerfe ich, dass dies ein Problem von war uwsgi:
/etc/uwsgi/apps-enabled/mysite.ini
%Vor%/var/log/uwsgi/app/mysite.log
%Vor%UPDATE 3:
Ich habe netstat -nap -p | grep 8888 eingegeben und es zeigt mir:
Dann tippte ich ps aux | grep 7550 und ...
Nun, ich habe das mit cat /var/log/gunicorn/mysite.log überprüft und ich habe folgendes bekommen:
Nun ... Gunicorn scheint zu versagen (es ist innerhalb von virtualenv), also habe ich die Debugging im Debug-Modus überprüft:
gunicorn mysite.wsgi: Anwendung --preload --debug --level auf Debug-Ebene
%Vor%Ich weiß, dass es bisher ein Problem mit Gunicorn gibt, es schlägt fehl und startet sich selbst neu und schlägt wieder fehl, aber diese Nachrichten zeigen mir keinen klaren Fehler ... Gibt es noch andere Ideen? Ich fange an, mich sehr verwirrt zu fühlen: S
Effektiv ... Umgebungsvariablen waren die Täter (und ich, weil ich es nicht bemerkte), sie waren nicht richtig konfiguriert, daher stürzt Django ab, als Gunicorn versucht, es auszuführen.
Und Ich habe dieses Problem gelöst, indem ich alle Umgebungsvars überprüft und richtig eingerichtet habe entsprechend meiner Instanz EC2 ... sagt @Serj Zaharchenko so viel zu dem einfachen aber mächtigen Hinweis.
Ich habe das gefunden, weiß nicht, ob es dein Problem löst.
Die erste Zeile der gunicorn_django Datei war "#! / opt / django / env / mysite / bin / python", was der Pfad meines virtualenvironment Python Pfades ist. Das gelöste Problem wird durch "#! / Usr / bin / env python"
ersetztTags und Links django nginx amazon-web-services amazon-ec2 uwsgi