Reader

Kaip deployint servisą be downtime?

Sako man – reikia servisą naujint, bet taip naujint, kad nebūtų prastovų (downtime). Pirmiausia reikia žinot, kad garantijų, kad niekada nieko nesugadinsi – nėra, tad 0% downtime (arba 100% uptime) nebūna – visada anksčiau ar vėliau pasibaigs bloguoju ir dar neaišku ar su restart nuo 0 ar kaip ten kitaip. Internetuose informacijos ir melo, kad galima vis tik taip padaryt pilna, bet angliškai. O ne visi anglų kalbą moka, o būna, kad ir moka, bet skaito ir nieko nesupranta. Tad čia pusiau versta, pusiau iš atminties, bet įkvėpus dūmo taiva taip gaunas:

• Padaryti taip, kad būtų profilaktinės valandos/dienos/savaitgaliai ir neskaičiuoti to laiko, kaip prastovos. Nesąmonė, rėkia programeris, taip negalima! Galima – šitas būdas labai dažnai naudojamas bankų. Jie sako – savaitgalį atsiskaitymas kortelėmis neveiks ir ką tu jiems, špyga taukuota. Garantuotai ten šitas neveikimas neįtraukiamas į probleminį ir ten naujina tą servisą naujina, kol ateina pirmadienis ir kažkas sutvarko viską ir paleidžia veikti. Ne kartą taip buvo ir ne kartą taip bus.
• Mėlynai/Žali atnaujinimai. Arba kitaip – blue/green. Kai išleidžiama nauja versija, ji paleidžiama green serveriuose, virtualiose mašinose ar tiesiog zonoje, o vartotojų ar kitoks kreipinių srautas palaipsniui nukreipimas, kad pažaliuotų. Mėlyna (senoji) versija aptarnauja vis mažiau ir mažiau užklausų, kol galų gale lieka tik kaip atsarginis variantas (ale atsukti atgal, jei šūdas gavos), išjungiama arba gali tarnauti kaip vieta būsimai žaliai zonai. Beje, tai gali būti ir vienas serveris, kuris teikia paslaugą iš skirtingų direktorijų. Aišku, vienas serveris gali bet kada nulūžti ir paslauga sustos, bet deploymentas tai visvien bus zero downtime :)
• Uždususios kanarėlės strategija (cannary) – apie pavadinimą galima sužinoti čia. Panašiu principu veikia ir pats serviso naujinimas – nauja versija paleidžiama serveriuose, į kuriuos srautas kreipiamas po truputį ir stebima situacija: žurnalai (logs), metrikos, galbūt vartotojų nusiskundimai; nustatoma kažkokia tolerancijos riba (klaidų retai kada pavyksta išvengti) ir neskubant vis daugiau vartotojų naudoja naują versiją. Jei pasiekta klaidų riba ar koks kitoks kriterijus – galima lengvai srautą kreipti atgal į seną versiją ir sutvarkyt problemas. Dažniausiai kanarėles naudoja daug vartotojų turinčios įmonės, kur pakeitimai gali iššaukti sniego lavinos efektą. Dar vienas privalumas – kad lengva ištestuoti fyčerius – t.y., pasinaudoja ne tik technologai, bet ir marketingistai. Turbūt teko laukti kokios nors naujienos, kuri paleista Amerikėj, bet nėra dar Lietuvoj – tai va, stebi, ar kanarėlės dūsta, ar ne.
• Šešėlių valdovo strategija – nauja sistema pastatoma kartu su sena, bet srauto leidžiama tik kopija ir vartotojai nemato rezultato. Stebimi žurnalai, metrikos, bandoma įvertinti ar viskas veikia gerai. Čia toks panašesnis į testavimą su realiais vartotojais, bet klaidos nuo jų paslėptos. Kai jau manoma, kad nauja sistema veikia gerai – virsta į mėlynai pažaliavusį deploymentą. Šiaip, šitas būdas yra ganėtinai sudėtingas, galima sugadinti duomenis ar turėtų jų suvienodinimo problemų.

Yra ir dar keletas strategijų, kurios vienaip ar kitaip panašios į išvardintas. Čia parašiau šiek tiek apie srauto ir vartotojų perkėlimą, bet ką daryt su duomenų bazių migracijom (schemų pakeitimais)? Į vieną pusę tai aišku – pridėjai stulpą ir lauki, kol suvažiuos. Egzistuoja visokių įrankių, kad tos migracijos neblokuotų. Pridėti visada lengviau negu atimti, o atgal atsukti, jei kas nors nepavyko – sunkiau. Tai dažnai duomenų bazės auga, turi visokių šiukšlių, schemos neoptimizuojamos, kažkaip traška braška, kol neprireikia padaryt offline profilaktikos. Turbūt viena iš priežasčių, kodėl NoSQL ir panašios duomenų bazės mėgstamos – jos yra laisvesnės schemos ir pakeitimus galima daryt be migracijų. Yra ir naudojančių SQL variklį su duomenų bazių schemom, kurios neatspindi SQL fengshui. Prišikt, prišikt ir palikt.

