Temat: Kompilować czy instalować z paczek
Osobiście z dnia na dzień tracę zaufanie do ubuntu jeśli chodzi o serwer produkcyjny - tym bardziej, że coraz częściej mają dużo fackupów, jak choćby ostatnio z apachem:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/...
Zastanawiałem się czemu mi się apache tak psuje wywala...
Prawdziwa, też jest ostatnia wypowiedź:
"Currently gutsy is unusable as a webserver in production evironments, and upgrade to hardy is usually a hard task it must be handle with a lot of care."
Niby gutsy przechodzi w niepamięć, ponieważ są kolejne wersja, to mimo to z wersji na wersje tracę zaufanie do tej dystrybucji - mimo, że ją bardzo lubię :) Ale to jest moje osobiste zdanie. No dobra, ale odchodzę od tematu.
Padło pytanie jak robimy upgrade maszyn. Może zabrzmi to kontrowersyjnie, ale jak najmniej niepotrzebnych aktualizacji systemu. Jeśli działa to zostawiamy i niech śmiga. Oczywiście nie tyczy się to krytycznych aktualizacji lub łatania dziur, które warto z wiadomych przyczyn poprawić.
Jeśli potrzebna jest aktualizacja (poważniejsza) to staram się stawiać nową maszynę. Może opiszę jak to jest u jednego z naszych klientów. Firma ta ma troszkę większych projektów napisanych w php (pisanych jeszcze za czasów php3 aż do początków php5). Aktualnie od jakiegoś półtora roku jest to głównie ruby on rails.
Wspólnie z kolegami z pracy oraz przy współpracy z programistami z tej firmy staramy się uniezależniać projekt od systemu. Mówiąc prościej: ściągam projekt z repozytorium svn (a już niedługo git), zmieniać kilka rzeczy w plikach konfiguracyjnych i projekt działa.
Daje nam to bardzo ważną rzecz. Padła maszyna -> w ciągu kilku minut mogę stworzyć identyczną (vmware infrastructure). Skrypty budujące budują mi maszynę. Za pomocą jednego kliknięcia myszy w webistrano budowane i konfigurowane jest środowisko dla projektu (export z svn projektu, stworzenie struktury katalogów, symlinki itp.). Chwila moment i maszyna jest gotowa. Co ważne jest to zautomatyzowane, więc nie ma możliwości, że gdzieś zostanie pominięty jeden z kroków.
Aktualizacja systemu -> stawiasz nową maszynę z nowym, czystym systemem. Odpalam projekt. Wszystko działa prawidłowo. Nie działa to usuwam nową maszynę i podnoszę tą starą. Mówię tu oczywiście o większych aktualizacjach (kernel, aktualizacja gemów dla rubego, aktualizacja apache, php itp.).
Dlaczego tak robię? Bo kiedyś miałem sytuację, jak bodajże na debianie zrobiłem sobie apt-get upgrade i nie wiedząc czemu system nie wstał. Zaktualizujesz sobie dystrybucję i okazuje się, że apache babola ma lub np. nie chcą się skompilować vmware tools (sterowniki itp. vmware)
Podsumowując:
- nowy soft nie zawsze jest lepszy od starego
- jeśli nie musisz robić aktualizacji to ich nie robisz
- jeśli wszystko działa na php 5.2.1 to nie robisz aktualizacji to php 5.2.2 tylko dlatego, że numerek się zmienił, która nic nie wnosi do Twojego projektu
- Twój klient/pracodawca prawdopodobnie zawsze chętniej zapłaci za to, że coś działa i się nie psuje, niż za to, że ma system "up to date".
пропозиції роботи
