Alpine Linux 3.14.0 aktualizuje řadu důležitých balíků

Už to konečně umí v Dockeru spouštět cron i jako ne-root? To je bod, ve kterém se zlomím a vracím pod Debian.

To mi pride ako poziadavka od stareho vlka - mat cron v kontajneri. Mladi hispteri pouziju napr. time scheduled tasks v Kubernetes, pripadne lenivi (tzv. opsless) pouziju infrastrukturu samotnu: napr. CloudWatch rules. Takze ziadne vyplakanie za starym cronom.

Staří vlci se netahají s kanónem na vrabce:-)

A hlavne načo v kontajneri viac ako jeden user? Veď už samotný kontajner je oddelený procesovy namespace, žiadne ďalšie delenie v kontajneri na viac užívateľov netreba, ak áno, tak to naštartuj v druhom kontajneri.

Co si představujete pod pojmem jeden user? Záznam v /etc/passwd?

Jeden aktivní uživatel totiž stačí, ale ne s uid 0. OpenShift například generuje náhodné uid pro každý kontejner.

Navíc, konkrétní uid má vliv na připojené adresáře (docker volumes) a schopnost čtení a psaní do nich.

To odporuje filozofii izolovaného a přenositelného kontejneru. Kontejner přenesete, nastavit host zapomenete, problém je na světě.

Jakej smysl má vytvářet další kontejner s úplně stejným prostředím, když stejný problém v Debianu vyřeším dvěma řádky a funguje to přesně jak potřebuju?

Tohle mi přišlo jako samozřejmost, ale po otestování mě zarazilo, že to opravdu nejde. Vada cronu?
Než se s tím zalamovat, nejjednodušším řešením je použití náhrady, třeba i vlastní.

Nemáte příklad? Zkoušel jsem různé obezličky přes další knihovny (některé se závislostma zvětší kontejner na dvojnásobek, což je přesně to, co nechci), ale vždy to shořelo na problémech s právy. Víc mé dovednosti nedovolují.

Uživatelský skript (i s logováním) se dá opakovaně spouštět v blbé bashové smyčce se sleep, ale protože nepíšete, co přesně potřebujete, tak není jasné, zda by vám takové řešení stačilo.

Je to Laravel, takže klasika. Každou minutu zapnout php artisan schedule:run >> /dev/null 2>&1. To by si šlo řešit tím způsobem, co popisujete.