search

azukaar / Cosmos-Server

ā˜ļø The Most Secure and Easy Selfhosted Home Server. Take control of your data and privacy without sacrificing security and stability (Authentication, anti-DDOS, anti-bot)
https://cosmos-cloud.io
Other
2.96k stars 105 forks source link

[BUG]: Updating Docker images (that uses a base image) seemingly doesn't update variables, when the base image does #246

Open engels74 opened 2 months ago

engels74 commented 2 months ago

What happened?

So there's this issue I had, specifically with the Docker images that hotio supplies.

He recently updated his base image, with a change to a Docker ENV/VAR, named S6_STAGE2_HOOK. It was changed from /init-hook to /etc/s6-overlay/init-hook.

When the images were updated in Cosmos-server, they didn't change the existing images environment variables to reflect this. They were left as /init-hook, which broke most of his images.

What should have happened?

The variable S6_STAGE2_HOOK should've been updated on the existing containers.

How to reproduce the bug?

  1. Download any hotio release older than this commit
  2. E.g. this radarr release here
  3. Run the container
  4. Check if the S6_STAGE2_HOOK has the value of /init-hook
  5. Update the container / Pull New Image
  6. Check Cosmos, and see that S6_STAGE2_HOOK is still set to /init-hook
  7. Check radarr logs, and see that everything has gone haywire (vpn/privoxy errors from the hook not working properly)
  8. Remove the var S6_STAGE2_HOOK manually through Cosmos
  9. Recreate the container
  10. The now-correct (updated) S6_STAGE2_HOOK will show up with /etc/s6-overlay/init-hook

Relevant log output

No response

Other details

The easy solution was to manually go into every Docker container through Cosmos, remove the S6_STAGE2_HOOK variable, press "Update Container" and let Cosmos recreate it, with the now-correct S6_STAGE2_HOOK variable.

I'm thinking this would be great if Cosmos would take this into account, when updating images. That being, when "base" images are updated, and if that somehow affects or changes existing containers variables. So that the user can use the auto update, and be sure knowing that Cosmos will update existing variables ;).

A simple GIF of how it was "solved" in Cosmos: https://i.imgur.com/hTJKwks.gif

I'm sure other users will end up having this problem, atleast if they use hotio's containers. I made a neat little simple bash script to detect what containers has the S6_STAGE2_HOOK variable set to /init-hook: https://logs.notifiarr.com/?37e0ff883c53d517=#8WuwvRSycAV4MzcMJJsDLDYtEtT48CmUbryiU6C8geUz

System details

azukaar commented 2 months ago

Thanks for the throughout ticket! Really appreciate it The main issue with this is that it's difficult to know what var the user has edited or not, the "overwriting" vars is normally a Docker thing (where you destroy the container, and re-create it without the var that the container has set in the first place), but because from the UI you update containers including the var the container has created, so Docker loses track of which one came from the container

engels74 commented 2 months ago

No problem šŸ˜

Portainer apparently has the same issue, according to the hotio discord. Is there anything to do about it? šŸ¤”

azukaar commented 2 months ago

Yeah I'd imagined so. Usually I try to fix even issues Portainer have in Cosmos, like this one : https://github.com/portainer/portainer/issues/2657

But for this, I am really not sure what to do tbh... I think dev should not do this kind of stuff in the first place honestly, env var are here to document a deployement's specific settings. if something is an env var it means we should be fully prepared for users to customize it in the first place, that does not look like it's even possible here because the value is then hardcoded in the RUN command

The only thing that could be done that i can see is, if the app was in the market, updating the env var inside the compose in the market woudl actually fix the container if you updated it from the market, basically