README

# `lego` -- build system management with docker

## Joe Balough 2016

lego is a utility for managing docker container chroots using the docker tool.
To use lego, it is best used in conjunction with a separate volume, formatted ext4,
and mounted to /var/lib/docker so that docker containers and their storage go there.
Follow the instructions for your distribution to change the docker launch options to
use the `overlay` or better `overlay2` storage backend. If you have to use `overlay`
make sure that your ext4 volume has a higher density of inodes to avoid running out.

With docker configured, start the service and make sure it all works ok.

Create a `Dockerfile` for your build environment. Base it off of the distribution you
are used to and install the packages your build tool needs inside. 
The `Dockerfile` should add a common user that all users can use (like `builder`)
so that when you promote a chroot and other people use it, they can still build as
expected.

Build your `Dockerfile` and tag it to make your first base-chroot.

From there, you can use lego just like it did with version 1.
The main difference is that chroot management is a bit better with docker.

### Config File

There is now a `lego` config file that lives at `/etc/lego.conf` in which you can
configure some behavior.

* `LEGO_VOLUMES`
** Configure volumes that should always be mapped inside of containers created by lego
** Useful for mapping your `OE_PREMIRRORS` volume

* `LEGO_RUN_CMD`
** Command that should be run to launch container, defaults to `/bin/bash`

* `LEGO_CONTAINER_NAME_IGNORE`
** Containers name patterns that should be ignored when doing `lego list` for the work chroots list
** This is useful when running other services on the server using docker like `jenkins` or `gitlab`

* `LEGO_IMAGE_NAME_IGNORE`
** Image name patterns that should be ignored when doing `lego list` for the base chroots list
** This is useful for hiding certain images that you don't want to use for lego like upstream images for services like `jenkins` or `gitlab`

### Integration with Jenkins

To use a Docker container to perform builds, make your build environment specify
SSHD to be the default RUN command. It should be possible to run one as a daemon
(with Docker) and ssh to the forwarded SSH port (as indicated in `docker ps`).
With this container, you can add it as an image in the Jenkins Docker plugin, then
limit builds to that container using the label.