Child pages
  • Bigtop CI Setup Guide
Skip to end of metadata
Go to start of metadata

This document is for you to quickly setup CI jobs to ensure the quality of your own customized Bigtop distribution.

Notice that, the document assume you already know well how to use Jenkins, hence the instructions are brief.

If you have questions, feel free to ask on Bigtop mailing list. (smile)

Setup a Jenkins master

If you already have a managed Jenkins/Hudson, or you prefer your all installation, skip and go to Setup Bigtop packages build matrix

To setup a Jenkins master by leveraging Docker, do the following:

# create jenkins user on host machine with uid=1000 to map the jenkins uid inside jenkins image
sudo adduser jenkins -u 1000
sudo yum install -y docker git
sudo su - jenkins -c "git config --global \"\""
sudo su - jenkins -c "git config --global \"jenkins\""
sudo usermod -a -G docker jenkins
sudo service docker start
sudo su - jenkins -c "docker run -d --name jenkins-master -p 80:8080 -v `pwd`:/var/jenkins_home jenkins"

And the needed Plugin(s):

  • git plugin

Setup Bigtop packages build matrix

Create a new job:

  • New Item -> Multi-configuration project

In Source Code Management section, fill in your repo and the branch, for example:

Repository URL:
Branch Specifier: master

In the Configuration Matrix section, add a user defined axis with following name and values:


Add another user defined axis:



Finally, add a shell build step with the following script:

docker run --rm -v `pwd`:/ws --workdir /ws bigtop/slaves:trunk-$BUILD_ENVIRONMENTS \
bash -l -c './gradlew allclean ; ./gradlew $COMPONENTS-pkg'

The result will be looked like this:

However, do aware that full matrix build of packages is time consuming, and they need roughly 50GB disk space for each build. 

Setup Bigtop deployment & smoke test job

To setup a deployment and smoke test job for centos 6 OS, use following shell script:

# setup configuration file
cat > bigtop-deploy/vm/vagrant-puppet-docker/vagrantconfig_Bigtop-Docker-provisioner-centos-6.yaml <<-__EOT__
        memory_size: "4096"
        image: "bigtop/deploy:centos-6"
        memory_size: "4096"
        number_cpus: "2"
repo: ""
distro: centos
components: [hadoop, yarn, spark]
namenode_ui_port: "54070"
yarn_ui_port: "8488"
hbase_ui_port: "64010"
enable_local_repo: false
smoke_test_components: [mapreduce, pig, spark]
jdk: "java-1.7.0-openjdk-devel.x86_64"
# destroy previous cluster
./gradlew docker-provisioner-destroy
# provision
./gradlew -Pconfig=vagrantconfig_Bigtop-Docker-provisioner-centos-6.yaml -Pnum_instances=3 -Prun_smoke_tests=true docker-provisioner
# destroy provisinoed cluster
./gradlew docker-provisioner-destroy

The result will be looked like this:


You can replace the repo by your own repo so that your packages can be tested using Bigtop deployment recipes.

The components and smoke_test_components are also configurable, choose what you'd like to deploy and test as what you want.

We'll switch to docker-compose instead of Vagrant in Bigtop Docker Provisioner so that the Provisioner can serve users w/o having the bigtop/deploy image limitation.

Stay tune!


Advanced part: Setup a SSL secured jenkins master 

First you need a SSL certificate.

Generating a SSL cert

Here we will use a certificate created by the service.

Most convient way to run it is as a docker container, building a container:


# git clone 
# cd letsencrypt
# docker build -t letsencrypt .

Now use this container to sign into letsencrypt. You have to make sure that no other service is running on port 80 and 443. This starts an intermediate server an handles a challenge response handshake in order to prove that we actually are running 

# docker run --rm -i -t -p 80:80 -p 443:443  -v "/etc/letsencrypt:/etc/letsencrypt" letsencrypt certonly --standalone --email -d

Please note that this writes into /etc/letsencrypt as root on the host.

Generating first cert

The command does not generate a certificate on first run. It generates new certificate (renewals) each new run. Please be sure that any httpd server is stopped

# docker run --rm -i -t -p 80:80 -p 443:443  -v "/etc/letsencrypt:/etc/letsencrypt" letsencrypt certonly --standalone --email -d

Please note it created  /etc/letsencrypt/live/ containing cert and key.

Enabling of SSL

Since the lifetime of the letsencrypt certs is quite short on needs a flexible infrastructure to use the certs as is.

The basic design here is to use a reverse proxy terminating the SSL at the proxy. I.e. All handling of https:// is done by the reverse proxy and requests are proxied to the web application and sent back to the client. 

A quick setup on a RPM based system is:

# yum install httpd mod_ssl

in /etc/http/conf.d/ssl.conf add this block after the line

<VirtualHost _default_:443>

 (see jenkins documentation about deeper insights into this glibberish)

<Proxy *>
        Order deny,allow
        Allow from all

ProxyRequests           Off

# Because of JENKINS-22539
ProxyPreserveHost On
Header edit Location ^
ProxyPass         /  http://localhost:8080/ nocanon
ProxyPassReverse  /  http://localhost:8080/
ProxyRequests     Off

AllowEncodedSlashes NoDecode

<Proxy http://localhost:8080/*>
  Order deny,allow
  Allow from all

This enables the reverse proxy mode of port 433 to port 8080 and setting Jenkins specific parameters. 


And the location of the certificates have to be aligned with letsencrypt in /etc/http/conf.d/ssl.conf

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.

SSLCertificateFile /etc/letsencrypt/live/

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)

SSLCertificateKeyFile  /etc/letsencrypt/live/

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.

SSLCertificateChainFile /etc/letsencrypt/live/

The last thing is to change jenkins to port 8080 and start apache httpd


# docker run -d --name jenkins-master-8080 -p 8080:8080 -v /home/jenkins:/var/jenkins_home jenkins
# systemctl start httpd

In order to redirect the browser from to place a file into /var/www/html/index.html


Renewing the cert

The command does not generate a certificate on first run. It generates new certificate (renewals) each new run. Please be sure that any httpd server is stopped

# /etc/init.d/httpd stop
# docker run --rm -i -t -p 80 -p 443:443 -v "/etc/letsencrypt:/etc/letsencrypt"  renew
# (obsolete) docker run --rm -i -t -p 80 -p 443:443  -v "/etc/letsencrypt:/etc/letsencrypt"  -v "/var/lib/letsencrypt:/var/lib/letsencrypt"  certonly --standalone --email -d
# /etc/init.d/httpd start
  • No labels