Wir werden das Verfahren zum Veröffentlichen einer Anwendung mit AWS beschreiben. In diesem Artikel wird Capistrano verwendet, um den Bereitstellungsprozess zu automatisieren.
Capistrano ist in Ruby geschrieben und Gem ist für die Öffentlichkeit zugänglich. Dieser Artikel beschreibt die Schritte zum Installieren von Capistrano in Schienen, aber es scheint, dass es in anderen Frameworks wie PHP verwendet werden kann.
Bearbeiten Sie die Gemfile wie folgt.
Gemfile
group :development, :test do
gem 'capistrano'
gem 'capistrano-rbenv'
gem 'capistrano-bundler'
gem 'capistrano-rails'
gem 'capistrano3-unicorn'
end
Führen Sie den folgenden Befehl im Terminal aus, um die Gem-Datei zu lesen.
bundle install
Führen Sie den folgenden Befehl aus, um die zugehörige Datei von Capistrano zu generieren.
bundle exec cap install
Die folgenden Dateien werden generiert. Details zu jeder Datei werden später beschrieben.
Einige Bibliotheken (Gems) müssen geladen werden, damit Capistrano funktioniert. Capfile ist eine Datei, in der angegeben wird, welche der Capistrano-bezogenen Bibliotheken geladen werden sollen.
Bearbeiten Sie die Capfile wie folgt. Dadurch wird das Verzeichnis gelesen, das die Dateien enthält, in denen die für die Bereitstellung erforderlichen Aktionen beschrieben sind. Referenz
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 und staging.rb werden im Verzeichnis config / deploy erstellt. Diese Dateien sind Dateien, die die Einstellungen für die Bereitstellung beschreiben. product.rb ist die Konfigurationsdatei für die Produktionsumgebung und staging.rb ist die Konfigurationsdatei für die Staging-Umgebung. Beschreiben Sie die folgenden Inhalte in Production.rb (Staging.rb).
Ändern Sie product.rb wie folgt. (Wenn die elastische IP der Anwendung 12.345.67.890 ist)
config/deploy/production.rb
server '12.345.67.890', user: 'ec2-user', roles: %w{app db web}
Beschreiben Sie in deploy.rb, das im Konfigurationsverzeichnis erstellt wurde, die Einstellungen, die für die Produktionsumgebung und die Staging-Umgebung gelten. Insbesondere wird das Folgende beschrieben.
--Anwendungsname --git Repository --SCM (Software Configuration Management) verwendet werden --Aufgabe
Löschen Sie die Beschreibung von deploy.rb und ändern Sie sie wie folgt. (Hier ist beispielsweise die Capistrano-Version "3.11.0", der Anwendungsname "testapp", der Github-Benutzername "test1234", der Repository-Name "testapp", die Ruby-Version "2.5.1" und der lokale PC Der Pfad zum SSH-Schlüssel (pem) der EC2-Instanz von lautet "~ / .ssh / xxx.pem".)
config/deploy.rb
# config valid only for current version of Capistrano
#Beschrieb die Version von Capistrano. Verwenden Sie weiterhin die feste Version und vermeiden Sie Probleme aufgrund von Versionsänderungen
lock '3.11.0'
#Wird zum Anzeigen von Capistrano-Protokollen verwendet
set :application, 'testapp'
#Geben Sie an, aus welchem Repository die App abgerufen werden soll
set :repo_url, '[email protected]:test1234/testapp.git'
#Geben Sie ein Verzeichnis an, auf das häufig verwiesen wird, auch wenn sich die Version ändert
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'
#Welcher öffentliche Schlüssel für die Bereitstellung verwendet werden soll
set :ssh_options, auth_methods: ['publickey'],
keys: ['~/.ssh/xxx.pem']
#Speicherort der Datei mit der Prozessnummer
set :unicorn_pid, -> { "#{shared_path}/tmp/pids/unicorn.pid" }
#Speicherort der Unicorn-Konfigurationsdatei
set :unicorn_config_path, -> { "#{current_path}/config/unicorn.rb" }
set :keep_releases, 5
#Beschreibung für den Neustart von Unicorn nach Abschluss des Bereitstellungsprozesses
after 'deploy:publishing', 'deploy:restart'
namespace :deploy do
task :restart do
invoke 'unicorn:restart'
end
end
Es wird in einer Datei namens gemfile.lock beschrieben.
DSL ist ein Programm, das pseudo erstellt wird, um die Effizienz der spezifischen Verarbeitung zu verbessern. Zum Beispiel gibt es eine Beschreibung von set: name, 'value'. Zu diesem Zeitpunkt kann 'Wert' durch Festlegen des Abrufnamens abgerufen werden. Der eingestellte Wert kann auch aus deploy.rb und Production.rb abgerufen werden. Außerdem gibt es eine Beschreibung der Aufgabe: xx do ~ end. Dies fügt zusätzlich zu der für Capfile erforderlichen Aufgabe eine Aufgabe hinzu. Was hier beschrieben wird, wird zum Zeitpunkt der Bereitstellung der Kappe ausgeführt.
Wenn die automatische Bereitstellung durch Capistrano ausgeführt wird, ändert sich die Verzeichnisstruktur der Produktionsumgebung. Es werden mehrere Verzeichnisse erstellt, z. B. das Sichern von Anwendungen mit Capistrano. Beispielsweise wird das folgende Verzeichnis erstellt.
Mit der Einführung von Capistrano ändert sich die Verzeichnisstruktur der Produktionsumgebung, sodass sich die Beschreibung von unicorn.rb entsprechend ändert.
Ändern Sie unicorn.rb wie folgt.
config/unicorn.rb
#Legen Sie das Verzeichnis, in dem der Anwendungscode auf dem Server installiert ist, in einer Variablen ab
#Ändern: Machen Sie die Hierarchie tiefer
app_path = File.expand_path('../../../', __FILE__)
#Bestimmen Sie die Leistung des Anwendungsservers
worker_processes 1
#Geben Sie das Verzeichnis an, in dem die Anwendung installiert ist
#Ändern: Strom angeben
working_directory "#{app_path}/current"
#Geben Sie den Speicherort der Dateien an, die zum Starten von Unicorn erforderlich sind
#Geändert: Freigegebenes Verzeichnis hinzugefügt
pid "#{app_path}/shared/tmp/pids/unicorn.pid"
#Geben Sie die Portnummer an
#Geändert: Freigegebenes Verzeichnis hinzugefügt
listen "#{app_path}/shared/tmp/sockets/unicorn.sock"
#Geben Sie eine Datei an, um Fehler zu protokollieren
#Geändert: Freigegebenes Verzeichnis hinzugefügt
stderr_path "#{app_path}/shared/log/unicorn.stderr.log"
#Geben Sie eine Datei an, um normale Protokolle aufzuzeichnen
#Geändert: Freigegebenes Verzeichnis hinzugefügt
stdout_path "#{app_path}/shared/log/unicorn.stdout.log"
#Legen Sie die maximale Wartezeit für die Antwort der Rails-Anwendung fest
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
Da sich die Verzeichnisstruktur geändert hat, ändern Sie die Datei rails.conf wie folgt. (Der Fall, in dem der Anwendungsname "testapp" und die elastische IP "12.345.67.890" lautet, wird als Beispiel beschrieben.)
rails.conf
upstream app_server {
#Geändert, um auf in geteilt zu verweisen
server unix:/var/www/testapp/shared/tmp/sockets/unicorn.sock;
}
server {
listen 80;
server_name 12.345.67.890;
#Stellen Sie die maximale Größe der vom Client hochgeladenen Dateien auf 2 Giga ein. Der Standardwert ist 1 Mega, halten Sie ihn also groß
client_max_body_size 2g;
#Geändert, um auf aktuell zu verweisen
root /var/www/testapp/current/public;
location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
#Geändert, um auf aktuell zu verweisen
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;
}
Nach dem Ändern der Nginx-Einstellungen SSH in die EC2-Instanz und Führen Sie den folgenden Befehl aus, um neu zu laden und neu zu starten.
sudo service nginx reload
sudo service nginx restart
Da es nur bereitgestellt werden kann, wenn MySQL ausgeführt wird, Führen Sie den folgenden Befehl aus und starten Sie MySQL für alle Fälle neu.
sudo service mysqld restart
Beenden Sie den Einhorn-Master-Prozess, bevor Sie die automatische Bereitstellung durchführen. Führen Sie zunächst den folgenden Befehl aus, um die Prozess-ID des Einhorn-Masters zu überprüfen.
ps aux | grep unicorn
Beenden Sie den durch den folgenden Befehl bestätigten Vorgang. (Diesmal lautet die Prozess-ID des Einhornmeisters 17877)
kill 17877
Verschieben Sie alle diesmal bearbeiteten Dateien in den Hauptzweig.
Führen Sie den folgenden Befehl in der lokalen Umgebung aus, um eine automatische Bereitstellung durchzuführen. Erfolg, wenn keine Fehler vorliegen.
bundle exec cap production deploy
--Führe es nochmals aus
Sie können auf die Anwendung zugreifen, indem Sie die elastische IP in das URL-Feld Ihres Browsers eingeben (nicht erforderlich: 3000).
Verfahren zum Veröffentlichen einer Anwendung mit AWS (1) AWS-Konto erstellen Verfahren zum Veröffentlichen einer Anwendung mit AWS (2) EC2-Instanz erstellen [So veröffentlichen Sie eine Anwendung mithilfe der AWS (3) EC2-Instanzumgebungskonstruktion] (https://qiita.com/osawa4017/items/8dc09203f84e04bf0e66) [Verfahren zum Veröffentlichen einer Anwendung mit AWS (4) Erstellen einer Datenbank] (https://qiita.com/osawa4017/items/7dba25f4fa30ab0b1246) [Verfahren zum Veröffentlichen eines Antrags mit AWS (5) Antrag veröffentlichen] (https://qiita.com/osawa4017/items/6f3125fcc21f73024311) [Verfahren zum Veröffentlichen der Anwendung mit AWS (6) Install Nginx] (https://qiita.com/osawa4017/items/9b707baf6ddde623068c)
Recommended Posts