6 ms·

My default question I give to interviewees looking for a dev or devops position is to tell me what a container is. Usually I get the "well it's like a vm but no

My default question I give to interviewees looking for a dev or devops position is to tell me what a container is. Usually I get the "well it's like a vm but not a vm" and then I ask the followup which is to ask what are the differences between a container and vm? A lot of hemming and hawing but in the 6 or so years I've been interviewing people who are going to be using Docker, I have yet to hear the answer that I give when I interview, which is, "a container is a process." I usually leave it at that and wait to see if I get a confused look on their face. Then I say, "with cgroups and namespaces". It's really not that complicated (to explain anyways). EDIT: I found this link at the bottom of the OP's blog that was even better at simplifying things, https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ https://jvns.ca/blog/2016/10/10/what-even-is-a-container/

mellosouls 5y ago
I'm not sure a "A process with cgroups and namespaces" makes things much clearer though somebody with understanding of those might infer certain properties. "a kind of lightweight VM" seems a much more intuitive answer, with limitations. The link is useful tho, she's a good writer.
- nomoreplease 5y ago
  Not OP but I also interview. I see CGroups and namespaces is a follow up to “how does it work or how is it usually isolated?” And I ask “why would I use it?” Or “when would I choose containers over vm?” Or vice versa to get to actual architectural decisions The wrong answer usually involves a lot of hemming and hawing
  - mellosouls 5y ago
    Yeah tbf it was offered as a follow on question, I'm just not sure it makes things clearer in describing functional and design differences.
- stuff4ben 5y ago
  Except "a kind of lightweight VM" is an incorrect answer. I'm trying to gauge if the person knows what they're talking about because running Docker and Kubernetes in production is hard. I don't want someone thinking they can go into some vsphere console to reboot their VMs when a pod is having problems.
  - mellosouls 5y ago
    Except "a kind of lightweight VM" is an incorrect answer It's a pretty reasonable starting point as a description compared to the meaningless rejoinder which says nothing about what the point of them is.
- nonameiguess 5y ago
  But they're trying to figure out if the person they're interviewing has the level of knowledge necessary to understand what a process sandboxed from other processes in its own cgroup and namespaces means, not trying to give an intuitive description to someone who doesn't understand how Linux works.
nonameiguess 5y ago
That's not usually complete. Minimally, it's a process in its own PID namespace. But assuming it's an OCI container, which will be the case if you're using any common managed container runtime and not rolling your own, it's a process in its own user namespace, mount namespace, UTS namespace, cgroup namespace, IPC namespace, and time namespace. It's assigned its own hostname and IP in the new UTS namespace. It runs in a chroot in the new mount namespace to a root filesystem assembled via overlay with a single writeable layer on top of N read-only layers shared with any other container that is launched from the same image. It gets bind mounts, kernel VFS mounts, an environment, and an entrypoint command from a config file colocated with the root filesystem in a container bundle created from the image defaults, system defaults, and command line overrides. The simplest way to compare it to a VM is a container is the Linux kernel using namespaces and cgroups to scope the services and resources it presents to a single userspace process. A VM is a hypervisor presenting virtualized hardware and BIOS services to guest kernels.
- stuff4ben 5y ago
  You're being a bit obtuse or maybe you just wanted to show off your knowledge a bit. I said basically the same, "it's a process... with namespaces and cgroups." If they can answer that and know what that means, I'm good and I go to my other interview questions. I'm not hiring a Docker developer or someone who needs to know the internals of Linux. I'm hiring SREs who manage and oversee Docker and Kubernetes production environments.
  - sombremesa 5y ago
    Technically you don’t need to know what a container “is” to oversee Docker and Kubernetes production environments (knowing that it’s not a VM is a plus, but then you already knew that by calling it a container rather than a VM). A container can just be a container, and you can leave it at that. If a zookeeper starts talking about jackdaws and crows in an interview, who’s the one being obtuse and trying to show off their knowledge? The important thing is that the animals are taken care of and the zoo visitors are happy.
    - 5y ago
zekrioca 5y ago
Usually, Docker used to be "a process with cgroups and namespaces". But it has evolved since then [1], although I'd agree that fundamentally, the "process + cgroups + namespaces" is a correct answer. [1] From their own FAQ: https://docs.docker.com/engine/faq/#what-does-docker-technology-add-to-just-plain-lxc https://docs.docker.com/engine/faq/#what-does-docker-technol...
- stuff4ben 5y ago
  Agreed, if I was asking what "Docker" was. I ask what a "container" is to skirt around that. Although I sometimes do ask what is Docker too.
  - zekrioca 5y ago
    It is just that nowadays the definition of a "Container" depends on the scope, and presumably "Docker" is an instance of a container. But I'd expect an interviewee to reply with "what type of OS-level virtualization tool are you referring to?", in which case you would get both a proper answer and a request for clarification :)
teraflop 5y ago
I think it's fairly important to say that a container is a process tree, not necessarily a single process. A lot of things wouldn't behave properly if a forked child process wasn't part of the same container as its parent. (Of course, it might not truly be a tree either, because you can use tools like nsenter to put additional processes into the PID namespace without them being children of the container's PID 1. But a tree is the common case.)
- tinalumfoil 5y ago
  I would argue that the virtualization aspect is more important than the processiness of a container. Sure it's a process but it's a process that you've carefully controlled the resources it can access. You've put it in its own network namespace, you've rebuilt it's filesystem so it sees an entirely different / than the rest of the system, etc etc. If the process isn't checking, you can make it behave like it's in its own little world, with it's own kernel. Because of that, it's much more predictable than just a process. Saying it's a process is mostly correct, and saying it's a process tree is a guess even more correct I think they both miss the point.

