What are containers in the DevOps world?
0
/
139
What exactly are the containers?
Containers are executable software units in which application code, as well as its libraries and dependencies, are packed in standard ways so that they may be run anywhere, whether on a desktop, on prem private cloud or public cloud.
Block diagram of containers in devops
Containers are tiny, quick, and portable because, unlike virtual machines, they do not require a guest OS in every instance and may instead use the capabilities and resources of the host computer.
Containers achieve this by utilising a type of operating system (OS) virtualization. The characteristics of the OS, in the instance of the Linux kernel,
the namespaces and cgroups primitives, are used to both separate programmes and regulate the amount of CPU, memory, and disc access that those processes have.
How are the containers different from virtual machines ?
Containers and virtual machines both have the same aim in mind: to isolate a programme and its dependencies into a self-contained entity that can operate anywhere.Containers virtualize the operating system (usually Linux) rather than the underlying hardware, thus each container just includes the programme and its libraries and dependencies. Containers are extremely light and portable because they don’t have a guest operating system.
Understanding how a container varies from a regular virtual machine is one method to have a deeper understanding of it (VM). A hypervisor is used to virtualize physical hardware in conventional virtualization, whether on-premises or in the cloud. A guest OS, a virtual duplicate of the hardware that the OS requires to function, as well as an application and its related libraries and dependencies, are all included in each VM.
Containers only package the user space, not the kernel or virtual hardware, like a virtual machine does. To allow numerous containers to function on a single host system, each container has its own segregated user space.
What exactly is a Container Image?
A container image is a static file containing executable code that may be used to start a container on a computer. A container image is immutable, which means it can’t be modified and may be used in any environment. It’s an essential part of any containerized architecture.
Because the image shares the host’s operating system kernel, it doesn’t need to include a whole operating system. Layers are added to a parent picture, also known as a base image, to make up a container image.
Container images provide everything a container needs to run, including the container engine, system libraries, utilities, configuration settings, and particular workloads to execute on the container.
Container images are read-only templates that may be used to construct containers. Containers are instances that are launched from those templates. Images and containers are inextricably linked, and both are required to run the Container software platform. Runnable Container Image instance is Container.
How is the term docker related to container and what is a container engine?
Docker is an open source project that provides a set of tools to assist you in creating containers. It is distributed under the Apache 2.0 licence. DotCloud was the original name for the Docker project, which was renamed Docker in 2013. Docker’s popularity has skyrocketed since then, as has the size of its devoted community.
Docker became the community-wide industry standard for producing containers due to its great utility in developing and distributing software, its expanding popularity, and the timely support of several significant industry leaders.
When it comes to containers, the term “Docker” is frequently used, and many people mistakenly believe that Docker and containers are the same thing. There is, however, a difference.
Docker and containers are no longer synonymous. Docker (the firm) backs some, but not all, of the container technologies available.
Container Engine :
When comparing Docker to other tools, it’s important to split them down into their individual components, and the container engines are the first to come up.
Container engine is a programme that provides a user interface for working with images and containers without having to deal with SECCOMP rules or SELinux policies.
It’s also responsible for downloading images from external sources and expanding them on your hard drive. It also seems to launch the containers, but its true purpose is to build the container manifest and directory containing image layers. The data is then sent to a container runtime such as runc or crun.
Aside from Docker, there are additional container engines to consider:
1. Podman – Podman, unlike Docker, does not require a daemon and does not require root privileges, which has been a long-standing issue with Docker. Podman, as the name suggests, can operate both containers and pods.
2. LXD – LXD is LXC’s container manager (daemon) (Linux Containers). This programme allows you to run system containers, which give a container environment that is more like a virtual machine.
3. CRI-O – You could come across the term “container engine” when searching for “cri-o.” But it is, in fact, container runtime. It’s not only not an engine, but it’s also not fit for “regular” use.
4. rkt – CoreOS’s rkt (“rocket”) container engine. This project has come to an end and development has been discontinued – and as a result, it should not be utilised.
Containers are quickly becoming the preferred method for creating and deploying programmes due to their mobility, small weight, and efficient resource utilisation. However, if you’re building huge, sophisticated apps, you’ll need a lot of containers. You’ll need a variety of container tools to assist you manage these containers.
What is container runtime ?
Container runtime is in charge of executing containers, as the name suggests.
1. runc – The most widely used container runtime is runc, which was developed in accordance with the OCI container runtime standard. With the exception of LXD, it’s utilised by Docker (through containerd), Podman, and CRI-O. (which uses LXC).
2. crun – It is a similar-sounding alternative to runc. This is a Red Hat utility that is entirely written in C, whereas runc is written in Go. This makes it a lot quicker and use less memory than runc.
3. CRI-O – To execute containers, CRI-O as a runtime use runc.
4. Containerd – A CNCF graduation project, is a daemon that serves as an API front end for a variety of container runtimes and operating systems. Runc is the default runtime for the Docker engine, therefore it’s used in the background.
Containerization and Devops
Containerization is a technology that has changed the way we build, distribute,and manage software. Containerized application deployments enable us to
streamline the delivery pipeline while lowering management costs. Following are the stages that make up a typical containerized pipeline :
- Using a version control system, develop and incorporate the modifications.
- Verify and validate the code modifications before merging them.
- Construct the container.
- Set up the staging environment for the container.
- Applicability testing should be carried out.
- In the production environment, deploy the same container.
Container Eco system & Standards –
The container ecosystem is made up of a lot of cool technology, a lot of language, and a lot of huge enterprises vying for market share. Thankfully, these corporations periodically form a tenuous ceasefire to agree on some norms. These standards make the ecosystem more compatible across platforms and operating systems, as well as less reliant on a particular firm or initiative.
The following are the important standards to be aware of –
CRI – The Kubernetes Container Runtime Interface (CRI) is an API that connects Kubernetes with the container runtime.
OCI – The Open Container Initiative (OCI), a group that produces image and container specs.
I hope you now have the knowledge you need to learn more about containers and perhaps utilise them in a project in the future.
Follow us on facebook:- https://facebook.com/golibraryco
Comments
