docker-base

Base repository for almost every docker public image at user @gestiweb. We do not depend on third parties. Everything here is referred to our own repos.

Almost everything is Makefile based (and if not, it has a shell script) so anything is automated even to the simplest parts. No arguments, no variables.

On most folders, "make" or "make help" would give you the common commands available. "make build" will rebuild the image. "make run" will (re)create a container for testing the image.

I put some care to help non-docker people to use this and avoid bloating the disc. Images are commonly removed wen you build newer ones. Containers for developing get recreated each run.

And also, a clean target which removes devel containers and images (if possible)

There is a concept of production containers, those won't get auto-deleted each time. So they are better to get production things up or anything that carries an state and should not be happily deleted anytime.

Our images are way bigger than usual. We bloat them on purpose. We want to have tools inside for debug purpose. And we don't want to recreate a image every time a new small config package or module is needed.

Also, we split them in several layers in order to delivery updates without redownloading the whole image. Here is a basic approach for updates:

Base / Raw images: Never updated. Created once per OS/Version.
Auto / Bundle images (OS): Updated once after two years and never again.
Update layer (OS): Every 6 months, if appropiate.
Auto / Bundle images (product): Updates every time its parent updates.
Update layer (product): Every month, if appropiate. May be updated if new or updated software is required
Developing layer: May be updated but does not carry OS/Product updates at all.

If you want up-to date images in a day-by-day basis, you should create an image deriving our developing layer and include "apt-get upgrade" on your dockerfile.

We have 3 folders, and each folder is a section:

base: Base raw images. Generally created using debian's instructions.
auto: Autogenerated images for docker hub.
upgrade: Update layers for OS and products
dev: Real branch for final products.

Base -> gestiweb/base:*

These images are raw plain containers.

debian-jessie: raw image for debian 8.0

Auto -> gestiweb/auto:*-$(YMD)

These images are autogenerated from docker hub. They mainly serve to add lots of packages, so they get uploaded quickly. They aren't updated so much, so newer versions of the OS will be served through "dev" images.

debian-jessie: lots of commonly used packages to get a only one big image for anything. Also it is dist-upgraded.
apache-server: derivated from the prior image "gestiweb/auto:debian-jessie", we add lots of packages useful for apache.
mariadb-server: derivated from "gestiweb/auto:debian-jessie" we added packages to get mariadb and other useful packages.

Upgrade -> gestiweb/*:upgrade-$(YMD)

Using the autogenerated version, with a simple dist-upgrade, these images make a layer for easy upgrades, so a new upgrade doesn't download every package again.

Dev -> gestiweb/:latest gestiweb/:$(YMD)

These images are meant to be built on any computer, and pushed using a regular ADSL. It should not take much time.

Example route of compiling

debian-jessie

gestiweb/base:debian-jessie (raw image)
gestiweb/auto:debian-jessie-20160408d (package bundle at hub)
gestiweb/debian-jessie:upgrade-20160408 | :upgrade (upgrade layer)
gestiweb/debian-jessie:20160408 | :latest (release layer)

apache-server

gestiweb/debian-jessie:upgrade-20160408 | :upgrade (from debian-jessie)
gestiweb/auto:apache-server-20160408 (package bundle at hub)
gestiweb/apache-server:upgrade-20160408 | :upgrade (upgrade layer)
gestiweb/apache-server:20160408 | :latest (release layer)

TL-DR;

(raw-jessie) RAW (base) -> BUNDLE (auto) -> UPGRADE  -> RELEASE (debian-jessie)
                                              |
      /---------------------------------------/
      |
      |\
      | \
      |  (*) -> BUNDLE -> UPGRADE -> RELEASE (apache-server)
      |
      |\
      | \
      |  (*) -> BUNDLE -> UPGRADE -> RELEASE (mariadb-server)
      |
    (...)

Raw image

Outdated on purpose. Built once for a stable release. Once for jessie, once for stretch. Surely it contains outdated vulnerable software.

Built using debian recommendations. One can safely depend upon this image and never will be needed a re-download.

Package Bundle at Hub

From a prior image (raw layer or upgrade layer), bundle everything we could need later in a big image. This work is done by the docker hub. The software on these images may not be up to date. These images may be static one year or two.

Upgrade Layer

Thin layer to serve updates. This may be updated once a month.

Why I'm using the Upgrade Layer as the base of new images, instead of using the Package Bundle? The reason is, if I do not use the upgrade layer from debian, that updates would be distributed again and again in any child upgrade layer.

So, to avoid re-downloading the same upgrades for every flavour I have, any child upgrade layer MUST depend on a upgrade layer of the parent.

Release Layer

These layers include final usable software, with any final modifications needed. Also referred as the "dev" or "developing" layer.

Add to /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory swapaccount=1 zswap.enabled=1 quiet splash"

gestiweb/docker-base