Coming up for 4 years ago (a lifetime in Container land) Ian Miell wrote about “The most pointless Docker Command Ever”. This was a docker command that you could run and it would return you back as root on your host.
One of the common tasks in a containerized environment, where you could be running multiple applications in containers on a single host, is “what’s the best way to route traffic to my web applications”?
One of the great things about the Kubernetes ecosystem is all the new projects that come out on a regular basis to help do various things (keeping up with them can be a challenge, of course).
After a little delay Docker 18.09 got it’s final release this week. This is a release I’ve been looking forward to for a while now, as it’s got a couple of cool new features, which should help in day-to-day usage of Docker.
I came across a very interesting post this morning on using Play With Docker (PWD) to let people try out applications directly from your GitHub repository. If you’ve not tried out Play With Docker before (or it’s companion site, Play with Kubernetes), they’re very useful resources which let you try things out in disposable Docker and Kubernetes environments. Handy for training courses amongst other things.
Based on the Kubernetes security reviews I’ve done, one of the most problematic areas for clusters is user authentication. Whilst Kubernetes provides a wide range of options, it lacks the “traditional” user database that you might expect to see with a multi-user networked system. Using external OIDC or webhook providers is often complex, so many clusters make use of the in-built authentication options which are :-
One of the key elements of the success of Docker is the availability of Docker Hub, which provides an effective “app store” of pre-build Docker images with a huge variety of pre-installed software. Everything from Databases, to CRM software to hacking tools is easily available at the drop of a docker run command.
Following on from looking at katacontainers and gVisor, I thought it might be interesting to look at the containerd project and the idea of using containerd and runc without docker to run containers. Looking round the documentation, I couldn’t find a good look at getting containerd and runc setup together without installing Docker, so lets do that.
This is the second part of a series, taking a brief look at some alternate container runtimes, which can be used with Docker and Kubernetes, the first part is here.
As part of some talks I did for the recent NCC Con, I started looking at the gVisor project from Google (nothing like having to write a presentation to provide motivation!).
