10 ms·

Non-Obvious Docker Uses

210 points by zdw 4y ago

iamwpj 4y ago
I can see the appeal as a replacement for make; in fact, it might be something I do without ever thinking of using make — just because I use Docker more often than make. I use Docker for sort of a virtual network interface to allow me to connect to two VPNs (a VPN inside a VPN environment). Any good hardware/software finds all sorts of niches to fill in time.
- rckrd 4y ago
  Docker just announced Docker Extensions for Docker Desktop -- already configured long-running agents that are "managed" with a nice GUI. I use the Tailscale extension to let my development pods talk to my tailnet. It's really handy (would be even better if it worked with the local Kubernetes cluster in Desktop). Of course you can do this yourself fairly easily, but it's nice to have it "managed" for a non-essential part of the workflow.
niros_valtos 4y ago
I would expect to see a code example, but overall makes sense.
- rckrd 4y ago
  Sorry, I should I have linked some in the article. - Alternative docker frontends - https://matt-rickard.com/building-a-new-dockerfile-frontend/ https://matt-rickard.com/building-a-new-dockerfile-frontend/ (https://github.com/r2d4/mockerfile https://github.com/r2d4/mockerfile) - Docker merge - https://matt-rickard.com/docker-merge/ https://matt-rickard.com/docker-merge/ (https://github.com/r2d4/docker-merge https://github.com/r2d4/docker-merge)
debarshri 4y ago
We actually use docker multistage build as mentioned here as a replacement for make file. The nice thing is you can run it locally to build but also run it in a podman container as a part of CI/CD process as is without any changes. Nice thing about this strategy is that you can uniformly enforce dependencies, versions, etc
- tlarkworthy 4y ago
  The horrible thing is that it is slow, hard to debug and develop on. I personally think it is a bad tradeoff and will make developers hate their day.
  - dingleberry420 4y ago
    Why would it be slow? Docker is just as fast as running native on Linux. Unless you're talking about running it on Windows or Mac. In which case, don't do that. You don't want your developers developing on a different OS than your CI & deployment environment anyway.
    - nicoburns 4y ago
      > You don't want your developers developing on a different OS than your CI & deployment environment anyway Eh, this kinda depends on what tech you're using. We use node.js at work which has very good cross-platform support. And we've had literally zero issues developing on mac and deploying to Linux in the 3 years I've been here.
      - OJFord 4y ago
        Your (potential) problems will come at the installing node/packages (that might use C extensions or whatever) level, not developing on top of it. Or just tooling issues like BSD vs. GNU versions, Homebrew installing things differently (e.g. using the more logical 'openapi-generator' vs. 'openapi-generator-cli' used by upstream and respected by at least apt, apk, and pacman).
        nicoburns 4y ago
        Do you use Python by any chance? Node.js native modules typically bundle the native code as part of the module, and don’t depend on externally installed tools. I’ve never used OpenAPI generator, but that looks true of this npm package too https://www.npmjs.com/package/@openapitools/openapi-generator-cli https://www.npmjs.com/package/@openapitools/openapi-generato... (read me mentions the tool is downloaded and installed on first run). I’ve had issues where modules didn’t run when upgrading OS versions (either macOS or Linux - but usually macOS), but we run prod on LTS versions of Ubuntu so that doesn’t happen very frequently, gets caught by our staging server, and is usually a case of simply upgrading libraries to newer versions.
AlphaSite 4y ago
I think this is basically the premise for Earthly and Dagger, right?
- Tao3300 4y ago
  > That's part of the idea behind the co-founder of Docker's second act, Dagger. Guess so!
- stavros 4y ago
  Has anyone used both? How do they compare? I really like the idea of Dagger, but I found the configuration files impenetrable and couldn't even get started with a single build. I guess some of my issue was that I had to learn Dagger and Cue at the same time, and didn't know what needed what.
  - shepherdjerred 4y ago
    I haven’t used dagger, but I have used Earthly for a couple of months. It needs some polishing, but I feel like it solves 95% of my problems with Makefiles + Docker for containerized builds.
    - stavros 4y ago
      That sounds promising, thanks!
    - AlphaSite 4y ago
      Same experience, I also looked at Dagger for it’s ecosystem of libraries, but I just didn’t understand it
