lava-dispatcher docker images - part 1

18 Jun 2018
Posted by stylesen

Introduction, Details and Preparation

Linaro Automated Validation Architecture a.k.a LAVA project has released official docker images for lava-dispatcher only containers. This blog post series explains how to use these images in order to run inpdependent LAVA workers along with devices attached to it. The blog post series is split into three parts as follows:

  1. lava-dispatcher docker images - part 1 - Introduction, Details and Preparation
  2. lava-dispatcher docker images - part 2 - Docker based LAVA Worker running pure LXC job
  3. lava-dispatcher docker images - part 3 - Docker based LAVA Worker running Nexus 4 job with and without LXC Protocol

Before getting into the details of running these images, let us see how these images are organized and what are the packages available via these images.

The lava-dispatcher only docker images will be officially supported by the LAVA project team and there will be regular releases of these images whenever there are updates or new releases. As of this writing there are two images released - production and staging. These docker images are based on Debian Stretch operating system, which is the recommended operating system for installing LAVA.

lava-dispatcher production docker images

The production docker image of lava-dispatcher is based on the official production-repo of LAVA project. The production-repo holds the latest stable packages released by LAVA team for each of the LAVA components.The production docker image is available in the following link:

https://hub.docker.com/r/linaro/lava-dispatcher-production-stretch-amd64/

Whenever there is a production release from the LAVA project there will be a corresponding image created with the tag name in https://hub.docker.com/r/linaro/lava-dispatcher-production-stretch-amd64/tags/ The latest tag as of this writing is 2018.5-3. In order to know what this production docker images are built with, have a look at the DockerFile in https://git.linaro.org/ci/dockerfiles.git/tree/lava/dispatcher/production/stretch-amd64/Dockerfile

lava-dispatcher staging docker images

The staging docker image of lava-dispatcher is based on the official staging-repo of LAVA project. The staging-repo holds the latest packages built everyday by LAVA team for each of the LAVA components, which is also a source for bleeding edge unreleased software.The staging docker image is available in the following link, which is built daily:

https://hub.docker.com/r/linaro/lava-dispatcher-staging-stretch-amd64/

Whenever there is a successful daily build of staging packages available, a docker image will be made available in https://hub.docker.com/r/linaro/lava-dispatcher-staging-stretch-amd64/tags/ with the tag name 'latest'. Hence, at any point of time there will be only one tag, i.e., latest in the staging docker image location. In order to know what this staging docker images are built with, have a look at the DockerFile in https://git.linaro.org/ci/dockerfiles.git/tree/lava/dispatcher/staging/stretch-amd64/Dockerfile

lava-lxc-mocker

Unlike regular installations of LAVA workers, installations via the above docker images will use a package called lava-lxc-mocker instead of lxc Debian package. lava-lxc-mocker is a pseudo implementation of lxc which tries to mock the lxc commands without running the commands on the machine, but providing the exact same output of the original lxc command. This package exists to provide an alternative (pseudo alternative) to lxc and also to avoid the overheads of running nested containers, which simplifies things without losing the power to run LAVA job definitions that has LXC protocol defined, unmodified.

Having seen the details about the lava-dispatcher only docker images, let us now see three different use cases where jobs are run within a docker container with and without using LXC protocol on attached device such as a Nexus 4 phone.

In demonstrating all these use cases we will use lava-dispatcher only staging docker images. We will use https://lava.codehelp.co.uk instance as the LAVA master to which the docker based LAVA worker will connect to. https://lava.codehelp.co.uk is an encrypted LAVA instance which accepts connections, only from authenticated LAVA workers. Read more about how to configure encrypted communication between LAVA master and LAVA worker in https://staging.validation.linaro.org/static/docs/v2/pipeline-server.html#using-zmq-authentication-and-encryption The following is a preparation step in order to connect the docker based LAVA slave to the encrypted LAVA master instance.

Creating slave certificate

We will name the docker based LAVA worker as 'docker-slave'. Let us create a slave certificate which could be shared to the LAVA master. In a previously running LAVA worker, issue the following command to create a slave certificate,

stylesen@hanshu:~$ sudo /usr/share/lava-dispatcher/create_certificate.py \
docker-slave-1
Creating the certificate in /etc/lava-dispatcher/certificates.d
 - docker-slave-1.key
 - docker-slave-1.key_secret

We can see the certificates are created successfully in /etc/lava-dispatcher/certificates.d As explained in https://staging.validation.linaro.org/static/docs/v2/pipeline-server.html#distribute-public-certificates copy the public component of the above slave certificate to the master instance (https://lava.codehelp.co.uk), which is shown below:

stylesen@hanshu:~$ scp /etc/lava-dispatcher/certificates.d/docker-slave-1.key \
stylesen@lava.codehelp.co.uk:/tmp

docker-slave-1.key                            100%  364     1.4KB/s   00:00   

Then login to lava.codehelp.co.uk to do the actual copy as follows (since we need sudo rights to copy directly, this is done in two steps):

stylesen@hanshu:~$ ssh lava.codehelp.co.uk
stylesen@codehelp:~$ sudo mv /tmp/docker-slave-1.key /etc/lava-dispatcher/certificates.d/
[sudo] password for stylesen:
stylesen@codehelp:~$ sudo ls -alh /etc/lava-dispatcher/certificates.d/docker-slave-1.key
-rw-r--r-- 1 stylesen stylesen 364 Jun 18 00:05 /etc/lava-dispatcher/certificates.d/docker-slave-1.key

Now, we have the slave certificate copied to appropriate location on the LAVA master. For convenience, on the host machine from where we start the docker based LAVA worker, copy the slave certificates to a specific directory as shown below:

stylesen@hanshu:~$ mkdir docker-slave-files
stylesen@hanshu:~$ cd docker-slave-files/
stylesen@hanshu:~/docker-slave-files$ cp /etc/lava-dispatcher/certificates.d/docker-slave-1.key* .

Similarly, copy the master certificate's public component to the above folder, in order to enable communication.

stylesen@hanshu:~/docker-slave-files$ scp \
stylesen@lava.codehelp.co.uk:/etc/lava-dispatcher/certificates.d/master.key .

master.key                                    100%  364     1.4KB/s   00:00   
stylesen@hanshu:~/docker-slave-files$ ls -alh
total 20K
drwxr-xr-x  2 stylesen stylesen 4.0K Jun 18 05:48 .
drwxr-xr-x 17 stylesen stylesen 4.0K Jun 18 05:45 ..
-rw-r--r--  1 stylesen stylesen  364 Jun 18 05:45 docker-slave-1.key
-rw-r--r--  1 stylesen stylesen  313 Jun 18 05:45 docker-slave-1.key_secret
-rw-r--r--  1 stylesen stylesen  364 Jun 18 05:48 master.key
stylesen@hanshu:~/docker-slave-files$

We are all set with the required files to start and run our docker based LAVA workers.

... Continue Reading Part 2