About #linux

Building docker images within the CI pipeline isn’t something new or unusual these days. Normally it’s super easy - you just have to install Docker in your Jenkins CI environment and add jenkins user to the docker group. Problems appear when your Jenkins instance is a docker container itself.

Inception begins

How to make docker available inside your container? Here is a three steps solution:

1. Install docker in your container.
2. Expose docker socket (/var/run/docker.sock) to the Jenkins container.
3. Expose host’s docker executable (/usr/bin/docker) to the container.

At this point, you should already be able to use docker inside Jenkins’ container. Nevertheless, all docker commands executing by Jenkins must start with sudo docker. That requirement has been greatly explained in Post-installation steps for Linux chapter of docker’s docs. If it fits your needs & security restriction you can stop here - but please know, that there is a better solution ;)

I want to share with you some of my thoughts about using Apache Solr (especially SolrCloud) on production. In one of the projects I’m participating in, we are using it to provide Near-Real-Time (NRT) searching along with frequent updates to the indexes. Here are some tips, that helped our project stand still on production environment against hundreds of simultaneous requests per second.

This post is focused on the memory related aspects of the Solr configuration. Most of the advice presented below apply to other large-heap Java applications as well.

Case

Imagine the following scenario: your world-famous web application is hosted with two Docker containers (eg. with application server). Both containers have access to same host’s directories (passed with Docker’s -v parameter) mounted as:

• /configuration - containing few configuration files,
• /logs - storing log files outside containers.

Arguably, there are lots of better solutions (including databases, log indexing systems etc.) but that’s the issue we need to face now.

The following user accounts are involved:

When docker kicked in to the enterprise market many things started changing. Along with microservice-based architectures it became a must-have technology for any “modern” project (the containers idea itself isn’t new - docker has just made things much simplier). In analogy to Java related slogan from 1995 “Write once, run anywhere” almost 20 years later docker enthusiasts say: “Build once, run everywhere”. In fact both ideas can coexist easily and that’s probably one of the reason they really do in practice nowadays. However, there ain’t no such thing as a free lunch…