mellosouls 5y ago

I'm not sure a "A process with cgroups and namespaces" makes things much clearer though somebody with understanding of those might infer certain properties. "a kind of lightweight VM" seems a much more intuitive answer, with limitations. The link is useful tho, she's a good writer.

nomoreplease 5y ago
Not OP but I also interview. I see CGroups and namespaces is a follow up to “how does it work or how is it usually isolated?” And I ask “why would I use it?” Or “when would I choose containers over vm?” Or vice versa to get to actual architectural decisions The wrong answer usually involves a lot of hemming and hawing
- mellosouls 5y ago
  Yeah tbf it was offered as a follow on question, I'm just not sure it makes things clearer in describing functional and design differences.
stuff4ben 5y ago
Except "a kind of lightweight VM" is an incorrect answer. I'm trying to gauge if the person knows what they're talking about because running Docker and Kubernetes in production is hard. I don't want someone thinking they can go into some vsphere console to reboot their VMs when a pod is having problems.
- mellosouls 5y ago
  Except "a kind of lightweight VM" is an incorrect answer It's a pretty reasonable starting point as a description compared to the meaningless rejoinder which says nothing about what the point of them is.
nonameiguess 5y ago
But they're trying to figure out if the person they're interviewing has the level of knowledge necessary to understand what a process sandboxed from other processes in its own cgroup and namespaces means, not trying to give an intuitive description to someone who doesn't understand how Linux works.

nonameiguess 5y ago

That's not usually complete. Minimally, it's a process in its own PID namespace. But assuming it's an OCI container, which will be the case if you're using any common managed container runtime and not rolling your own, it's a process in its own user namespace, mount namespace, UTS namespace, cgroup namespace, IPC namespace, and time namespace. It's assigned its own hostname and IP in the new UTS namespace. It runs in a chroot in the new mount namespace to a root filesystem assembled via overlay with a single writeable layer on top of N read-only layers shared with any other container that is launched from the same image. It gets bind mounts, kernel VFS mounts, an environment, and an entrypoint command from a config file colocated with the root filesystem in a container bundle created from the image defaults, system defaults, and command line overrides. The simplest way to compare it to a VM is a container is the Linux kernel using namespaces and cgroups to scope the services and resources it presents to a single userspace process. A VM is a hypervisor presenting virtualized hardware and BIOS services to guest kernels.

stuff4ben 5y ago
You're being a bit obtuse or maybe you just wanted to show off your knowledge a bit. I said basically the same, "it's a process... with namespaces and cgroups." If they can answer that and know what that means, I'm good and I go to my other interview questions. I'm not hiring a Docker developer or someone who needs to know the internals of Linux. I'm hiring SREs who manage and oversee Docker and Kubernetes production environments.
- sombremesa 5y ago
  Technically you don’t need to know what a container “is” to oversee Docker and Kubernetes production environments (knowing that it’s not a VM is a plus, but then you already knew that by calling it a container rather than a VM). A container can just be a container, and you can leave it at that. If a zookeeper starts talking about jackdaws and crows in an interview, who’s the one being obtuse and trying to show off their knowledge? The important thing is that the animals are taken care of and the zoo visitors are happy.
  - 5y ago

zekrioca 5y ago

Usually, Docker used to be "a process with cgroups and namespaces". But it has evolved since then [1], although I'd agree that fundamentally, the "process + cgroups + namespaces" is a correct answer. [1] From their own FAQ: https://docs.docker.com/engine/faq/#what-does-docker-technology-add-to-just-plain-lxc https://docs.docker.com/engine/faq/#what-does-docker-technol...

stuff4ben 5y ago
Agreed, if I was asking what "Docker" was. I ask what a "container" is to skirt around that. Although I sometimes do ask what is Docker too.
- zekrioca 5y ago
  It is just that nowadays the definition of a "Container" depends on the scope, and presumably "Docker" is an instance of a container. But I'd expect an interviewee to reply with "what type of OS-level virtualization tool are you referring to?", in which case you would get both a proper answer and a request for clarification :)

teraflop 5y ago

I think it's fairly important to say that a container is a process tree, not necessarily a single process. A lot of things wouldn't behave properly if a forked child process wasn't part of the same container as its parent. (Of course, it might not truly be a tree either, because you can use tools like nsenter to put additional processes into the PID namespace without them being children of the container's PID 1. But a tree is the common case.)

tinalumfoil 5y ago
I would argue that the virtualization aspect is more important than the processiness of a container. Sure it's a process but it's a process that you've carefully controlled the resources it can access. You've put it in its own network namespace, you've rebuilt it's filesystem so it sees an entirely different / than the rest of the system, etc etc. If the process isn't checking, you can make it behave like it's in its own little world, with it's own kernel. Because of that, it's much more predictable than just a process. Saying it's a process is mostly correct, and saying it's a process tree is a guess even more correct I think they both miss the point.