On Tuesday October 14th the Amsterdam Middleware Meetup experimented with Dropwizard. The idea was to find out what this technology is about, where it could be useful and what the alternatives are. So below I’ll give you an overview of Dropwizard and compare it to Spring Boot. Read more
Docker reached production status a few months ago. But having the container technology alone is not enough. You need a complete platform infrastructure before you can deploy your docker application in production. Amazon AWS offers exactly that: a production quality platform that offers capacity provisioning, load balancing, scaling, and application health monitoring for Docker applications.
In this blog, you will learn how to deploy a Docker application to production in five easy steps.
Challenges with integration testing
Suppose that you are writing a MongoDB driver for java. To verify if all the implemented functionality works correctly, you ideally want to test it against a REAL MongoDB server. This brings a couple of challenges:
- Mongo is not written in java, so we can not embed it easily in our java application
- We need to install and configure MongoDB somewhere, and maintain the installation, or write scripts to set it up as part of our test run.
- Every test we run against the mongo server, will change the state, and tests might influence each other. We want to isolate our tests as much as possible.
- We want to test our driver against multiple versions of MongoDB.
- We want to run the tests as fast as possible. If we want to run tests in parallel, we need multiple servers. How do we manage them?
Let's try to address these challenges. Read more
I’ve spent Xebia’s Innovation Day last August experimenting with Docker in a team with two of my colleagues and a guest. We thought Docker sounds really cool, especially if your goal is to run software that doesn’t require lots of infrastructure and can be easily installed, e.g. because it runs from a jar file. We wondered however what would happen if we tried to run enterprise-software, like an Oracle database. Software that is notoriously difficult to install and choosy about the infrastructure it runs on. Hence our aim for the day: install an Oracle database on CoreOS and Docker.
A couple of days ago I had the chance to spend a full day working with Salt(stack). On my current project we are using a different configuration management tool and my colleagues there claimed that Salt was simpler and more productive. The challenge was easily set, they claimed that a couple of people with no Salt experience, albeit with a little configuration management knowledge, would be productive in a single day. Read more
This blog describes how easy it is to use docker in combination with a Raspberry Pi. Because of docker, deploying software to the Raspberry Pi is a piece of cake.
What is a raspberry pi?
The Raspberry Pi is a credit-card sized computer that plugs into your TV and a keyboard. It is a capable little computer which can be used in electronics projects and for many things that your desktop PC does, like spreadsheets, word-processing and games. It also plays high-definition video. A raspberry pi runs linux, has an ARM processor of 700 MHZ and internal memory of 512 MB. Last but not least, it only costs around 35 Euro.
Because of the price, size and performance, the raspberry pi is a step to the 'Internet of things' principle. With a raspberry pi it is possible to control and connect everything to everything. For instance, my home project which is an raspberry pi controlling a robot.
Friday August 22nd was Xebia’s first Innovation Day. We spent a full day experimenting with technology. I helped organizing the day for XITA, Xebia’s IT Architects department (Hmm. Department doesn’t feel quite right to describe what we are, but anyway). Innovation days are intended to inspire as well as educate. We split up in small teams and focused on a particular technology. Below is as list of project teams:
• Installing Oracle on Docker
• Run a web application high-available across multiple CoreOS nodes using Kubernetes
• Application architecture (team 1)
• Application architecture (team 2)
• Getting started with Salt
• Scale "infinitely" with Apache Mesos
In the coming weeks we will publish what we learned in separate blogs.
The world of on-premise private PaaSes is changing rapidly. A few years ago, we were building on on-premise private PaaSes based upon the existing infrastructure and using Puppet as an automation tool to quickly provision new application servers. We provided a self-service portal where development teams could get any type of server in any type of environment running within minutes. We created a virtual server for each application to keep it manageable, which of course is quite resource intensive.
Since June 9th, Docker has been declared production ready, so this opens the option of provisioning light weight containers to the teams instead of full virtual machine. This will increase the speed of provisioning even further while reducing the cost of creating a platform and minimising resource consumption.
To illustrate how easy life is becoming, we are going to deploy an original CloudFoundry node.js application to Docker on a CoreOS cluster. This hands-on experiment is based on MacOS, Vagrant and VirtualBox.
You could use Salt to build and run Docker containers but that is not how I use it here. This blogpost is about Docker containers that run Salt minions, which is just an experiment. The use case? Suppose you have several containers that run a particular piece of middleware, and this piece of middleware needs a security update, i.e. an OpenSSL hotfix. It is necessary to perform the update immediately.
In order to build a container you have to write down the container description in a file called Dockerfile. Here is the Dockerfile:
#------- # Standard heading stuff FROM centos MAINTAINER No Reply firstname.lastname@example.org # Do Salt install stuff and squeeze in a master.conf snippet that tells the minion # to contact the master specified. RUN rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm RUN yum install -y salt-minion --enablerepo=epel-testing RUN [ ! -d /etc/salt/minion.d ] && mkdir /etc/salt/minion.d ADD ./master.conf /etc/salt/minion.d/master.conf # Run the Salt Minion and do not detach from the terminal. # This is important because the Docker container will exit whenever # the CMD process exits. CMD /usr/bin/salt-minion #-------
Build the image
Time to run the Dockerfile through docker. The command is:
$ docker build --rm=true -t salt-minion .
provided that you run this command in the directory where file Dockerfile and master.conf resides. Docker creates an image with tag ‘salt-minion’ and throws away all intermediate images after a successful build.
Run a container
The command is:
$ docker run -d salt-minion
and Docker returns:
The Salt minion on the container is started and searches for a Salt master to connect to, defined by the configuration setting “master” in file /etc/salt/minion.d/master.conf. You might want to run the Salt master in “auto_accept” mode so that minion keys are accepted automatically. Docker assigns a container id to the running container. That is the magic key that docker reports as a result of the run command.
The following command shows the running container:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES 273a6b77a8fa salt-minion:latest /bin/sh -c /etc/rc.l 3 seconds ago Up 3 seconds distracted_lumiere
Apply the hot fix
There you are: the Salt minion is controlled by your Salt master. Provided that you have a state module that contains the OpenSSL hot fix, you can now easily update all docker nodes to include the hotfix:
salt \* state.sls openssl-hotfix
That is all there is to it.