Public | Automated Build

Last pushed: 2 years ago
Short Description
Autogenerated images for docker hub.
Full Description


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

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


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


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


(raw-jessie) RAW -> BUNDLE -> 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.

Docker Pull Command
Source Repository