Skip to content(if available)orjump to list(if available)

docker2exe: Convert a Docker image to an executable

Epskampie

> Requirements on the executing device: Docker is required.

arjvik

Good friend built dockerc[1] which doesn't have this limitation!

[1]: https://github.com/NilsIrl/dockerc

hnuser123456

That screenshot in the readme is hilarious. Nice project.

vinceguidry

Looks like MacOS and Windows support is still being worked on.

dheera

But will this run inside another docker container?

I normally hate things shipped as containers because I often want to use it inside a docker container and docker-in-docker just seems like a messy waste of resources.

vinceguidry

Docker in Docker is not a waste of resources, they just make the same container runtime the container is running on available to it. Really a better solution than a control plane like Kubernetes.

rcfox

Doesn't podman get around a lot of those issues?

harha_

Yeah, it feels like nothing but a little trick. Why would anyone want to actually use this? The exe simply calls docker, it can embed an image into the exe but even then it first calls docker to load the embedded image.

jve

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.

lelanthran

> 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?

matsemann

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.

johncs

Basically the same as Python’s zipapps which have some niche use cases.

Before zipapp came out I built superzippy to do it. Needed to distribute some python tooling to users in a university where everyone was running Linux in lab computers. Worked perfectly for it.

j45

Could be ease of use for end users who don't docker.

worldsayshi

But now you have two problems.

alumic

I was so blown away by the title and equally disappointed to discover this line.

Pack it in, guys. No magic today.

stingraycharles

Thank god there’s still this project that can build single executables that work on multiple OS’es, I’m still amazed by that level of magic.

cozyman

[flagged]

drawfloat

Is there any alternative way of achieving a similar goal (shipping a container to non technical customers that they can run as if it were an application)?

mrbluecoat

See the dockerc comment above

regularfry

It feels like there ought to be a way to wrap a UML kernel build with a container image. Never seen it done, but I can't think of an obvious reason why it wouldn't work.

Hamuko

I feel like it's much easier to send a docker run snippet than an executable binary to my Docker-using friends. I usually try to include an example `docker run` and/or Docker Compose snippet in my projects too.

null

[deleted]

dennydai

Just use shebang

https://news.ycombinator.com/item?id=38987109

#!/usr/bin/env -S bash -c "docker run -p 8080:8080 -it --rm \$(docker build --progress plain -f \$0 . 2>&1 | tee /dev/stderr | grep -oP 'sha256:[0-9a-f]*')"

cess11

That's bat guano insane, but I still like it more than TFA.

renewiltord

It's not that crazy. Another fun use is with a `uv run` shebang https://news.ycombinator.com/item?id=42855258

rullopat

It's great for sending your 6 GB hello world exe to your friends I suppose

xandrius

The beauty of docker is that it is a reflection of how much someone cares about deployments: do you care about being efficient? You can use `scratch` or `X-alpine`. Do you simply not care and just want things to work? Always go for `ubuntu` and you're good to go!

You can have a full and extensive api backend in golang, having a total image size of 5-6MB.

hereonout2

I've done both, tiny scratch based images with a single go binary to full fat ubuntu based things.

What is killing me at the moment is deploying Docker based AI applications.

The CUDA base images come in at several GB to start with, then typically a whole host of python dependencies will be added with things like pytorch adding almost a GB of binaries.

Typically the application code is tiny as it's usually just python, but then you have the ML model itself. These can be many GB too, so you need to decide whether to add it to the image or mount it as a volume, regardless it needs to make it's way onto the deployment target.

I'm currently delivering double digit GB docker images to different parts of my organisation which raises eyebrows. I'm not sure a way around it though, it's less a docker problem and more an AI / CUDA issue.

Docker fits current workflows but I can't help feeling having custom VM images for this type of thing would be more efficient.

kevmo314

PyTorch essentially landed on the same bundling CUDA solution, so you're at least in good company.

anthk

Golang should not need docker. It's statically built.

hereonout2

Docker / containers are more than just that though. Using it allows your golang process to be isolated and integrated into the rest of your tooling, deployment pipelines, etc.

nine_k

Tired: docker run.

Wired: docker2exe.

Inspired: AppImage.

(I'll show myself out.)

rietta

I remember thinking that the Visual Basic runtime was unacceptable bloat overhead and now this. Cool work though. Also reminds me of self extracting WinZip files.

sitkack

At some point in the future we will be nostalgic for the monstrosities of the present.

kkapelon

This is just a simpler wrapper over the docker executable that you need to have installed anyway.

cik

It sounds like docker export and makeself combined. We already ship to select customers prebuilt containers exactly this way.

fifilura

Docker is mostly backend, but I wonder how far we are from universally executable native applications?

I.e. download this linux/mac/windows application to your windows/linux/mac computer.

Double-click to run.

Seems like all bits and pieces are already there, just need to put them together.

Piskvorrr

The devil is in the details.

What do you mean, "requires Windows 11"? What is even "glibc" and why do I need a different version on this Linux machine? How do I tell that the M4 needs an "arm64", why not a leg64 and how is this not amd64?

In other words, it's very simple in theory - but the actual landscape is far, FAR more fragmented than a mere "that's a windows/linux/mac box, here's a windows/linux/mac executable, DONE"

(And that's for an application without a GUI.)

fifilura

Yes, it is difficult, but difficult problems have been solved before.

With dependency management systems, docker, package managers.

MacOS and Windows is closed source and that is of course a problem, I guess the first demo would be universally runnable linux executable on Windows.

lucasoshiro

> universally executable native applications

To achieve that you'll need some kind of compatibility layer. Perhaps something like wine? Or WSL? Or a VM?

Then you'll have what we already have with JVM and similar

woodrowbarlow

https://justine.lol/ape.html -- αcτµαlly pδrταblε εxεcµταblε

this works for actual compiled code. no vm, no runtime, no interpreter, no container. native compiled machine code. just download and double-click, no matter which OS you use.

Piskvorrr

"Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil."

null

[deleted]

ivewonyoung

How different would that be from Flatpak

fifilura

Does it make linux applications run on Windows or mac?

hda111

Why? Would be easier to embed both podman and the image in one executable to create a self-contained file. No docker needed.

ransom1538

Ah finally. We have finished where we started.

blueflow

That was my first thought. Back in the days you gave your friends a stand-alone *.COM program on a floppy. We have come full circle on static linking.

arjav0703

This is useful if you want to share your container (probably something that is prod ready) to someone who knows nothing about docker. An usecase would be, you built a custom software for someone's business/usecase and they are the only one using that particular container.