- stepchowfun 4y ago
  And Toast: https://github.com/stepchowfun/toast https://github.com/stepchowfun/toast
hultner 4y ago
Something about a hammer and nails.
- doliveira 4y ago
  When the options are a hammer or a book of secret spells...
- deleted 4y ago
  [deleted]
cmckn 4y ago
I think Earthly is a better replacement for make; but containerized builds are definitely slower (often to a disappointing degree). Luckily Earthly has a ton of knobs you can turn re: caching to make things suck less. https://earthly.dev https://earthly.dev
- shepherdjerred 4y ago
  Earthly is my *favorite* tool. It replaces the glue of Makefiles fantastically. Don’t get me wrong, make is great, but I think it only really shines when you’re using a language like C/C++ where you can use it’s awesome dependency graphs. For projects in Go or JavaScript it quickly becomes a task runner with a very inconvenient syntax. Earthly gives you a make-esque syntax while doing all of the work in Docker which gives you repeatability and parallelization for free.
  - deleted 4y ago
    [deleted]
- cmehdy 4y ago
  It might be a silly question since I know little about this tool but I didn't see a mention of docker-compose in the FAQ: do you have personal experience with use-cases where multiple volumes might need to be mounted, ports forwarded, and multiple containers talking to each others or depending on each others?
  - cmckn 4y ago
    Earthly doesn't run containers, it builds them. You can use the resulting images with whatever runtime/orchestrator you want.
vesinisa 4y ago
Docker doesn't really help with ARM/Intel differences. You need something like JVM for that.
- k__ 4y ago
  I like, how someone solves the OS issue and suddenly people start using different CPU archs.
- rckrd 4y ago
  It actually does nowadays. The --platform flag integrates with QEMU. It's emulation so it's slower, but better than doing it manually. [0] https://docs.docker.com/build/buildx/#build-multi-platform-images https://docs.docker.com/build/buildx/#build-multi-platform-i...
  - pydry 4y ago
    Either QEMU itself or the QEMU integration seems a bit buggy to me coz it goes wrong a lot.
    - bavell 4y ago
      I use QEMU on a regular basis and have hardly ever have issues so I'd guess it's the integration piece.
- qbasic_forever 4y ago
  It does help, docker's buildkit backend (enabled when you use the buildx command instead of build) supports building for other architectures automatically. You can for example on an ARM device build a perfectly fine x86 or x64 image and push it to a registry, or vice-versa. It works by behind the scenes using QEMU to emulate the other architecture and binfmt_misc to run its executables. This all happens transparently and wraps up what used to be a bit of manual work and tweaking. It also supports running other architecture images using the same QEMU magic. It's really quite polished and works well.
- shepherdjerred 4y ago
leotaku 4y ago
I don't know about BuildKit and `docker buildx`, but I've been using an approach similar to what is outlined in paragraph two to generate static executables for one of my projects. I use a multistage build to generate a podman/docker image that contains all my build artifacts and then just copy them out of the container onto my host system. What advantages would there be in using BuildKit for this sort of thing?
- rckrd 4y ago
  Essentially the same thing in one step. Can avoid some of the permission issue gotchas with `docker cp`.
notatoad 4y ago
any examples of the "registry as config store" idea? i've got a use-case where that could be pretty handy
- rckrd 4y ago
  I can't find the code anymore but I originally saw this in docker/compose. I forget what they were using it for, but it boiled down to packing up a json file or two in a tarball and pushing it to the local daemon with a special suffix. Then it could pull that and unpack it on the next run.
- john-tells-all 4y ago
  Note that with "Docker as package" style development, you lose the ability to specify dependencies. Consider building real packages, then installing them in shim Docker images. This gives you the best of both worlds: rich dependency specification, and "just run the thing" facility with Docker.
