O tym, jak prosty skrypt PHP zaczął porządkować pliki, przenosić je do Nextclouda i tłumaczyć chmurze, że właśnie dostała nową dostawę.

Cześć, z tej strony Kuba. Czasami trzeba napisać coś, czego nikt pewnie i tak nie przeczyta 🙁 

No trudno, ważne że ja mam fun. Pisane po czasie, pół roku po odpaleniu i z pamięci, więc mam nadzieję, że nie ma tu żadnych składniowych głupot 😛

No to zaczynamy!

Był już Cieć.

Pierwszy na służbie.

Chodził po stronach, szarpał za klamki i darł się, kiedy administrator zostawił coś otwartego.

Potem przyszli kolejni.

A dzisiaj czas na Zwykolaka #002.

Tragarza.

I jak sama nazwa wskazuje, jego zadanie nie jest szczególnie skomplikowane.

Nosi paczki.

Tyle że nie pomiędzy magazynem a samochodem.

Pomiędzy systemem plików a chmurą.

GENEZA

Przy projekcie dla 4neuro potrzebowaliśmy prywatnego środowiska do wymiany plików, dokumentów, opisów i wyników badań.

Rozwiązanie miało działać na infrastrukturze klienta, więc postawiliśmy Nextclouda.

Wszystko dobrze.

Prawie.

Bo szybko pojawił się jeden bardzo konkretny problem.

Nextcloud nie działa jak zwykły katalog na dysku.

To, że plik fizycznie leży sobie w:

/data/user/files/…

nie oznacza jeszcze, że Nextcloud wie o jego istnieniu.

Chmura przechowuje informacje o strukturze plików i ich metadanych w swojej bazie, między innymi w oc_filecache.

Czyli mieliśmy sytuację:

plik istnieje na serwerze → system plików go widzi → Nextcloud go nie widzi

Piękne.

Plik istniejący i nieistniejący jednocześnie.

Schrödinger byłby dumny.

DLACZEGO TO W OGÓLE BYŁO PROBLEMEM?

Część danych wpadała na serwer poza standardowym klientem synchronizacji Nextclouda.

Na przykład przez:

• FTP,
• rsync,
• katalog zrzutowy,
• inne procesy działające bezpośrednio na systemie plików.

I wtedy Nextcloud mówił mniej więcej:

nie widziałem, nie słyszałem, nie ma.

Pliki mogły sobie spokojnie leżeć na dysku, ale dopóki baza nie została poinformowana o zmianach, użytkownicy nie widzieli ich w panelu.

Można oczywiście robić wszystko ręcznie.

Można też zbudować małego człowieka od noszenia paczek.

I TAK POWSTAŁ TRAGARZ

Tragarz został napisany w PHP.

Bez wielkiego frameworka.

Bez kolejnej platformy.

Bez AI.

Po prostu dostał zestaw prostych reguł i jedno zadanie:

weź paczkę z bufora, połóż ją tam, gdzie trzeba, i powiedz Nextcloudowi, że coś się zmieniło.

Cały proces wyglądał mniej więcej tak.

KROK 1: STAGING AREA

Najpierw Tragarz zaglądał do katalogu tymczasowego.

To była jego poczekalnia.

Wpadały tam surowe paczki i pliki, które jeszcze nie zostały przypisane do docelowej struktury.

Tragarz przechodził po zawartości i sprawdzał:

• co przyszło,
• jak się nazywa,
• do jakiej kategorii należy,
• gdzie powinno ostatecznie trafić.

Czyli klasyczna sortownia.

Tylko bez taśmy produkcyjnej i kamizelki odblaskowej.

KROK 2: KATEGORYZACJA

Na podstawie reguł zapisanych w kodzie Tragarz ustalał docelową ścieżkę.

Mogły decydować o tym między innymi:

• prefiksy w nazwach,
• data,
• typ paczki,
• katalog źródłowy,
• przypisana struktura odbiorcy.

Jeżeli odpowiedniego folderu jeszcze nie było, skrypt go tworzył.

Czyli zanim paczka została przeniesiona, Tragarz wiedział już:

kto ją dostaje i na którą półkę ją odłożyć.

KROK 3: FIZYCZNY TRANSFER

Potem następowało właściwe noszenie.

Pliki były przenoszone bezpośrednio na poziomie systemu plików.

W zależności od sytuacji:

rename()

albo systemowe:

mv

Bez pobierania pliku i wysyłania go ponownie przez interfejs WWW.

Jeżeli dane są już na tym samym serwerze, nie ma sensu organizować im wycieczki krajoznawczej przez pół stosu aplikacyjnego.

Przesuwamy je tam, gdzie mają być.

Koniec.

No, prawie.

KROK 4: „NEXTCLOUD, MASZ NOWE PLIKI”

