There is a rather unhealthy obsession, in my opinion, in the Docker community about developing the smallest possible container size. Obviously you don’t want your container to contain hundreds of megabytes of useless junk, but perhaps we have passed the point of diminishing returns. It turns out that it is less expensive to have files in your base image that aren’t used than it is to have duplicated files in higher layers.
This post is part of a series where we examine a different container image each week. See previous Containers of the Week here. This week’s image is the official image for the Jenkins project, an open source application for building, deploying and automating software.
Running Jenkins inside a container is a simple task, but I’m going to give you a few tips to improve your Jenkins experience with Docker.
In his book, Antifragile, Nassim Nicholas Taleb describes and develops the concept of antifragility – the property of a system to increase in robustness in response to faults or failures. In the computing world, errors often propagate a long way from their source. A simple memory allocation failure dozens of levels deep inside an application can bubble up and cause a long process to be interrupted and waste hours of work. This is pretty much the definition of a fragile system.
Recently I came across the Maximum Failure Percentage option in Ansible that is part of the Rolling Updates feature and was thinking about how it could be used to build antifragile systems for deploying and updating software.
Welcome to another episode of Container of the Week! This time we are going to look at a utility container that assists you in debugging container operation or just helping to understand what’s going on.
Sometimes testing out a new container or troubleshooting is a simple matter of using “docker logs“. Unfortunately some containers do not log very much to standard output but instead use syslog. The factorish/syslog container can be used to start a simple syslog container in a few seconds to aid troubleshooting a container setup.
RUN apt-get update && apt-get install git wget
or maybe you need to build a C program to run in your container and use something like this:
RUN apt-get update && \ apt-get install autoconf automake gcc
If you were lucky enough to go to DockerCon 2017 (I wasn’t) you might have seen the announcement of Moby and LinuxKit, Docker’s new framework for assembling specialised container systems. Traditionally a bare metal or virtual machine that runs Docker has run a “full service” distribution like Debian, Ubuntu or RedHat Linux. Docker and containerized applications are then installed and run on that server. LinuxKit gives us a quick and easy way of building an OS for the host machine that’s customised to run containers and not a lot else.
I recently wrote an article about command line completion for Docker. This is the parallel article for Kubernetes. The TLDR for command line completion in Docker was that it probably already works just fine. The same is not true for Kubernetes but is easily fixed.
Overall, the installation process for Kubernetes is still slightly complicated and there are many vendors making their own Kubernetes packages. Unfortunately the majority of the effort is focussed on installing and configuring the server-side components of Kubernetes. This makes sense given the complexity involved, but it leaves users of the command line client out of luck. There’s good news though as it’s very easy to install the pieces needed for command line completion for Kubernetes. Continue reading “Kubernetes Command Line Completion”
This week we are going to look at a very simple container, but one that I personally did not know about up until a few days ago. It’s a standard base container, but one with an important property that many users of Docker and Kubernetes are concerned about.
A base container is the container image used in the FROM command of your Dockerfile. Base containers are usually a customised minimal install of a full-sized Linux distribution such as Debian, Ubuntu or CentOS. Read on to find out more about the debian:jessie-slim base container.
This is the first post in an ongoing series looking at container images. Each week I’m going to analyze a particular image and see how it ticks. The one I’m going to look at first is the library/alpine container.
I remember the first time that I discovered command line completion for my shell way back in the early 90’s. Up until then, you needed to remember the filename you wanted to use for any command and type the full name out in its entirety. This could be a frustrating and error-prone process even if you were a good typist. From then on being able to hit TAB and get the right filename was just pure bliss!
Depending on your situation, command line completion for Docker client may already be working and you might not realise it! Read on for details. Continue reading “Docker Command Line Completion”