- ImJasonH 4y ago
  There's lots of examples of folks packaging non-container-image things and stuffing them in a registry: - cosign signatures, SBOMs, attestations: https://docs.sigstore.dev/cosign/overview/ https://docs.sigstore.dev/cosign/overview/ - Istio wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/ https://istio.io/latest/docs/reference/config/proxy_extensio... - OPA bundles: https://www.openpolicyagent.org/docs/v0.13.5/bundles/ https://www.openpolicyagent.org/docs/v0.13.5/bundles/ - Tekton bundles: https://github.com/tektoncd/resolution/tree/main/bundleresolver https://github.com/tektoncd/resolution/tree/main/bundleresol... There's even a demo (plug: in a talk I co-presented) of running a RISC-V emulator where its memory is stored in an OCI registry: https://www.youtube.com/watch?v=Xt_G-pUArTM https://www.youtube.com/watch?v=Xt_G-pUArTM These all tend to include a CLI to collect/generate/validate resources and push/move/pull them, but the underlying implementation is roughly the same -- package content in a tarball, generate some JSON pointing to it, push that JSON to the registry (with auth). The real benefit to this is that basically everyone has access to a registry these days -- in their cloud provider, on-prem, whatever -- with exactly the same APIs and mostly sane auth and client tooling. If you're interested in exploring it for your use case let me know, I'd be happy to give you some pointers.
palata 4y ago
I have been using Dockcross for years for cross-compiling
2bluesc 4y ago
Wish I would see more mentions of `podman` where you can just run a container without a daemon and all permissions issues (root by default in Docker). Podman seems like a simpler container management tool for things that are merely wrapping/emulating traditional command line tools.
mechtaev 4y ago
Apart from caching, BuildKit also provides automatic parallelization. Because of these two features, we use BuildKit to make our research results, experiments with program analysis tools on software benchmarks, easier to share and faster to execute. As a more expressive frontend of BuildKit, we created a simple, non-Turing-complete logic programming language, which can also be thought of as docker-based Makefile. https://modus-continens.com/ https://modus-continens.com/
code_runner 4y ago
99% of projects I setup have a docker-compose.yml at the project root and it defines all of the external dependencies. docker-compose up -d and F5 in vscode… up and running.
wbillingsley 4y ago
These do look a little like "an alternative use for a screwdriver is to use the handle to bang in nails". Yes, but it looks a little hacky and I suspect there might be another tool designed for that niche. I'm not convinced that the screwdriver development team will be prioritising its nail-banging feature long-term.
sidlls 4y ago
Make replacement? Why? Make is fast. Docker is not, unless you've very carefully set up the build stage pipeline--which generally has many more limitations than Make.
- qbasic_forever 4y ago
  Because your Makefile likely depends on a very particular environment setup with specific versions of compilers, script hosts, tools, etc. You can meticulously maintain a giant readme that tells devs how to set each tool up (and inevitably takes everyone days and weeks of time to troubleshoot), or you can make a container that has everything setup and ready to go. Make is great and you'd likely use it inside the container. But everything around make is typically an enormous pain to manage across multiple machines, multiple architectures, etc. and that's where docker containers help greatly.
  - hatware 4y ago
    Isn't it funny to see how folks have a hard time putting down the tools they're used to for the latest and greatest? As if something being fast is all that matters.
    - sidlls 4y ago
      Make also has more features for the intended purpose than Docker does—as I noted in my original comment.
      - hatware 4y ago
        Docker is still the right choice if you want environmental parity without needing to separately manage it. It's less specific and that's good.
