Je crée actuellement une application Rails par développement personnel, mais le CSS de l'application Rails qui fonctionnait normalement a soudainement arrêté le chargement (et le fichier image), ce qui a fait perdre du temps. Je ne connais pas la cause exacte après tout, mais j'écrirai ici le processus jusqu'à ce qu'il soit résolu.
Environnement de développement
Ecrivez un test avec la spécification système de rspec, exécutez-le, répétez l'échec environ 10 fois et accédez à localhost (root_path) CSS n'était plus reflété. Détails de l'erreur de la console à ce moment-là ↓
Failed to load resource: the server responded with a status of 500 (Internal Server Error)
L'erreur elle-même était quelque chose que je vois souvent, et comme le titre l'indique, le fichier CSS n'a pas été chargé.
Pour être honnête, il est délicat que cette solution soit correcte, mais j'écrirai ici comment elle a été guérie. D'après la conclusion, il semble qu'il a été guéri en réécrivant le contenu de nignx.conf de manière appropriée, en reconstruisant le conteneur docker, en le redémarrant, en provoquant une erreur, en le reconstruisant à nouveau et en démarrant le conteneur. ** La reconstruction n'a normalement pas aidé. ** Cela a pris du temps à cause de ça, j'ai fait une erreur et ça a été guéri, mais ... Seuls ceux qui savent cela peuvent le comprendre en détail ci-dessous.
Dans mon environnement de développement, je lance le conteneur nginx en tant que serveur WEB afin de le rendre le plus proche possible de l'environnement de production. Le nginx.conf est le fichier de configuration ↓
#Spécification de la destination du proxy
#Envoyez la demande reçue par Nginx au backend puma
upstream webapp {
#Je veux communiquer avec des prises, donc puma.Spécifier la chaussette
server unix:///webapp/tmp/sockets/puma.sock;
}
server {
listen 80;
#Spécifiez le domaine ou l'adresse IP
server_name webapp ;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
#Spécifier la racine du document
root /webapp/public;
client_max_body_size 100m;
error_page 404 /404.html;
error_page 505 502 503 504 /500.html;
try_files $uri/index.html $uri @webapp;
keepalive_timeout 5;
#Paramètres liés au proxy inverse
location @webapp {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://webapp;
}
}
Réécrivez proxy_pass dans ce fichier de paramètres de manière appropriée et provoquez une erreur intentionnellement. (L'endroit peut être n'importe où)
$ docker-compose down
$ docker-compose up -d --build
L'option -d s'exécute en arrière-plan. Avec l'option --build, il fera tout de la construction au démarrage à la fois.
Puis
$ docker-compose ps
Name Command State Ports
----------------------------------------------------------------------------
webapp_app_1 bundle exec puma -C config ... Up
webapp_db_1 docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp
webapp_web_1 /bin/sh -c /usr/sbin/nginx ... Exit 1
Le conteneur webapp_web_1 doit se fermer avec une erreur. (Le nom du conteneur change en fonction des paramètres de docker-compose.yml, veuillez donc le remplacer vous-même.)
Ici, réécrivez-le correctement et restaurez le fichier nginx.conf qui a provoqué l'erreur intentionnellement. Puis exécutez à nouveau 2. Ensuite, cela s'est reflété pour une raison quelconque! heureux! !!
Honnêtement, quel genre de logique cette méthode a-t-elle guéri? Est-ce correct en premier lieu? Je ne sais pas. Si vous avez des questions, je vous serais reconnaissant de bien vouloir commenter.
Pour le moment, c'est un fait que si je faisais cela, ce serait guéri. Je sais toujours si le chargement CSS ne fonctionne pas pendant la précompilation dans un environnement de production, mais cette fois, c'était une erreur soudaine, il a donc fallu beaucoup de temps pour la corriger. Si vous rencontrez la même erreur, j'espère que cela vous aidera!