JON, MARTEN: cron bezi pod rootom, aj to echo som uz skusal :-/ skuste si to spustit, skutocne by mali stacit tie 2 subory. Subor z /etc/crontabs/root sa nalinkuje do /var/spool/cron, crontab -l vypise spravne nastavenie, len to proste neseje :)

# ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 crond -f -L /var/log/crond.log
    6 root      0:00 sh
   18 root      0:00 ps aux

MISO: zkusil bych misto nejakyho commandu jen echo "prdel" >> /date.txt
a problem muze byt v tom, ze cron nebude mit prava zapisu skoro nikam. Tak bych to daval do /pokus/date,txt a pripadne tomu /pokus menil prava.

DANIELSOFT: diky za tip, bohuzial to nepomohlo :-/ skor asi nahradim distro alpine za nieco ine

/ # crontab -l
* * * * * /bin/date >> /date.txt

DANIELSOFT: u cronu to někdy tak je, že nemá "dobře" nasetované některé proměnné prostředí, důvod jsem teď línej hledat (bezpečnost?)

MISO: možná date není v $PATH - co dát plnou cestu, např. /bin/date >> /foo.txt

Ahoj, prosim o nakopnutie. Kde robim chybu? Spustim docker-compose up, kontajner sa spusti, z /var/log/crond.log i ps aux je zrejme, ze crond bezi, akurat /foo.txt sa vobec nevytvori. Vopred dakujem za vas cas.

docker-compose.yml

version: '2'

services:

  cron:
      image: alpine:latest
      volumes:
          - ./etc/crontabs:/etc/crontabs
      command: crond -f -L /var/log/crond.log

/etc/crontabs/root

* * * * * date >> /foo.txt

ADM: jo srry, nezareagoval. Pak jsem si ráno uvědomil, že s RUN service crond start v Dockerfile není řešení;-) Tak jak říkáš to udělám. Prostě použiji ten postgres jako s image s vlastním CMD nebo entrypointem a tu zálehu provede.

RUDOLF: proto jsem se ptal jak spoustis v postresi imagi ten crond, protoze na to musis prece ten entrypoint nejak upravit ...
jinak my cron resili tak, ze byla jedna image (byla tam nejaka php aplikace, doinstaloval se cron, na entrypoint se nesahalo) a spustili jsme ze stejne image 2 sluzby, v docker compose nebo kubernetes je mozny externe predefinovat entrypoint, takze to php se spustilo normalne s default entrypointem z image a pro cron se jako entrypoint dalo spusteni crond

Nevím kam s tím, nejdřív jsem přemýšlel o cloud auditku ale nakonec sem.

Řeším, že bych rád použil AWS Fargate pro streamování z S3. Ale ještě jsem si to neošahal.

Hlavní trabl je, že necheme použít ALB ani jiný druh load balancingu, kvůli pricingu (půjde tím tuna GB)

Požadavek je:
- zákoš dostane https spojení s friendly hostname (naše.doména.com)

friendly hostname bych pořešil propagací fargate init/terminate eventu do SNS a lambda funkcí na úpravu route53.

Ale nevím, jak naložit s TLS. Naše obyklá kombinace na serverech je nginx-proxy+nginx-proxy-companion. Ale teď bych musel řešit Let's encrypt per task a mít tak v kontejneru ještě paralelní let's encrypt, což vypadá na tunu trablů.

ADM: jj, ale na ten entrypoint jsem nechtěl šahat.. Aby kdyby se změnil v uprestreamu, nemusel jsem ho u sebe pokaždé měnit..

cron cte taky /etc/environment (bud ten z debianu nebo apline, uz nevim), takze se da udelat na zacatku entrypointu printenv do toho souboru

RUDOLF: ale i klasickej cron ti skripty bude poustet s cistym envem. Ja si vzdycky zasourcuju soubor s promennejma pro cron pred behem.

RUDOLF: asi je čas jít spát, vůbec mi nedošlo že RUN service cron start mi cron nenastartuje;-) Ale postgres má nějaké inciační skripty, takže to bude v cajku;-) ale radši se na to vyspát..

srry za samomluvu..

RUDOLF: jo, fachá to.. udělat jsem ze secret shell script, kterej mi vyexportuje prostředí pro cron..

zase trochu trablík, jak jsou ty secrets immutable.. od compose 3.5 je větší flexibility v pojmenování secrets.. tak asi napíšu něco na porovní hashe secretu a přidám to do pipeline..

ADM: jo v tom image běží postgres + cron

not good, not bad;-)

RUDOLF: a jak spoustis crond v postgres:latest imagi? predpokladam ze v ni bezi postgres

RUDOLF: jo, tak vyreším to přes docker secret;-) jdu na to

češtík,

mám postgres image s shellovým scriptem, který prdá encryptovanej dump na s3, pouštím ho cronem. Ale nějak to nefachalo. Image je postavený na klasickým postgres:latest.

Došlo mi, že ten shell script potřebuje env proměné, které definuji runtime při spouštění docker image podle target prostředí.. tj. pokud se přihlásím přes docker exec, ty env jsou součástí shellu a skript pustím v pohodě.. ale ty env nejsou dostupné cron službě, když spouští ten skript, zdechne na nedefinovaných proměných..

Asi bych mohl trapně dumpnut ty proměné do nějakého souboru a upravit skript aby si je načetl, ale nechci přepisovat CMD ani ENTRYPOINT toho postgresového image, je tam nějaká logika z toho zdrojového image..

Asi na to jdu nějak špatně;-)

ADMIX: Slouží to pro spouštění SQL scriptů, kterými se "updatuje" databáze.
Příklad:
- jako vývojář u sebe na lokálu upravim databázi, např. přidám tabulku.
- Vytvořim soubor např. patch-1.0.5.sql v určitym adresáři, do kterýho dám ty CREATE TABLE příkazy
- Tento adresář s migračními scripty je součástí repozitáře
- Na ostrých serverech se pak při spuštění kontejneru spustí ten můj migrační script. Ten mrkne, jestli existují nové soubory patch-*.sql, které ještě nespustil. Pokud ano, tak spustí a ostrou DB tak uvede do aktuálního stavu.

Jako vývojáři totiž nemáme do ostré DB přístup. Navíc ty soubory s SQL jsou verzovány, takže je vidět kdo co udělal (podělal:) a řeší to i konflikty.