Dieses Mal habe ich unter Bezugnahme auf diesen Artikel versucht, mithilfe der Aails-App, die ich zum ersten Mal erstellt habe, mithilfe von AWS eine Infrastruktur aufzubauen. https://qiita.com/naoki_mochizuki/items/814e0979217b1a25aa3e
$git make gcc-c++ patch
git: 'make' is not a git command. See 'git --help'.
The most similar commands are blame, merge, stage
Ich habe den Fehler bekommen. Dies musste unkommentiert sein und als einzeiliger Befehl ausgeführt werden.
$sudo yum install git make gcc-c++ patch openssl-devel libyaml-devel libffi-devel libicu-devel libxml2 libxslt libxml2-devel libxslt-devel zlib-devel readline-devel mysql mysql-server mysql-devel ImageMagick ImageMagick-devel epel-release
$sudo mkdir www
mkdir: Verzeichnis "www" kann nicht erstellt werden: Datei existiert
Ich habe den Fehler bekommen. Es scheint, dass es bereits existiert, aber ich erinnere mich nicht daran, es geschaffen zu haben ...
Ich habe mich gefragt, ob ich es so verwenden soll, aber ich habe eine Datei mit einem anderen Namen (XYZ) erstellt und stattdessen verwendet.
$cat aws_git_rsa.pub
cat: aws_git_rsa.pub: No such file or directory
Geben Sie die Datei ein, in der der Schlüssel gespeichert werden soll (): aws_git_rsa (Leerzeichen halber Breite in diesem Teil) Als ich den Schlüssel neu erstellte, konnte ich den Inhalt des öffentlichen Schlüssels erfolgreich anzeigen.
Wenn ich versuche, MySQL zu starten, wird der folgende Fehler angezeigt
$ sudo service mysqld start #start mysqld
Redirecting to /bin/systemctl start mysqld.service
Failed to start mysqld.service: Unit not found.
Ich habe den folgenden Befehl mit Bezug auf den folgenden Artikel ausgeführt und es hat funktioniert.
https://qiita.com/yuta-38/items/4074f5ada9e22088c8dd
$ sudo yum install -y mariadb-server
$ sudo systemctl enable mariadb
$ sudo service mariadb start
Unter Amazon Linux 2 scheint es auch so zu sein, dass beim Versuch, MySQL mit yum zu installieren, versucht wird, mariaDB zu installieren. Ich habe es nicht geübt, aber die folgenden Artikel können hilfreich sein. https://qiita.com/hamham/items/fd77bb0bb167a150dc8e#mysql57%E3%81%AE%E5%B0%8E%E5%85%A5
Ich habe den folgenden Befehl eingegeben, aber Nginx startet nicht.
$ sudo service nginx start
Redirecting to /bin/systemctl start nginx.service
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
Führen Sie den folgenden Befehl gemäß den Anweisungen des Fehlers aus
$ systemctl status nginx.service
nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Aktiv: fehlgeschlagen (Ergebnis: Exit-Code) seit dem Monat 2020-07-13 09:10:04 UTC; vor 57s
Process: 11360 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
Process: 11356 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 11355 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Ich kannte die Ursache nicht und führte daher Folgendes aus.
$sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Es schien kein Problem mit der Konfigurationsdatei zu geben, daher hatte ich Probleme.
Ich habe den folgenden Befehl gefunden, als ich verschiedene Dinge recherchiert habe.
$ sudo service nginx status -l
Redirecting to /bin/systemctl status -l nginx.service
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Aktiv: fehlgeschlagen (Ergebnis: Exit-Code) seit dem Monat 2020-07-13 09:10:04 UTC; vor 27 Minuten
Process: 11360 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
Process: 11356 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 11355 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
13. Juli 09:10:02 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] bind () bis [::]: 80 fehlgeschlagen (98) : Adresse bereits verwendet)
13. Juli 09:10:03 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] bind () bis 0.0.0.0:80 fehlgeschlagen (98: Adresse bereits verwendet)
13. Juli 09:10:03 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] bind () bis [::]: 80 fehlgeschlagen (98) : Adresse bereits verwendet)
13. Juli 09:10:03 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] bind () bis 0.0.0.0:80 fehlgeschlagen (98: Adresse bereits verwendet)
13. Juli 09:10:03 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] bind () bis [::]: 80 fehlgeschlagen (98) : Adresse bereits verwendet)
13. Juli 09:10:04 ip-10-0-10-10.ap-northeast-1.compute.internal nginx [11360]: nginx: [emerg] konnte immer noch nicht binden ()
13. Juli 09:10:04 ip-10-0-10-10.ap-northeast-1.compute.internal systemd [1]: nginx.service: Steuerungsprozess beendet, Code = Status beendet = 1
13. Juli 09:10:04 ip-10-0-10-10.ap-northeast-1.compute.internal systemd [1]: Start des Nginx-HTTP- und Reverse-Proxy-Servers fehlgeschlagen.
13. Juli 09:10:04 ip-10-0-10-10.ap-northeast-1.compute.internal systemd [1]: Die Einheit nginx.service ist in den Status "Fehlgeschlagen" eingetreten.
13. Juli 09:10:04 ip-10-0-10-10.ap-northeast-1.compute.internal systemd [1]: nginx.service fehlgeschlagen.
Demnach scheint der eingestellte Port 80 bereits zu laufen.
Als Ergebnis der Prüfung der Ursache erinnerte ich mich daran, dass ich Apache zuvor installiert und so eingestellt hatte, dass es automatisch in einem Webkurs gestartet wird.
$ sudo systemctl status httpd.service
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Aktiv: aktiv (läuft) seit Tag 2020-07-12 06:24:44 UTC; vor 2 Tagen
Docs: man:httpd.service(8)
Main PID: 21760 (httpd)
Status: "Total requests: 149; Idle/Busy workers 100/0;Requests/sec: 0.00084; Bytes served/sec: 2 B/sec"
CGroup: /system.slice/httpd.service
├─20766 /usr/sbin/httpd -DFOREGROUND
├─21049 /usr/sbin/httpd -DFOREGROUND
├─21055 /usr/sbin/httpd -DFOREGROUND
├─21056 /usr/sbin/httpd -DFOREGROUND
├─21760 /usr/sbin/httpd -DFOREGROUND
├─21761 /usr/sbin/httpd -DFOREGROUND
├─21762 /usr/sbin/httpd -DFOREGROUND
├─21763 /usr/sbin/httpd -DFOREGROUND
├─21764 /usr/sbin/httpd -DFOREGROUND
├─21765 /usr/sbin/httpd -DFOREGROUND
└─21887 /usr/sbin/httpd -DFOREGROUND
Sicher genug, dass Apache bereits funktionierte. Nachdem ich den automatischen Start deaktiviert und gestoppt hatte, führte ich den Startbefehl von NginX aus und es konnte sicher gestartet werden.
「We're sorry, but something went wrong. If you are the application owner check the logs for more information.」
Sehen Sie sich vorerst die Fehlerprotokolle von Unicorn und Nginx an. (Referenzartikel Jede Einstellung enthält eine Beschreibung des Pfads zum Fehler.)
$ tail -f /var/xyz/rails/circle_app/log/unicorn.log
I, [2020-07-14T08:37:26.186843 #19212] INFO -- : listening on addr=/var/xyz/rails/circle_app/tmp/sockets/.unicorn.sock fd=9
I, [2020-07-14T08:37:26.203171 #19212] INFO -- : master process ready
I, [2020-07-14T08:37:26.207382 #19214] INFO -- : worker=0 ready
I, [2020-07-14T08:37:26.207617 #19215] INFO -- : worker=1 ready
Einhorn scheint kein Problem zu sein.
$ tail -f /var/xyz/rails/circle_app/log/nginx.error.log
2020/07/14 08:36:17 [crit] 19174#0: *1 connect() to unix:/var/xyz/rails/circle_app/tmp/sockets/.unicorn.sock failed (2: No such file or directory) while connecting to upstream, client: 103.5.140.158, server: 46.51.239.151, request: "GET / HTTP/1.1", upstream: "http://unix:/var/xyz/rails/circle_app/tmp/sockets/.unicorn.sock:/", host: "46.51.239.151"
Es scheint ein Problem mit Nginx zu geben. Wie Sie im nächsten Artikel sehen können, müssen Sie anscheinend die Art und Weise ändern, um den Pfad von CentOS 7 aus zu schreiben. https://qiita.com/emahiro/items/b2762a26bca35bbb0cf9
Ich habe die Unicorn- und Nginx-Dateien unter Bezugnahme auf den folgenden Artikel geändert.
https://qiita.com/noraworld/items/c8acf4bb981c8d8535df
Überprüfen Sie auch, ob das Einhorn mit dem folgenden Befehl ausgeführt wird, und stoppen Sie es mit dem Befehl kill
$ ps aux | grep unicorn
$ kill -9 pid ← Ersetzen Sie den pid-Teil durch die durch den obigen Befehl angezeigte Nummer
Ich habe mit dem folgenden Befehl neu gestartet
$ unicorn_rails -c / var / www / Rails / (App-Name) /config/unicorn.conf.rb -D -E Produktion
Nachdem Sie alle oben genannten Schritte ausgeführt haben, wird sie beim erneuten Laden der Webseite sicher angezeigt! !! !!
Die folgenden Kurse wurden von Udemy gekauft, bevor der Infrastrukturbau funktionierte, und ich konnte sie in einem guten Tempo verstehen. https://www.udemy.com/course/aws-and-infra/
Recommended Posts