Docker vs Containerd: Understanding the Differences and Choosing the Right Containerization Tool

one of the common questions we've been getting from our students lately is what's the difference between Docker and container D you see we used to see Docker everywhere where we learned kubernetes before but it's now all replaced with container D so what's the story there and what happened and in this video we're going to walk you through the history behind kubernetes and Docker and katinner d and some of the common CLI tools that you will come across such as cry control node control Etc my name is mugshot modern Beth and before we begin this video I want to remind you to subscribe to our Channel as we release new educational videos every week so you're going to come across Docker and containerd many times going forward so when you read older blogs or documentation Pages you'll see Docker mentioned along with kubernetes and when you read newer blogs you will see container D and you'll wonder what the difference is between the two and there are a few CLI tools like CTR cry control or nerd control and you'll wonder what are these CLI tools and and which one should you be using so that's what I'm going to explain in this video so let's go back in time to the beginning of the container era and in the beginning there was just Docker and there were other tools like rocket but docker's user experience made working with containers super simple and hence Docker became the most dominant container tool and then came kubernetes to orchestrate Docker so kubernetes was built to orchestrate Dockers specifically in the beginning so Docker and kubernetes were tightly coupled and back then kubernetes only worked with Docker and didn't support any other container Solutions and then kubernetes grew in popularity as a container orchestrator and now other container runtimes like rocket wanted in so kubernetes users needed it to work with continue runtimes that are other than just docker and so kubernetes introduced an interface called container runtime interface or CRI so CRI allowed any vendor to work as a container runtime for kubernetes as long as they adhere to the oci standards so oci stands for open container initiative and it consists of an image spec and a runtime spec image spec means the specifications on how an image should be built so that's what it defined an image spec defined the specifications on how an image should be built and the runtime spec defined the standards on how any container runtime should be developed so keeping these standards in mind anyone can build a container runtime and that can be used by anybody to to work with kubernetes so that was the idea so rocket and other container runtimes that adhere to the oci standards were Now supported as container runtimes for kubernetes via the CRI however Docker wasn't built to support the CRI standards because remember Docker was built way before CRI was introduced and Docker still was the dominant container tool used by most so kubernetes had to continue to support Docker as well and so kubernetes introduced what is known as Docker shim which was a hackie but temporary way to continue to support Docker outside of the container runtime interface so while most other container runtimes worked through the CRI Docker continued to work without it so now you see Docker isn't just a container runtime alone Docker consists of multiple tools that are put together for example the docker CLI the docker API the build tools that help in building images there was support for volumes auth security and finally also the container runtime called run C and and the Daemon that managed run C and that's that was called as container D so container D is CRI compatible and can work directly with kubernetes as all other runtimes so container D can be used as a runtime on its own separate from docker so now you have container d as a separate runtime and Docker separately so kubernetes continue to maintain a support for Docker engine directly however having to maintain the docker shim was an unnecessary effort and added complications so it was decided in version 1.24 release of kubernetes to remove Docker shim completely and so support for Docker was removed but you see all the images that were built before Docker was removed so all the docker images continue to work because Docker followed the image spec from the OCS standard so all the images built by Docker follow the standard so they continue to work with containerdy but Docker itself was removed as a supported runtime from kubernetes so that's kind of the whole story and now let's look into container D more specifically so container D although is part of Docker is a separate project on its own now and is a member of cncf with the graduated status so you can now install container D on its own without having to install Docker itself so if you don't really need docker's other features you could ideally just install container D alone so typically we run containers using the docker run command when we when we had Docker and if Docker isn't installed then how do you run containers with just container D now once you install containerd it comes with a command line tool called CTR and this tool is solely made for debugging containerdy and is not very user friendly as it only supports a limited set of features and this is what you can see the documentation Pages for for this particular tool so for the other than the limited set of features that it provides anything any other way that you want to interact with container D you'll have to rely on making API calls directly which is not the the most user-friendly way for us to operate so just to give you an idea this can be the CTR command can be used to perform basic container related activities such as pull images for example to pull a Reddit image you will run the CTR images pull command followed by the address of the image and to run a container we use the CTR run command and specify the image address but as I mentioned this tool is solely made for debugging containerdy and is not very user friendly and not to be used for running or managing containers on on a production environment so a better alternative recommended is the nerd control tool or nerd CTL tool so the node control tool is a command line tool that's very similar to Docker so it's like a Docker like CLI for container D it kind of supports all most of the options that Docker supports and apart from that it has the added benefit that it can give us access to the newest features implemented into continuity so for example we can work with the encrypted container images a rather new feature that will eventually be implemented into the regular Docker commands in the future it also supports lazy pulling of images P2P image distribution image signing and verifying and namespaces in kubernetes which is not available in in Docker so the nerd control tool works very similar to Docker CLI so instead of Docker you would ideally simply have to replace it with node control so you can run almost all Docker commands that interact with containers like this so some examples are instead of running the docker run command to create a container put on a container you could just use the node control run command and similarly uh let's say you want to use some options for port mappings or exposing ports with the dash P option for the docker run command you could do the same with node control simply replace Docker with node control so so that's pretty easy and straightforward so now that we have talked about CTR and the node control Tool uh it's important to talk about another command line utility known as CRI CTL or cry control so earlier we talked about the container runtime interface or CRI which is a single interface used to connect CRI compatible container runtimes the container the rocket and others so the cry control is a command line utility that is used to interact with the CRA compatible container runtime so this is kind of an interaction from the kubernetes perspective so this this tool is kind of maintained by developed and maintained by the kubernetes community and this is this tool Works across all the different container runtimes as opposed earlier you had the CTR and the nerd control tool that were built by the containerdy community specifically for container D this particular tool is from the kubernetes perspective that works across a different container runtimes so it must be installed separately and it is used to inspect and debug container runtime so this again is not ideally used to create containers unlike Docker or the node control utility this again a debugging tool you can technically create containers with the cry control utility but it's not easy it's only to be used for some special debugging purposes and the remember that it kind of works along with the cubelet so we know that a cube the cube that is responsible for ensuring that the specific number of containers or parts are available on on node at a time so if you kind of go through the cry control utility and try and create containers with it then eventually cubelet is going to delete them because it accumulate is unaware of some of those containers or pods that are created outside of its knowledge so anything that is sees is going to go and delete it so because of those things so remember that the cry control utility is only used for debugging purposes and getting into containers and all of that so so let's look at some of the command line examples so you simply run the try control CRI CTL command for this and this can be used to perform basic container related activities such as pull images or List existing images list containers very similar to the docker command where you use the PS command so in Docker you run the PS command here you run the cry control PS command and to to run a command inside a container in Docker remember we use the exact command and it's the same here and along with the same options such as the dash i and T and then you specify the container ID and then and the command that needs to be run to view the logs again you use the cry control logs command very similar to Docker command and one major difference is that the cry control command is also aware of PODS so you can list Parts by running the cry control pods command so this wasn't something that Docker was aware of so while working with kubernetes in the past we use docker a lot to troubleshoot containers and view logs especially on the worker nodes now you're going to use the cry control command to do so so the syntax is a lot similar so it shouldn't be it shouldn't be really hard so here's a chart that lists the comparison between Docker and the cry control command line tool so as you can see a lot of commands such as attach exec images info inspect logs PS stats version Etc work exactly the same way and some of the commands to create remove and start the stop images work similarly too so a full list of differences can be found in the the link given below so since as I mentioned cry control can be used to connect to any CRA compatible runtime remember to set the right endpoint if you have multiple container runtimes configured or if you want cry control to interact with the specific runtime so for example if you haven't configured anything by default it's going to connect to these sockets in this particular order so it's going to try and connect to Docker shim first and then container D and then cryo and then you have the cry Docker D that's that's kind of the order that it follows but if you want to override that and set a specific endpoint you use the runtime endpoint option with the price control command line or you could use the container runtime endpoint environment variable set the environment variable to the to the right endpoint so to summarize we have the CTR command line utility that comes with container D and works with containerdy which is used for debugging purposes only and has a very limited limited set of features so it ideally you wouldn't be using this at all so you can kind of ignore this then we have the nerd control CLI which is again from the containerdy community but this is a Docker like CLI for containerd used for general purpose to create containers and supports the same or more features than local CLI so there's something that I think we'll be using a lot more going forward and then we have the cry control utility which is from the kubernetes community mainly used to interact with CRI compatible runtime so it's not just for container D this can be used for all CRX supported runtimes again this is mainly for to be used for debugging purposes so if you look at the comparisons here you can see that CTR and cry control are used mainly for debugging purposes whereas the Nerf control is used for a general purpose the CTR and nerd control are from the containerdy community and works with container D whereas cry control is from the kubernetes community and works across all CRA compatible runtimes so our Labs originally had Docker installed on all the nodes so we use the docker commands to troubleshoot but now it's all Container D so remember to use the the cry control command instead to troubleshoot thank you for watching this video if you liked our content do like and share in your community and don't forget to subscribe to our Channel as we release new videos every week foreign

Channel: KodeKloud

Views: 25,121

Keywords: docker vs containerd, docker vs containerd vs cri-o, docker vs containerd runtime, docker vs containerd performance, docker vs containerd vs podman, docker vs containerd vs rkt, docker vs cri-o vs containerd, what is container and docker, what is containerd, dockershim vs containerd, what is container docker, docker, kubernetes, containers, docker tutorial, devops, docker tutorial for beginners, containerd, docker containers, Kodekloud, Kodekloud career, what is docker used for

Id: 21onkZfL2yM

Length: 13min 59sec (839 seconds)

Published: Fri May 19 2023