[HN Gopher] Non-Obvious Docker Uses
___________________________________________________________________
Non-Obvious Docker Uses
Author : zdw
Score : 128 points
Date : 2022-07-24 14:44 UTC (8 hours ago)
(HTM) web link (matt-rickard.com)
(TXT) w3m dump (matt-rickard.com)
| palata wrote:
| I have been using Dockcross for years for cross-compiling
| debarshri wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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-
| 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.
| OJFord wrote:
| I use both, and have had such issues with both.
|
| I suppose using busybox as your base image will most
| readily highlight any missing library issues if you fancy
| it.
|
| (If I remember in the morning I think I can quite quickly
| find whatever it was that was last a problem - it was
| definitely an npm not a pip install when last I
| encountered it.)
| deckard1 wrote:
| MacOS has a case insensitive filesystem (default). If you
| mix up the case with your files/folders and imports then
| everything will work just fine on your machine. We had a
| coworker that did this once. Stupidly, it even passed
| staging and somehow was merged upstream.
| nicoburns wrote:
| Indeed. This is the one incompatibility I have seen in
| the wild. On my previous machine I actually created a
| secondary case-sensitive partition to store code on. But
| unfortunately our iOS app doesn't work on a case-
| sensitive file system so this meant having two different
| project folders. On my new machine I've not bothered and
| I'm just careful about casing.
| folkrav wrote:
| Anecdotally as well, we've had two that I can think of in
| the last two years (both were specific to Windows).
| TameAntelope wrote:
| You can argue or disagree all day long about what OS is
| best for development, but it's not reasonable to think that
| developers on MacOS would only write code for MacOS
| servers.
|
| You can very successfully write code that runs on Linux on
| either MacOS or Windows, depending on what you're
| developing.
|
| Probably not a big deal, but just seems pointlessly narrow
| to think all developers would or should prever actually
| developing on Linux exclusively.
| lmeyerov wrote:
| WSL2 solved docker for us on windows (except broken
| opencl), so afaict just OS X now unless you go into major
| contortions
|
| We do both containerized and native for developing one
| service, but generally docker compose for the composition
| (vs say k8s or all native). And important that CI is in
| docker: that means we can do accurate local docker testing
| of same env in case of CI fails.
| TacticalCoder wrote:
| > You don't want your developers developing on a different
| OS than your CI & deployment environment anyway.
|
| Who's running OS X servers in production?
|
| What are the devs running OS X and IntelliJ tools deploying
| on?
| pid-1 wrote:
| While that's true for processes running in containers,
| _building_ containers is generally noticeably slower than
| Makefiles as it involves several extra steps besides
| executing instructions (e.g. loading build context, gziping
| files, calculating hashes etc...)
| folkrav wrote:
| You'd typically not rebuild CI images that often.
| zokier wrote:
| IO (both network and disk) are afaik taking significantly
| roundabout way with docker vs bare linux
| debarshri wrote:
| I switched from docker desktop to Colima, my life has been
| much better since then.
| pid-1 wrote:
| > hard to debug
|
| When I started using Docker four years ago that was my
| biggest issue. When builds fail, I can't just pick up where
| it left to expect the environment and try stuff out (unless I
| purposely build an image with a ton of layers).
|
| Soooo much time was wasted figuring out what was going on.
| forty wrote:
| Can podman run within unprivileged docker nowadays ? (My main
| issue with those docker based builds is that they are annoying
| to run in unprivileged docker, in a CI for example)
| debarshri wrote:
| You can actually [1]. See the last example.
|
| [1] https://www.redhat.com/sysadmin/podman-inside-kubernetes
| rckrd wrote:
| I've been playing around with changing the default shell for
| some Makefiles to a shell inside a docker container (with
| dependencies baked in). It's a bit hacky, but kind of
| interesting!
|
| [0]
| https://www.gnu.org/software/make/manual/html_node/Choosing-...
| [deleted]
| iamwpj wrote:
| 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 wrote:
| 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.
| leotaku wrote:
| 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 wrote:
| Essentially the same thing in one step. Can avoid some of the
| permission issue gotchas with `docker cp`.
| AlphaSite wrote:
| I think this is basically the premise for Earthly and Dagger,
| right?
| Tao3300 wrote:
| > That's part of the idea behind the co-founder of Docker's
| second act, Dagger.
|
| Guess so!
| stavros wrote:
| 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.
| notatoad wrote:
| any examples of the "registry as config store" idea? i've got a
| use-case where that could be pretty handy
| ImJasonH wrote:
| 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/
|
| - Istio wasm plugins:
| https://istio.io/latest/docs/reference/config/proxy_extensio...
|
| - OPA bundles:
| https://www.openpolicyagent.org/docs/v0.13.5/bundles/
|
| - Tekton bundles:
| 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
|
| 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.
| qbasic_forever wrote:
| Helm can store kubernetes charts in an OCI/docker registry
| too: https://helm.sh/blog/storing-charts-in-oci/
| notatoad wrote:
| helm links to https://oras.land/, which seems like a pretty
| cool generalization of all this.
| rckrd wrote:
| 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.
| jonjonsonjr wrote:
| I gave a very compressed lightning talk last year about this:
| https://youtu.be/ExyWAhS2zBA
| john-tells-all wrote:
| 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.
| 2bluesc wrote:
| 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.
| niros_valtos wrote:
| I would expect to see a code example, but overall makes sense.
| rckrd wrote:
| Sorry, I should I have linked some in the article.
|
| - Alternative docker frontends - https://matt-
| rickard.com/building-a-new-dockerfile-frontend/
| (https://github.com/r2d4/mockerfile)
|
| - Docker merge - https://matt-rickard.com/docker-merge/
| (https://github.com/r2d4/docker-merge)
| mechtaev wrote:
| 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/
| cmckn wrote:
| 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
| vesinisa wrote:
| Docker doesn't really help with ARM/Intel differences. You need
| something like JVM for that.
| rckrd wrote:
| 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-i...
| pydry wrote:
| Either QEMU itself or the QEMU integration seems a bit buggy
| to me coz it goes wrong a lot.
| bavell wrote:
| I use QEMU on a regular basis and have hardly ever have
| issues so I'd guess it's the integration piece.
| k__ wrote:
| I like, how someone solves the OS issue and suddenly people
| start using different CPU archs.
| qbasic_forever wrote:
| 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.
| hultner wrote:
| Something about a hammer and nails.
| doliveira wrote:
| When the options are a hammer or a book of secret spells...
| [deleted]
___________________________________________________________________
(page generated 2022-07-24 23:00 UTC)