Jenkins and the Ansible plugin

I have been slacking on posting anything as of late and it hasn’t been from lack of topics, but my latest client has been me keeping quite engaged. The project has been really cool. I’ve been leading an installation of Red Hats PaaS environment, Openshift. Part of our engagement has been to demonstrate how DevOps and PaaS can increase developer productivity, quality of code, decrease time to market, and confidence the application will do what is supposed to.

During any installation of Openshift the recommendation is to always stand up DNS server specific for Openshift. The reason is that DNS dynamically adds and removes records as containers are added/removed from the PaaS and most network admins are not keen on allowing these dynamic features in the enterprise DNS servers (and rightfully so). This causes problems though. This means that any computer that logs into the Openshift console and creates a container won’t be able to access the container, because their computer won’t be able to resolve the new DNS entry. The fix is to basically forward on traffic to this server from the enterprise servers. However, since making such a change to a company’s DNS server(s) is not something to take lightly and takes time to evaluate risks and such, you may need to create a workaround like adding the Openshift DNS server to your computers list of DNS resolvers.

So nice workaround, right? Well, yes and no. We have worked around the issue of having the developers computer be able to resolve the correct FQDN, cool. What happens when as part of our DevOps process we leverage enterprise Jenkins server to push code directly to Openshift? You got it, the FQDN won’t resolve. The FQDN will not resolve without the correct DNS server.

What do you do? I mean the current set up is only temporary while the new enterprise DNS servers are set up to forward to the Openshift DNS. We really can’t blindly update the DNS servers for Jenkins, because there are a number of other development teams and quite possibly break their builds.

So what do we do… Yes, you got it. Ansible.

jenkins openshift bridge

We will use Ansible to bridge the Jenkins server to our server running the correct DNS to then remotely push an application to Openshift.You may¬† be asking yourself why not just use ssh? There are a few other little tidbits I didn’t mention and that is Openshift requires a special set of client tools that are not installed on the Jenkins server. There is a Openshift plugin which works, but only with ssh keys. The Jenkins server doesn’t use SSH keys, so no Openshift Plugin. However, even if we could use SSH keys the jenkins server wouldn’t be able to resolve the hostname. Which brings us back to using Ansible to execute commands on the bridge VM and then uses the Openshift client tools and the correct DNS server resolve and push code.

We ran into other issues with using the Ansible plugin that I’ll talk about in another post.

Docker: Dockerfile oddities

I have been itching for a reason to create a project using docker. I wanted to get more hands on experience than the [well] documented tutorials from docker, because stuff always, always is left off. A few weeks ago I was asked to give a demo of Jboss Data Virtualization to some system integrators. Anybody familiar with JDV knows it is an extremely powerful tool with many use cases and almost immediately I’m thinking leveraging docker containers to isolate each use case. This would allow me to spin up these demos in a matter of seconds and don’t really have to worry about issues that always happen when running demos on host box.

Reason to use Docker…Check

Know how of Docker…ehhh Check

Use Cases… Check . It turns out Teiid, our community project of JDV has a slew of quickstarts that hit more or less all the use cases I would want to show and quite thoroughly documented. I start here trying to dockerize these quickstarts for the community.

Great! Things are going well and I’m working with our technical marketing team leveraging all their knowledge and minimizing the amount of rework.

Then, there is an oddity. Part of our instructions calls a script to configure the server, however the server needs to be running first before it can be configured. Clearly this is easy start the server then execute the script against the running server…

snippet of my project


RUN $DV_HOME/jboss-eap-6.1/bin/standalone.sh -c standalone.xml -b 0.0.0.0 -bmanagement 0.0.0.0 && \
$DV_HOME/jboss-eap-6.1/bin/jboss-cli.sh --connect --file=$DV_HOME/jboss-eap-6.1/teiidfiles/scripts/setup.cli

WRONG.

AFAIK, this will not work, Dockerfile layers (execution commands) are run in isolation and can’t have concurrent process running. Which kind of makes sense if there is unneeded complexity and whomever is pulling and building the image may be time and resource hog. But really who cares. Once the image is built its not like it has to be be built again and again once it is in your repository. Basically, due to this limitation I first need to run the server externally to create my custom server configurations then take that file and simply replace the current configurations.

Now it isn’t a big deal, but now instead of putting the burden on the container to do I now need to do an additional step of preparation, maintenance, documentation for this docker image.

With that said, once the image is built it is super nice to spin up a container on the fly and fast.