Closed dezeroku closed 6 months ago
What's the benefit in splitting up the file? Is that so the entry point can be overridden? I'm open to the change, would just like to understand it better.
Yes, overriding the entrypoint is basically the reason. With this split it's easy to automate:
For example, let's say that you want to use a local mirror by setting the live_endpoint
entry. Currently to achieve it you have to:
With this PR merged you could automate this with a "middle-man" container, like so:.
/init.sh
(to obtain the configuration files)sed
)An example docker-compose
file using this scheme would look like that:
---
version: "2.1"
services:
netbootxyz-init:
image: ghcr.io/netbootxyz/netbootxyz
environment:
- MENU_VERSION=2.0.47
volumes:
- ./config:/config
- ./assets:/assets
command: /init.sh
netbootxyz-customisations:
image: busybox
volumes:
- ./config:/config
command: sed 's#set live_endpoint.*#set live_endpoint http://my-custom-endpoint#' -i /config/menus/remote/boot.cfg
depends_on:
netbootxyz-init:
condition: service_completed_successfully
netbootxyz:
image: ghcr.io/netbootxyz/netbootxyz
container_name: netbootxyz
environment:
- NGINX_PORT=80
volumes:
- ./config:/config
- ./assets:/assets
ports:
- 3000:3000
- 69:69/udp
- 8080:80
restart: unless-stopped
depends_on:
netbootxyz-customisations:
condition: service_completed_successfully
In k8s environments it's quite common to bootstrap the deployments following these steps:
Currently there's no easy way to perform the initial configuration without starting the main processes, this PR separates "init" and "run" parts.
The
init.sh
file is basically copied as-is from thestart.sh
with two changes:then
in line 30, as it was causing/start.sh: line 30: : not found
warning/error