Often times you need to inject a configuration file into a container in Kubernetes. This is really easy to do using the ConfigMap resource. But once in a while you might need to inject an executable script into a container.
Running a successful developer workshop (aka tutorial) is really difficult. I’ve attended enough workshops that have gone poorly to know that for a fact. Participating in such a workshop can be very frustrating and a huge turn off for whatever technology is being presented. That translates directly into losing developer mindshare. I think we, as an industry, can do a better job of running developer workshops.
There can be any number of reasons to run a once off task on every node in a Kubernetes cluster such as reading some info off of the node or running a quick test. But doing so is not straight-forward. None of the current resources are quite capable of it. A Job is designed to run to completion but there’s no way to ensure one runs on every node. A DaemonSet is designed to run on every node but there’s no way to ensure that it runs to completion only once. Because if the tasks exits after running once the DaemonSet RestartPolicy of Always will cause it to run again.
I use Docker for Mac (DFM) every single day. Up until now all of the out of the box configuration settings just worked for me. However, I ran into an issue with DNS and an issue with subnet collisions that required me to change the configuration. I also needed to script those changes so others could conveniently use them and the changes needed to persist between Docker for Mac restarts.
Before the final release of Docker 1.12, Chanwit Kaewkasi proposed forming a 2000 node Docker Swarm mode cluster. He wanted to test Swarm at scale, find its limitations, and live upgrade each cluster manager. To do so he reached out to the Docker community to contribute 2000 nodes to the effort he called #DockerSwarm2000. Here’s how I was able to help out by joining 100 nodes to the Swarm from my Rackspace account.