Nous décrirons la procédure de publication d'une application à l'aide d'AWS. Cet article utilise Capistrano pour automatiser le processus de déploiement.
Capistrano est écrit en Ruby et Gem est ouvert au public. Cet article décrit les étapes pour installer Capistrano dans les rails, mais il semble qu'il puisse être utilisé dans d'autres frameworks tels que PHP.
Modifiez le Gemfile comme suit.
Gemfile
group :development, :test do
gem 'capistrano'
gem 'capistrano-rbenv'
gem 'capistrano-bundler'
gem 'capistrano-rails'
gem 'capistrano3-unicorn'
end
Exécutez la commande suivante dans le terminal pour lire le Gemfile.
bundle install
Exécutez la commande suivante pour générer le fichier associé de Capistrano.
bundle exec cap install
Les fichiers suivants sont générés. Les détails de chaque fichier seront décrits plus loin.
Certaines bibliothèques (Gems) doivent être chargées pour que Capistrano fonctionne. Capfile est un fichier pour spécifier laquelle des bibliothèques liées à Capistrano charger.
Modifiez le fichier Capfile comme suit. Cela lira le répertoire contenant les fichiers qui décrivent les actions requises pour le déploiement. Référence
Capfile
require "capistrano/setup"
require "capistrano/deploy"
require 'capistrano/rbenv'
require 'capistrano/bundler'
require 'capistrano/rails/assets'
require 'capistrano/rails/migrations'
require 'capistrano3/unicorn'
Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }
Production.rb et staging.rb sont créés dans le répertoire config / deploy. Ces fichiers sont des fichiers qui décrivent les paramètres de déploiement. production.rb est le fichier de configuration de l'environnement de production et staging.rb est le fichier de configuration de l'environnement intermédiaire. Décrivez le contenu suivant dans production.rb (staging.rb).
--Nom d'hôte du serveur --Nom d'utilisateur de connexion au serveur AWS --Rôle serveur
Modifiez production.rb comme suit. (Lorsque l'adresse IP élastique de l'application est 12.345.67.890)
config/deploy/production.rb
server '12.345.67.890', user: 'ec2-user', roles: %w{app db web}
Dans deploy.rb créé dans le répertoire config, décrivez les paramètres communs à l'environnement de production et à l'environnement intermédiaire. Plus précisément, ce qui suit est décrit.
--Nom de l'application --git repository --SCM (Software Configuration Management) à utiliser --Tâche --Commandes à exécuter dans chaque tâche
Supprimez la description de deploy.rb et modifiez-la comme suit. (Ici, à titre d'exemple, la version Capistrano est "3.11.0", le nom de l'application est "testapp", le nom d'utilisateur Github est "test1234", le nom du dépôt est "testapp", la version ruby est "2.5.1", PC local Le chemin d'accès à la clé SSH (pem) de l'instance EC2 de est "~ / .ssh / xxx.pem".)
config/deploy.rb
# config valid only for current version of Capistrano
#Décrit la version de capistrano. Continuer à utiliser la version fixe et éviter les problèmes dus aux changements de version
lock '3.11.0'
#Utilisé pour afficher les journaux Capistrano
set :application, 'testapp'
#Spécifiez à partir de quel référentiel extraire l'application
set :repo_url, '[email protected]:test1234/testapp.git'
#Spécifiez un répertoire qui est couramment référencé même si la version change
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', 'public/system', 'public/uploads')
set :rbenv_type, :user
set :rbenv_ruby, '2.5.1'
#Quelle clé publique utiliser pour le déploiement
set :ssh_options, auth_methods: ['publickey'],
keys: ['~/.ssh/xxx.pem']
#Emplacement du fichier contenant le numéro de processus
set :unicorn_pid, -> { "#{shared_path}/tmp/pids/unicorn.pid" }
#Emplacement du fichier de configuration Unicorn
set :unicorn_config_path, -> { "#{current_path}/config/unicorn.rb" }
set :keep_releases, 5
#Description du redémarrage de Unicorn une fois le processus de déploiement terminé
after 'deploy:publishing', 'deploy:restart'
namespace :deploy do
task :restart do
invoke 'unicorn:restart'
end
end
Il est décrit dans un fichier appelé gemfile.lock.
DSL est un programme qui est préparé de manière pseudo pour améliorer l'efficacité d'un traitement spécifique. Par exemple, il existe une description de set: name, 'value'. À ce stade, «valeur» peut être récupérée en définissant le nom de récupération. La valeur définie peut également être récupérée à partir de deploy.rb et production.rb. Il existe également une description de la tâche: xx do ~ end. Cela ajoute une tâche en plus de celle requise par Capfile. Ce qui est décrit ici est exécuté au moment du déploiement du plafond.
Lorsque le déploiement automatique par Capistrano est exécuté, la structure des répertoires de l'environnement de production change. Plusieurs répertoires sont créés, comme la sauvegarde des applications avec Capistrano. Par exemple, le répertoire suivant est créé.
--releases répertoire
Avec l'introduction de Capistrano, la structure des répertoires de l'environnement de production changera, donc la description de unicorn.rb changera en conséquence.
Modifiez unicorn.rb comme suit.
config/unicorn.rb
#Placez le répertoire où le code de l'application sur le serveur est installé dans une variable
#Changement: approfondissez la hiérarchie
app_path = File.expand_path('../../../', __FILE__)
#Déterminer les performances du serveur d'applications
worker_processes 1
#Spécifiez le répertoire dans lequel l'application est installée
#Changement: spécifiez le courant
working_directory "#{app_path}/current"
#Spécifiez l'emplacement des fichiers requis pour démarrer Unicorn
#Changé: répertoire partagé ajouté
pid "#{app_path}/shared/tmp/pids/unicorn.pid"
#Spécifiez le numéro de port
#Changé: répertoire partagé ajouté
listen "#{app_path}/shared/tmp/sockets/unicorn.sock"
#Spécifiez un fichier pour consigner les erreurs
#Changé: répertoire partagé ajouté
stderr_path "#{app_path}/shared/log/unicorn.stderr.log"
#Spécifiez un fichier pour enregistrer les journaux normaux
#Changé: répertoire partagé ajouté
stdout_path "#{app_path}/shared/log/unicorn.stdout.log"
#Définir le temps maximum d'attente pour la réponse de l'application Rails
timeout 60
preload_app true
GC.respond_to?(:copy_on_write_friendly=) && GC.copy_on_write_friendly = true
check_client_connection false
run_once = true
before_fork do |server, worker|
defined?(ActiveRecord::Base) &&
ActiveRecord::Base.connection.disconnect!
if run_once
run_once = false # prevent from firing again
end
old_pid = "#{server.config[:pid]}.oldbin"
if File.exist?(old_pid) && server.pid != old_pid
begin
sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
Process.kill(sig, File.read(old_pid).to_i)
rescue Errno::ENOENT, Errno::ESRCH => e
logger.error e
end
end
end
after_fork do |_server, _worker|
defined?(ActiveRecord::Base) && ActiveRecord::Base.establish_connection
end
La structure des répertoires ayant changé, modifiez rails.conf comme suit. (Le cas où le nom de l'application est "testapp" et l'adresse IP Elastic est "12.345.67.890" est décrit à titre d'exemple)
rails.conf
upstream app_server {
#Changé pour faire référence à dans partagé
server unix:/var/www/testapp/shared/tmp/sockets/unicorn.sock;
}
server {
listen 80;
server_name 12.345.67.890;
#Définissez la taille maximale des fichiers téléchargés depuis le client sur 2 giga. La valeur par défaut est de 1 méga, alors gardez-la grande
client_max_body_size 2g;
#Changé pour faire référence à dans le courant
root /var/www/testapp/current/public;
location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
#Changé pour faire référence à dans le courant
root /var/www/testapp/current/public;
}
try_files $uri/index.html $uri @unicorn;
location @unicorn {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
error_page 500 502 503 504 /500.html;
}
Après avoir modifié les paramètres Nginx, SSH dans l'instance EC2 et Exécutez la commande suivante pour recharger et redémarrer.
sudo service nginx reload
sudo service nginx restart
Puisqu'il ne peut être déployé que si MySQL est en cours d'exécution, Exécutez la commande suivante et redémarrez MySQL au cas où.
sudo service mysqld restart
Tuez le processus maître licorne avant d'effectuer le déploiement automatique. Tout d'abord, exécutez la commande suivante pour vérifier l'ID de processus du maître licorne.
ps aux | grep unicorn
Tuez le processus confirmé par la commande suivante. (Cette fois, l'ID de processus du maître licorne est 17877)
kill 17877
Poussez tous les fichiers édités cette fois vers la branche master.
Exécutez la commande suivante dans l'environnement local pour effectuer le déploiement automatique. Succès s'il n'y a pas d'erreurs.
bundle exec cap production deploy
--Run à nouveau
Vous pouvez accéder à l'application en saisissant l'adresse IP Elastic dans le champ URL de votre navigateur (pas besoin d'ajouter: 3000).
Procédure pour publier une application à l'aide d'AWS (1) Créer un compte AWS Procédure pour publier une application à l'aide d'AWS (2) Create EC2 instance [Comment publier une application à l'aide de la construction d'environnement d'instance AWS (3) EC2] (https://qiita.com/osawa4017/items/8dc09203f84e04bf0e66) [Procédure pour publier une application à l'aide de AWS (4) Create database] (https://qiita.com/osawa4017/items/7dba25f4fa30ab0b1246) [Procédure de publication d'une application à l'aide d'AWS (5) Publish application] (https://qiita.com/osawa4017/items/6f3125fcc21f73024311) [Procédure pour publier une application à l'aide d'AWS (6) Install Nginx] (https://qiita.com/osawa4017/items/9b707baf6ddde623068c)