Tag: hosting

Opublikowane w

Pomigracyjnie

W poprzednim wpisie pisałem o planowanej migracji na Oracle Cloud. Jak widać blog stoi już w nowej lokalizacji, więc operacja jest zakończona i mogę napisać kilka słów z perspektywy.

Migracja

Poszło niemal bezproblemowo. Backup w zasadzie zadziałał. Był problem z detalami typu lista zainstalowanych pakietów i crony. W sumie nieistotne i/lub poprawione. Xpil opisał swoją migrację VPSa i po tej lekturze miałem silne postanowienie zamknięcia wszystkiego w kontenerach LXC. To nieco wydłużyło proces migracji i dodało trochę zadań. Co prawda nadal nie jest to taka separacja jak w dockerach czyli per usługa, ale mariadb + nginx + całe WWW w osobnym VPSie też jest OK.

Konieczne było lekkie przemeblowanie. Musiałem rozdzielić skrypty cron do właściwych kontenerów. Okazało się też, że wynik działania jednego kontenera (Planeta Joggera) musi trafić nie do hypervisora, tylko do innego kontenera, a ten nie ma dostępu. Skrypt w cronie na hypervisorze załatwił sprawę.
Podobnie niezbyt elegancko rozwiązany jest backup bazy danych. Dump robię teraz w LXC, a następnie cały kontener jest backupowany. W ten sposób zawartość bazy jest zdublowana. Mam pomysł jak to rozwiązać, nie wiem, czy potrzebuję. Tyle o samej migracji, a efekty i hosting?

Efekty

Przede wszystkim jest szybciej, przynajmniej wg GTmetrix. Niestety nie zrobiłem testu tuż przed migracją i od razu po niej. Mam tylko ten link z twardymi danymi, ale w międzyczasie się poprawiło, więc polegam głównie na pamięci. Ale tak dobrze to nigdy nie było:

Blog GTmetrix w Oracle Cloud
GTmetrix w Oracle Cloud

Hosting

Pewnie w sporej części to kwestia przejścia z jednego VPSa na dwa, w dodatku z widocznymi dwoma rdzeniami w systemie. W Arubacloud było:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 79
model name      : Intel(R) Xeon(R) CPU E5-2650L v4 @ 1.70GHz
stepping        : 1
microcode       : 0xb000038
cpu MHz         : 1699.999
cache size      : 35840 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 dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx hypervisor lahf_lm 3dnowprefetch pti arat
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips        : 3399.99
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual

Teraz jest (pojedynczy rdzeń):

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 1
model name      : AMD EPYC 7551 32-Core Processor
stepping        : 2
microcode       : 0x1000065
cpu MHz         : 1996.249
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
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 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr virt_ssbd arat npt nrip_save arch_capabilities
bugs            : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 3992.49
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual

Blog zawsze dominował, jeśli chodzi o obciążenie, ale teraz ma całe zasoby dla siebie. Z drugiej strony bieżący VPS ma sporo wolniejszy dysk (3000 IOPS, 24 MB/s). Można tym jakoś sterować, ale zakładałem na domyślnych wartościach. No i nie widzę potrzeby zmiany.

Wady

Żeby nie było, że wszystko jest fajnie – port 25 TCP w Oracle Cloud jest zablokowany na twardo, w obie strony. Czyli ani maila nie przyjmę, ani nie wyślę. Znalazłem, że trzeba pisać do supportu o odblokowanie. Napisałem i zobaczymy. O ile do monitoringu poczta nie jest mi potrzebna, bo powiadomienia mogę wysyłać Telegramem, to przy blogu jest to jakby kluczowe. Potwierdzanie subskrybcji komentarzy itp. Z drugiej strony widzę, że nie było to jakoś mocno wykorzystywane… Zobaczę co odpowiedzą i wtedy pomyślę, co dalej.

Ogólnie sporo rzeczy w Oracle Cloud jest załatwianych przez support. Ustawienie PTR – support (działa!). Inny obraz dysku dla arm64 – support (tak powiedzieli na czacie, odpuściłem).

UPDATE: Port 25 nie został odblokowany, bo free tier. Nie jest to duży problem – wystarczy skonfigurować SMTP relay u któregoś z dostawców.

Opublikowane w

Chmura Wyroczni

Niewiele brakowało, a lipiec byłby pierwszym od wielu miesięcy, jeśli nie w historii, miesiącem bez wpisu. Jakoś tak się złożyło, że było parę rzeczy, ale żadna nie wydała mi się godna wpisu.

Najważniejszym zagadnieniem jest rozpoczęcie prac związanych z migracją na nowy hosting (Oracle Cloud), o którym wspominałem we wpisie z początku roku. Jest to jednocześnie ostatnie z zaplanowanych postanowień. PUM jest już przepisany na Pythona i działa. Skrypt generujący stan rowerów na stacjach Nextbike, w zeszłym miesiącu przeniosłem na repo na GitHub.

Pozostał hosting. Moim wyborem jest Oracle Cloud. Ich free tier jest bardzo zachęcający, szczególnie jeśli chodzi o moje potrzeby. Ilość przestrzeni na dysku wręcz rozpieszcza – obecnie mieszczę się „ze wszystkim” na 1 VPS i 20 GB. Przynajmniej, jeśli chodzi o rzeczy „produkcyjne”. Nie ukrywam, że po pierwsze dopiero się uczę, po drugie nie jest to wszystko ani intuicyjne, ani dopracowane. Dobrze, że kiedyś miałem nieco więcej do czynienia z Openstack, bo filozofia podobna.

