Appliquez votre propre domaine à Rails of VPS et rendez-le SSL (https) (CentOS 8.2 / Nginx)

• Cet article est une réimpression du contenu publié sur mon blog. Je suis très redevable aux articles de Qiita au quotidien, alors postez une page qui est souvent consultée (c'est-à-dire qu'il semble y faire référence) dans mon article de blog à Qiita et redonnez même un peu. Je pense.

De plus, je travaille en continu à partir des articles suivants publiés la dernière fois. Cependant, comme il n'y a pas de lien direct avec l'article précédent, il est normal de n'effectuer que le travail de cet article de manière indépendante.

"Déployer sur ConoHa VPS (CentOS 8.2) avec Rails 6 + PostgreSQL + Nginx + Unicorn + Capistrano"

Ce qui suit est le début immédiat.

Il est basé sur l'environnement de CentOS (8.2) et Nginx. Au début du travail, on suppose que l'application Rails sera affichée lorsque vous entrez http: // adresse IP.

De plus, j'écris en partant du principe que vous avez déjà acquis votre propre domaine sur Name.com (même si le bureau d'enregistrement auprès duquel vous avez acquis n'a pas d'importance).

Maintenant, suivez les étapes ci-dessous.

1. 1. Appliquez votre propre domaine

1-1. Modifiez les paramètres DNS de votre nom dot com

Ajoutez les deux éléments suivants sur la page des paramètres d'enregistrement DNS de Name.com. Par exemple, le domaine est ʻexample.com`.

Après avoir implémenté ce qui précède, les paramètres d'enregistrement doivent être les suivants.

Dès que les paramètres sont reflétés, lorsque vous accédez à «exemple.com» et «www.exemple.com», cela change pour accéder au serveur.

Cependant, lorsque j'essaye d'accéder à «exemple.com» dans cet état, la page Nginx s'affiche. Vous devez également modifier les paramètres Nignx.

• Remarque: à propos des paramètres DNS

Ce que cela signifie

• L'adresse IP de ʻexample.com est xxx.xxx.xxx.xxx --www.example.com est un autre nom pour ʻexample.com

Donc, en d'autres termes, vous accéderez à xxx.xxx.xxx.xxx, quel que soit celui que vous entrez.

Ici, sans utiliser le paramètre CNAME (alias)

Le mouvement est exactement le même que ci-dessus, mais dans un souci de sens, il est préférable de définir en utilisant CNAME.

1-2. Modifier les paramètres de Nginx

Après vous être connecté au serveur et basculé vers l'utilisateur root, ouvrez le fichier de configuration ci-dessous.

vim /etc/nginx/conf.d/Nom de l'application.conf

Cela devrait ressembler à celui ci-dessous.

nginx:/etc/nginx/conf.d/Nom de l'application.conf

upstream unicorn_Nom de l'application{
  server unix:/var/www/Nom de l'application/current/tmp/sockets/unicorn.sock;
}
server {
  listen 80;
  server_nom Adresse IP du serveur;
  root /var/www/Nom de l'application/current/public;
  access_log /var/log/nginx/Nom de l'application_access.log;
  error_log /var/log/nginx/Nom de l'application_error.log;
  location / {
    try_files $uri @unicorn;
  }
  location @unicorn {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://unicorn_Nom de l'application;
  }
}

Changez l'adresse IP de nom_serveur ci-dessus en «exemple.com» comme indiqué ci-dessous.

nginx:/etc/nginx/conf.d/Nom de l'application.conf

server_name example.com;

Après la modification, testez s'il y a un problème avec le fichier de paramètres.

nginx -t

Si tout se passe bien, redémarrez Nginx.

systemctl restart nginx

Après cela, lorsque vous accédez à http: // example.com, la page de l'application sera affichée.

Ici, si vous accédez avec http: // adresse IP, l'application était affichée auparavant, mais maintenant la page Nginx est affichée. C'est le résultat de la réécriture du fichier de paramètres précédent et de l'élimination de la description de l'adresse IP.

Une fois de plus, modifiez le fichier de configuration Nginx pour obtenir le comportement suivant.

