Software plumber with twenty years of experience. I build the pipes other engineers ship their code through, and I get unreasonably excited when nothing leaks.
Somewhere between a programmer, an ops guy and a team lead, depending on the day and on who’s asking. Lately the pipes are sometimes made of roadmaps and budgets, but it’s still plumbing.
In my free (what?!) time I make electronic music. It takes longer to build than my pipelines, but it’s nicer to listen to.
There we go — the Red Hat—IBM merger is now complete: As #RedHat’s acquisition by @IBM closes, Red Hat will maintain independence and neutrality to give customers freedom, choice and flexibility. Get the news: https://t.co/ggZWYrT8ut pic.twitter.com/rw6hdvrqv7 — Red Hat, Inc. (@RedHat) 9 lipca 2019 This is a pretty big deal. And I’m not talking about money only. Red Hat — a company as I know it I’m a Red Hatter since over 10 years now. I joined the company when it had just a little bit over 2k people. Now we have over 14k. Over all these years I saw how we grow. And we grew really fast. Especially in recent years. ...
TL;DR; I’m back! It took a while. We didn’t see each other in long time. Probably too long. So, let me introduce myself again. I’m Marek. Since almost 10 years I work for the same company: Red Hat, in the Middleware part of it. Over that time I was working on various different technologies. Among other things it was: virtualization (KVM, IaaS), Fedora (RPM packaging), Cloud (OpenShift), Middleware (TorqueBox) and more. If I would be tasked to select one technology that influenced my work the most — I would choose containers. This topic is close to everything I do in the last few years in a row. ...
In this blog post I would like to touch on the topic of resource management for Docker containers. It is often unclear how it works and what we can and cannot do. I hope that after reading this blog post resource management will be a bit easier for you to understand. Note I assume that you are running Docker on a systemd enabled operating system. If you are on RHEL/CentOS 7+ or Fedora 19+ this is certainly true. But please note that there can be some changes in the available configuration options between different systemd versions. When in doubt, use the systemd man pages for the system you work with. ...
Starting and stopping Docker containers is easy with the docker run and docker {stop|kill} commands. By default, when the Docker daemon is restarted, running containers are also restarted. This is a great feature but sometimes you need more control over the container’s lifecycle. Imagine having a container which is linked to another one. Docker does not provide any way of specifying which container should be started when or what to do if a container dies. ...
Default configuration is a great place to start with a project. We at JBoss try to make our projects (and products too!) usable out-of-box for as many use cases as we can, but there is no way that one configuration could satisfy everyone’s needs. For example, we ship 4 flavors of the standalone.xml configuration file with WildFly since there are so many different deployment scenarios. But this is still not enough. We need to be able to tweak it at any point. The jboss/wildfly image is not an exception here. ...
There are various ways to set up logging for Docker containers. Docker itself has a built-in logs command, you can mount a volume from the host and save the logs there, you can create a different container that would be only responsible for log handling, or set up a logging daemon. Every method has some pros and cons and it is up to you to choose the one that fits best. ...
I recently announced the availability of the official WildFly Docker image. Since then, our portfolio of images has grown a bit - as of today, we have 8 images. But this is not the end. We want to have a nice collection of JBoss projects shipped as Docker images. Automated builds All of our images are hooked up to automated builds. When we push an update to the repository, a new image will be created and pushed to the global registry. I also set up links between the images so if a base image is updated, our dependent images will be rebuilt. This is a fully automated process that ensures you get the latest available software. ...
The default way of creating an image with Docker is to extend an image by using the FROM call in the Dockerfile. But this is not the only way to do this. You can easily create a base image by using only the yum command. WildFly 8.0.0.Final was recently released and is now available in Fedora 20 updates-testing repository. Let’s create an image that could be used to test this release but make it as minimal as it could be. The application server does have a lot of dependencies, so do not expect a 100 MB image. It’ll be closer to 1 GB. ...
Warning This guide is based on an old version of Docker. The instructions you find below may be already removed or changed in the Docker codebase. In my last blog post I explained how to run a Docker installation across multiple hosts. In the comments I was asked if it would be possible to use a DHCP server to assign IPs to the containers. I thought immediately — why not? In fact, assigning IPs using DHCP is a nice way to overcome the IP assignment issue I talked about before. ...
Warning This guide is based on an old version of Docker. The instructions you find below may be already removed or changed in the Docker codebase. In my previous blog post I talked about running the Fedora Cloud images on a local KVM with libvirt. This was not a standalone task, but rather the preparation for this blog post: running Docker containers on multiple hosts attached to the same network. I was asked in the comments on my WildFly cluster based on Docker blog post if it would be possible to run a cluster on multiple hosts. I found a very nice tutorial written by Franck Besnard. I’ve decided to set up a similar environment on my own to see how/if it works. ...