2018s

Už několik měsíců to nade mnou viselo — blog, který jsem před deseti lety založil se blížil ke svému jubilejnímu výročí — a já jsem přemýšlel, jak tento tradiční článek pojmout. V minulých letech jsem vždycky nějak zhodnotil daný rok, co se v mém profesním (a někdy i osobním) životě událo, často jsem přidal nějakou prognózu, či přání do budoucna. Vloni jsem z tohoto mustru vykročil — poprvé za tu dobu jsem si udělal jednoduchou statistiku všech článků, které jsem zde na blogu napsal.

Pamatujete si na film Inception? Šlo o to, že ve snu se odehrává sen, ve kterém se odehrává sen a něm… se odehrává sen. 🤯 Tak něco podobného jsem implementoval ve Fluentd. Jak už jsem psal v úvodu této minisérie o Fluentd, dostal jsem se k této technologii v rámci práce na novém produktu. Nebudu ho jmenovat, ale zaměřím se na statickou architekturu a jak na ní aplikovat Fluentd.

Protože první den na FOSDEM 2021 v Golang room se mi líbil, podíval jsem se, co ještě zajímavého dávají druhý den. Jednotlivých roomů bylo hodně, ale nic moc mě nezaujalo (že by se v open source nic zajímavého nedělo? 🤔). Nicméně protože jsem se nedáno hodně zabýval Fluentd a před dvěma lety zase Prometheem, vybral jsem si nakonec Monitoring and Observability room. A nebylo to špatný. Observability for beginners Atibhi Agrawal byla na stáži v Grafana Labs, kde — logicky — přičuchla k distribuovanému monitoringu.

Nejsem vymetač konferencí. V dobách před pandemií to nebylo úplně jednoduché se dostat na zahraniční konferenci — stálo to dost peněz (od registrace, přes cestu a ubytování) a ne každá firma to chtěla zaplatit. Dnes, kdy se všechny konference přesunuly do virtuálního prostoru je situace v mnohém jednodušší. Ale nějak to není ono. Nemůžu si dát kafe a catering, nemůžu si pokecat s lidma (většinou to nedělám, ale když je řečník excelentní, tak mu to řeknu), nemůžu poznávat nová místa.

Přiznám se, že posledních pár let mě baví se zabývat bezpečností aplikací. Čistě technicky. A když člověk tyhle věci implementuje, dostane se k zajímavým problémům, které by ho ani nenapadly. A tak se stalo, že jsem se dostal k proxy. Jako slepý k houslím. Proxy pro mne dlouhá léta byla tím, čím pro mnoho jiných, běžných vývojářů — pain-in-the-ass, která dělala problémy při vývoji aplikací. Pořád se muselo řešit, jak se dostat do nějaké síťě, nebo na internet, jak nastavit tenhle nástroj, aby fungoval přes proxy, vykoumat, aby to fungovalo jak přes VPN, tak mimo firemní síť, atd.

V Golangu dělám už druhým rokem a je to láska. Je to první jazyk, po kterém sáhnu, když potřebuju udělat nějaký PoC. Nejčastěji používám GoLand IDE, občas píšu ve Vimu s vim-go pluginem. Zkoušel jsem i VS Code, ale nějak jsme se neskamarádili. Vzhledem k tomu, že poslední tři roky píšu cloudovou infrastrukturu, jsou moje aplikace relativně jednoduché micro-servisy. A tak jsem si prozatím vystačil jen s lokálním debuggingem přímo z IDE.

Dnes budeme pokračovat dalším dílem minisérie o Fluentd. Minule jsme si řekli něco o historii logování a zasadili si Fluentd do kontextu. A trochu jsme si načrtli architekturu a design. Dnes se podíváme, jak si nakonfigurovat jednoduchou logovací infrastrukturu. Ale ještě před tím, se krátce vrátím k minulému článku. Lesk a bída bulvárních titulků Když jsem předešlý článek nazval Fluentd, budoucnost logování, měl jsem u toho postranní úmysly. Respektive, nemyslel jsem to úplně vážně.

Dlouhá léta byl synonymem pro sbírání distribuovaných logů, tzv. ELK stack, (dnes nazývaný Elastic Stack), kdy ELK je akronym pro Elasticsearch, Logstash, Kibana. A je to framework věru letitý (což není samo o sobě na škodu). Bohužel, letitost sebou nese v IT jednu nepříjemnou věc — ukotvenost v čase a určitém kontextu. Tím kontextem je v případě ELKu tehdy ještě převažující důraz na server-based architekturu, která se teprve zvolna začínala přesouvat do cloudu.

Disclaimer: Tento článek je napsán pod vlivem confirmation biasu. Měli jsme v práci takovou planou diskuzi o microservices vs. monolit. Jelikož to k ničemu nespělo (ehm, jsem z toho vycouval 🤭), řekl jsem si, že si v tom udělám trochu jasno a abych si potvrdil, že to, co tak nějak intuitivně tuším, je podepřený nějakými reálnými zkušenostmi. Následující text je kompilací článků, které jsem četl, respektive rekonstrukcí z výpisků, které jsem si během jejich čtení pořídil.

Terraform je skvělý nástroj, který se profiluje jako jeden z leaderů nastupujícího trendu Infrastructure as Code (IaC). Vytvořit a zrušit infrastrukturu pomocí příkazů terraform apply a terraform destroy je jednoduché a přímočaré. Když se nad tím ale zamyslíme, Terraform nedělá nic jiného, než že mapuje abstraktní DSL na API jednotlivých providerů. (Protože my znalci a evangelisti IaC víme, že všechny cloudy jsou API-driven.) Takže, když to hodně zjednoduším, většina zdrojů v cloudu se manipuluje pomocí CRUD volaným přes REST.

Když jsem před časem začal psát blog v Hugo, byl jedním z kroků výběr (grafického) tématu. Témata udržuje komunita a tak nepřekvapí, že jsou rozdílné kvality. U obou blogů, které momentálně provozuji jsem potřeboval vybraná témata upravit. Kromě různých CSS úprav a přizpůsobení layoutu a dalších feature jsem se už nějaký čas chystal na Twitter Cards. Je dost možný, že Twitter Cards už jsou ve vašem tématu nachystaný, ale v mém případě tomu tak nebylo ani v jednom případě.

Rok se s rokem sešel a blog SoftWare Samuraj slaví už 9. narozeniny. Dneska to pojmu trochu jinak, než bylo mým zvykem a podívám se ne na svůj uplynulý rok, ale na historii blogu. To se dá pojmout různě — třeba někdo by se blýsknul statistikami návštěvnosti (ale tím já se pyšnit nemohu), jiný by nabídl sofistikovanou data science (v tom jsem sotva začátečník). Ne, já to vezmu jednoduše — pár základních součtů a agregací, proložených barevnými grafy.