Zmiany we free tier w Google Cloud Platform

Tytułem wstępu: Google ma swoją chmurę, czyli Google Cloud Platform, a w ramach niej coś takiego jak free tier, czyli zasoby dostępne bez opłat[1]. Zasoby są niewielkie, dodatkowo podlegające pewnym ograniczeniom, raczej do zabawy. Ale do testów, nauki czy właśnie zabawy – idealne. Między innymi można mieć uruchomioną w ramach compute engine najsłabszą VMkę, czyli f1-micro.

Mail

Jeśli ktoś korzysta z GCP, to zapewne dostał już maila. Dla tych, co maila przeoczyli, krótkie podsumowanie. Od pierwszego sierpnia 2021 instancje e2-micro są bezpłatne (w określonej ilości czasu), natomiast od pierwszego września instancje f1-micro będą płatne. Regiony pozostają bez zmian. Instrukcja zmiany linkowana w mailu dostępna jest tu.

To różne platformy, więc ciężko porównać dokładnie, ale:
f1-micro to 0.2 VCPU i 0.6 GB RAM w cenie $0.0076 (us-central1)
e2-micro to 0.25 VCPU i 1 GB RAM w cenie $0.008376 (us-central1)
Dodatkowo w przypadku e2-micro możliwy jest burst do 2 VCPU.

Google pisze[2]:

As we improve the experience of the Free Tier, we will be introducing the E2-micro VM, which is a part of a second generation VM family.

Wydajność

W przypadku RAM zysk jest oczywisty, natomiast w przypadku CPU – niekoniecznie. Wiele zależy od tego, na jakiej platformie CPU znajduje się obecnie VMka, i na jakiej wyląduje po przeniesieniu. Tabela platform CPU dla serii N1 i E2 jest dość skomplikowana. Jednak patrząc na base frequency, przeciętnie powinno być szybciej.

I jeszcze wynik cat /proc/cpuinfo z mojej instancji f1-micro:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology n$
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64

Jak się zmigruję to uzupełnię wpis, co dostałem po migracji i jak wrażenia.

Migracja

Wczoraj zmigrowałem maszynę na e2-micro. Migracja błyskawiczna i bezproblemowa. Zgodnie z instrukcją zatrzymać instancję, wyedytować typ, zapisać zmianę, uruchomić maszynę.

Po migracji dostałem dokładnie ten sam procesor. Tyle, że teraz cat /proc/cpuinfo pokazuje dwa. Jeśli chodzi o osiągi i wydajność w praktyce, to najlepiej widać to na obrazku.

Wykorzystanie CPU na f1-micro i po migracji na e2-micro w GCP free tier
Wykorzystanie CPU na f1-micro vs e2-micro

Migracja chwilę przed 12:00, później wzrost obciążenia spowodowany porządkami, chwilę po 18:00 koniec ostatnich ręcznych prac. Jak widać, główny zysk wynika ze wzrostu mnożnika z 0.2 do 0.25 VCPU. Ponieważ przydział jest dynamiczny, procesy jednowątkowe także skorzystają na zmianie parametrów.

Podsumowując, warto migrować, bo e2-micro w stosunku do f1-micro oferuje 66% więcej RAM i 25% więcej CPU.

[1] Wymagane jest podpięcie karty debetowej, a po przekroczeniu puli darmowych zasobów jest automatycznie naliczana opłata za przekroczoną część.
[2] Nawiasem, wysłaniem tego maila Google Cloud Platform zdobyło u mnie sporo punktów sympatii. Mogli przecież np. zamieścić info o zmianie cenników free tier na blogu i billować nieuważnych, albo wysłać suchego maila o zmianach w cenniku. Wiele firm tak właśnie by postąpiło. A tu osobne, czytelne powiadomienie, z instrukcją migracji. Miło.

Instalacja podatnych wersji oprogramowania HOWTO

Niekiedy zachodzi potrzeba uruchomienia starej, podatnej wersji systemu lub usługi w celu przetestowania czegoś, np. exploita. W przypadku Debiana i podobnych dystrybucji opartych na pakietach deb, instalacja starej wersji systemu bywa nieco problematyczna. Po pierwsze, system pakietów nie wspiera downgrade’u, po drugie, domyślnie instalator instaluje najnowsze wersje pakietów, jeśli tylko ma taką możliwość.

Sposoby instalacji podatnych wersji oprogramowania

