Post

Od jakiegoś około roku czasu używam namiętnie sd, mega prosty i naprawdę wygody skrypt do organizowania skryptów powłoki. Kilka miesięcy temu do katalogu źródłowego zawierającego moje skrypty, czyli $HOME/sd/ podpiąłem sobie gitwatch. Dzięki temu każda zmiana leci od razu do mojego repozytorium ze skryptami, a co za tym idzie na wszystkich maszynkach, na których używam sd mam je wszystkie dostępne. Mega fajna sprawa i naprawdę polecam taką konfigurację.

Przez lata pracy jako admin, potem developer, a aktualnie devops zawsze zachodzę w głowę dlaczego skrypty shell bardzo często wyglądają jakby były pisane na kolanie. Oczywiście nie zawsze, ale traktowanie skryptu bash/sh z reguły wygląda na zasadzie zrób po kolei to i to, nie ma porządnej parametryzacji, a o handlowaniu błędów to już w ogóle można zapomieć. Sam tak kiedyś robiłem, bo skrypt traktowałem jako taki nazwijmy to “pierdolnik” z komendami do wykonania i wsio. Ale to nie jest dobra droga, a już na pewno nie jest dobra w bardziej skomplikowanych procesach, które mają dużo zależności, konfiguracji i są rozczłonowane na wiele systemów i elementów. Traktując takie skrypty jak wspomniany już pierdolnik skończymy z wyrwanym owłosieniem, podkrążonymi i zalanymi szałem oczami, a przecież nie o to chodzi w fajnym i seksownym procesie. ...

To już u mnie chyba zwyczaj, albo co najmniej “tradycja”. Jak co roku zabieram się w grudniu do robienia małych lub większych porządków w mojej cyfrowej przestrzeni. W tym roku postanowiłem pozbyć się kilku vps’ów, które od lat sobie stoją i w sumie mało robią. Teraz większość przeniosłem na jeden, który zasilany jest kubernetesem i drugi, na którym stoi klasycznie nginx. W końcu uporządkowałem swoje terrformy, bo tam wiało złem. Provider do hetzner cloud działa całkiem spoko, ten z proxmoxa też ujdzie w tłumie. Teraz w jednym tf apply leci AWS, proxmox, hetzner i cloudflare - co powiem? Działa :) ...

Jak już pisałem, postanowiłem po latach ożywić starego pryka, ale przy okazji zmienić techologię. Na niby prostrzą czyli prosty blog oparty o markdown zasilany świetnym silnikiem hugo, nigdy nie miałem odpowiednio sporo weny i zaparcia, żeby starego wordpressa przemigrować na markdown, ale w końcu się zebrałem. Pierwszym krokiem było znalezienie jakiegoś sensowanego narzędzia do migracji z backupu wordpressa do struktury strawnej dla hugo, znalazłem fajne (acz nie pozbawione wad) narzędzie wp2hugo. Problemy z migracją polegały głównie na tym, że mój stary blog średnio spełniał standardy i np. code-block na starych postach zdziebko trącił myszką. Tutaj z pomocą przyszedł stary dobry sed ...