Are all containers just Linux processes? How does the OCI runtime specification define a container? What platforms do OCI containers support? What is a Docker container? Linux containers vs. Virtual Machine containers.
There are terminology issues here, both in the Lemmy post title, in the article body, and in the article’s TL;DR. Basically, nothing is internally consistent except maybe the OCI Runtime spec itself, although its terminological relevancy is a separate issue.
Lemmy title: Containers are not Linux containers
Article title: What Is a Standard Container: Diving Into the OCI Runtime Spec
Both titles imply the existence of non-Linux containers, yet only the latter actually describes the contents of the article, specifically naming the “other” type of container, being “Standard Containers” defined by the OCI Runtime spec. As a title, I greatly prefer the latter, whereas the former is unnecessarily antagonistic.
That aside, the article could really be helped by a central glossary section, as it refers to all of these as containers, without prefacing that these can all validly be called “containers”:
OCI-compliant containers
Standard containers
Linux containers
Docker containers
Kata VM-based containers
Other VM-based containers that have been deprecated
If the goal was to distinguish what each of these mean, the article doesn’t do that great of a job, other than to say “these exist and aren’t Linux containers, except Linux containers are obviously Linux containers”.
Reframing what I think the article tried to convey, while borrowing some terminology from C++/Python, the OCI Runtime specification defines an Abstract Base Class known as a Standard Container. A Standard Container supports the most minimal functions of starting and stopping an execution runtime. For Linux, FreeBSD, Kata, etc, those containers are subclasses of the Standard Container.
For the most part, unless your containerized application is purely computational and has zero dependencies upon the OS, your container will be one of the subclasses. There are essentially zero practical container images that can meet the zero-dependency requirements of being a Standard Container. So while it’s true that any runtime capable of running the container subclasses could also run a Standard Container, it is of little value in production. Hence why I assert that it’s an abstract base class: it cannot really be instantiated in real life.
This is the reality of containers: none can abstract away an application’s dependency upon the OS. The container will still rely upon Win32 calls, POSIX calls, /proc, BSD sockets, or whatever else. So necessarily, all practical containers need a kernel layer. Even the case of Kata’s VM-based containers just mean that the kernel is included within the container. Portability in this context just means that the kernel version can change beneath, but you cannot take a Linux container and run it on FreeBSD, not without shims and other runtime kludges.
There are terminology issues here, both in the Lemmy post title, in the article body, and in the article’s TL;DR. Basically, nothing is internally consistent except maybe the OCI Runtime spec itself, although its terminological relevancy is a separate issue.
Both titles imply the existence of non-Linux containers, yet only the latter actually describes the contents of the article, specifically naming the “other” type of container, being “Standard Containers” defined by the OCI Runtime spec. As a title, I greatly prefer the latter, whereas the former is unnecessarily antagonistic.
That aside, the article could really be helped by a central glossary section, as it refers to all of these as containers, without prefacing that these can all validly be called “containers”:
If the goal was to distinguish what each of these mean, the article doesn’t do that great of a job, other than to say “these exist and aren’t Linux containers, except Linux containers are obviously Linux containers”.
Reframing what I think the article tried to convey, while borrowing some terminology from C++/Python, the OCI Runtime specification defines an Abstract Base Class known as a Standard Container. A Standard Container supports the most minimal functions of starting and stopping an execution runtime. For Linux, FreeBSD, Kata, etc, those containers are subclasses of the Standard Container.
For the most part, unless your containerized application is purely computational and has zero dependencies upon the OS, your container will be one of the subclasses. There are essentially zero practical container images that can meet the zero-dependency requirements of being a Standard Container. So while it’s true that any runtime capable of running the container subclasses could also run a Standard Container, it is of little value in production. Hence why I assert that it’s an abstract base class: it cannot really be instantiated in real life.
This is the reality of containers: none can abstract away an application’s dependency upon the OS. The container will still rely upon Win32 calls, POSIX calls, /proc, BSD sockets, or whatever else. So necessarily, all practical containers need a kernel layer. Even the case of Kata’s VM-based containers just mean that the kernel is included within the container. Portability in this context just means that the kernel version can change beneath, but you cannot take a Linux container and run it on FreeBSD, not without shims and other runtime kludges.
thx. I just reposted from reddit