Poziom: 0 | Kategoria: Komputerowo-internetowo. | 4 komentarze
Według mnie dobry programista to leniwy programista. A leniwy programista nie zaprząta sobie głowy rzeczami niepotrzebnymi. Po dosyć długiej przerwie w pisaniu postanowiłem podzielić się kilkoma użytecznymi sztuczkami dla programistów, którzy rozwijają aplikacje internetowe. Myślę, że nie dla wszystkich poniższe sztuczki są znane.
Zakładając, że pracujemy równolegle nad kilkoma aplikacjami, z których każda znajduje się na innym serwerze, dokładając do tego jeszcze serwery testowe, możemy powoli przestać ograniać adresy i dane dostępowe do poszczególnych serwerów. Z pomocą przychodzi plik konfiguracyjny SSH — ~/.ssh/config. Możemy w nim umieścić konfigurację dla poszczególnych hostów, nadając każdemu z nich swoją nazwę. Przykładowo, mając 3 serwery dla projektów X, Y, Z, serwer testowy X-test oraz klucze prywatne, służące nam do uwierzytelniania w każdym projekcie, zamiast wywoływać za każdym razem komendę:
$ ssh username@x.com -C -p 1234
oraz analogiczne dla innych serwerów, możemy zdefiniować konfigurację w pliku ~/.ssh/config:
Host X User username Port 1234 HostName x.com Compression yes Host Y User developer HostName y.net Host Z User z HostName z.org Compression yes TCPKeepAlive yes Host X-test User tester HostName x-test.development.com
Od tej pory logowanie do serwera będzie wymagało jedynie podania jego nazwy:
$ ssh X-test
Pełna lista dostępnych opcji, które możemy wpisać do pliku ~/.ssh.config znajduje się w podręczniku ssh.
Ponieważ tworze aplikacje wykorzystujące Ruby on Rails, korzystam lokalnie z serwera nginx oraz z Passengera. Dla każdej aplikacji tworzę osobny wirtualny host w konfiguracji, przydzielając każdej aplikacji osobną domenę z końcówką .local (najczęściej odpowiadającą produkcyjnej domenie, np. zamiast foo.com tworzę host foo.local — rozwiązanie to jest, w mojej ocenie, bardzo wygodne). Do tej pory, tworząc nową aplikację, musiałem ręcznie dopisywać jej domenę do pliku /etc/hosts. Problem pojawił się, gdy pracowałem równocześnie nad kilkunastoma aplikacjami, z których niektóre wykorzystywały subdomeny. Niestety nie da się ustawić wildcard w pliku /etc/hosts, stąd musiałbym definiować każdą subdomenę osobno.
Z pomocą jednak przychodzi plik automatycznej konfiguracji PROXY — proxy.pac. Tworząc taki plik możemy w bardzo prosty sposób pozbyć się uciążliwości tworzenia kolejnych domen dla kolejnych aplikacji w lokalnym środowisku. Pliki .pac mają składnię w JavaScript i pozwalają ustawiać odpowiednie PROXY dla wybranych hostów. W naszym przypadku potrzebujemy przekierowywać wszystkie żądania na wszelkie domeny, które kończą się końcówką .local na localhost. W tym celu powinniśmy stworzyć plik, np. ~/.proxy.pac z następującą zawartością:
function FindProxyForURL(url, host) { if (/\.local$/.test(host)) { return "PROXY localhost"; } return "DIRECT"; }
Funkcja FindProxyForURL jest odpowiedzialna za znalezienie odpowiedniej konfiguracji PROXY dla podanego adresu.
Wykorzystując powyższy plik, jedyne, co pozostaje nam zrobić, to ustawić nasz skrypt automatycznej konfiguracji w przeglądarce oraz usunąć wszelkie dodatkowe wpisy z /etc/hosts — są już po prostu niepotrzebne, ponieważ wszystkim zajmie się przeglądarka.