• Dasnap@lemmy.world
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    8 months ago

    Gotta love using a base container image that is far too overkill for what you’re trying to run.

    • MotoAsh@lemmy.world
      link
      fedilink
      arrow-up
      1
      arrow-down
      2
      ·
      8 months ago

      I mean, isn’t the entire point of a container largely non-functional compared to good deploy/install scripts? Both are perfectly capable of guaranteeing a predictable functional environment for the app. The container is just easier to use, harder to accidentally render insecure, and easier to clean up.

      All of their benefits are NOT for the app itself.

      • jj4211@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        8 months ago

        Harder to accidently render insecure? My experience is the opposite, that docker style containers frequently fail to update vulnerable dependencies.

        Also depending on context, I can say often the container is harder to use. Snap is probably the easiest to use of the solutions, flatpak makes cli invocation a pain, and docker style sucks entirely for interaction, but is fine if your primary interaction is via Web service once you set it up (but oh boy, adding a webui package means you get to mess with nginx or apache proxypass by hand, and each app may require subtly different parameters in proxypass).

        • MotoAsh@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          8 months ago

          Docker is not in a competitor for snap and flatpak. They are tackling very differend kinds of installations.

          • jj4211@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            8 months ago

            The person said “containers” so I was responding to both.

            However, docker containers could stand to learn a thing or two with how flatpak and snap compose a runtime. Applications can say “allow x, y, and z dependency layers to update independent of the application container”, versus the docker style of the app developer must own maintenance of the entire image.

            There may be reasonable differences with respect to how much of a users “real” files and environment are presented to a container in those scenarios, and functional differences like gui and networking suggesting different defaults, but image composition does not need differentiation for their use cases.