forked from kamba4/sunders
update init #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
init should be in one container
two steps:
Added #5 for updating the compose file and the initial production push.
Feel free to ping me, once that Containerfile is ready!
5e12ac6b38
@ViMaSter this is the new Containerfile for the data_handler container (name is just what came up in my head, feel free to change it)
Moved to fedora, since the original php-cli image was too big (managed to go from 557 MB to 188 MB)
next step will be adding a crond (I'll probably use dcrond)
the init container now starts a dcrond in foreground and runs the update_camera.sh at 5 minutes past every hour.
The init_db.php is run on every start of the container. (since it wont change anything if the database is already on the current state)
next step: create sql files to be executed on start (with data from every diff in a separate file, so a simple diff apply can be executed)
Always a fan of saving resources, nice job!
Would you be okay with moving that image definition from your personal GitHub into this repository? That way Renovate can catch updates to the Fedora base image, plus everyone with an account on this instance can modify the image, if there's ever a need to in the future.
Alternatively, could we consider using
php:$version-alpine
? Those tend to be fairly compact and come with the BusyBox version of cron preinstalled, which should remove the need for us to build an extra image entirely.Data handler sounds great to me!
This might be out of scope for this issue (so feel free to create a new one for it, if you agree), but I'm wondering if it would make sense to move the Containerfiles into subdirectories:
Containerfile
only requires files inside/www
; if we move it there, it could justCOPY ./*
/utils
and/Containerfile.data_handler
intodata_handler
. Right now, we only ever need all utilities (initial data and the update loop) in one image.That way, each image is contained in its own subdirectory and only the overarching compose file resides at the root.
Awesome progress, really appreciate all the work that's gone into it so far! I'll hold off on rebasing #5 until you give the final go, to not make the changelist more difficult to review than it needs to be. : D
Based on what I can see, I would include the data handler like this; let me know if I'm missing anything:
(I'm also unsure if
web
should change fromdepends_on: ['db']
todepends_on: ['db', 'datahandler']
. I would argue that the website should only be ready once the data is properly initialized, but that would require the data handler to offer some kind of health check post initialization. Open to any opinions on it.)moving to sub directories sounds good to me.
I added the data_handler to the compose and the build job. Local (using podman-compose) it starts the containers in the order db (with a wait of 30s) -> data_handler -> web so the db is initialized once the web starts.