#Mastodon 4.2 oficjalnie wydany 🥳

Dla mnie poprawienie wyszukiwarki jest dość ważne. Jeśli to włączycie (domyślnie nie). Ładniejsze wątki, lepsze podglądy, koniec ścinania obrazków do 16/9, lepszy onboarding i w końcu import list! Czekałem po migracji 😉

No i authorized_fetch jako opcja do kliknięcia, więc pewnie się spopularyzuje.

Na #PolSocial aktualizacja w nocy z piątku na sobotę:

pol.social/@sebastian/11110308

Więcej o tym co w 4.2 nowego, w notkach do wydania (język techniczny):
github.com/mastodon/mastodon/r

@m0bi13 Z ciekawości - pol.social stoi na Mastodonie zainstalowanym bezpośrednio w systemie czy na Dockerze? Bo przyznam, że zaczynam odczuwać, że zrobiłem błąd instalując Masto na social.wildasoftware.pl na "czysto" i teraz mam problem z aktualizacją (co wiąże się z aktualizacją Ruby, a nie znam tego środowiska). Prawdopodobnie w którymś momencie po prostu zrobię backup bazy i postawię to na Dockerze, natomiast zastanawia mnie, jak to mają zrobione większe instancje.

@SceNtriC Tylko na dockerze. Jeśli nie jesteś ruby dev, nie piszesz własnych poprawek masto.

I tak być może będziesz musiał podnosić bazę bo wymagania „wzrosły”, teraz min to Postgresql 10.

A jak się obawiasz dockera z linii komend to może CapRover? Sam używam w Lab FTdL do testowania itp.

@m0bi13 @SceNtriC

Nie polecam dockera przy takim case jak mastodon przy większym ruchu - sam akurat preferuję "raw" setup. Troszkę doświadczenia z aufs/overlay i docker proxy oraz wymogi zastosowania "innych" rozwiązań niż domyślne, zabezpieczających i upewniających, że przy wystawianiu się "na świat" wszystko działa jak należy - wymusza takie podejście.

Teoretycznie image docker'a byłby prostszy w utrzymaniu, lecz pierw sugerowałbym konkretnie skonfigurować środowisko pod docker'a, aby był w stanie obsłużyć ten "większy ruch".

Samego postgresa to polecam cokolwiek nowszego niż wymagana, leciwa i EOL'ed 10'tka 😉

@spoofy Mastodon na dockerze, z Varnishem przez Traefika daje radę.

Też polecam od razu przy zmianie Postgresql 15.

@SceNtriC

@m0bi13 a ten szatan docker userland proxy też daje radę przewalić ruch by default, czy może jakieś tweak'i względem parametrów jądra/obsługi sieci?

Raw setup bez problemu z wersjami utrzymuję na klasycznym Debianie :debian: zaś komponenty takie jak postgres to polecam oficjalne 3rd party repo.

@SceNtriC

@spoofy Tu już zawołam Piotra @piotrsikora do tablicy ;)

Sam jestem zwolennikiem "klasycznego" stawiania usług, długo opierałem się przed dockerem, bo po co kolejna warstwa i komplikacje?

Życie mnie zmusiło

@SceNtriC

@m0bi13 @piotrsikora

Panowie, utrzymujecie masę usług to pewno wam jest łatwiej utrzymywać obrazy docker'a. Sam troszkę utrzymuję i taka warstwa mocno pomaga, w szczególności np. przy deprecated softcie.

Pamiętam czasy w których memy "docker on production" były codziennością, podczas gdy dość nefralgiczne aplikacje w ilosciach dużych były już na produkcji pewnej marki. Oczywiście że cgroups/namespace ma znaczenie, tym bardziej FS i overlay, o czym niejednokrotnie się przekonaliśmy.

Jak bardzo chcecie, to mogę podać realny przykład marki, gdzie przeżyliśmy wczesne wersje docker'a, potem rocket'a i wiele alternatyw runc. Osobiście bardzo lubię docker'a, ale tak samo jak k8s czy inne rozwiązania kontenerowe - lubię dobierać konkretne narzędzia do realizacji konkretnych zadań i akurat w środowisku PVE/LXD lubuję się w raw LXC i implementacjach bez użycia demonów, bridge'ów czy userland tam, gdzie wymagany jest realny performance a nie feature'y pod rozproszoną infrastrukturę.