--Lorsque vous accédez à «exemple.com», la page «exemple.com» s'ouvre. --Lorsque vous accédez à «www.example.com» (avec la redirection 301), la page «exemple.com» s'ouvre. --Lorsque vous accédez à l '«adresse IP» (avec une redirection 301), la page «exemple.com» s'ouvre.

En d'autres termes, le mouvement pour tout déplacer vers «exemple.com» (sans www).

Ouvrez à nouveau le fichier

vim /etc/nginx/conf.d/Nom de l'application.conf

Mettez à jour la partie serveur du fichier de paramètres comme suit.

nginx:/etc/nginx/conf.d/Nom de l'application.conf

server {
  listen 80;
  server_name example.com;
  root /var/www/Nom de l'application/current/public;
  access_log /var/log/nginx/Nom de l'application_access.log;
  error_log /var/log/nginx/Nom de l'application_error.log;
  location / {
    try_files $uri @unicorn;
  }
  location @unicorn {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://unicorn_Nom de l'application;
  }
}
server {
  listen 80;
  server_name www.example.Adresse IP du serveur com;
  return 301 http://example.com$request_uri;
}

Ajoutez une autre description du serveur, ajoutez «www.example.com» et «l'adresse IP» du serveur à nom_serveur (insérez un espace demi-largeur entre eux), et 301 redirigez vers «exemple. Dirigé vers com`.

$request_uriというのはその時のページを指している変数で、例えば、www.example.com/blogsにアクセスしたら、example.com/blogsにリダイレクトしている。

Après avoir effectué la modification, n'oubliez pas de tester les paramètres et de redémarrer Nginx s'il n'y a pas de problème.

nginx -t

systemctl restart nginx

Ceci termine les paramètres pour activer l'accès par domaine.

2. Convertir en SSL (https)

2-1. Autoriser la connexion https (ouvrir le port 443)

Ouvrez le port 443 pour autoriser https.

Tout d'abord, vérifions l'état des paramètres de firewalld.

firewall-cmd --list-all

Vérifiez que les services: cockpit dhcpv6-client http ssh. http et ssh sont autorisés.

Procédez comme suit:

firewall-cmd --add-service=https --permanent

Rechargez firewalld pour refléter les paramètres.

firewall-cmd --reload

Exécutez à nouveau pour confirmer la modification.

firewall-cmd --list-all

services: cockpit dhcpv6-client http https ssh et https a été ajouté.

2-2. Installez Certbot

Certbot est un outil qui exécute automatiquement tout, du certificat SSL au paramétrage avec Let ’s Encrypt.

Installez Certbot et les plugins nécessaires pour utiliser Certbot avec Nginx.

dnf -y install certbot python3-certbot-nginx

Vérifiez s'il a été installé.

certbot --version

Si certbot 1.7.0 s'affiche, c'est OK.

2-3. Obtenez et définissez le certificat SSL

Utilisez Certbot pour obtenir et définir le certificat SSL.

certbot --nginx

Des questions sur les paramètres vous seront posées de manière interactive, alors répondez-y. Voici toutes les questions et exemples de réponses.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): [email protected] #Entrez votre adresse email

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: (A)gree/(C)ancel: A #Sélectionnez A (d'accord)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N #Sélectionnez N (Non)

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: example.com
2: www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1 # exmaple.Convertir jp en HTTPS
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/conf.d/Nom de l'application.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/conf.d/Nom de l'application.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2020-XX-XX. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Confirmez que le certificat a été obtenu et défini. Procédez comme suit:

certbot certificates

Si les informations de certificat du domaine example.com s'affichent, c'est OK.

Vous pouvez maintenant vous connecter via HTTPS. Assurez-vous que vous pouvez y accéder sur https: // example.com.

De plus, la date d'expiration du certificat est de 3 mois, donc s'il est laissé tel quel, il expirera après 3 mois. Ajoutez un travail Coulomb et faites renouveler automatiquement le certificat sur une base régulière afin qu'il puisse être utilisé pratiquement en permanence. Procédez comme suit:

echo "0 0,12 * * * root python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

Sortez le contenu du fichier pour confirmer que le Coulomb a été défini.

