| commit | 5e133e12be42969990a32700a58e63ae160a7bdc | [log] [tgz] |
|---|---|---|
| author | Thomas Draebing <thomas.draebing@sap.com> | Wed Dec 05 09:55:53 2018 +0100 |
| committer | Thomas Draebing <thomas.draebing@sap.com> | Thu Jan 17 16:03:51 2019 +0100 |
| tree | 05de0855e4633bd677e592b5b5e49c1c750e875e | |
| parent | f7cea69152ba99fd05aaca36661582585c6eac34 [diff] |
Rewrite gerrit-init image to allow to handle other databases The gerrit-init container was only able to initialize a MySQL database. The provided bash scripts weren't easy to extend to support more databases. With Gerrit 2.16 a H2-database is usually enough, since the content does not change during runtime. Thus, at least this database should be supported. This change adapts the gerrit-init container to be able to support H2-databases. To do this, python scripts were used instead of bash, since it makes it easier to provide extensible code and since python possesses libraries to communicate with several databases, making it easier and more efficient to work with the databases. This change makes the Gerrit initialization in the helm charts more flexible. Also, using python and sqlalchemy to communicate with the database is a lot faster than using bash and the mysql client, greatly fasten up pod startup. Change-Id: Ic06de5ba6686b4c47365cbadb919c9a6ebfbd6b5
Container images, configurations and Helm charts for installing Gerrit on Kubernetes.
Images to run a Gerrit master and slave setup based on the latest stable-2.12 Gerrit build.
To build all images, the build-script in the root directory of the project can be used:
./build
If a specific image should be build, the image name can be specified as an argument. Multiple images can be specified at once:
./build gerrit-slave git-gc
The build-script usually uses the latest-tag to tag the images. By using the --tag TAG-option, a custom tag can be defined:
./build --tag test
The build script will in addition tag the image with the output of git describe --dirty.
The single component images inherit a base image. The Dockerfile for the base image can be found in the ./base-directory. It will be automatically built by the ./build-script. If the component images are built manually, the base image has to be built first with the target base:latest, since it is not available in a registry and thus has to exist locally.
The publish script in the root directory of the project can be used to push the built images to the configured registry. To do so, log in first, before executing the script.
docker login <registry>
To configure the registry and image version, the respective values can be configured via env variables REGISTRY and TAG. In addition, these values can also be passed as command line options named --registry and --tag in which case they override the values from env variables:
./publish <component-name>
The <component-name> is one of: apache-git-http-backend, git-gc, gerrit-slave.
Adding the --update-latest-flag will also update the images tagged latest in the repository:
./publish --update-latest <component-name>
Assuming a Gerrit site already exists, is located at /path/to/gerrit-slave and owned by the gerrit-user defined in the docker image (default UID: 1000) run the following command for each image in the directories containing the respective docker image:
./start /path/to/gerrit-slave <component-name>
The <component-name> is one of: apache-git-http-backend, git-gc, gerrit-slave, gerrit-master, gerrit-init.
If a specific version of the image should be used, the --tag TAG-option can be used to provide the image tag:
./start /path/to/gerrit-slave --tag d4fad48 <component-name>
or define the tag as an env variable:
export TAG=d4fad48 ./start /path/to/gerrit-slave <component-name>
To detach the running container from the shell, use the --detach-flag:
./start --detach /path/to/gerrit-slave <component-name>
Currently, java is installed under /usr/lib/jvm/java-8-openjdk-amd64/jre. Therefore, make sure that container.javaHome is set to that path in the gerrit.config:
javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
The mysql-replication-init docker image is only required for setting up the Gerrit slave on Kubernetes. If deploying the Gerrit slave outside of Kubernetes, it can be ignored.
These Helm charts can be used to install a Gerrit cluster consisting of a Gerrit master and a Gerrit slave on a Kubernetes cluster.
To evaluate and test the helm-charts, they can be installed on a local machine running Minikube. Follow this guide to get a detailed description how to set up the Minikube cluster and install the charts.
Currently this deployment uses NFS, some options: