Capistrano bereitstellen rails-Anwendung - zu behandeln, wie lange Migrationen?

So, ich bin mit Capistrano für die Bereitstellung einer rails-Anwendung auf meinem produktiven server (apache+passenger) und im moment der Bereitstellung geht in der Regel entlang der Linien:

$cap deploy
$cap deploy:migrations

Er hat mich gefragt, sagen wir mal meine db:Migration dauerte eine lange Zeit zum ausführen auf den Produktions-server (eine große Umgestaltung des db-Schemas) - in diesem Fall, was ist die beste Praxis mit Capistrano? Was passiert, wenn Benutzer verbunden sind, um meine Bewerbung zum Zeitpunkt der Bereitstellung? Sollte ich anmutig senden Benutzer eine statische Platzhalter-Seite, während die Datenbank aktualisiert wird? Nicht Capistrano behandeln dies automatisch? Muss ich code ein Rezept zu helfen, mit dieser? Oder hat die internen Mechanismen von rails /passenger bedeuten, dass ich nicht haben, um sorgen über diesen speziellen Fall?

Dank.

InformationsquelleAutor Clinton | 2010-02-11
  1. 36

    Sollten Sie eine Wartung der Seite, wenn die Anwendung wird nicht verfügbar sein für eine Weile. Ich benutze diese Capistrano-task:

    namespace :deploy do
  namespace :web do
    desc <<-DESC
      Present a maintenance page to visitors. Disables your application's web \
      interface by writing a "maintenance.html" file to each web server. The \
      servers must be configured to detect the presence of this file, and if \
      it is present, always display it instead of performing the request.

      By default, the maintenance page will just say the site is down for \
      "maintenance", and will be back "shortly", but you can customize the \
      page by specifying the REASON and UNTIL environment variables:

        $ cap deploy:web:disable \\
              REASON="a hardware upgrade" \\
              UNTIL="12pm Central Time"

      Further customization will require that you write your own task.
    DESC
    task :disable, :roles => :web do
      require 'erb'
      on_rollback { run "rm #{shared_path}/system/maintenance.html" }

      reason = ENV['REASON']
      deadline = ENV['UNTIL']      
      template = File.read('app/views/admin/maintenance.html.erb')
      page = ERB.new(template).result(binding)

      put page, "#{shared_path}/system/maintenance.html", :mode => 0644
    end
  end
end

    Den app/views/admin/maintenance.html.erb Datei sollte enthalten:

    <p>We’re currently offline for <%= reason ? reason : 'maintenance' %> as of <%= Time.now.utc.strftime('%H:%M %Z') %>.</p>
<p>Sorry for the inconvenience. We’ll be back <%= deadline ? "by #{deadline}" : 'shortly' %>.</p>

    Der Letzte Schritt ist die Konfiguration des Apache virtual host mit einigen Richtlinien zu suchen, die maintenance.html - Datei und leiten alle Anfragen an, falls es vorhanden ist:

    <IfModule mod_rewrite.c>
  RewriteEngine On

  # Redirect all requests to the maintenance page if present
  RewriteCond %{REQUEST_URI} !\.(css|gif|jpg|png)$
  RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
  RewriteCond %{SCRIPT_FILENAME} !maintenance.html
  RewriteRule ^.*$ /system/maintenance.html [L]
</IfModule>

    Um die Anwendung in den Wartungsmodus ausführen cap deploy:web:disable zu machen, und wieder Leben tun cap deploy:web:enable.

    • Wird die Wartung Seite werden serviert mit "200 OK" oder "503 Service temporarily Unavailable"? Google könnte denken, Ihr kostbarer Inhalt könnte verschwunden sein, wenn Sie dazu dienen, mit 200 OK. Siehe googlewebmastercentral.blogspot.com/2011/01/...
    • Guter Punkt, Capistrano selbst legen die folgenden snippet für die .htaccess: gist.github.com/1292705
    • Sie vergaß die enable Aufgabe!
    • Levitt Der enable Aufgabe wurde in Capistrano selbst, so gibt es keine Notwendigkeit, geben Sie es explizit überschreiben, es sei denn, es.
    InformationsquelleAutor John Topley
  2. 5

    Meine Produktion setzt in der Regel Folgen Sie diesem Verfahren:

    1. cap production deploy:web:disable der leitet alle Anfragen auf eine statische Seite " Wartung
    2. cap production deploy
    3. Migrationen etc, testen Sie jeden Server individuell zu machen, ob auch alles OK
    4. cap production deploy:web:enable um die Website so funktionieren, wie es sollte

    John Topley Antwort gibt Ihnen einige gute in der Tiefe Informationen hier.

    InformationsquelleAutor dylanfm
Schreibe einen Kommentar