[HN Gopher] Runlike: Given an existing Docker container, prints ...
___________________________________________________________________
Runlike: Given an existing Docker container, prints the command
line to run it
Author : thunderbong
Score : 171 points
Date : 2023-01-20 09:51 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| codazoda wrote:
| 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?
| moondev wrote:
| > 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.
| codazoda wrote:
| 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.
| pas wrote:
| 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.
| sneak wrote:
| Almost all of my containers have environment variables I
| don't wish to provide to random websites.
| eurasiantiger wrote:
| Those shouldn't be in a container, but provided by docker
| environment.
| traverseda wrote:
| 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.
| ujtrruijt wrote:
| ddd
| wwarner wrote:
| 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
| mdaniel wrote:
| > error: unknown flag: --export
|
| that flag went away quite a while ago, I'd guess somewhere in
| the 1.20 versions
| wwarner wrote:
| thank you fixed
| lnxg33k1 wrote:
| 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
| jpeeler wrote:
| 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...
| nunez wrote:
| This is pretty neat!
| czx4f4bd wrote:
| 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
| [deleted]
| 0xbadcafebee wrote:
| 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.
| XiS wrote:
| Wow, this really is the best thing since sliced bread!
| nicolaslem wrote:
| I am still waiting for `docker upgrade my-container my-
| image:latest`.
| _ikke_ wrote:
| docker compose up -d --pull
| justin_oaks wrote:
| 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?
| nicolaslem wrote:
| 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.
| DelightOne wrote:
| Why is it so much manual work to turn Docker runs/Containers into
| Kubernetes yaml anyway? Or is that only me.
| benatkin wrote:
| Issue for podman support:
| https://github.com/lavie/runlike/issues/71
| api wrote:
| This is the way systems should be more generally: visible,
| modular, redeployable.
| efrecon wrote:
| I offer you all this one instead. There is a one liner to use it
| in the comments. It is a template to the docker inspect command.
| So the only thing you need to download is the template itself.
|
| 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...
| rubyist5eva wrote:
| 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.
| tracker1 wrote:
| 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.
| jesse_faden wrote:
| 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.
| ihucos wrote:
| That is nice. I am writing my own docker with blackjack and ...
| https://github.com/ihucos/plash
| v3ss0n wrote:
| Why this is needed when we can easily compose with docker compose
| conroydave wrote:
| i see this as more of 'quick and dirty' type approach, which
| there is often still value in
| radpanda wrote:
| 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.
| nickjj wrote:
| > 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.
| j33zusjuice wrote:
| 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!
| jmholla wrote:
| Do you have any good resources on how to manage this?
|
| I've run into similar history management problems with
| `screen`.
| j33zusjuice wrote:
| For bash, and maybe zsh, I use this in a profile.d script
| to log history output. HISTTIMEFORMAT="%F
| %T $(logname) $(pwd) " if [ ! -d
| $HOME/.history ] then mkdir -p $HOME/.history
| fi PROMPT_COMMAND='echo "$(history 1)" >>
| $HOME/.history/$(date "+%F")
|
| fi export PROMPT_COMMAND
|
| 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.
| [deleted]
| radpanda wrote:
| 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.
| revskill wrote:
| No more docker devcontainer inside another docker devcontainer !
___________________________________________________________________
(page generated 2023-01-20 23:01 UTC)