Unlike many people think, containers are not new, they have been around for more than a decade, they however just became popular for a larger part of our ecosystem. Some people think containers will eventually take over.
Imvho It is all about application workloads, when 8 years ago I wrote about a decade of open source virtualization, we looked at containers as the solution for running a large number of isolated instances of something on a machine. And with large we meant hundreds or more instances of apache, this was one of the example use cases for an ISP that wanted to give a secure but isolated platform to his users. One container per user.
I`m working on getting even more moving parts automated, those who use Jenkins frequently probably also have Love - Hate relationship with it.
The love coming from the flexibility , stability and the power you get from it, the hate from it’s UI. If you’ve ever had to create a new Jenkins job or even pipeline based on one that already existed you’ve gone trough the horror of click and paste errors , and you know where the hate breeds.
Back in 2006 I wrote a blog post about linux troubleshoooting. Bert Van Vreckem pointed out that it might be time for an update ..
There’s not that much that has changed .. however :)
Everything is a DNS Problem
Everything is a Fscking DNS Problem
No really, Everything is a Fscking DNS Problem
If it’s not a fucking DNS Problem ..
It’s a Full Filesystem Problem
If your filesystem isn’t full
It is a SELinux problem
If you have SELinux disabled
It might be an ntp problem
If it’s not an ntp problem
It’s an arp problem
If it’s not an arp problem…
It is a Java Garbage Collection problem
If you ain’t running Java
It’s a natting problem
If you are already on IPv6
It’s a Spanning Tree problem
If it’s not a spanning Tree problem…
It’s a USB problem
If it’s not a USB Problem
It’s a sharing IRQ Problem
If it’s not a sharing IRQ Problem
But most often .. its a Freaking Dns Problem !
We’re increasingly using Docker to build packages, a fresh chroot in which we prepare a number of packages, builds typically for ruby (rvm) , or python (virtualenv) or node stuf where the language ecosystem fails on us … and fpm the whole tree as a working artifact.
Now part of that build is running the actual build script in docker with a local volume mounted inside the container This is your typical -v=/home/src/dashing-docker/package-scripts:/scripts param.
A child balloon
you inflate it, play with it for a while, then it explodes, you throw it away you inflate another one, maybe even a different color. the kid plays with it .. till it breaks, then you throw it away…
An inflatable castle.
you inflate it, play with it for a while, deflate it, move it around, inflate it again, if it has a hole in it, you patch the hole.
The tyres on your kids bike,.
You inflate it , kid rides on it, if it starts losing air, you fix it asap so you can continue using it.
When people sign up for Configuration Management Camp, we ask them what community room they are mostly interested in.
We ask this question because we have rooms in different sizes and we don’t want to put communities with 20 people showing interest in a 120 seat room and we don’t want to put a community with 200 people in a 60 seat room.
But it also gives us to opportunity to build some very interesting graph over the potential evolution of the communities.
I gave a couple of new and updated talks the last couple of months.
At Fosdem, I opened up the Distributions Devroom with a talk on how we could improve the collaboration between the developers of a distro, and their users, the ops folks. I seemed to not be the only person with similar ideas as the smart folks over at the CentOS project were already actively talking about their efforts into making some my ideas become reality the day before at the CentOS Dojo.
There’s been a lot of discussion about the sillynes of the term BiModal IT, aka the next big thing for IT-organisations that don’t dare to change, but still want to sound cool.
So here is my idea to reuse that term for something relevant.
BiModal IT, is the idea where you take a fully automated infrastructure which has been build on the principles of Infrastructure as Code. Which gets periodic idempodent updates (e.g every 15 or 30 minutes, or when you orchestrate it), and consistency checks , where the source code for that infrastructure is versioned , tested and delivered trough a traditional Continuous Delivery pipeline for the majority of your services. and add realtime reconfiguration capacities based on service discovery for the other services that really change fast, or in a real elastic way, using tools like Consul, Consul_template, etcd etc..
Software delivery is hard, plenty of people all over this planet are struggling with delivering software in their own controlled environment. They have invented great patterns that will build an artifact, then do some magic and the application is up and running.
When talking about continuous delivery, people invariably discus their delivery pipeline and the different components that need to be in that pipeline.
Often, the focus on getting the application deployed or upgraded from that pipeline is so strong that teams
forget how to deploy their environment from scratch.
A couple of months ago we were seeing weird behaviour with consul not knowing all it’s members at a customer where we had deployed Consul for service registration as a POC
The first couple of weeks we hadn’t noticed any difficulties but after a while we had the impression that the number of nodes in the cluster wasn’t stable.
Obviously the first thought is that such a new tool probably isn’t stable enough so it’s expected behaviour , but rest asured that was not the case.