You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When installing a new raw NetBox docker instance, this enforces you to initially clone the repository, so docker can mount the paths mentioned above. When upgrading to a new container version, this results in, pulling the repository, and then restart the containers.
OK, someone could argue, why aren't you just overwrite the bind mounts in the docker-compose.overide.yml file ? Well, why should i ? Why should the person that does not need to make any modifications to any scripts or configurations, be forced to override the default behaviour of a software ?
Wouldn't it be better to switch this case. Let's say someone would like to extend the configuration/configuration.py with its own modifications ? So he could than clone the original configurations path, extend it and then copy it into the container with a bind mount in the docker-compose.override.yml file ?
Sure it would be better, to build a custom image, instead of a bind mount, but that's not the point now.
With scenario two, a raw native netbox docker deployment would not rely on local files, overwriting anything, it would be just configuration via environment and starting the compose stack.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently the bind mount in the
docker-compose.yml
file are fixed.IMO this is a very huge overhead, especially in the upgrade process.
The paths
startup_scripts
,initializers
,configuration
are already copied to the container image on build.netbox-docker/Dockerfile
Lines 73 to 75 in ebda466
When installing a new raw NetBox docker instance, this enforces you to initially clone the repository, so docker can mount the paths mentioned above. When upgrading to a new container version, this results in, pulling the repository, and then restart the containers.
OK, someone could argue, why aren't you just overwrite the bind mounts in the
docker-compose.overide.yml
file ? Well, why should i ? Why should the person that does not need to make any modifications to any scripts or configurations, be forced to override the default behaviour of a software ?Wouldn't it be better to switch this case. Let's say someone would like to extend the
configuration/configuration.py
with its own modifications ? So he could than clone the originalconfigurations
path, extend it and then copy it into the container with a bind mount in thedocker-compose.override.yml
file ?Sure it would be better, to build a custom image, instead of a bind mount, but that's not the point now.
With scenario two, a raw native netbox docker deployment would not rely on local files, overwriting anything, it would be just configuration via environment and starting the compose stack.
Beta Was this translation helpful? Give feedback.
All reactions