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.

SYNTAX_TERROR: Docela by me zajimalo co to vlastne dela, pac to zni jako zajimavej antipattern :D
No judging, nektery obskurni usecases proste jinak nejdou, jen me to zaujalo

SYNTAX_TERROR:
A jen si tu odložim řešení, třeba se bude někomu (mě v budoucnu) hodit:

Dockerfile

COPY ./docker-php-entrypoint /usr/local/bin/
ENTRYPOINT ["docker-php-entrypoint"]
CMD ["apache2-foreground"]

docker-php-entrypoint

#!/bin/bash

set -e

# first arg is `-f` or `--some-option`
if [ "${1#-}" != "$1" ]; then
	set -- php "$@"
fi

echo "Executing DB migration"
php /var/www/html/bin/db-migration.php
echo "Executed DB migration"

exec "$@"