 Hi my name is Chris I'm going to talk to you today about alternatives to Docker and how you can replace Docker in your infrastructure and a few minutes ago when I was telling Sophia what I was talking about she asked why I hated Docker and that's not the case but you know alternatives are good and I thought I'd share some of these with you. So how many people, well yeah, how many people here are using containers in production? It's probably a lot now right? How many of you are using something other than Docker to run those containers in production? All right cool that's more than I thought there was gonna be here. So really quickly let's break down a little bit of what Docker does. Docker is a interacts with a runtime. It's a user interface and an API. It's used for building images and sharing images and it's generally it's a large demon that kind of handles a whole bunch of things right? To clarify real quick a container runtime is a low-level program that just creates runs and stops containers. The engine is the user interface that creates images and manages images and creates the definition of the container that the runtime uses to create it. Unfortunately people tend to use these two things interchangeably. So some example runtimes here. RunC is kind of the standard container runtime. It's actually used by Docker through its interface with container D but you can use it on its own. You can use it on the CLI itself or you can use it with a wrapper like a system D unit or just a bash script. Cata is another container runtime. It's used for running containers inside of virtual machines. These are tiny quick to start virtual machines that are great for a little bit of additional security and these come out of the Intel ClearContainer and HyperSH Hyper-V technology. Again container engines are the user interface in the image management portion. It's the piece that they're higher level applications and they're actually designed to be worked with by humans. Cryo is kind of the one of the de facto container engines now. This is what's used by the Kubernetes project. It works with the cry standard or container runtime interface and it talks to RunC down below. Podman is another potential container engine. It's originally was designed to debug and troubleshoot the cryo pods in Kubernetes but it can be used as a drop-in replacement for Docker. So like Podman run, Docker run, Podman build, Docker build. It'll just for almost everything just be a drop-in replacement. Rocket is a demonless engine that uses the default unit of an application or considers a Kubernetes pod the default unit of an application and it's got some really cool tools for process segregation or keeping processes away from one another. So you can go from a single process all the way up to confined within its own virtual machine. Singularity is a container engine that's used a lot for research in HPC and it's got really good robust GPU support for research workloads. It has its own image format but it also can use the Docker image format and they're working toward compatibility with the Kubernetes cry interface so someday Kubernetes can run Singularity containers for you. LexD is a container engine that's used for interacting with the LXC runtime in the canonical projects. They run full system containers or like a full operating system in the container and LexD is a user interface in an API that makes working with the runtime a little more simple. There are also a lot of tools that you can use to replace just small pieces of what Docker does. They generally follow the UNIX philosophy of doing one thing and doing it well. Scopio is an example of this. This is a project from the project atomic team. It's a command line tool for inspecting local and remote images and it can push and pull images to registries and repositories but that's all it does. It doesn't build images. It doesn't run containers. It just inspects and allows you to run or to move image container images back and forth. Build is probably one of my favorite tools and I talk about it a lot. It's a great way to build container images without using Docker. You can actually use whatever tools you want with or without a Docker file so you could build a container image with a Python script or a make file and whatever you would like to use to combine all those layers into a container image. And then when it comes to orchestration, really at the moment Kubernetes is the best option I think in my own opinion. There's not anything else that's really in the same ballpark at the moment so just use Kubernetes until we have more and better competing alternatives for container orchestration. And thank you very much. My name is Chris Collins and if you'd like to talk about containers or anything else, I'd love to talk to you. Thank you.