Runlike: Given an existing Docker container, prints the command line to run it(github.com)
github.com
Runlike: Given an existing Docker container, prints the command line to run it
https://github.com/lavie/runlike
43 comments
I feel like this is something that should be in docker itself. I hope that this list gets a lot smaller:
https://github.com/lavie/runlike#not-yet-supported-run-optio...
https://github.com/lavie/runlike#not-yet-supported-run-optio...
This is really cool. I wondered if there was anything like this for generating docker-compose files, and it turns out there is: https://github.com/Red5d/docker-autocompose
This seems like a nice alternative in some way to me.
I never run docker commands by itself unless it’s really simple. Simply whip up a docker compose file and aliasing compose works pretty well for me.
I never run docker commands by itself unless it’s really simple. Simply whip up a docker compose file and aliasing compose works pretty well for me.
This looks great. I typically type my run commands into a script and run that, so they are reproducible, but this looks like a nice way to capture one that you ran temporarily but that worked well.
As an aside, the way Python code works feels really weird to me (even though I’ve done a bit of python). In particular, I find env to be odd. In this case you already need python installed (using pip to install this) or you need to run it as a container (which may or may not have significant overhead depending on how it was built). I’d suggest a compiled binary installed via a package manager for a command line tool. Had it been that, I may not have noticed.
I’m curious if other HN readers feel differently?
As an aside, the way Python code works feels really weird to me (even though I’ve done a bit of python). In particular, I find env to be odd. In this case you already need python installed (using pip to install this) or you need to run it as a container (which may or may not have significant overhead depending on how it was built). I’d suggest a compiled binary installed via a package manager for a command line tool. Had it been that, I may not have noticed.
I’m curious if other HN readers feel differently?
Not sure I understand the complaint, honestly. If it was a bash script instead of a python script it would still be weird for it to be packaged using like 6+ different package formats for all those different distributions.
Personally I'd be inclined to install it via pipx.
Personally I'd be inclined to install it via pipx.
> or you need to run it as a container (which may or may not have significant overhead depending on how it was built)
What overhead are you referring to? It runs, prints the cmdline and exits.
What overhead are you referring to? It runs, prints the cmdline and exits.
I’m talking about the base image overhead. Honestly, I hadn't tried it on this tool. As an example, if the container was using Ubuntu as a base, you might fetch a big base image. If it’s using scratch, no problem. So, it depends on how it’s built and I didn’t dig in.
Edit: I’ve gone back and looked at the dockerfile. The base image is Ubuntu, so the docker image is heavy. I fetched the indicated image from Dockerhub and it's 228.13 MB. Most of the command line tools in my toolbox are measured in K not in hundreds of MB.
Edit: I’ve gone back and looked at the dockerfile. The base image is Ubuntu, so the docker image is heavy. I fetched the indicated image from Dockerhub and it's 228.13 MB. Most of the command line tools in my toolbox are measured in K not in hundreds of MB.
Running it as a docker container is pretty okay.
If it would be a website where I paste the docker inspect output that would be the best.
If it would be a website where I paste the docker inspect output that would be the best.
Almost all of my containers have environment variables I don't wish to provide to random websites.
Those shouldn’t be in a container, but provided by docker environment.
A very handy tool I have reached for often. Will optionally emit docker-compose yaml. Great for sharing details with others. K8S has something similar with kubectl get deployment,service,pod myApp -o yaml
That's pretty cool. I can image this becoming an OCI manifest of sorts, that defines the requirements of a container, so that it can be fed to an OCI-compliant tool to run the container. Basically the same as a k8s manifest, but simpler. Give it an extension and have people download the file and execute it, and it executes the container. You'd never have to manually download, make executable, and execute a binary, ever again.
This is the way systems should be more generally: visible, modular, redeployable.
That is nice. I am writing my own docker with blackjack and … https://github.com/ihucos/plash
Wow, this really is the best thing since sliced bread!
I am still waiting for `docker upgrade my-container my-image:latest`.
How would this work? I'm guessing that the container would keep the same options as it was started with (entrypoint, command, port mappings, networks, volumes, environment variables, etc.) but be restarted using a new base image.
The devil is in the details, though. What do you do with files that were created in the container but aren't part of the a volume? A simple solution would be to throw them all away and start fresh, but then the "upgrade" command would only be able to work correctly for a subset of containers where throwing away previous files would be OK. If that were the case, I think "replace" would be a better command name than "upgrade" since you're effectively, if not literally, replacing the container.
Any other approach where you keep the files in from the old container files would lead to all sorts of corner cases or odd behavior. What if the upgraded image has moved where files are stored? What if the upgraded image's configuration is incompatible with the previous image's version?
The devil is in the details, though. What do you do with files that were created in the container but aren't part of the a volume? A simple solution would be to throw them all away and start fresh, but then the "upgrade" command would only be able to work correctly for a subset of containers where throwing away previous files would be OK. If that were the case, I think "replace" would be a better command name than "upgrade" since you're effectively, if not literally, replacing the container.
Any other approach where you keep the files in from the old container files would lead to all sorts of corner cases or odd behavior. What if the upgraded image has moved where files are stored? What if the upgraded image's configuration is incompatible with the previous image's version?
I feel that users understand well that files outside of volumes are basically temp files. Those who don't end up learning it the hard way at some point. This is why I think that pulling the image, stopping the container and starting a new one with the same parameters would be the right thing to do.
It is very easy to do manually unless the command to start the container is lost, at that point a tool like the one being discussed becomes handy.
It is very easy to do manually unless the command to start the container is lost, at that point a tool like the one being discussed becomes handy.
docker compose up -d --pull
Why is it so much manual work to turn Docker runs/Containers into Kubernetes yaml anyway? Or is that only me.
I find the fact that you can run this without installing by using docker, I immediately though of running runlike with runlike
runlike -p runlike
This looks like a pretty neat tool, but when I'm spinning anything up non-trivial I usually just write docker-compose files so I'm not sure what use case I would have for it personally.
runlike -p runlike
This looks like a pretty neat tool, but when I'm spinning anything up non-trivial I usually just write docker-compose files so I'm not sure what use case I would have for it personally.
Same... but I've seen enough people just run stuff via cli when starting, and/or worse would be inheriting a running server, where you don't have the bash history of the user who created the thing. Worse still, is if there are many attempts in the history with different params...
I try to use at least docker-compose.yaml for nearly everything. This is a nice tool for other times, without the hassle of other options.
I try to use at least docker-compose.yaml for nearly everything. This is a nice tool for other times, without the hassle of other options.
Issue for podman support: https://github.com/lavie/runlike/issues/71
Podman has ˋgenerate systemdˋ which creates unit files that include the command.
Why this is needed when we can easily compose with docker compose
But what if the person who started the container didn't use docker-compose? Sure, it's nice to run your stuff in documented, reproducible ways - but if you find yourself inheriting a server and wondering how a container was started, this seems like a nice easy way to try to reverse engineer how to use that container. I've been in that situation before and was shocked that Docker didn't include that functionality to begin with.
> But what if the person who started the container didn't use docker-compose?
There's your shell history, combined with fzf this helps recall previously run commands. You can search for something like "docker redis" and find it in a few key strokes.
If the container got spawned by something else then I think that's reaching for "beyond-the-edge" edge cases. I've been using Docker since 2014 and worked with dozens of companies (contract work) related to using Docker and this scenario has happened 0 times where I wanted to be able to replicate the flags used to spawn a container but couldn't find the command. Nearly every container is spawned from using Docker Compose or it exists in your shell's history.
There's your shell history, combined with fzf this helps recall previously run commands. You can search for something like "docker redis" and find it in a few key strokes.
If the container got spawned by something else then I think that's reaching for "beyond-the-edge" edge cases. I've been using Docker since 2014 and worked with dozens of companies (contract work) related to using Docker and this scenario has happened 0 times where I wanted to be able to replicate the flags used to spawn a container but couldn't find the command. Nearly every container is spawned from using Docker Compose or it exists in your shell's history.
I hear ya. I've also been using Docker for years and have encountered this scenario: Now-retired Cowboy Coder "got things working" using vanilla "docker run" commands before he departed but didn't document it or script it, now I need to figure out what he did to firstly understand it, and secondly extend it. I don't have his bash history, I just have the running container. I get it if you can't conceive of a use for this but apparently at least a couple of us think it could occasionally be useful.
I’ve run into this several times in my current role. The people who came before me fucked up command history really badly (they were trying to have per-user, per-connection logging, and didn’t know how to do that properly), so a good deal of commands used to spawn containers have been lost over here.
I agree you should never be in this situation (this place is an absolute nightmare), but here I am!
I agree you should never be in this situation (this place is an absolute nightmare), but here I am!
Do you have any good resources on how to manage this?
I've run into similar history management problems with `screen`.
I've run into similar history management problems with `screen`.
For bash, and maybe zsh, I use this in a profile.d script to log history output.
I suppose adding `readonly PROMPT_COMMAND` would be a good idea so no one overwrites it, but most people wouldn’t even think to look for it.
I don’t think this would do much for handling screen history, though.
HISTTIMEFORMAT=“%F %T $(logname) $(pwd) “
if [ ! -d $HOME/.history ]
then mkdir -p $HOME/.history
fi
PROMPT_COMMAND=‘echo “$(history 1)” >> $HOME/.history/$(date “+%F”)I suppose adding `readonly PROMPT_COMMAND` would be a good idea so no one overwrites it, but most people wouldn’t even think to look for it.
I don’t think this would do much for handling screen history, though.
resh is my favorite
https://github.com/curusarn/resh
resh is my favorite
[deleted]
i see this as more of 'quick and dirty' type approach, which there is often still value in
No more docker devcontainer inside another docker devcontainer !
It's quite cool, I don't run with docker run that often so might get involved to let it give the yaml to make it run through ansible
This is pretty neat!
[deleted]
ㄷㄷㄷ
I tried to persuade the docker maintainers that this was a good idea at some point, but the issue got closed in the end.
https://gist.github.com/efrecon/8ce9c75d518b6eb863f667442d7b...