Podsumowanie roku 2018

W mijającym już roku 2018 prężnie rozwijały się nasze aplikacje… Dla niektórych z nich trzeba było przygotować dodatkową infrastrukturę, a niektóre z nich przeszły gruntowną reorganizację infrastruktury (przykładowo aplikacja z serwera shared została migrowana na infrastrukturę rozproszoną pracującą na dwóch VPS, a w „sezonie” na trzech + loadbalancer). Wszytko za sprawą ruchu, który z dnia na dzień z 0,5 req/sec urósł do 15 req/sec, a w sezonie do 25 req/sec…

Poniższe screeny pokazują skalę gwałtownego przyrostu – i ciągle rośnie 🙂 

Pushe odbierane przez klientów.

 

Sesje w porównaniu do 2017 roku… w roku obecnym 2k sesji dziennie 🙂

 

Inne aplikacje również doświadczyły sporych zmian, część z nich została migrowania na WP 😉

Rok 2018 kończmy dość dobrze, oby 2019 nie był gorszy!

 

EDIT: 

czy udało się zrealizować plany częstszych  postów (https://aljandor.ovh/blog/nowy-rok-nowe-plany/) ? Chyba tak, choć w 2019 na pewno będzie ich więcej (więcej konkretów!) 🙂 

 

Prace serwisowe, okna serwisowe – jak je robimy

Jakiś czas temu pisaliśmy o deploymencie – jak je robimy (https://aljandor.ovh/blog/deployment-jak-je-robimy/). Dziś napiszemy o pracach serwisowych.

Okna serwisowe przeprowadzamy zazwyczaj w nocy (wtedy jest najmniejszy ruch na serwerach). Termin prac serwisowych planujemy conajmniej dwa tygodnie wcześniej. 

Gdy planujemy okno serwisowe dla konkretnej usługi bierzemy pod uwagę wiele czynników. Pierwszym z nich jest ruch – w jakich godzinach jest najmniejszy? Drugim czynnikiem jest możliwość przełączenia na zapasowe środowisko (blue / green). Cześć najwyżej infrastruktury posiada refundowane środowiska produkcyjne  – przeprowadzanie prac na takiej infrastrukturze jest mniej bolesne 🙂

Powyższy wykres przedstawia odwiedziny użytkowników jednej z aplikacji. Prace 

 

 

Dumps links #4

Przed nami czwarta edycja Dump links 🙂

Zapraszamy!

  • https://larsjung.de/h5ai/demo/ – directory listener
  • https://blog.lftechnology.com/date-ing-javascript-6203650b752c – praca z obiektem Date (w JavaScript)
  • https://bootsnipp.com – snippety szablonów Bootstrapowych
  • https://axibase.com – baza danych +dashboard do agregowania serii czasowych 
  • https://jdorn.github.io/php-reports/ – framework pomocny do generowania oraz prezentacji raportów z różnych źródeł
  • https://gist.github.com/vodolaz095/5073080 – watchdog usług linuxowych 
  • https://gatling.io – narzędzie do testowania wydajności aplikacji internetowych 
  • https://medium.com/@hakibenita/be-careful-with-cte-in-postgresql-fca5e24d2119 – ostrożnie z używaniem CTE!
  • https://github.com/BookStackApp/BookStack/blob/master/readme.md 
  • https://github.com/Valve/fingerprintjs2 – fingerprit przeglądarki – identyfikacja przeglądarki JS
 

Deployment – jak je robimy?

Zależnie od inftastruktury aplikacji, jej architektury zawsze planujemy deplyment tak aby był jak najmniej uciążliwy dla użytkownika końcowego systemu. Często nasze stsytemy aktualizujemy podczas nocnych okienek serwisowych. I tak jedna z aplikacji, która ma 20, a w sezonie 30-40 req/sec jest aktualizowana głównie poza sezonem. W trakcie szczytu, gdzie dziennie jest kilkadziesiąt tysięcy wizyt przeprowadzamy jedynie krytyczne poprawki – jeśli są niezbędne do prawidłowego oraz stabilnego działania systemu.

Poza sezonem aplikacja jest aktualizowana we wtorki oraz czwartki, w godzinach 16-18. Zmiany są przygotowywane oraz testowane we wcześniejszym tygodniu. Jeśli trwa sezon, utrzymuje się spory ruch, deployment przeprowadzamy jedynie w nocnych oknach serwisowych – które zaczyna się od 1 w nocy, a kończy o 3 rano.

Każde z wdrożeń niezależnie od pory jest możliwe do cofnięcia w krótkim czasie. Jeśli aktualizujemy większa aplikacje często przepinamy ruch na czas wdrożenia na zapasowe środowisko produkcyjne (które jest w stanie przejęć 100% ruchu w razie problemów z głównym środowiskiem) tak aby zminimalizować ryzyko down time (metoda Blue-Green).

 

Przekierowanie z WWW na bez WWW + SSL

Często zachodzi potrzeba ustalenia dla naszej aplikacji jednego, głównego adresu pod którym będzie ona dostępna. Ważne jest to nie tylko z uwagi na „wygodę” użytkowników, ma to także wpłwy na SEO naszej strony. Tak więc, posiadamy domenę wraz z certyfikatem SSL. Chcemy aby nasza aplikacja była dostępna jedynie pod adresem https://domena.com

Pomocne okazać się może dość proste przekierowanie utworzone w pliku .htaccess:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.(.*)
RewriteRule ^.*$ https://%1/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Powyższe wpisy przekierują wszystkie odwołania do naszej aplikacji z subdomeny www na domenę główną po protokole https oraz przekierują wszystkie żądania http na https.