ctroein89 4y ago
> As a cross-platform compatibility layer We use docker in this way for work, and it’s merely okay. We use docker to bundle the environment (which changes rarely) separate from the code and build system (which changes often). For this, docker has been great for 95% of all our internal users: way more than a makefile helped, but the remaining 5% were a huge pain. The most recent issue was the in-docker user having a different id from the local user, which isn’t a problem on macOS but is on Ubuntu. At the point where docker made sense as a compatibility layer, it was trivial to convert the whole system into a service running on Kubernetes.
- mmis1000 4y ago
  > The most recent issue was the in-docker user having a different id from the local user Probably the mount id mapping added in the linux kernel can be a way to resolve problem when user in docker and host have different id. Although I don't know whether the system utils / docker command have integrated it or not yet. https://lwn.net/Articles/837566/ https://lwn.net/Articles/837566/
kvnhn 4y ago
I don't know about replacing Make with Docker, but I use the two together to good effect. One of my favorite hacks is adding a 'docker-%' rule in my Makefile to run make commands in a Docker image[1]. It's a bit mind-bending, and there's a few gotchas, but it works surprisingly well for simple rules. [1]: https://github.com/kevin-hanselman/dud/blob/e98de8fcdf7ad564d4088fd49ef4063a0e38793a/Makefile#L36 https://github.com/kevin-hanselman/dud/blob/e98de8fcdf7ad564...
- jfkimmes 4y ago
  I toyed with a similar setup recently and I had the problem that I, too, would have rules depend on a "docker build"-step (like `docker-image` in your example). Usually `make` would stop building the dependency for non-PHONY targets if it finds the correct file but in this case it obviously cannot find anything. I tried `touch`ing hidden files for each step and then add those as a dependency but that is not very elegant. Do you have this problem at all?
tarasglek 4y ago
I needed to iterate on bare metal images. Docker buildkit turned out to be an awesome environment for composing minimal/fast vm/bare-metal images. https://github.com/tarasglek/metallize/ https://github.com/tarasglek/metallize/
- magicalhippo 4y ago
  Oh excellent, just the tool I've been looking for!
  - tarasglek 4y ago
    while it's probably much better than starting from scratch, might be a few rough edges.
brunojppb 4y ago
Cross-compiling binaries for many platforms and architectures using Docker and QEMU[1] was a neat way I found to support more targets without having to have the hardware. [1] https://www.qemu.org/ https://www.qemu.org/

210 points by zdw 4y ago

I can see the appeal as a replacement for make; in fact, it might be something I do without ever thinking of using make — just because I use Docker more often than make. I use Docker for sort of a virtual network interface to allow me to connect to two VPNs (a VPN inside a VPN environment). Any good hardware/software finds all sorts of niches to fill in time.

rckrd 4y ago
Docker just announced Docker Extensions for Docker Desktop -- already configured long-running agents that are "managed" with a nice GUI. I use the Tailscale extension to let my development pods talk to my tailnet. It's really handy (would be even better if it worked with the local Kubernetes cluster in Desktop). Of course you can do this yourself fairly easily, but it's nice to have it "managed" for a non-essential part of the workflow.

niros_valtos 4y ago

I would expect to see a code example, but overall makes sense.

rckrd 4y ago
Sorry, I should I have linked some in the article. - Alternative docker frontends - https://matt-rickard.com/building-a-new-dockerfile-frontend/ https://matt-rickard.com/building-a-new-dockerfile-frontend/ (https://github.com/r2d4/mockerfile https://github.com/r2d4/mockerfile) - Docker merge - https://matt-rickard.com/docker-merge/ https://matt-rickard.com/docker-merge/ (https://github.com/r2d4/docker-merge https://github.com/r2d4/docker-merge)

debarshri 4y ago

We actually use docker multistage build as mentioned here as a replacement for make file. The nice thing is you can run it locally to build but also run it in a podman container as a part of CI/CD process as is without any changes. Nice thing about this strategy is that you can uniformly enforce dependencies, versions, etc

