Hacker News new | ask | show | jobs
by harryruhr 2003 days ago
Docker for every application? If you create and maintain the Docker image or Dockerfile for every applucation yourself, you must have plenty of time. If you rely on public images from Docker Hub, you must have plenty of trust in the creators of those images.
4 comments

Hmmm... what alternative does not either take time or trust?
It's all relative, of course. But getting a signed package from the repo of the distro I'm using for years is something different than using a random image from hub.docker.com.
Sure, but you are still relying on trust, and you are choosing to limit yourself to things released by your chosen distro. This is the same as if you were to pick a specific docker publisher that you trust, and only use their images.
It's arguable that it's not quite the same. It all comes down to consequences.

If a distro messes up the trustworthiness of an application, they, the big and important company loses clout.

If the application developer messes up, they also lose clout - people may stop using their software.

Chances are, if you're using a third party for a third party piece of software that isn't officially dockerized by the company that developed it, nor a major distro, there's no real backlash if it doesn't work or if they get hacked, etc: "it was a third party trick, so _of course_ it wasn't trustworthy" would be the statement everyone makes.

Debian messing up, or Cisco or Oracle, etc, is a much bigger deal.

Yep, the reality is that we all rely on hundreds of millions of lines of code of software (mostly OSS) that make up our OS, tool chains, libraries, etc. every day. Basically, it's not feasible to even review a meaningful fraction of a percent of that in a lifetime; assuming you even have the skill level to do such a review. In other words, mostly you are blindly trusting other people to have signed off on something and that those people who you don't know personally did a good job of that.
I'm running a similar setup, whereby I run most applications (even the browser I'm using to type this reply) in docker or podman containers, opportunely created.

Judging from the Git repo containing my dockerfiles, I've been doing so since ~mid June 2018.

I've since automated:

* checking new versions of Git repos, alpine versions, and short crawlers for tools (i.e. I run "perl latest.pl" and a bunch of stuff happens and eventually some dockerfiles might get updated)

* auto-committing any change made from the above step (i.e. ./autocommit.sh) with a meaningful message based on the directory the dockerfile resides, as well as which environment variable containing the version changed

* I use https://github.com/crazy-max/diun/ running on my dokku server to keep up with base images updates (i.e. I get an email in the morning stating alpine:3.12 has been updated or debian:buster-slim or whatever); when a base image changes I have to manually "dp alpine:3.12" to "docker pull" and "podman pull" it; after that, I "make base-images" and my local base images (each coming with a short line to enable a local apt-cache-ng proxy) to also get updated; then a simple "make" makes all of them (docker build -t .... and podman build -t ...)

* Quite a lot of (mostly small) bash scripts to run those images.

As an example, the Dockerfile I use to build hadolint:

    FROM local/mfontani/base:latest AS fetcher
    LABEL com.darkpan.github-check github.com/hadolint/hadolint HADOLINT_VERSION
    ENV HADOLINT_VERSION v1.19.0
    RUN curl -sSL "https://github.com/hadolint/hadolint/releases/download/$HADOLINT_VERSION/hadolint-Linux-x86_64" -o /usr/bin/hadolint
    RUN chmod +x /usr/bin/hadolint && \
        /usr/bin/hadolint --version
    FROM scratch
    COPY --from=fetcher /usr/bin/hadolint /usr/bin/hadolint
    ENTRYPOINT ["/usr/bin/hadolint"]
... and the shell script I use to run it:

    #!/bin/bash
    DOCKER_FLAGS=()
    [[ -t 0 ]] && DOCKER_FLAGS+=(-t)
    podman run --rm --init -i "${DOCKER_FLAGS[@]}" \
        --network none \
        -v "${PWD}:/usr/src:ro" \
        --workdir /usr/src \
        localhost/mfontani/hadolint "$@"
It's not that speedy doing this, but it's... okay:

    $ hadolint curl/Dockerfile
    Took: 0.837s (837ms)
You also have to have plenty of trust in the creators of the applications. Using Docker isn't really different, especially when the creators of the applications have also provided the Dockerfiles. What you had before Docker was just as much based on trust.
I have much more trust in the application developers. Thus, I'd trust first party docker images, but repackaged applicaton images would fall out of date more often and remain out of date for longer than most distro packages IMO. And, with distributions, there's a community of maintainers that try to package everything to a standard, with docker, I don't think that's the case.
How is writing a dockerfile any different from installing an application normally? You just write down the steps you'd otherwise have to take.