[HN Gopher] Show HN: dockerc - Docker image to static executable...
___________________________________________________________________
Show HN: dockerc - Docker image to static executable "compiler"
Author : NilsIRL
Score : 84 points
Date : 2024-03-06 19:55 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dflock wrote:
| Nice idea! How does this actually work? I'm guessing it's
| wrapping a custom loader + docker + the image into an executable
| binary - or something like that?
| NilsIRL wrote:
| Yep pretty much.
|
| The executables bundle crun (a container runtime)[0], and a
| fuse implementation of squashfs and overlayfs. Appended to that
| is a squashfs of the image.
|
| At runtime the squashfs and overlayfs are mounted and the
| container is started.
|
| [0]: https://github.com/containers/crun
| dvfjsdhgfv wrote:
| The Reddit screenshot is hilarious. But it reflects my feelings
| whenever I want to install a product made by many of these self-
| proclaimed "open source" companies that bend over backwards to
| make it almost impossible to install the open version (...and
| often to discover the crucial features are missing anyway).
| OJFord wrote:
| That was Sourceforge really I suppose wasn't it - I enjoy
| GitHub for the opposite reason really (that I am a 'smelly
| nerd' and do want code more often than an executable, well
| actually they said '.exe', and I _never_ want that) but I 've
| definitely come across repos, even maintain one^, where they
| have that kind of real world leaking in, not really realising
| GitHub's not for them and then getting frustrated by it or just
| doing strange things.
|
| (^I'm a collaborator on awesomecv, a latex CV/resume template,
| and we get a _lot_ of PRs from people trying to edit their own
| information & experience into the example. I keep meaning to
| set up a template repo of how to use it properly as a latex
| class, maybe include rendering in Actions, the way my own use
| of it is basically, and more strongly point people towards that
| in the readme, maybe even remove the example. But I've been
| saying that for years, since before 'template repo' existed in
| fact.)
| jiripospisil wrote:
| I had to look it up because I couldn't believe it was real
| but...
| https://old.reddit.com/r/github/comments/1at9br4/i_am_new_to...
| c0balt wrote:
| Interestingly, the OP also doesn't appear to have changed
| their tone since then. They were even active within the last
| week.
| soraminazuki wrote:
| I made the mistake of looking at the comments of that post's
| author. All I can say is quite a few people would probably be
| glad to know that the author didn't figure out how to install
| that OSINT tool.
| politelemon wrote:
| OK that's a cool idea. I did try the example in the README but I
| get an error right away (Ubuntu 22.04)
|
| -----
|
| $ ./dockerc --image docker://oven/bun --output bun
|
| FATA[0000] Error loading trust policy: open
| /etc/containers/policy.json: no such file or directory open CAS:
| validate: read oci-layout: invalid image detected Cannot stat
| source directory "/tmp/dockerc-fbObho/bundle" because No such
| file or directory error: FileNotFound
|
| -----
|
| Btw does this also solve the last line in the original user's
| complaints?
| NilsIRL wrote:
| Thanks for the bug report! Just pushed a change that fixes it
| (and made a new release with the issue fixed:
| https://github.com/NilsIrl/dockerc/releases/)
| hiatus wrote:
| Curious about the choice of Zig, any specific reason for using
| it?
| seabrookmx wrote:
| Probably because it has a super nice build toolchain,
| especially when you consider cross compilation.
|
| There's quite a few folks using zig _just_ for the toolchain,
| while still writing C.
| Alifatisk wrote:
| So what does this mean? That I can finally ship portable Ruby
| executable without requiring the end user to install Ruby?
| NilsIRL wrote:
| Yep! It works with any docker image!*
|
| *: https://github.com/NilsIrl/dockerc/issues/6
| tekknolagi wrote:
| You should also be able to do that with Cosmopolitan/APE.
| misnome wrote:
| Same thing as Apptainer/Singularity? Or a different approach?
|
| I always remember having issues using the Singularity outputs for
| anything that needed to interact with the filesystem.
| Oras wrote:
| I think it's a great idea, but what kind of file size range
| should I expect?
| NilsIRL wrote:
| It will depend heavily on the docker image you're trying to
| ship. For example with macos-cross-compiler[0] the resulting
| binary is over 2GB. With python:alpine[1] it's only 25MB.
|
| Because the image isn't copied whether the image is 2GB or 25MB
| the startup time will be nearly instantaneous for both.
|
| The runtime adds 6-7MB of overhead although I expect that this
| can be reduced to less than 3MB with some work.
|
| [0]: https://github.com/shepherdjerred/macos-cross-compiler
| [1]: https://hub.docker.com/_/python
| ryukoposting wrote:
| The README indicates that this tool will only support Windows and
| MacOS through emulation. I find that odd.
|
| Let's face it, if you're using Linux, you're comfortable typing
| some stuff into the terminal to install software. Or if you
| aren't comfortable with it yet, you will be soon. That's just the
| reality of using Linux. Even ignoring that, snap and flatpak apps
| provide a generally awful user experience, and I fail to see how
| this tool would do a better job.
|
| That leaves Windows and MacOS users as the primary audience for
| software packaged using a tool like this. It would make sense
| that a tool like this would prioritize MacOS/Windows support
| above all else. Even the angry redditeur shown in the README
| clearly mentions .EXE files.
|
| Why would QEMU even necessary? Docker runs fine on Windows. Maybe
| it's to avoid requiring the user to install Docker? Either way,
| asking the user to fiddle with Hyper-V settings is bad UX.
| NilsIRL wrote:
| > It would make sense that a tool like this would prioritize
| MacOS/Windows support above all else.
|
| Yep, unfortunately I've not had the time to make it work well
| on those platforms. I got an initial demo working on MacOS but
| I'm currently facing the issue that I'm unable to statically
| compile QEMU on MacOS. I've also started writing a
| VirtualizationFramework[0] based backend.
|
| > Why would QEMU even necessary? Docker runs fine on Windows.
|
| When docker runs on Windows/MacOS it's actually running the
| containers in a Linux VM. Containers rely on features provided
| by the Linux kernel.
|
| > Maybe it's to avoid requiring the user to install Docker?
|
| The main reason to use dockerc is to avoid the user having to
| install Docker.
|
| > Either way, asking the user to fiddle with Hyper-V settings
| is bad UX.
|
| Yep I don't think that would be nice. I expect the experience
| to be transparent to the user.
|
| [0]: https://developer.apple.com/documentation/virtualization
| Cu3PO42 wrote:
| > Yep, unfortunately I've not had the time to make it work
| well on those platforms. I got an initial demo working on
| MacOS but I'm currently facing the issue that I'm unable to
| statically compile QEMU on MacOS.
|
| How static are we talking here? There's no reasonable way to
| not link dynamically against libSystem. Then again, that's
| obviously present on all Macs, so shouldn't be an issue.
|
| > When docker runs on Windows/MacOS it's actually running the
| containers in a Linux VM.
|
| True on macOS, but only partially true for Windows. There are
| actual Windows containers, running natively on Windows and
| runnihng Windows inside the containers.
|
| But do you even want to distribute Windows binaries? Or are
| you looking for a way to transparently ship a Linux binary to
| Windows users?
|
| > Yep I don't think that would be nice. I expect the
| experience to be transparent to the user.
|
| Does this include automagically mounting filesystems?
| NilsIRL wrote:
| > How static are we talking here?
|
| Enough for the executables to run everywhere. So I'm happy
| for system libraries to be dynamically linked.
|
| > But do you even want to distribute Windows binaries?
|
| That's what I'm imagining. A windows binary that starts a
| Linux VM in which the container runs.
|
| > Does this include automagically mounting filesystems?
|
| Yep, inside of the Linux kernel. Here's what PID 1 looks
| like: https://github.com/NilsIrl/dockerc/blob/non_linux/src
| /init.z...
| Cu3PO42 wrote:
| Hey, I appreciate the reply!
|
| > A windows binary that starts a Linux VM in which the
| container runs.
|
| I'm afraid my wording was somewhat ambiguous here. I
| meant to ask "do you aim to wrap Windows apps in a single
| Windows binary", but I suppose you answered my question
| anyway. You want to distribute Linux applications to
| Windows users.
|
| Running on Windows/macOS was also the context in which I
| meant to ask about filesystem mounts. I understand this
| is not something that's implemented yet, but I'm
| wondering about your goals. Things obviously get much
| trickier than they are on Linux. On Windows I'd probably
| include a Plan9 server for file sharing.
|
| The much larger hurdle I see for Windows support is that
| I don't think you can setup virtualization without Admin
| privileges in the general case. If Hyper-V is not already
| present and enabled you'll need to install some
| hypervisor. Even QEMU needs Hyper-V for proper
| virtualization.
| Maskawanian wrote:
| Both the standard Windows and Mac OS versions of docker use VMs
| (Windows uses WSL2 and IIRC Mac OS uses
| Virtialization.framework) as the OSes don't provide the a linux
| kernel for the containerized userspace. If it didn't do this,
| it'd have to host Windows and Mac OS environments, which would
| defeat the portable nature of Docker.
| k8svet wrote:
| Folks will literally shove a container runtime, FUSE, and
| operating system image into a binary to avoid going to thera...
| learning Nix.
| yjftsjthsd-h wrote:
| Learning nix results in needing more therapy, though;)
| pvg wrote:
| _Omit internet tropes.
|
| Please don't post shallow dismissals, especially of other
| people's work._
|
| https://news.ycombinator.com/newsguidelines.html
| flaminHotSpeedo wrote:
| Might be worth calling out that it supports any OCI images, which
| seems to be the case from a quick skim throught the repo!
| Cu3PO42 wrote:
| Let me start by saying this looks like a fun project to work on
| and, honestly, that's reason enough for doing it.
|
| As a solution to the problem of app distribution, I do have some
| concerns, though:
|
| How do you deal with resource sharing? This starts with just
| filesystem mounts, but also concerns ports, possibly devices, and
| probably many other things I'm forgetting. Is this somehow
| configurable?
|
| How does this compare to AppImage? IIRC that also puts everything
| into a squashfs.
|
| If a user without CAP_SYS_USER_NS executes one of the binaries
| built by dockerc, do you handle that gracefully in any way?
| Zambyte wrote:
| > Usage: Install dockerc from the latest release.
|
| I love the juxtaposition with the image directly above this
| KomoD wrote:
| Okay, that is interesting and cool, though I assume the binaries
| will be pretty large
| 39 wrote:
| Only if you don't use multistage builds
___________________________________________________________________
(page generated 2024-03-06 23:00 UTC)