Обработка на различни статични файлове между среди при внедряване на актуализация към основни/резервни Django сървъри

Следя отговора на Ken Cochrane на въпроса Безпроблемно внедряване на Django на един сървър. По същество използвам два производствени сървъра, един primary и един fallback, и моят nginx е конфигуриран по следния начин (пропускайки ненужните подробности):

upstream app-primary {
    server localhost:12345;
    server localhost:12346 backup;
}
server {
    root /home/fraxtil/app/primary;
    location /static/ {
        alias /home/fraxtil/app/primary/static/;
    }
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://app-primary;
    }
}

Когато натискам актуализация, надстройвам fallback, след което изключвам primary, надстройвам го и го включвам отново. Решението е почти перфектно, но има един проблем: използвам django-compressor, за да събирам и компресирам моите CSS и JS файлове и не е гарантирано, че двата екземпляра имат еднакви статични имена на файлове. Така че докато primary не работи, сървърът fallback обработва заявките за приложения съвсем добре, но nginx търси статични файлове в /.../primary/static/ вместо в /.../fallback/static/.

Има ли начин да се реши този проблем без маршрутизиране на заявки за статични файлове през Django? Като алтернатива, има ли по-добър начин за безпроблемно внедряване на актуализации на Django? (Интересувам се да имам нулев престой, поради което моделът с два сървъра ме привлече.)


django nginx caching fallback
person ashastral    schedule 22.06.2013    source източник

Отговори (1)


arrow_upward
0
arrow_downward

Намерих начин да го накарам да работи с помощта на директивата try_files. Всъщност бях опитал това, преди да публикувам въпроса, но по някаква причина първият ми опит направи всяка заявка 404. Това обаче изглежда работи:

server {
    # Moved the root up one level
    root /home/fraxtil/app;
    location /static/ {
        # Try the primary instance's static folder, then the fallback's
        try_files /primary/$uri /fallback/$uri =404;
    }
...

Единственият недостатък тук е, че всички заявки за несъществуващи статични файлове ще ударят диска два пъти, но това не би трябвало да е голям проблем.

person ashastral    schedule 22.06.2013