Skip to main content

Jenkins on Raspberry Pi 2

I had an old Raspberry Pi which was fun to play with but really too underpowered to do much with. However, I recently took part in the BCS Womens App-athon World Record attempt where I had a chat with a guy about Pis and running Minecraft and he pointed out the newer Pi2 was quite capable of running MCServer (a C++ implementation of a Minecraft Server).

But I wanted a Pi2 for something more serious - something running Jenkins to manage the various bits of codes I knock up. I'd tried this on the original Pi but it was unusable...

Install from instructions Random Code Solutions were ok but the version installed via apt-get was old and slow and couldn't easily be updated (managed package). I removed this and installed Tomcat 7 but this bizarrely used Java 1.6 and similarly wasn't easily changed...

Managed packages, they make life easy but you're dependent on them keeping things up to date.

So the process I finally used was:

1. Install Java 8, the Oracle version. This was already there on the version of Raspbian I was using.

2. Ensure this JVM is set as the default:
update-alternatives --config java

Should give you something like image below. Select the version corresponding to java 8...

update-alternatives --config java

3. Download Tomcat. Version 7.0.62 was the one I used.
cd /usr/local/bin
wget http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-7/v7.0.62/bin/apache-tomcat-7.0.62.tar.gz
tar -zxf apache-tomcat-7.0.62.tar.gz

4. Jenkins will complain about URI charset on startup so before installing change the URIEncoding parameter for Tomcat i18n in apache-tomcat-7.0.62/conf/server.xml to set the URIEncoding as UTF-8:
<Connector port="8080" URIEncoding="UTF-8"/>

5. Startup Tomcat
/usr/local/bin/apache-tomcat-7.0.62/bin/startup.sh

Check this is running by hitting the server: http://{server}:8080/ and you should see something like below:

Tomcat Successful Install

6. Download Jenkins (just grab the jenkins latest release though at time of writing the version I have is 1.617) and put this into the webapps folder under Tomcat. Or...
wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war -O /usr/local/bin/apache-tomcat-7.0.62/webapps/jenkins.war

7. Tomcat will now deploy the WAR. This can take a little time and the easiest way to see it running is to run "top" and you should see Java consuming 100% CPU. When this drops to 0% it'll be done.

8. You should now be able to see Jenkins running on http://{server}:8080/jenkins/ (on my network it's called raspberrypi2  - genius huh!).

All done! Kind of, it's best to update all plugins and restart, configure security, set access control and configure an email server for alerting.

A simple task runs ok and Jenkins is quite responsive when nothing else is running on the server...

I can run MCServer ok at the same time but Jenkins gets slow when the world is in use. Otherwise no issues yet though I suspect as I add more jobs it'll probably run out of RAM. We shall see. Perhaps I'll be buying another one of these Pi2's; wife will be pleased.. ;)

Comments

Post a comment

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.