Głównie chodzi o bolączkę zbędnego dockerd, ale podman też tego nie rozwiązuje. Docker jest dobry przy rozproszeniu, przy developmencie, przy konkretnych przypadkach - mastodon na jednym serwerze IMHO to inny case, tym bardziej jako publiczna aplikacja webowa przyciągająca często niepożądany ruch sieciowy.

Na końcu powiem, że bardzo lubię benchmarki różnych incepcji w namespace - np. w którym momencie zauważalny będzie performance loss (cpu/network) - polecam zrobić sobie takie testy i zbadać samemu, jak bardzo "raw" jest to zarówno sam proces jak i cała abstrakcja wokół.

@SceNtriC

@spoofy @m0bi13 @SceNtriC zgodzę się z Tobą że jeśli masz mieć jedną aplikację odpaloną to rzeczywiście nawet mikro nadmiarowość dockera jest zbędna.

Wracając do mojego wyżej przykładu z kbin.social to tam serwer bazy danych jest standalone. Tylko czysty postgres, nic więcej tam nie działa.

Jednak mastodon to nie jedna aplikacja, masz tam masę różnych rzeczy… do tego na tym serwerze co stoi pol.social mastodon jest także masa innych usług i rozdział ich jest bardzo potrzebny.
Na szybko mówiąc mastodon to: baza, web apka, Sidekiq (x5 bo każda kolejka to osobny zestaw procesów) , varnish, redis, streaming.

A tam mamy jeszcze nch.pl, tube.pol.social, bin.pol.social i wiele innych.

Jezu, brzmi strasznie w porównaniu z Pleromą gdzie jest to jedna elixirowa aplikacja, postgresql i ewentualnie oddzielnie jakieś meilisearch… Ale przynajmniej potrafi się skalować…
Follow

@mkljczk @SceNtriC @spoofy @m0bi13 @piotrsikora afaik to był jeden z głównych powodów czemu zaczęli robić pleromę, bo się złapali za głowę użerając się z architekturą mastodona.

@Amikke @mkljczk @SceNtriC @spoofy @m0bi13 no jest to zakręcone… ale jak mówicie… ładnie się to skaluje.

Kbin ma podobną. Tam masz bazę, redisa, apke w php, dwa messengery do obsługi dwóch kolejek, do tego rabbit mq.

Ładnie się to skaluje.

@piotrsikora @Amikke @mkljczk @SceNtriC @m0bi13 Tylko kurcze dockeryzacja apki to nie problem - nawet symfony z zależnymi usługami obok. Dopóki nie potrzebujemy jednego namespace to po czystej sieci jakoś lepiej to działa.

Jeżeli zaś chodzi o "szybkie" przeprowadzki usług - to jakakolwiek forma abstrakcji wyżej nie robi kompletnie żadnej różnicy w tym przypadku - kontener z zawartością przenosi się tak samo zawsze.

Dodatkowo, niestety w przypadku kontenerów ilości tysięcy, aktualizacja to raczej porażka niż przyjemny proces a równie dobrze możemy zrobić plain lxc z overlay i wyjedzie lepiej.

Dla mnie kompilacja PHP z odpowiednimi flagami a nie instalacja z paczek to podstawa przy performance hostingu takich właśnie apek i raczej znacznie prościej, wygodniej i bezpieczniej (również pod kątem security compliance, często wymaganych nawet przez sektor gov) przy utrzymywaniu, nawet pod replikacje/HA usług w stylu DB - wychodzi znacznie lepiej niż pchanie się w dockera.

Tak jak mówiłem, tak powtarzam zawsze - odpowiednie narzędzia do odpowiednich rzeczy 😉

Mastodon sam w sobie nie jest aż tak rozległy i zły - ot, taki sobie ror, więc nie widzę większych problemów w utrzymywaniu czy skalowaniu, co innego przy dopisywaniu funkcji/rozwijaniu/patch'owaniu/forkowaniu dla kogoś kto nie zna ruby, ale nawet z AI assistant potrafię dopisać przykładowo handler pod obsługę translate bo w miarę czytelny projekt. ES raczej tak jak cokolwiek z elk stack czy bazodanowego - nie trzymałbym w dockerze, nawet z podmontowanym volume, ze względu na performance właśnie. Rabbit/kafka to już prędzej, tylko też większego sensu nie widzę gdy nie ma realnych potrzeb.

Pleroma zaczęła jako klient do GNU Social, mogący zastąpić ten oficjalny lub wtyczkę Qvitter.
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.