[RUBY] Erreur lors de la création de l'infrastructure avec l'application AWS

Cette fois, en me référant à cet article, j'ai essayé de créer une infrastructure à l'aide d'AWS avec l'application rails que j'ai créée pour la première fois. https://qiita.com/naoki_mochizuki/items/814e0979217b1a25aa3e

Construction de l'environnement d'instance EC2

$git make gcc-c++ patch git: 'make' is not a git command. See 'git --help'. The most similar commands are blame, merge, stage

J'ai eu l'erreur. Cela devait être décommenté et exécuté comme une commande sur une ligne. $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: impossible de créer le répertoire `www ': le fichier existe J'ai eu l'erreur. Il semble qu'il existe déjà, mais je ne me souviens pas l'avoir créé ... Je me demandais si je devais l'utiliser tel quel, mais j'ai créé un fichier avec un autre nom (XYZ) et l'ai utilisé à la place.

Coopération avec git, clone d'application

$cat aws_git_rsa.pub cat: aws_git_rsa.pub: No such file or directory

Cela était dû au fait que lorsque j'ai créé la clé publique, l'opération était différente de l'entrée de commande normale, j'ai donc ajouté un espace demi-largeur derrière: aws_git_rsa. (Erreur générale ...) $ ssh-keygen -t rsa

Entrez le fichier dans lequel enregistrer la clé (): aws_git_rsa (espace demi-largeur dans cette partie) Lorsque j'ai recréé la clé, j'ai pu révéler avec succès le contenu de la clé publique.

Paramètres MySQL

Lorsque j'essaye de démarrer Mysql, j'obtiens l'erreur suivante $ sudo service mysqld start #start mysqld Redirecting to /bin/systemctl start mysqld.service Failed to start mysqld.service: Unit not found. J'ai exécuté la commande suivante en référence à l'article suivant et cela a fonctionné. https://qiita.com/yuta-38/items/4074f5ada9e22088c8dd $ sudo yum install -y mariadb-server $ sudo systemctl enable mariadb $ sudo service mariadb start

De plus, sur Amazon Linux 2, il semble que lorsque vous essayez d'installer mysql avec yum, il essaie d'installer mariaDB. Je ne l'ai pas pratiqué, mais les articles suivants peuvent être utiles. https://qiita.com/hamham/items/fd77bb0bb167a150dc8e#mysql57%E3%81%AE%E5%B0%8E%E5%85%A5

Démarrez Nginx

J'ai entré la commande suivante, mais Nginx ne démarre pas. $ 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.

Exécutez la commande suivante comme indiqué par l'erreur $ 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) Actif: échec (résultat: code de sortie) depuis le mois 2020-07-13 09:10:04 UTC; il y a 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)

Je ne connaissais pas la cause, alors j'ai également exécuté ce qui suit. $sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

Il ne semblait y avoir aucun problème avec le fichier de configuration, donc j'étais en difficulté. J'ai trouvé la commande suivante en recherchant diverses choses. $ 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) Actif: échoué (résultat: code de sortie) depuis le mois 2020-07-13 09:10:04 UTC; il y a 27min 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 juillet 09:10:02 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] bind () to [::]: 80 échoué (98) : Adresse déjà utilisée) 13 juillet 09:10:03 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] bind () à 0.0.0.0:80 a échoué (98: Adresse déjà utilisée) 13 juillet 09:10:03 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] bind () to [::]: 80 échoué (98) : Adresse déjà utilisée) 13 juillet 09:10:03 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] bind () à 0.0.0.0:80 a échoué (98: Adresse déjà utilisée) 13 juillet 09:10:03 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] bind () to [::]: 80 échoué (98) : Adresse déjà utilisée) 13 juillet 09:10:04 ip-10-0-10-10.ap-Nord-Est-1.compute.internal nginx [11360]: nginx: [émerg] ne pouvait toujours pas lier () 13 juillet 09:10:04 ip-10-0-10-10.ap-Nord-Est-1.compute.internal systemd [1]: nginx.service: processus de contrôle terminé, code = état de sortie = 1 13 juillet 09:10:04 ip-10-0-10-10.ap-Nord-Est-1.compute.internal systemd [1]: Impossible de démarrer le serveur HTTP et proxy inverse nginx. 13 juillet 09:10:04 ip-10-0-10-10.ap-Nord-Est-1.compute.internal systemd [1]: L'unité nginx.service est passée en état d'échec. 13 juillet 09:10:04 ip-10-0-10-10.ap-Nord-Est-1.compute.internal systemd [1]: nginx.service a échoué.

D'après ce qui précède, il semble que le port défini 80 soit déjà en cours d'exécution. En considérant la cause, je me suis souvenu que j'avais précédemment installé Apache et l'avais configuré pour démarrer automatiquement dans un cours Web. $ sudo systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Actif: actif (en cours d'exécution) depuis le jour 2020-07-12 06:24:44 UTC; il y a 2 jours 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 Effectivement, Apache fonctionnait déjà. Après avoir désactivé et arrêté le démarrage automatique, j'ai exécuté la commande de démarrage de NginX et cela a démarré avec succès.

J'ai terminé les paramètres finaux, mais ce qui suit est affiché sur la page Web.

「We're sorry, but something went wrong. If you are the application owner check the logs for more information.」

Pour le moment, regardez les journaux d'erreurs de Unicorn et Nginx. (Article de référence Chaque paramètre a une description du chemin d'accès à l'erreur) $ 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 La licorne ne semble pas être un problème.

$ 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"

Il semble y avoir un problème avec Nginx. Comme vous pouvez le voir dans l'article suivant, il semble que vous deviez changer la façon dont le chemin est écrit à partir de CentOS 7. https://qiita.com/emahiro/items/b2762a26bca35bbb0cf9

J'ai changé les fichiers Unicorn et Nginx en me référant à l'article suivant. https://qiita.com/noraworld/items/c8acf4bb981c8d8535df Vérifiez également le fonctionnement de la Licorne avec la commande suivante et arrêtez-vous avec la commande kill $ ps aux | grep unicorn $ kill -9 pid ← Remplacez le nombre affiché par la commande ci-dessus par la partie pid J'ai redémarré avec la commande suivante $ unicorn_rails -c / var / www / rails / (nom de l'application) /config/unicorn.conf.rb -D -E production Après avoir fait tout ce qui précède, le rechargement de la page Web l'affiche en toute sécurité! !! !!

Les cours suivants ont été achetés à Udemy avant que la construction de l'infrastructure ne fonctionne et j'ai pu comprendre à un bon rythme. https://www.udemy.com/course/aws-and-infra/