Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate init script from the start script #56

Merged
merged 1 commit into from
Feb 4, 2024

Conversation

dezeroku
Copy link
Contributor

@dezeroku dezeroku commented Jan 31, 2024

In k8s environments it's quite common to bootstrap the deployments following these steps:

  1. Initialize the environment using upstream container
  2. Apply local customizations with a script
  3. Run the upstream container "as usual"

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 the start.sh with two changes:

  1. removed the unnecessary backslash with a trailing space after then in line 30, as it was causing /start.sh: line 30: : not found warning/error
  2. wrapped echoed variable in double quotes in line 70

@antonym
Copy link
Member

antonym commented Feb 2, 2024

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.

@dezeroku
Copy link
Contributor Author

dezeroku commented Feb 2, 2024

Yes, overriding the entrypoint is basically the reason. With this split it's easy to automate:

  1. obtaining the config
  2. applying local changes
  3. starting the service

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:

  1. start the container (to obtain the configuration files)
  2. stop it manually
  3. modify the config file
  4. start it again (to serve the modified content).

With this PR merged you could automate this with a "middle-man" container, like so:.

  1. start the container with entrypoint /init.sh (to obtain the configuration files)
  2. modify the config file (e.g. with sed)
  3. start the container with default entrypoint (to serve the modified content)

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

@antonym antonym merged commit 8cb28ab into netbootxyz:master Feb 4, 2024
1 check passed
@dezeroku dezeroku deleted the to-upstream-two branch February 4, 2024 19:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants