21–30 of 293 posts
However, I don’t agree with using it for sandboxing for security. Especially if you are giving it access to the X11 socket, as the author does in the examples. It might not be obvious, but the app will have access to all your other open windows.
Docker is the NoSQL of 2020.
A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app). I use a bash alias for each common application. For examp…
For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting application…
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.
A few years ago I set a goal to minimize the number of applications installed bare-metal on my laptop. Everything is containerized, just as the blog describes. There is some initial overhead, and some extra work associated with maintaining the infrastructure, but overall I can report improved reproducibility (due to an isolated and static environment per app). I use a bash alias for each common application. For examp…
That just seems insane to be running black inside a container. Why dont you just configure your environment properly?
On the other hand, you get some benefits from installing black through docker rather than through the system package manager: is is completely isolated from the host and the only way to break black is to update it, changing anything in the host will not break your black install.
I am not sure either what you mean by "just configure your environment properly", but I am going to assume you mean installing black under a virtual env or equivalent? Then it is also annoying for different reasons: you must reinstall it once for each project, updating python to a new (major) version breaks your formatter, you cannot move the env around, to name the ones that come on top of my head.
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.
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"]
#!/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 "$@"
$ hadolint curl/Dockerfile
Took: 0.837s (837ms)Docker is the best medium for distributing - A static file is far easier to share / distribute.
Cross-platform - You need an arguably complex and unstable Linux interface to run Docker images, cgroups et al
Sandboxed - security claims about Docker have always been controversial. Simple Unix/BSD constructs like chroot/jails are far simpler and they are reliable
Version pinning - a binary can embed a version and you can stick with it
Reproducible - Everyone gets confused about Docker image checksums. `sha1sum static-binary` is far far simpler.
Minimizes global state - wouldn't be a problem is people built static binaries.