tlarkworthy 4y ago
The horrible thing is that it is slow, hard to debug and develop on. I personally think it is a bad tradeoff and will make developers hate their day.
- dingleberry420 4y ago
  Why would it be slow? Docker is just as fast as running native on Linux. Unless you're talking about running it on Windows or Mac. In which case, don't do that. You don't want your developers developing on a different OS than your CI & deployment environment anyway.
  - nicoburns 4y ago
    > You don't want your developers developing on a different OS than your CI & deployment environment anyway Eh, this kinda depends on what tech you're using. We use node.js at work which has very good cross-platform support. And we've had literally zero issues developing on mac and deploying to Linux in the 3 years I've been here.
    - OJFord 4y ago
      Your (potential) problems will come at the installing node/packages (that might use C extensions or whatever) level, not developing on top of it. Or just tooling issues like BSD vs. GNU versions, Homebrew installing things differently (e.g. using the more logical 'openapi-generator' vs. 'openapi-generator-cli' used by upstream and respected by at least apt, apk, and pacman).
      - nicoburns 4y ago
        Do you use Python by any chance? Node.js native modules typically bundle the native code as part of the module, and don’t depend on externally installed tools. I’ve never used OpenAPI generator, but that looks true of this npm package too https://www.npmjs.com/package/@openapitools/openapi-generator-cli https://www.npmjs.com/package/@openapitools/openapi-generato... (read me mentions the tool is downloaded and installed on first run). I’ve had issues where modules didn’t run when upgrading OS versions (either macOS or Linux - but usually macOS), but we run prod on LTS versions of Ubuntu so that doesn’t happen very frequently, gets caught by our staging server, and is usually a case of simply upgrading libraries to newer versions.

AlphaSite 4y ago

I think this is basically the premise for Earthly and Dagger, right?

Tao3300 4y ago
> That's part of the idea behind the co-founder of Docker's second act, Dagger. Guess so!
stavros 4y ago
Has anyone used both? How do they compare? I really like the idea of Dagger, but I found the configuration files impenetrable and couldn't even get started with a single build. I guess some of my issue was that I had to learn Dagger and Cue at the same time, and didn't know what needed what.
- shepherdjerred 4y ago
  I haven’t used dagger, but I have used Earthly for a couple of months. It needs some polishing, but I feel like it solves 95% of my problems with Makefiles + Docker for containerized builds.
  - stavros 4y ago
    That sounds promising, thanks!
  - AlphaSite 4y ago
    Same experience, I also looked at Dagger for it’s ecosystem of libraries, but I just didn’t understand it
stepchowfun 4y ago
And Toast: https://github.com/stepchowfun/toast https://github.com/stepchowfun/toast

hultner 4y ago

Something about a hammer and nails.

doliveira 4y ago
When the options are a hammer or a book of secret spells...
deleted 4y ago
[deleted]

cmckn 4y ago

I think Earthly is a better replacement for make; but containerized builds are definitely slower (often to a disappointing degree). Luckily Earthly has a ton of knobs you can turn re: caching to make things suck less. https://earthly.dev https://earthly.dev

shepherdjerred 4y ago
Earthly is my *favorite* tool. It replaces the glue of Makefiles fantastically. Don’t get me wrong, make is great, but I think it only really shines when you’re using a language like C/C++ where you can use it’s awesome dependency graphs. For projects in Go or JavaScript it quickly becomes a task runner with a very inconvenient syntax. Earthly gives you a make-esque syntax while doing all of the work in Docker which gives you repeatability and parallelization for free.
- deleted 4y ago
  [deleted]
cmehdy 4y ago
It might be a silly question since I know little about this tool but I didn't see a mention of docker-compose in the FAQ: do you have personal experience with use-cases where multiple volumes might need to be mounted, ports forwarded, and multiple containers talking to each others or depending on each others?
- cmckn 4y ago
  Earthly doesn't run containers, it builds them. You can use the resulting images with whatever runtime/orchestrator you want.

vesinisa 4y ago

Docker doesn't really help with ARM/Intel differences. You need something like JVM for that.

