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

Support for custom commands upon entering container #1302

Open
josecastillolema opened this issue Jun 2, 2023 · 6 comments
Open

Support for custom commands upon entering container #1302

josecastillolema opened this issue Jun 2, 2023 · 6 comments
Labels
1. Feature request A request for a new feature

Comments

@josecastillolema
Copy link

josecastillolema commented Jun 2, 2023

Is your feature request related to a problem? Please describe.
Today, for running custom commands when entering a toolbox container the recommendations is to have a custom .bashrc entry, i.e.: toolbox.sh.
This makes the toolbox configuration split into two files, the Containerfile (i.e.: Containerfile) and the bash script ^.

Describe the solution you'd like
To follow best IaC/declarative practices, it would be better to have all the configuration related to the container in one place, the Containerfile. For that to happen, toolbox should support a way to place custom commands somewhere in the Containerfile (i.e. the RUN section).

@josecastillolema josecastillolema added the 1. Feature request A request for a new feature label Jun 2, 2023
@debarshiray
Copy link
Member

Hey, @josecastillolema ! I remember we discussed this before.

In this specific Containerfile there's:

# Initialize opam
RUN useradd $user
USER $user
RUN opam init --disable-sandboxing
RUN opam install -y dune merlin ocaml-lsp-server odoc ocamlformat utop dune-release

# Clean
USER root
RUN mkdir /usr/share/opam/
RUN cp -r /home/jose/.opam /usr/share/opam
RUN userdel -r jose
RUN dnf clean all \
    && rm -rf /var/cache/dnf
RUN echo "toolbox create -i localhost/ocaml:5 ocaml"

I remember you wanted ~/.opam inside the container. Isn't that already the case, because HOME is always bind mounted from the host? So everything inside HOME should be available inside the container.

@debarshiray
Copy link
Member

debarshiray commented Jun 28, 2023

I remember that you had mentioned offering a hook in the Containerfile to specify commands to be run inside the container.

I can think of two broad categories:

  • Commands that don't need to be run in the context of the current shell. eg., mkdir(1), ln(1), etc. like in your Containerfile.

These are likely necessary to be run only once when the container starts. The entry point can read these from the Containerfile hook and run them.

  • Commands that have side-effects that are only available to the current shell. eg., setting up environment variables and aliases like in your toolbox.sh.

These are likely necessary to be run on every invocation of toolbox enter and toolbox run, and will be trickier to implement with a Containerfile hook. It reminds me of my idea of a toolbox shell command. It would run inside the container between the podman exec and the final process inside the container that the user interacts with. It could then take care of reading the Containerfile hook.

All that makes me wonder if we need two separate Containerfile hooks to differentiate between those cases, and what those hooks might be. I am apprehensive of using CMD for this because there are images out there with unexpected things in CMD. eg., the fedora base images have CMD /bin/bash, which won't terminate on its own. I think we would need something explicitly specific to Toolbx.

@josecastillolema
Copy link
Author

Some custom annotation in the Dockerfile comments specific to toolbox could do the trick as well.

@secretmango

This comment was marked as resolved.

@bellegarde-c
Copy link

another feature supported by distrobox :D

distrobox-enter boxname -- command works normally, on toolbox it does nothing

toolbox run -c boxname command

@secretmango
Copy link

this means it should work right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. Feature request A request for a new feature
Projects
None yet
Development

No branches or pull requests

4 participants