Sposobów na instalację starszych, podatnych wersji pakietów jest wiele. Można kompilować określoną wersję, ale nie jest to wygodne, jest czasochłonne i niekoniecznie uzyskamy wersję dokładnie taką, jaka była w systemie, np. z powodu patchy nakładanych przez Debiana czy nieco innego środowiska w którym pakiet był budowany[1].

Skoro jednak korzystamy z dystrybucji opartej o pakiety binarne, można także próbować robić downgrade pakietów, albo usuwać pakiety i instalować przy pomocy dpkg zamiast apt[2]. Jeśli nie mamy pecha, wszystko zadziała czy to od razu, czy po małym force przy instalacji. Można też instalować ze starych obrazów instalacyjnych, bez dostępu do sieci. Czasem jednak nie mamy szczęścia. A wszystko można zrobić szybciej i prościej.

Repozytorium starych wersji pakietów Debiana

Przede wszystkim, i tak trzeba jakoś zdobyć podatne wersje pakietów. W przypadku Debiana istnieje snapshot.debian.org, czyli serwis z oficjalnymi, snapshotami mirrorami repozytoriów Debiana. Doskonałe miejsce pozwalające i na pobranie pakietów w takich wersjach, w jakich były w danym momencie w repo, i na postawienie całego systemu w stanie na dany dzień. Snapshoty wykonywane są częściej, niż raz dziennie. Poza głównym repozytorium pakietów dostępne inne, w tym security i backports, więc trudno sobie wyobrazić coś lepszego. Pozostaje instalacja systemu z wykorzystaniem powyższych repozytoriów.

Naprościej można to zrobić z użyciem debootstrap, poprzez podanie mirrora., z którego mają być pobierane pakiety. Przykładowo, aby zainstalować Debiana Buster w wersji, w jakiej był on dostępny dzień po wydaniu:

debootstrap buster /chrooted/ https://snapshot.debian.org/archive/debian/20190707T150059Z/

Po instalacji należałoby jeszcze wejść do chroota i uzupełnić sources.list o wpisy dla repozytorium security, zaktulizować pakiety i… gotowe. W katalogu /chrooted będzie dostępny podatny system. Jeśli był tam podmontowany dysk zdalny, to można uruchomić podatną maszynę według podlinkowanej wyżej instrukcji.

Wykorzystanie LXC do uruchamiania podatnych wersji

Istnieje jeszcze szybszy i IMO wygodniejszy sposób uruchomienia podatnej wersji systemu. Można wykorzystać kontenery LXC do instalacji, a następnie uruchomienia podatnego systemu. O tyle wygodne i bezpieczne, że kontener LXC może być dostępny – i jest to domyślna konfiguracja – wyłącznie z poziomu hypervisora, bez udostępniania go na świat. Kontener z Debianem Buster w wersji na dzień po wydaniu z użyciem LXC tworzymy:

lxc-create -n test -t debian -- -r buster -a amd64 --mirror=https://snapshot.debian.org/archive/debian/20190707T150059Z/ --security-mirror=https://snapshot.debian.org/archive/debian-security/20190707T153344Z/

I gotowe. Po zakończeniu powinniśmy mieć dostępny kontener LXC z podatną wersją systemu. W tym przypadku o nazwie test, którym możemy zarządzać w standardowy sposób, czyli sources.list będziemy mieli:

cat /etc/apt/sources.list
deb https://snapshot.debian.org/archive/debian/20190707T150059Z/          buster         main
deb https://snapshot.debian.org/archive/debian-security/20190707T153344Z/ buster/updates main

[1] Przy weryfikacji zgodności pakietów pomóc mogą reproducible builds.
[2] W tym miejscu nadal odsyłam do wpisu o wajig i zachęcam do zapoznania się z narzędziem. To stary wpis, nie wszystkie opisane okoliczności muszą być prawdziwe, ale wajig ma się dobrze. Warto więc zatem go poznać.

MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako MauiBot. Dokładnie:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów. W User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS). A nawet , że są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów. Następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane. Bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Ostatecznie przestałem go obserwować na bieżąco przez cztery tygodnie i w zasadzie czekałem tylko, kiedy skończy pobierać i czy np. nie zmieni IP. Nie zmienił, za to pobierać przestał 20 sierpnia 2018. Tempo pobierania w ostatnich godzinach to ok. 335/h, pobierał ze wszystkich stron w grupach nie po 4, a po 8 requestów.