When I started docker images, they reached 2 gb. Now there’s no limit to image size unless it becomes impossible to push and pull image. Even if they do “apps” now it’s still one big fat database and combined codebases that gets added and deployed. More and more apps will be added, that’ll only make the image sizes big.
Yeah you’re right, I tried with the base image and the size is reduced, I must have something wrong in my custom image.
This has messed up your assets.json in sites volume. You’ll have to reset that file and related dist files. Then try again. Just clearing redis cache for that specific key is the real workaround, Crashing frontend - #2 by revant_one
I’ll try to check it, thanks!
Not really, 2 years ago I asked someone from core team why we’ve to keep secrets like db password credential and encryption key in json that is mutable? Answer is, some have environment variables, others we’ve to send PR.
Is the site_config.json and common_site_config.json the only dependencies for removing the shared volume? Couldn’t an init script on the pod that sets all configs solve that issue? I see that frappe also has used or is using file locks on the sites folder, has that been completely replaced in favor of redis locks?
I do know people who use frappe alpine bare images under vpn with all forked hacks as a trade off. You can even decouple images, yet you’ll be stuck with same thing, it only benefits at some degree if you’re ready for a fork.
In short, if you need upstream frappe, you will be stuck with legacy that is made to work for modern systems.
Note: whoever from core team who does containers, kubernetes will leave! No one will be there for longer periods who will maintain or suggest container best practices.
I understand, I guess my suggestion to the Frappe team is to change the frappe deployment to a container-first mentality. I think it would make the products more attractive to large companies and developers.