I właśnie tutaj był najważniejszy element całej operacji.

Sam transfer nie wystarczał.

Nextcloud nadal mógł nie wiedzieć, że paczka właśnie pojawiła się w jego strukturze.

Dlatego Tragarz wykonywał jeszcze komendę CLI:

php /var/www/nextcloud/occ files:scan –path=”/[user]/files/[sciezka]” [w praktyce z ID konkretnego folderu grupowego].

A w odpowiednich przypadkach również:

php /var/www/nextcloud/occ groupfolders:scan

To zmuszało Nextclouda do ponownego przeskanowania wskazanej ścieżki.

System:

• wykrywał nowe pliki,
• indeksował je,
• aktualizował bazę,
• przeliczał potrzebne metadane,
• i wreszcie pokazywał paczkę użytkownikom w panelu WWW.

Czyli:

Tragarz nie tylko przynosił paczkę.

Jeszcze stawiał ją na biurku i mówił:

dzień dobry, to przyszło.

DLACZEGO NIE DZIAŁAŁ CAŁY CZAS?

Bo automatyzacja nie polega na tym, żeby proces odpalać tak często, jak tylko technicznie się da.

Ma działać wtedy, kiedy ma to sens.

Tragarz uruchamiał się dwa razy dziennie.

Rano i wieczorem.

Dlaczego?

Bo skanowanie katalogów, operacje na dysku i aktualizacja bazy też kosztują zasoby.

Nie było żadnego powodu, żeby przy każdej pojedynczej paczce natychmiast robić pełny przebieg.

Lepiej zebrać „pocztę” z kilku godzin i załatwić ją hurtowo wtedy, kiedy ruch na serwerze jest mały.

Cron odpalał Tragarza.

Tragarz robił obchód.

Przesuwał paczki.

Indeksował.

I znikał.

A TELEGRAM?

Oczywiście był.

Bo jaki Zwykolak nie miałby Telegrama?

Na początku Tragarz raportował swoje działania.

Tyle że po pewnym czasie pojawiła się fundamentalna prawda o dobrych automatyzacjach:

jeżeli wszystko działa, nie muszą cały czas mówić, że działają.

Tragarz więc z czasem po prostu przestał się odzywać.

Pracował.

Cicho.

Regularnie.

Jak dobry pracownik nocnej zmiany.

I właśnie dlatego później powstał kolejny bot, którego rolą było gadanie w imieniu systemów korporacyjnym językiem.

Ale to już historia na osobny wpis.

STACK

Engine: PHP
Trigger: cron, dwa razy dziennie
Źródło: Staging Area
Transfer: rename() / mv
Nextcloud: CLI occ
Indeksacja: files:scan, opcjonalnie groupfolders:scan
Alerty: Telegram
AI: brak

I bardzo dobrze.

DLACZEGO NIE API? DLACZEGO NIE AI? DLACZEGO NIE JAKIŚ WIELKI SYSTEM?

Bo nie było takiej potrzeby.

Problem był deterministyczny.

Plik wpada do bufora.

Reguła mówi, gdzie ma trafić.

Skrypt przenosi.

Nextcloud dostaje informację.

Koniec.

To jest dokładnie ten typ problemu, przy którym bardzo łatwo przesadzić z architekturą.

Mikroserwisy.

Kolejki.

Event bus.

Workflow engine.

AI agent.

A potem okazuje się, że chcieliśmy tylko przenieść plik z katalogu A do katalogu B i uruchomić occ.

My wolimy inaczej.

Najpierw najprostsze rozwiązanie, które robi robotę.

Dopiero jeśli przestaje wystarczać, dokładamy kolejną warstwę.

DNA ZWYKOLAKA

Tragarz bardzo dobrze wpisuje się w zasadę całej Gildii.

Jedno zadanie.

Mały zakres.

Proste reguły.

Brak ręcznej pracy tam, gdzie człowiek niczego wartościowego nie wnosi.

Bo człowiek nie powinien siedzieć i sprawdzać:

czy paczka już przyszła?
gdzie ją przenieść?
czy Nextcloud ją widzi?
czy trzeba przeskanować katalog?

Od tego jest Tragarz.

Człowiek ma zrobić coś ciekawszego.

TRAGARZ. ZWYKOLAK #002.

Nie analizuje świata.

Nie podejmuje strategicznych decyzji.

Nie generuje insightów.

Nie ma copilota.

Nie ma agenta.

Nosi paczki.

Ale robi to regularnie, we właściwe miejsce i bez zawracania komukolwiek głowy.

I czasami dokładnie takiej automatyzacji potrzebuje firma.

Nie rewolucji.

Po prostu jednego małego procesu, który od jutra przestaje być problemem.

Tragarz.

Zwykolak #002.

Dostarcza. Nie dyskutuje.