Was recently somewhat surprised that you can’t just copy a Rust executable into a ´scratch´ container and have it work, so this is a cool blog post to find in my RSS feed.

I’m guessing, if you’re doing something less complex, then you just need the ´musl´ target and the allocator…

  • Hexorg@beehaw.org
    link
    fedilink
    arrow-up
    3
    ·
    7 days ago

    Why would you build docker images for Rust? I mean if you’re renting containers from data centers or just want to run in a sandbox - sure… but rust binaries are statically linked which negates almost all other benefits of containers.

      • Hexorg@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        7 days ago

        That’s what I’m saying though - with statically linked binaries it’s just as easy to deploy the binary as it is the docker image.

        • Ephera@lemmy.mlOP
          link
          fedilink
          arrow-up
          5
          ·
          7 days ago

          You’re looking at it from the perspective of having coded a single application and wanting to deploy it. Try to think more like a sysadmin:

          • You’ve got a whole bunch of applications to deploy. Some of them may use dynamic linking, too.
          • You don’t know any of them too intimately, so want to just prevent them from interfering with each other, unless you allow it.
          • You want a uniform tool to manage all these different applications, and especially also when they’re allowed to interact.

          The result is deployment orchestration tools like Kubernetes, Docker Compose, Podman Compose etc… And as a dev, you have to provide a container image, if you want to play along in those.

          • Hexorg@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            7 days ago

            Hmm there are plenty of tools to do that without containers… though I do see your point that docker provides a unified way of doing that which is easier.

  • José Devezas@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    8 days ago

    Personally, I settled on wolfi-base, which feels a lot like Alpine, but is based on glibc, so there’s fewer compatibility issues. I also considered debian-slim, but there’s just too many CVEs in Debian, and I was fed up with it being so outdated all the time. What I really wanted was something like wolfi, but more open, i.e., not associated with paid images. We need a glibc-based Alpine!

    • davel [he/him]@lemmy.ml
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      7 days ago

      Thanks, I hadn’t heard of Wolfi, nor of Chainguard. They are by a for-profit company, which isn’t an automatic deal-breaker by any means—it could even be a positive—but I do have some more homework to do before jumping onboard.

      • José Devezas@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        7 days ago

        Because most images from Chainguard are paid, apart from the base image, the way I use it is through multi-stage builds, where I simply copy what I need from other images into the wolfi base, unless of course it’s just easier to install what I want using apk. If I could do that with plain Alpine, I would, but most stuff is compiled for glibc, so it’s a no-go.

        If security is the main factor for your, I’d recommend you scan the image with grype, so you can get a grasp of how many CVEs you’re working with.