k__ 4y ago
I like, how someone solves the OS issue and suddenly people start using different CPU archs.
rckrd 4y ago
It actually does nowadays. The --platform flag integrates with QEMU. It's emulation so it's slower, but better than doing it manually. [0] https://docs.docker.com/build/buildx/#build-multi-platform-images https://docs.docker.com/build/buildx/#build-multi-platform-i...
- pydry 4y ago
  Either QEMU itself or the QEMU integration seems a bit buggy to me coz it goes wrong a lot.
  - bavell 4y ago
    I use QEMU on a regular basis and have hardly ever have issues so I'd guess it's the integration piece.
qbasic_forever 4y ago
It does help, docker's buildkit backend (enabled when you use the buildx command instead of build) supports building for other architectures automatically. You can for example on an ARM device build a perfectly fine x86 or x64 image and push it to a registry, or vice-versa. It works by behind the scenes using QEMU to emulate the other architecture and binfmt_misc to run its executables. This all happens transparently and wraps up what used to be a bit of manual work and tweaking. It also supports running other architecture images using the same QEMU magic. It's really quite polished and works well.
shepherdjerred 4y ago

leotaku 4y ago

I don't know about BuildKit and `docker buildx`, but I've been using an approach similar to what is outlined in paragraph two to generate static executables for one of my projects. I use a multistage build to generate a podman/docker image that contains all my build artifacts and then just copy them out of the container onto my host system. What advantages would there be in using BuildKit for this sort of thing?

rckrd 4y ago
Essentially the same thing in one step. Can avoid some of the permission issue gotchas with `docker cp`.

notatoad 4y ago

any examples of the "registry as config store" idea? i've got a use-case where that could be pretty handy

rckrd 4y ago
I can't find the code anymore but I originally saw this in docker/compose. I forget what they were using it for, but it boiled down to packing up a json file or two in a tarball and pushing it to the local daemon with a special suffix. Then it could pull that and unpack it on the next run.
john-tells-all 4y ago
Note that with "Docker as package" style development, you lose the ability to specify dependencies. Consider building real packages, then installing them in shim Docker images. This gives you the best of both worlds: rich dependency specification, and "just run the thing" facility with Docker.
ImJasonH 4y ago
There's lots of examples of folks packaging non-container-image things and stuffing them in a registry: - cosign signatures, SBOMs, attestations: https://docs.sigstore.dev/cosign/overview/ https://docs.sigstore.dev/cosign/overview/ - Istio wasm plugins: https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/ https://istio.io/latest/docs/reference/config/proxy_extensio... - OPA bundles: https://www.openpolicyagent.org/docs/v0.13.5/bundles/ https://www.openpolicyagent.org/docs/v0.13.5/bundles/ - Tekton bundles: https://github.com/tektoncd/resolution/tree/main/bundleresolver https://github.com/tektoncd/resolution/tree/main/bundleresol... There's even a demo (plug: in a talk I co-presented) of running a RISC-V emulator where its memory is stored in an OCI registry: https://www.youtube.com/watch?v=Xt_G-pUArTM https://www.youtube.com/watch?v=Xt_G-pUArTM These all tend to include a CLI to collect/generate/validate resources and push/move/pull them, but the underlying implementation is roughly the same -- package content in a tarball, generate some JSON pointing to it, push that JSON to the registry (with auth). The real benefit to this is that basically everyone has access to a registry these days -- in their cloud provider, on-prem, whatever -- with exactly the same APIs and mostly sane auth and client tooling. If you're interested in exploring it for your use case let me know, I'd be happy to give you some pointers.

palata 4y ago

I have been using Dockcross for years for cross-compiling

2bluesc 4y ago

Wish I would see more mentions of `podman` where you can just run a container without a daemon and all permissions issues (root by default in Docker). Podman seems like a simpler container management tool for things that are merely wrapping/emulating traditional command line tools.

mechtaev 4y ago

Apart from caching, BuildKit also provides automatic parallelization. Because of these two features, we use BuildKit to make our research results, experiments with program analysis tools on software benchmarks, easier to share and faster to execute. As a more expressive frontend of BuildKit, we created a simple, non-Turing-complete logic programming language, which can also be thought of as docker-based Makefile. https://modus-continens.com/ https://modus-continens.com/

