4 ms·

I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes. I haven't t

by jve 1y ago

I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes. I haven't tried this stuff, but maybe this is something in that direction.

matsemann 1y ago
I do that for a lot of stuff. Got a bit annoyed with internal tools that was so difficult to set up (needed this exact version of global python, expected this and that to be in the path, constantly needed to be updated and then stuff broke again). So I built a docker image instead where everything is managed, and when I need to update or change stuff I can do it from a clean slate without affecting anything else on my computer. To use it, it's basically just scripts loaded into my shell. So if I do "toolname command args" it will spin up the container, mount the current folder and some config folders some tools expect, forward some ports, then pass the command and args to the container which runs them. 99% of the time it works smooth. The annoying part is if some tool depends on some other tool on the host machine. Like for instance it wants to do some git stuff. I will then have to have git installed and my keys copied in as well for instance.
- rzzzt 1y ago
  CoreOS had a toolbox container that worked similarly to the one you have (the Podman people took over its maintenance): https://github.com/containers/toolbox https://github.com/containers/toolbox
- endofreach 1y ago
  > my keys copied in as well for instance. Tip: you could also forward your ssh agent. I remember it was a bit of a pain in the ass on macos and a windows WSL2 setup, but likely worth it for your setup.
lelanthran 1y ago
> I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes I don't understand this requirement/specification; presumably this use-case will not be satisfied by a shell script, but I don't see how. What are you wanting from this use-case that can't be done with a shell script?
- lazide 1y ago
  Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them.
  - lelanthran 1y ago
    > Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them. How's "packing" cli commands into a shell script any different from "packing" CLI commands into a container?
    - lazide 1y ago
      Calling a container on the CLI is a pain in the ass. People generally don’t put stuff that works in whatever environment you’re in on the CLI already into contains. Stuff that doesn’t, of course they do. Having a convenient shell script wrapper to make that not a pain in the ass, while letting all the environment management stuff still work correctly in a container is convenient. Writing said wrapper each time, however is a pain in the ass. Generating one, makes it not such a pain in the ass to use. So then you get convenient CLI usage of something that needs a container to not be a pain in the ass to install/use.
- james_marks 1y ago
  An icon a non-technical user can click to run it.
  - cmeacham98 1y ago
    A non-technical user that has docker installed?

by jve 1y ago

matsemann 1y ago

I do that for a lot of stuff. Got a bit annoyed with internal tools that was so difficult to set up (needed this exact version of global python, expected this and that to be in the path, constantly needed to be updated and then stuff broke again). So I built a docker image instead where everything is managed, and when I need to update or change stuff I can do it from a clean slate without affecting anything else on my computer. To use it, it's basically just scripts loaded into my shell. So if I do "toolname command args" it will spin up the container, mount the current folder and some config folders some tools expect, forward some ports, then pass the command and args to the container which runs them. 99% of the time it works smooth. The annoying part is if some tool depends on some other tool on the host machine. Like for instance it wants to do some git stuff. I will then have to have git installed and my keys copied in as well for instance.

rzzzt 1y ago
CoreOS had a toolbox container that worked similarly to the one you have (the Podman people took over its maintenance): https://github.com/containers/toolbox https://github.com/containers/toolbox
endofreach 1y ago
> my keys copied in as well for instance. Tip: you could also forward your ssh agent. I remember it was a bit of a pain in the ass on macos and a windows WSL2 setup, but likely worth it for your setup.

lelanthran 1y ago

> I see a use case. The other day I wished that I could pack CLI commands as docker containers and execute them as CLI commands and get return codes I don't understand this requirement/specification; presumably this use-case will not be satisfied by a shell script, but I don't see how. What are you wanting from this use-case that can't be done with a shell script?

lazide 1y ago
Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them.
- lelanthran 1y ago
  > Presumably, they don’t want to write/maintain a shell script wrapper for every time they want to do this, when they could use a tool which does it for them. How's "packing" cli commands into a shell script any different from "packing" CLI commands into a container?
  - lazide 1y ago
    Calling a container on the CLI is a pain in the ass. People generally don’t put stuff that works in whatever environment you’re in on the CLI already into contains. Stuff that doesn’t, of course they do. Having a convenient shell script wrapper to make that not a pain in the ass, while letting all the environment management stuff still work correctly in a container is convenient. Writing said wrapper each time, however is a pain in the ass. Generating one, makes it not such a pain in the ass to use. So then you get convenient CLI usage of something that needs a container to not be a pain in the ass to install/use.
james_marks 1y ago
An icon a non-technical user can click to run it.
- cmeacham98 1y ago
  A non-technical user that has docker installed?