update init #3

Open
opened 2025-10-11 20:42:23 +02:00 by asohh · 5 comments
Collaborator

init should be in one container

two steps:

  1. create db and user
  2. add data
init should be in one container two steps: 1. create db and user 2. add data
Collaborator

Added #5 for updating the compose file and the initial production push.

Feel free to ping me, once that Containerfile is ready!

Added #5 for updating the compose file and the initial production push. Feel free to ping me, once that Containerfile is ready!
Author
Collaborator

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)

https://git.hamburg.ccc.de/CCCHH/sunders/commit/5e12ac6b388c956997d827f7db7d162f6b464f99 @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)
Author
Collaborator

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)

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)
Collaborator

Moved to fedora, since the original php-cli image was too big (managed to go from 557 MB to 188 MB)

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.

this is the new Containerfile for the data_handler container (name is just what came up in my head, feel free to change it)

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:

  • The web Containerfile only requires files inside /www; if we move it there, it could just COPY ./*
  • The same would apply if we move the files inside /utils and /Containerfile.data_handler into data_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.

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)

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:

  datahandler:
    image: git.hamburg.ccc.de/ccchh/sunders/datahandler:latest
    environment:
      MYSQL_HOST: db
      MYSQL_DB: camera # ${{secrets.MYSQL_DATABASE}}
      MYSQL_USER: camera # ${{secrets.MYSQL_USER}}
      MYSQL_PASSWORD: camerapassword # ${{secrets.MYSQL_PASSWORD}}
    depends_on:
      - db

(I'm also unsure if web should change from depends_on: ['db'] to depends_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.)

> Moved to fedora, since the original php-cli image was too big (managed to go from 557 MB to 188 MB) 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. > this is the new Containerfile for the data_handler container (name is just what came up in my head, feel free to change it) 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: - The web `Containerfile` only requires files inside `/www`; if we move it there, it could just `COPY ./*` - The same would apply if we move the files inside `/utils` and `/Containerfile.data_handler` into `data_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. > 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) 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: ```yml datahandler: image: git.hamburg.ccc.de/ccchh/sunders/datahandler:latest environment: MYSQL_HOST: db MYSQL_DB: camera # ${{secrets.MYSQL_DATABASE}} MYSQL_USER: camera # ${{secrets.MYSQL_USER}} MYSQL_PASSWORD: camerapassword # ${{secrets.MYSQL_PASSWORD}} depends_on: - db ``` (I'm also unsure if `web` should change from `depends_on: ['db']` to `depends_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.)
Author
Collaborator

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.

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.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: CCCHH/sunders#3
No description provided.