Napaliłem się na maszynki ARMowe i… szybko dostałem kubłem zimnej wody. Po pierwsze, w oficjalnych obrazach nie ma Debiana. Po drugie, w przypadku ARM nie ma możliwości cywilizowanej metody instalacji, przez dostarczenie swojego obrazu. Znalazłem co prawda tego typu wygibasy, które rozumiem, ale… nie działają od kopa. Przynajmniej nie dla najnowszego Ubuntu. Pewnie popróbuję jeszcze, ale wariant, że polegam na dostępności starego Ubuntu dla „produkcyjnych” gratów, średnio mi się uśmiecha.

Tak czy inaczej mam soft, który wymaga amd64, więc po prostu postawiłem maszynkę amd64. Tu również nie dają Debiana, ale istnieje ręczna, jednak dość cywilizowana metoda instalacji Debiana w Oracle Cloud. Trochę mniejsze zasoby, ale w zupełności wystarczają. Pierwsze kontenery już przeniosłem. Oczywiście zacząłem od strony zadniej, czyli od zabawek i rzeczy nieprodukcyjnych. Pozwoliło mi to złożyć „tymczasowego” VPSa. W przyszłym tygodniu pewnie będzie większa przerwa. Akurat blog nie jest skonteneryzowany, więc przywrócenie nie będzie po prostu wgraniem backupu kontenera.

Opublikowane w

Noworoczne porządki

Postanowień noworocznych brak, ale zmiana roku na 2022 to dobry moment na porządki informatyczne z jednej strony, a na ich zapowiedź – w roli motywatora – z drugiej.

PUM

Zaczęło się od informacji na IRCu, że PUM przestał działać[1]. Przyczyną okazała się cicha zmiana API przez Uptime Robot. API v2 to większe zmiany, niż sądziłem – część danych przekazywana jest teraz w payload w POST, pojawił się limit zapytań w czasie, lekkie zmiany formatu danych. Nie wiem, czy pierwsza wersja umiała zwracać dane w JSON, v2 potrafi. Rzut oka na Perla i wiedziałem, że raczej do przepisania na Pythona[2], przy okazji parę zmian i… trochę utknąłem. Mam „większą połowę” zrobioną, obecnie jestem rozdarty między chęcią zachowania dokładnej starej funkcjonalności, a napisaniem tego bardziej elegancko. W ogóle trochę uderza mnie oglądana z perspektywy zwięzłość Perla.

Zrobiłem. Nie jestem w 100% zadowolony, ale pum.pl is dead, long live pum.py!

Nextbike

Monitoring ilości rowerów Nextbike na stacjach zacząłem w roku 2013. W roku 2017 skrypt został przepisany na zgrabniejszego Pythona. O ile na początku zaglądałem regularnie, to obecnie praktycznie nie korzystam. Powód jest prosty: rzadko kiedy korzystam z rowerów na stacjach. Odkąd pojawiły się rowery z odbiornikiem GPS, niemal zawsze w praktyce biorę rower „z ulicy”, nie ze stacji. I tak go zostawiam. Po prostu niemal zawsze bliżej mam jakiś rower luzem. No i rzadko moja trasa kończy się na stacji Nextbike.

Co się udało w tym projekciku? Całkiem sporo: działał i był użyteczny, przynajmniej dla mnie, przynajmniej przez pewien czas. Pozwoliły poćwiczyć Pythona i zapoznałem się w praktyce z jinja2. Nauczyłem się, ile (nie)warte są „darmowe” domeny (tu: .tk).

Co się nie udało? Liczyłem, że stanie się popularniejszy. Nie udał się eksperyment z automatycznym SEO. Liczyłem, że dobrze otagowane strony z konkretnymi informacjami trafią wysoko w pozycje w wyszukiwarce Google. Nie było całkiem źle, ale gorzej, niż liczyłem, biorąc pod uwagę otagowanie metadanymi. Chęć zachowania maksymalnej prostoty i automatyzacji spowodowały, że nie dodawałem dodatkowej treści, mogącej pozytywnie wpłynąć na pozycjonowanie.

Wkrótce projekt przestanie istnieć – skrypt zostanie wyłączony i zapewne trafi na GH.

Hosting

Szykuje się zmiana platformy, na której utrzymuję hosting. VPS w Aruba Cloud podrożał jakiś czas temu i od tamtego czasu rozglądałem się niespiesznie za czymś innym. W zasadzie decyzja już zapadła i była pierwsza próba, niestety, weryfikacja kart w nowym miejscu jest lekko przesadzona. Ma szansę być szybciej, bo znacznie większe zasoby, ma szansę być wesoło, bo szykuje się przesiadka na architekturę ARM. Nie rozwijam tematu, bo zapewne zasłuży na osobny wpis.

Tyle z większych planowanych zmian. Od dawna wisi temat lekko przestarzałego softu do tworzenia Planety Joggera, ale na razie się nie pali – póki co system posiada jeszcze wsparcie.

[1] Tak, jest pomysł na drobną modyfikację we wszystkich skryptach tak, by przy błędzie wykonana powiadamiały np. mailem. Bo nie jest to pierwszy raz, kiedy o padzie czegoś z powodu zmian po stronie źródła dowiaduję się po długim czasie. Inna sprawa, że to nic krytycznego.
[2] Nazwa zostanie bo Perl Uptime Monitor -> Python Uptime Monitor.