Visa tai lengviau, jei yra aiškios procedūros, kurias galima automatizuoti. Automatika gerai tuo, kad, jei daro klaidas, tai paprastai tas pačias – Operatoriaus rezultatai būna mažiau nuspėjami (dar jų būna ne vienas ir skirtingo lygio/žinių apie sistemas). Galim tarti, kad bet kokios programinės įrangos naujos versijos paleidime norisi kuo mažiau neapibrėžtumo, aiškumo ir iš anksto suplanuotų procedūrų, ką daryti, jei kas nors nepavyko. Na, o kaip tai sekasi – pasidalinkit. Vieni nešioja marškinėlius su užrašu “mes leidžiam naujas versijas penktadieniais”, kaip garbės ženklą, o kiti iš tolo vengia kompanijų, kuriose dirba tokie žmonės.

Lengvo darbo!

Caddyfile for running Lemmy

How to follow Lemmy community from Mastodon

Spent a couple of hours.. wanted to follow a Lemmy community from group.lt instance on Mastodon. Here is a working config for Caddy (Caddyfile):

group.lt {
	reverse_proxy	http://lemmy_lemmy-ui_1:1234
        tls saint@ghost.lt {
}

@lemmy {
        path    /api/*
        path    /pictrs/*
        path    /feeds/*
        path    /nodeinfo/*
        path    /.well-known/*
}

@lemmy-hdr {
	header Accept application/*
}

@lemmy-post {
	method POST
}

handle @lemmy {
        reverse_proxy   http://lemmy_lemmy_1:8536
}

handle @lemmy-hdr {
        reverse_proxy   http://lemmy_lemmy_1:8536
}

handle @lemmy-post {
        reverse_proxy   http://lemmy_lemmy_1:8536
}

The key point here was

@lemmy-hdr {
	header Accept application/*
}

I have taken a hint from lemmy.coupou.fr

and from some nginx conf for lemmy

Reclaiming space in synapse postgresql database

Follow the fat elephant

I have received an alert from Grafana – that my synapse directory is almost full, which was kinda strange as I have given 100GB partition to it just a couple of weeks ago.. So I have put a hat, picked up some cider and something to smoke and went to the adventure.

From the old times I knew that postgresql database size can be reduced using vacuumdb. Entered the container and boom – after 15 or so minutes it has finished and reclaimed 100MB of space.. Hmmm... Interesting – which table eats the space. Google, link

SELECT
    relname AS "relation",
    pg_size_pretty (
        pg_total_relation_size (C .oid)
    ) AS "total_size"
FROM
    pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C .relnamespace)
WHERE
    nspname NOT IN (
        'pg_catalog',
        'information_schema'
    )
AND C .relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY
    pg_total_relation_size (C .oid) DESC
LIMIT 5;

 relation      | total_size
--------------------+------------
 state_groups_state | 65 GB
 event_json         | 1197 MB
 event_edges        | 619 MB
 events             | 595 MB
 event_auth         | 528 MB

Alright!!! Google: stategroupsstate, link and found a compression tool.

git clone, crap a short docker-compose.yml and build the tool.

root@instance-20211112-2005:/opt/synapse-compress-state# cat docker-compose.yaml
---
version: "3.5"
services:
  synapse-compress:
      build:
        context: rust-synapse-compress-state/
      command: synapse_auto_compressor -p postgresql://user:pass@dbhost/dbname -c 500 -n 100
      networks:
          - synapse

networks:
        synapse:
                name: synapse

let's crap some more:

root@instance-20211112-2005:/opt/synapse# cat /opt/synapse-compress-state/run.sh
#!/bin/bash

cd /opt/synapse-compress-state/

docker-compose up

put it into crontab:

@daily /opt/synapse-compress-state/run.sh > /dev/null

later googled more and found some smarter people than me: shrink synapse database and that really helped, especially reindexing.

How to send mail using php mail() function in docker way

Using ssmtp to send email to the relay container

Sometimes we want to run dockerized old php site that we do not want to work with, or a programmer is gone and nobody cares to make changes to use email relay host, such as mailgun or gmail or anything else. In the Linux VM or bare metal server it is quite easy task – you run web server and mail server two in one and mail server takes care of mail routing.

In the dockerized environment usually you want to run the least amount of services possible in the container, so sending mail using PHP's mail() function becomes a tricky.

Let's create a docker-compose.yml file, containing all required containers:

caddy – web server

php – php server for the app – the trick here to use msmtp as a sendmail to have mail sent to remote server (our mail container)

mail – smtp relay server, we will use postfix

the source code is here: docker-php-mail-example

the main thing is to use ssmtp on the php container and send data to mail container

enjoy!

Getting rid of * WARNING ** Mnesia is overloaded: {dumplog, timethreshold}

On high load environment, we had a message in RabbitMQ logs every second or so:

* WARNING ** Mnesia is overloaded: {dump_log, time_threshold}

Internet said that it is nothing to worry about for everybody, who has asked on how to change it, but I still wanted to get rid of the noise. After playing with RabbitMQ installation, I have found where to put config changes:

/etc/rabbitmq/rabbitmq-env.conf

there you have to put 

SERVER_ADDITIONAL_ERL_ARGS="-mnesia dump_log_write_threshold XXXXX -mnesia dc_dump_limit YY"

Where XXXXX and YY numbers, that work for your environment.

Here is the best explanation on what it is... just kidding.

More breadcrumbs here and you can find a reply and a comment of somebody that understood the assignment.