kaynak değişikliğinde gunicorn otomatik yeniden yükleme


113

Sonunda geliştirme ortamımı runserver'dan gunicorn / nginx'e taşıdım.

Çalıştırma sunucusunun otomatik yeniden yükleme özelliğini gunicorn'a kopyalamak uygun olacaktır, böylece kaynak değiştiğinde sunucu otomatik olarak yeniden başlar. Aksi takdirde sunucuyu ile manuel olarak yeniden başlatmam gerekiyor kill -HUP.

Manuel yeniden başlatmayı önlemenin herhangi bir yolu var mı?


Errata: benim env silahımdaki mısır, süpervizör tarafından yönetiliyor / izleniyor, bu yüzden gerçekten kill -HUPPID işlemi yapmam , bunun yerine supervisorctl kullanıyorum. Yine de bunun çok değiştiğini düşünmeyin.
Paolo

Yanıtlar:


232

Bu eski bir soru olsa da, sadece tutarlılık için - gunicorn sürüm 19.0'dan beri --reloadseçenek var. Bu nedenle hiçbir üçüncü taraf araca daha fazlasına gerek kalmadı.


5
kabul. Diğer cevaplar işe yarayabilir, ancak bu en basit olanıdır ve geçici bir çözüm değildir. OP'nin istediği tam olarak buydu.
J-bob

1
Gunicorn'a yerleşik bir - yeniden doldurma seçeneği olduğuna inanmıyorum. Bunu nereden buldun? Dokümanları, yapılandırmayı yeniden yüklemeyi killall -HUP procname, yeni çalışanların başlaması için bir HUP ( iyi çalışacak) göndermenizi ve eski çalışanların nazikçe kapatılmasını söylüyor.
sofly

3
Teşekkürler @Guandalino, kaçırmış olmalıyım. Bununla birlikte, "Bu ayar geliştirme amaçlıdır" demeleri ilginçtir. Bu, bazı durumlarda açıkça üretim için işe yarayacaktır, ancak diğerleri için de sorunlu olabilir. Evet, aşağıda üretim / dağıtım konusunda görünüşte ilgisiz olduğunuzu görüyorum.
sofly

Üretim sunucuları için kolay bir şekilde nasıl yapılır?
juan Isaza

@juanIsaza üretimde asla böyle bir işlevselliği kullanmamalısınız. İhtiyacınız olduğunu düşünüyorsanız - geliştirme veya dağıtım için yaklaşımınızı yeniden düşünmeniz gerekir.
Dmitry Ziolkovskiy

20

Bir seçenek, --max-isteklerini kullanarak ortaya çıkan her süreci --max-requests 1, başlangıç ​​seçeneklerine ekleyerek yalnızca bir istek sunacak şekilde sınırlamaktır . Yeni ortaya çıkan her süreç kod değişikliklerinizi görmeli ve bir geliştirme ortamında istek başına fazladan başlatma süresi ihmal edilebilir olmalıdır.


1
Dev env için güzel, zarif numara. Üretimde kullanılamaz ... ancak "sürekli dağıtım" yapmadığınız sürece yine de prod üzerinde otomatik yeniden yükleme istemeyebilirsiniz. Bunu yaparsanız, Bryan Helmig'in yaklaşımı, pipyetenekli paketi gerektirmesine rağmen daha iyidir watchdog.
Ocak

2
Yeni bir çalışanı başlatmak ~ 3 saniye sürecek, bu benim için çok yavaş. (2009 ortası MBP)
Blaise

11

Bryan Helmig bunu buldu ve doğrudan run_gunicornbaşlatmak yerine kullanmak üzere değiştirdim gunicorn, bu 3 komutu kesip django proje kök klasörünüzdeki bir kabuğa yapıştırmayı mümkün kılmak için (virtualenv etkinken):

pip install watchdog -U
watchmedo shell-command --patterns="*.py;*.html;*.css;*.js" --recursive --command='echo "${watch_src_path}" && kill -HUP `cat gunicorn.pid`' . &
python manage.py run_gunicorn 127.0.0.1:80 --pid=gunicorn.pid

Django 1.5.4, gunicorn 18.0, watchdog 0.6, bash 4.2 ile fedora 15'te kendim için kullandım.
ocak

127.0.0.1:80Gerekirse IP veya FQDN'nizi ve bağlantı noktasını yerine koymayı unutmayın .
ocaklar

1
@Guandalino, şansın var mı? Birkaç haftadır benim için iyi çalışıyor. El ile yeniden başlatmam gereken tek zaman settings.py, kalıplarımda models.pyolmayan bazı harici uygulamaların kaynak kodunu değiştirdiğimde (taşıma gerekli) veya kaynak kodunu değiştirdiğim zamandır watchmedo.
ocak

Hatırlatma için teşekkürler. Ama oyumu başkalarının başarısına vermek istemiyorum. Neden bu (gereksiz) acele ediyor? Bazı StackOverflow kuralını mı ihlal ediyorum? Öyleyse lütfen nasıl düzeltebileceğimi bana bildirin.
Paolo

1
Telaşa gerek yok. Kesinlikle bir SO kuralını ihlal etmiyor, yararlı yanıtları değerlendirmeye çaba / öncelik vermek sadece düşünceli / istekli / düşünceli. Görünüşe göre Dave ve ben size yardım etmek için tatlı zamanımızı harcadık (aylarca), bu yüzden çözümlerimizi doğrulamanızı sağlamak için aciliyet duygum orantısız - yöntemimde gizli kusurlar olup olmadığını bilmek için fazlasıyla hevesliyim. Sunucumu yapılandırdım ve Dave'in yaklaşımına geçmem gerekirse . Mutlu tatiller!
Ocak

5

Üretime dağıtmak için git push kullanıyorum ve bir komut dosyası çalıştırmak için git kancaları ayarlıyorum. Bu yaklaşımın avantajı, geçiş ve paket kurulumunuzu aynı anda yapabilmenizdir. https://mikeeverhart.net/2013/01/using-git-to-deploy-code/

mkdir -p /home/git/project_name.git
cd /home/git/project_name.git
git init --bare

Ardından bir komut dosyası oluşturun /home/git/project_name.git/hooks/post-receive.

#!/bin/bash
GIT_WORK_TREE=/path/to/project git checkout -f
source /path/to/virtualenv/activate
pip install -r /path/to/project/requirements.txt
python /path/to/project/manage.py migrate
sudo supervisorctl restart project_name

Emin olun chmod u+x post-receiveve sudoers'a kullanıcı ekleyin. sudo supervisorctlParola olmadan çalışmasına izin verin . https://www.cyberciti.biz/faq/linux-unix-running-sudo-command-without-a-password/

Yerel / geliştirme sunucumdan, git remoteüretim sunucusuna göndermeme izin verecek şekilde ayarladım

git remote add production ssh://user_name@production-server/home/git/project_name.git

# initial push
git push production +master:refs/heads/master

# subsequent push
git push production master

Bonus olarak, komut dosyası çalışırken tüm istemleri göreceksiniz. Böylece, geçiş / paket kurulumu / gözetmen yeniden başlatmasıyla ilgili herhangi bir sorun olup olmadığını göreceksiniz.


Git örneğinde #!/bin/basholduğu gibi yukarıda belirtildiği gibi shebang kullanmayı unutmayın ! #!/bin/shpost-receive
curtisp
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.