2013-02-21 10 views
6

Mamy problemy z rozmieszczeniem na gorąco jednorożca. W zasadzie używamy konfiguracji kanonicznych unicorn.rb, ustawiając working_directory tak, aby wskazywała na folder dowiązania symbolicznego, ale jakoś utknęła w rzeczywistym folderze, gdy był po raz pierwszy uruchomiony i nie podążała za dowiązaniem symbolicznym.jednorożec katalog_pracy z symbolem rzeczywistym

# config/unicorn.rb 
if ENV['RAILS_ENV'] == 'production' 
    worker_processes 4 
else 
    worker_processes 2 
end 

working_directory "/var/local/project/symlinkfolder" 

# Listen on unix socket 
listen "/tmp/unicorn.sock", :backlog => 64 

pid "/var/run/unicorn/unicorn.pid" 

stderr_path "/var/log/unicorn/unicorn.log" 
stdout_path "/var/log/unicorn/unicorn.log" 

preload_app true 

before_fork do |server, worker| 
    # the following is highly recomended for Rails + "preload_app true" 
    # as there's no need for the master process to hold a connection 
    if defined?(ActiveRecord::Base) 
    ActiveRecord::Base.connection.disconnect! 
    end 

    # Before forking, kill the master process that belongs to the .oldbin PID. 
    # This enables 0 downtime deploys. 
    old_pid = "/var/run/unicorn/unicorn.pid.oldbin" 
    if File.exists?(old_pid) && server.pid != old_pid 
    begin 
     Process.kill("QUIT", File.read(old_pid).to_i) 
    rescue Errno::ENOENT, Errno::ESRCH 
     # someone else did our job for us 
    end 
    end 
end 

after_fork do |server, worker| 
    # the following is *required* for Rails + "preload_app true", 
    if defined?(ActiveRecord::Base) 
    ActiveRecord::Base.establish_connection 
    end 

    # this makes sure the logging-rails framework works when preload_app = true 
    Logging.reopen 
    # if preload_app is true, then you may also want to check and 
    # restart any other shared sockets/descriptors such as Memcached, 
    # and Redis. TokyoCabinet file handles are safe to reuse 
    # between any number of forked children (assuming your kernel 
    # correctly implements pread()/pwrite() system calls) 
end 

Kiedy wystawiamy USR2 widzimy to w dzienniku jednorożca:

executing ["/var/local/project/project.d/6/vendor/bundle/ruby/1.9.1/bin/unicorn_rails", "-E", "staging", "-D", "-c", "/var/local/project/symlinkfolder/config/unicorn.rb"│· 
, {12=>#<Kgio::UNIXServer:fd 12>}] (in /var/local/project/project.d/8) 

tak jednorożec jest jakoś „zatrzymany” w wersji 6, podczas gdy rzeczywista folderu dowiązane jest od wersji 8 .. . staje się to problemem, jak tylko przycinać folder dla wersji 6 po kilku wdraża ...

  • working_directory jest ustawiony do fol symlink'd der
  • punktów dowiązania symbolicznego do /var/local/project/project.d/[id] folderze poprawnie
  • aktualizować dowiązania przed wysyłając sygnał

Co tracimy USR2 ??

Odpowiedz

7

Rozwiązaniem było jawnie ustawić jednorożec ścieżkę binarne, jak wyjaśniono (w nieco mylący sposób) na http://unicorn.bogomips.org/Sandbox.html

app_root = "/var/local/project/symlinkfolder" 
working_directory app_root 
# see http://unicorn.bogomips.org/Sandbox.html 
Unicorn::HttpServer::START_CTX[0] = "#{app_root}/vendor/bundle/ruby/1.9.1/bin/unicorn_rails" 

Następnie musieliśmy wydać unicorn reload polecenia (kill -HUP), więc jednorożec przeładowuje plik konfiguracyjny . Od tego momentu wydawanie sygnału USR2 działa poprawnie.