This post adds on to Dockerfile for Building and Testing OpenJ9. At Eclipse OpenJ9 we want to be able to compile & test code on different architecture and operating system combinations. However we are constrained by the number of machines we have access to, so we use Docker containers to supplement them. Docker containers are like light weight virtual machines designed for short term use. This makes them very useful for testing purposes as you can generate a new container for every test and you are guaranteed to run against the same environment every time. The Docker containers we’ve created can support either testing, or building and testing. This is because every platform needs to be able to perform testing, but only one platform for each architecture needs to support compiling. A Docker image is built using a Dockerfile which defines how to setup the container. The table below shows the status of various Dockerfiles on different platforms.
x86 | s390x | ppc64le | |
---|---|---|---|
Ubuntu16 | Test Only | Build & Test | Test Only |
Ubuntu18 | Test Only | Test Only | Test Only |
Centos6.9 | Build & Test | N/A | Out of scope |
Centos7 | TODO | N/A | Build & Test |
RHEL7 | TBD | TBD | TBD |
SLES12 | TODO | TODO | TODO |
Windows | TODO | N/A | N/A |
Eclipse OpenJ9 CI
These Dockerfiles are used by two Jenkins jobs at the Eclipse OpenJ9 CI to generate the Docker images. The first job is run manually by supplying the architecture and operating system. It should be run after a Dockerfile change has been merged. The second job is used to test pull requests. Whenever a PR makes changes to a Dockerfile, a PR build should be launched for each Dockerfile changed. A PR build can be launched by making a comment in the PR with the following format
Jenkins build docker <ARCH> <OS>
Both jobs will push the Docker images to Docker Hub under the repository eclipse/openj9-jenkins-agent-<ARCH>-<OS>:<TAG>
. If a manual build is run the tag will be the build number of the job, as well as the latest
tag. If a PR build is run the tag will contain PR
followed by the ID of the pull request used to build the job. Once the image is uploaded, you can pull it locally in order to test the PR change by hand.
Using containers from a terminal
If you have docker installed on your local machine, you can run docker pull eclipse/openj9-jenkins-agent-<ARCH>-<OS>:<TAG>
to pull a docker image of the specified architecture and operating system. You can use docker run -it eclipse/openj9-jenkins-agent-<ARCH>-<OS>:<TAG> /bin/bash
to start up a new container and enter it. Once inside of a container, run su - jenkins
to switch to the jenkins user. This way when you run your code you won’t have root privileges. If the container is capable of building openj9 it will also have reference repos and bootJDKs. The reference repos can be used to improve clone times, and the bootJDKs can be used for compiling openj9. The locations of the reference repos and bootJDKs can be found here. A full list of docker commands for managing/using containers can be found here.
Docker and Jenkins
There is a Docker plugin for Jenkins which allows Jenkins to orchestrate running Docker containers on remote machine(s). Details of the plugin can be found here. After the plugin is installed, you need a machine with Docker installed, and enable its remote API. In the Jenkins Configure System page under the Cloud section, add a new Docker Cloud. Fill in the details for the remote host and add one or more Agent templates with the appropriate details. Add the labels as you would a normal agent. Additionally add label hw.arch.docker
to indicate that the agent is running inside a container.
Summary
In conclusion these Docker containers are useful because they require less setup and maintenance than physical machines, and they can be generated as required by Jenkins. In the future we are looking towards adding more platforms such as centos7 on x86/s390x, windows on x86, and RedHat on multiple architectures. Ideally we will eventually have another job on the Eclipse Jenkins which can run tests on a Docker container built from a pull request, as well as machines that can provision Docker containers at scale.