code_runner 4y ago

99% of projects I setup have a docker-compose.yml at the project root and it defines all of the external dependencies. docker-compose up -d and F5 in vscode… up and running.

wbillingsley 4y ago

These do look a little like "an alternative use for a screwdriver is to use the handle to bang in nails". Yes, but it looks a little hacky and I suspect there might be another tool designed for that niche. I'm not convinced that the screwdriver development team will be prioritising its nail-banging feature long-term.

sidlls 4y ago

Make replacement? Why? Make is fast. Docker is not, unless you've very carefully set up the build stage pipeline--which generally has many more limitations than Make.

qbasic_forever 4y ago
Because your Makefile likely depends on a very particular environment setup with specific versions of compilers, script hosts, tools, etc. You can meticulously maintain a giant readme that tells devs how to set each tool up (and inevitably takes everyone days and weeks of time to troubleshoot), or you can make a container that has everything setup and ready to go. Make is great and you'd likely use it inside the container. But everything around make is typically an enormous pain to manage across multiple machines, multiple architectures, etc. and that's where docker containers help greatly.
- hatware 4y ago
  Isn't it funny to see how folks have a hard time putting down the tools they're used to for the latest and greatest? As if something being fast is all that matters.
  - sidlls 4y ago
    Make also has more features for the intended purpose than Docker does—as I noted in my original comment.
    - hatware 4y ago
      Docker is still the right choice if you want environmental parity without needing to separately manage it. It's less specific and that's good.

ctroein89 4y ago

> As a cross-platform compatibility layer We use docker in this way for work, and it’s merely okay. We use docker to bundle the environment (which changes rarely) separate from the code and build system (which changes often). For this, docker has been great for 95% of all our internal users: way more than a makefile helped, but the remaining 5% were a huge pain. The most recent issue was the in-docker user having a different id from the local user, which isn’t a problem on macOS but is on Ubuntu. At the point where docker made sense as a compatibility layer, it was trivial to convert the whole system into a service running on Kubernetes.

mmis1000 4y ago
> The most recent issue was the in-docker user having a different id from the local user Probably the mount id mapping added in the linux kernel can be a way to resolve problem when user in docker and host have different id. Although I don't know whether the system utils / docker command have integrated it or not yet. https://lwn.net/Articles/837566/ https://lwn.net/Articles/837566/

kvnhn 4y ago

I don't know about replacing Make with Docker, but I use the two together to good effect. One of my favorite hacks is adding a 'docker-%' rule in my Makefile to run make commands in a Docker image[1]. It's a bit mind-bending, and there's a few gotchas, but it works surprisingly well for simple rules. [1]: https://github.com/kevin-hanselman/dud/blob/e98de8fcdf7ad564d4088fd49ef4063a0e38793a/Makefile#L36 https://github.com/kevin-hanselman/dud/blob/e98de8fcdf7ad564...

jfkimmes 4y ago
I toyed with a similar setup recently and I had the problem that I, too, would have rules depend on a "docker build"-step (like `docker-image` in your example). Usually `make` would stop building the dependency for non-PHONY targets if it finds the correct file but in this case it obviously cannot find anything. I tried `touch`ing hidden files for each step and then add those as a dependency but that is not very elegant. Do you have this problem at all?

tarasglek 4y ago

I needed to iterate on bare metal images. Docker buildkit turned out to be an awesome environment for composing minimal/fast vm/bare-metal images. https://github.com/tarasglek/metallize/ https://github.com/tarasglek/metallize/

magicalhippo 4y ago
Oh excellent, just the tool I've been looking for!
- tarasglek 4y ago
  while it's probably much better than starting from scratch, might be a few rough edges.

brunojppb 4y ago

Cross-compiling binaries for many platforms and architectures using Docker and QEMU[1] was a neat way I found to support more targets without having to have the hardware. [1] https://www.qemu.org/ https://www.qemu.org/