Ustaw interfejs apache documentRoot na symboliczny (dla łatwego wdrożenia)

Question

Szukamy sposobu, aby skierować naszą Apache DocumentRoot do dowiązania symbolicznego. E.g. DocumentRoot/var/www/html/finalbuild

finalbuild należy wskazać folder gdzieś jak/home/user/build3

kiedy poruszamy się nowy build do/home/user/build4 chcemy wykorzystać powłokę skrypt, który zmienia dowiązanie symboliczne "finalebuild" w ten nowy katalog/home/user/build4 i wykonuje pełne wdzięku restartowanie apache, aby nowa wersja aplikacji internetowej działała bez większego ryzyka.

Jaki jest najlepszy sposób utworzenia tego dowiązania symbolicznego i zmiany tego łącza za pomocą skryptu powłoki?

Answer 1

Użyłem dowiązań symbolicznych jako Apache DocumentRoot w produkcji bez konieczności pełnego ponownego uruchamiania. Ogólnie rzecz biorąc, pomysł powinien zadziałać. Błąd 403 prawdopodobnie wskazuje błąd uprawnień niezwiązany ze zmianą dowiązania symbolicznego. Dodatkową zmarszczką, którą chcesz dodać, jest making the symlink switch atomic, więc dowiązanie symboliczne zawsze istnieje. To znaczy, w żadnym momencie dowiązanie symboliczne nie istnieje, nawet na chwilę.

Rozwiązaniem tego problemu jest wprowadzenie zmiany poprzez utworzenie nowego dowiązania symbolicznego, a następnie zmiana jego nazwy na stare dowiązanie symboliczne. W systemach uniksowych zmiana nazwy jest operacją atomową, a zatem dowiązanie symboliczne "zmiana" będzie również atomowe. Przez strony, proces wygląda następująco:

$ ln -s new current_tmp && mv -Tf current_tmp current 

Answer 2

Używamy Capistrano zatrudnić podobną konfigurację. Jednak natrafiliśmy na kilka problemów:

Po przełączeniu do konfiguracji wszystko wyglądało dobrze, ale potem zaczęliśmy zauważać, że po uruchomieniu cap deploy, mimo że dowiązanie symboliczne zostało zmienione tak, aby wskazywało na głowę rewizja, przeglądarka nadal będzie wyświetlać stare strony, nawet po wielu odświeżeniach i dołączaniu różnych parametrów GET.

Najpierw pomyśleliśmy, że to buforowanie przeglądarki, więc dla rozwoju wyłączyliśmy buforowanie przeglądarki przez nagłówki HTTP, ale to niczego nie zmieniło. Następnie sprawdziłem, aby upewnić się, że nie robimy buforowania strony po stronie serwera, a my nie. Zauważyłem jednak, że gdybym usunął plik w wersji, do której wskazywałby dowiązanie symboliczne, otrzymalibyśmy plik 404, więc Apache wyświetlał nowe strony, ale nadal śledził "stare dowiązanie symboliczne" i wyświetlał strony od zły katalog.

To jest udostępniony hosting, więc nie mogłem ponownie uruchomić Apache. Próbowałem więc usunąć dowiązanie symboliczne i utworzyć za każdym razem nowe. Wydawało się, że działa to niekiedy niezawodnie. Działało prawdopodobnie 25 ~ 50% czasu.

końcu, okazało się, że jeśli:

1. usunięty istniejący symlinka (usunięcie go lub jej zmiany nazwy);
2. złożyła wniosek strony, powodując Apache próbować rozwiązać dowiązania ale uważają, że brakuje (w wyniku czego 404)
3. następnie stworzył nową dowiązania do nowego katalogu

spowodowałoby to ten docroot do być odpowiednio aktualizowany przez większość czasu.Jednak nawet to nie jest doskonałe, a około 2-5% czasu, gdy skrypt wdrażania miał wget, aby pobrać stronę zaraz po zmianie nazwy starego dowiązania symbolicznego, zwrócił starą stronę zamiast 404.

Wygląda na to, że Apache albo buforuje system plików, albo może komenda mv zmieniła tylko system plików w pamięci, podczas gdy Apache czytał z systemu plików na dysku (tak naprawdę nie ma żadnego sensu). W obu przypadkach podjąłem czyjeś zalecenie do uruchomienia sync po zmianie dowiązania symbolicznego, co powinno spowodować zsynchronizowanie systemu plików z pamięcią, a być może niewielkie opóźnienie również pomoże wget zwrócić 404.