cat /etc/crontab

Confirmez qu'il y a "0 0,12 * * * root python3 -c'import random; import time; time.sleep (random.random () * 3600) '&& certbot renew -q" à la fin du résultat de sortie.

Redémarrez le démon Coulomb pour refléter les paramètres.

systemctl restart crond

Enfin, essayez un essai à vide (= test) pour confirmation.

certbot renew --dry-run

Si le résultat dit "Félicitations, tous les renouvellements ont réussi", c'est OK.

2-4. Modifier les paramètres de Nginx

Vérifiez maintenant le fichier de configuration Nginx.

vim /etc/nginx/conf.d/Nom de l'application.conf

Ensuite, vous pouvez confirmer que la partie serveur du contenu a changé automatiquement. C'est parce que Certbot l'a mis à jour. Voici un exemple après avoir été mis à jour.

nginx:/etc/nginx/conf.d/Nom de l'application.conf

server {
  server_name example.com;
  root /var/www/Nom de l'application/current/public;
  access_log /var/log/nginx/Nom de l'application_access.log;
  error_log /var/log/nginx/Nom de l'application_error.log;
  location / {
    try_files $uri @unicorn;
  }
  location @unicorn {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://unicorn_Nom de l'application;
  }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
  listen 80;
  server_name www.example.Adresse IP du serveur com;
  return 301 https://example.com$request_uri;
}

server {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


  listen 80;
  server_name example.com;
    return 404; # managed by Certbot


}

Cependant, si ce qui précède est laissé tel quel, il peut ne pas être possible de rediriger lors de l'accès avec https: // www.example.com ou https: // adresse IP, ou vous pouvez organiser proprement l'indentation et la position de description. Par conséquent, il a été réaménagé sous la forme suivante.

De plus, écrire «listen 443 ssl;» sur une ligne et «listen 443;» «ssl on;» sur deux lignes ont la même signification.

nginx:/etc/nginx/conf.d/Nom de l'application.conf

server {
  listen 443;
  ssl on;
  server_name example.com;
  root /var/www/Nom de l'application/current/public;
  access_log /var/log/nginx/Nom de l'application_access.log;
  error_log /var/log/nginx/Nom de l'application_error.log;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
  location / {
    try_files $uri @unicorn;
  }
  location @unicorn {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://unicorn_Nom de l'application;
  }
}
server {
  listen 443;
  server_name www.example.Adresse IP du serveur com;
  return 301 https://example.com$request_uri;
}
server {
  listen 80;
  server_name example.com www.example.Adresse IP du serveur com;
  return 301 https://example.com$request_uri;
}

Vous serez maintenant 301 redirigé vers https: // example.com dans tous les cas suivants:

• https://www.example.com --https: // adresse IP
• http://example.com
• http://www.example.com --http: // adresse IP

N'oubliez pas de tester et de redémarrer Nginx pour que les paramètres prennent effet.

nginx -t

systemctl restart nginx

3. 3. référence

Rails config / environnements / production.rb a les options suivantes:

config/environments/production.rb

# config.force_ssl = true

Par défaut, il doit être commenté comme ci-dessus.

Si vous décommentez et activez cette option, vous serez en mesure de rediriger vers https lorsque l'application est accessible via http. En d'autres termes, la même chose qui peut être définie dans Nginx peut être obtenue.

Cependant, je pense que ce traitement est à l'origine géré par le serveur Web (Nginx), donc si vous utilisez un serveur Web comme celui-ci, n'utilisez pas la fonction Rails ci-dessus et gérez-la côté serveur Web. Garde le.

c'est tout

C'est la fin.

Supplément

Merci d'avoir lu l'article.

Je vais mettre un lien vers l'article de blog original ci-dessous, mais comme le contenu est le même que cet article, vous n'avez pas besoin de vous y référer en particulier, mais plutôt, parce qu'il a la fonction de coloration syntaxique de Qiita, c'est un article sur Qiita Cela devrait être plus facile à comprendre si vous lisez.

knmts.com | Appliquez votre propre domaine à Rails of VPS et faites-le SSL (https) (CentOS 8.2 / Nginx)