Containers - why all the hype? If you're looking for answers then this course is for you!
"Deploying Containerized Applications Technical Overview" provides an in-depth review of containers and why they've become so popular. Complementing the technical discussions, several hands-on demonstrations are provided, enabling you to learn about the concepts of containerization by seeing them in action.
You'll also learn about containerizing applications and services, testing them using Docker, and deploying them into a Kubernetes cluster using Red Hat OpenShift.
In this next video I'm going to be giving you a little bit of a history about where the technology behind containers came from. So I'm going to jump right in and I'll start talking about how Containers seem like there's something that's really just kind of come up really strong in the last five six seven years but in reality the technology behind containers has existed within Linux for a few decades. So you may have seen Red Hatters or people using the slogan containers are Linux.
What they're referring to there, is that a lot of the features that are built into Linux have you know created the space that allowed containers to become as popular as they are and most of these features are built around containers needing to be isolated. So many years ago people realized that we needed to find a way to isolate processes and this gave rise to containers. So what are these features in Linux that help containers exist.
So the first thing is Namespaces, so with namespaces the kernel is able to isolate resources both you know from each other and from the machine this protects the containers from each other. There are also control groups this is going to limit the amount of resources that the containers can consume. So this is going to prevent a container from running wild and just taking up all the resources of a of the hosts or of other containers.
Seccomp was introduced around 2014, so this limits how containers can use certain system calls and similarly SELinux is used to protect processes, the container processes from each other and from the host machine. So you can't just run a container than do whatever you want so the host machine SELinux is going to prevent that. We'll talk maybe a little bit later about how you are able to get by and actually do some interaction with the host machine if you need to do things like persist data but for the most part SELinux is there to protect us from ourselves.
Okay, I want to talk a little bit about some of the container architecture terms that we're going to be using throughout this Tech Overview, so the first are containers. We already know what those are, right. Containers are segregated user space environments for running applications that are isolated from other applications sharing the same operating system. Okay so you can create many many many containers.
An image is a template from which containers are created. There's a metaphor that I like to use, that I think helps ground these terms a little bit and that is that you can think of a container as like a dish or some food that you're preparing and an image is really like the recipe from which you're using that. So you can use one recipe and you can make multiple dishes from that recipe but that recipe isn't going to change.
You can make little adjustments to it but you can always be generating new and new recipes from that. So in the same way that image to contain our relationship is the same. Now to take this metaphor a little bit further and stay with me on this one an Image Repository is where your images are stored. If we want to go with this metaphor we could say that image repository is like a cookbook, okay. We can go through we can look at all of our recipes, pick out the one we want to use and from that recipe we can generate lots of those containers or dishes. So there are a lot of image repositories that you can use. One of the ones that I want to focus on is the Red Hat Container Catalog.
This includes an area for us to access a bunch of trusted images from Red Hat. They do a great job of communicating if there are any vulnerabilities within those images but they stand by all these images, so you know you're getting a trusted source. Red Hat Quay is also another option for a public registry. This one will have a little bit more of the the bleeding edge so you know it's more of a public one people can just upload their images to there and the same goes for Docker Hub where people are able to just upload their images.
So you need to be maybe just a little more careful about which images you're using to trust your applications with. Here's a quick screenshot of the Red Hat Container Catalog. This page is showing the Red Hat Enterprise Linux 7 version image, you can see down here we have a health index that was what I was discussing earlier. We can get an idea about if there are any vulnerabilities so you only want to really use those images that have a grade of A for their health index. We have an idea about when this was most recently updated, so we want to make sure that we're using images that are up-to-date, so there aren't any security, vulnerabilities.
And from the container catalog you can do a lot of cool things you can easily click a button that will let you test out that image, will open up your OpenShift online free account and you can just go ahead and try out that image right there. There's all sorts of you know great Red Hat support of course. So how do we interact with these three things, how do we interact with containers, how do we interact with images and how do we interact with our image registries. We are going to use a tool called Podman.
If you're familiar with Docker that's great because Podman works very similar to Docker, it's an open source tool that we're using to manage our containers and our container images and interact with our image registries. So Podman is compliant with the open container initiative so that means you're not going to be tied in any specification, if you wanted to jump back into using Docker or something all that's going to be very simple because podman is using this specified format.
Podman will store all the images in the local file system so when you download your images from those image registries it'll be available in your local file system, in contrast to the Docker CLI. The Docker CLI uses a client-server architecture whereas Podman is much simpler it all just runs on the same machine. Podman is also compatible with Kubernetes, so you don't need to just learn Podman and then forget about it as soon as you want to start orchestrating your applications but you can still use it with Kubernetes and it's very simple to install.
So all you need to do is run that yum install podman command if you're using rhel and if using Fedora is that DNF install pod man. I'll draw a quick diagram here to give you an idea just wanted to tie these concepts together for you. So over here we have let's say this is our container and I'm going to draw a few of these. Okay and all of these containers are based on one image, okay and all of the in this image is going to have originated from an image repository. Okay let me draw the flow of this so we're going from the image repository to the image and then the image is creating multiple containers, we can create as many containers as we like from that same image.
Again one of the nice things about containers is how portable they are, we can take that image and we can upload it to our source control, we can share it we can upload it to Quay IO so that others can use it but the nice thing about it is that we can just create as many containers as we want from that single image. Okay so podman is going to be down here so we've got podman here and this is the CLI client we're going to use.
Podman is able to interact with all of these aspects of running containers, so podman is going to call to the image repository and say I would like to download this image, it'll pull the image for us that's the command we use podman pull and then is going to download that image from that image will use a podman run command and it's going to create the container force.
So it's going to go to the image repository and then it's going to go over to the image and then it's going to create those containers for us and pod man is also able to manage those containers. We can kill the containers and stop, restart the containers, we can use an exec command which is going to allow us to go inside the container and then run further commands, so it's a very versatile utility. Again if you're familiar with Docker and then you are going to be able to use a lot of those same commands.
So that concludes this video and join us in the next video and we'll start talking a little bit about Kubernetes and OpenShift.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, Azure, GCP), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, Azure, GCP, Terraform, Kubernetes (CKA, CKAD, CKS).