Support Docker-based development sandboxes

[amotl]

Building on top what @aghster already contributed the other day, I already mentioned at #6 (comment) that

there might be another type of Docker container in the future which will give you a complete development sandbox setup.

and in #8 (comment), we again found that this would be a good option to have.

[amotl]

@aghster and @ElvezPelvez: Please let me know if you would be interested in such a setup, then I would try to add some details here about which additional steps would have to be taken to solve this.

[amotl]

Problem

The current Docker setup doesn't fit well with running PatZilla in development mode sandboxed inside Docker, as it downloads a stable release source distribution package from the Python package index.

Proposal

There should be yet another Docker setup living in a different directory which will spin up and provision a container carrying all the infrastructure required for running PatZilla directly from source. The container would obviously mount the current source tree and then run pserve --reload as well as yarn run watch on top of that in its first incarnation. In later iterations, we could add some more convenient entry points for working with the sandboxed PatZilla instance directly from the command line of the host workstation.

Thoughts

• Because of the fact the current Docker setup will not use the codebase of this repository at all, it could well be split apart from it, right?
• Should we think about actually starting to provide readymade images on Docker Hub?
• While I recognize Alpine Linux is popular amongst Docker people by optimizing for resource efficiency and image size, I am also looking into the direction of a regular Debian-based Docker container here. As the production system is running on Debian Linux, this would yield an environment which is closer to each other.

[ElvezPelvez]

I would be very much interested in such an alternative Docker setup! I am afraid, however, I cannot contribute too much to it since I am far to unexperienced in this field (let me know though if I can be of any help).

Regarding Alpine Linux I thought about bitnami/minideb:jessie which is also (more or less) lightweight and which already brings Python. Then there would be bitnami/mongodb which uses minideb.

[aghster]

I agree that the current Docker setup could be split apart. A separate repository could be created including just the contents of the docker directory. This repository could then be the base for pre-built images on Docker Hub.

As regards another docker setup for development, this would require creating a Dockerfile that starts with a base Debian image and then executes every command neccessary for setting up the development sandbox. However, I have no experience with setting up such environment. @amotl, could you provide a list of commands for installing and configuring all that is required? You could start with running a shell within a pristine debian container by

docker run -it --name patzilla-dev debian:stable-slim /bin/bash

and then execute and protocol every step needed until the development sandbox is set up. The same steps can then be included in the Dockerfile.

[amotl]

Regarding Alpine Linux I thought about bitnami/minideb:jessie which is also (more or less) lightweight and which already brings Python. Then there would be bitnami/mongodb which uses minideb.

This advertises itself as "A small glibc/apt base image designed for use in containers", which I consider a good thing. Thanks for sharing that, @ElvezPelvez.

In turn, I just wanted to share some valuable information related to the topic "To Alpine or not to Alpine" I just came across recently and which I haven't been aware about:

I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.

-- https://news.ycombinator.com/item?id=19861921

And an answer to that:

For anyone who want a small image but with glibc, https://github.com/GoogleContainerTools/distroless is a good choice, especially if you are writing in static linked language e.g. Go and Rust.

-- https://news.ycombinator.com/item?id=19862002

distroless looks pretty decent: It's based on the glibc, apparently driven through binaries coming from the Debian ecosystem and build-support for Bazel.

---

Please still note that we should only go down that route if we really need to have small images. Otherwise, a vanilla Ubuntu or Debian filesystem image like bitnami/minideb:jessie, balenalib/amd64-debian:stretch or just amd64/debian:stretch-slim will offer an installation which is mostly compatible with the one found on non-Dockerized environments aka. regular (vm) machines.