Linux containers rely on Control groups (cgroups), which not only track groups of processes, but also expose metrics of the CPU, memory, and block I/O usage. You can access these metrics and obtain network usage metrics as well. Cgroups are another important component of Linux containers. Cgroups have been around for a while and were initially merged into the Linux kernel code 2.6.24. They ensure that each Docker container will get a fixed amount of memory, CPU, and disk I/O, so that any container will not able to bring the host machine down at any point of time under any circumstances. Cgroups do not play a role in preventing one container from being accessed, but they are essential to fend off some Denial of Service (DoS) attacks.
On Ubuntu 16.04, a cgroup is implemented in the /sys/fs/cgroup path. The memory information of Docker is available at the /sys/fs/cgroup/memory/docker/ path.
Similarly, the CPU details are made available in the /sys/fs/cgroup/cpu/docker/ path.
Let's find out the maximum limit of memory that can be consumed by the container (41668be6e513e845150abd2dd95dd574591912a7fda947f6744a0bfdb5cd9a85).
For this, you can go to the cgroup memory path and check for the memory.max_usage_in_bytes file:
/sys/fs/cgroup/memory/docker/41668be6e513e845150abd2dd95dd574591912a7 fda947f6744a0bfdb5cd9a85
Execute the following command to see the contents:
$ cat memory.max_usage_in_bytes
13824000
So, by default, any container can use up to 13.18 MB memory only. Similarly, CPU parameters can be found in the following path:
/sys/fs/cgroup/cpu/docker/41668be6e513e845150abd2dd95dd574591912a7fda 947f6744a0bfdb5cd9a85
Traditionally, Docker runs only one process inside the containers. So typically, you have seen people running three containers each for PHP, NGINX, and MySQL. However, this is a myth. You can run all your three processes inside a single container also.
Docker isolates many aspects of the underlying host from an application running in a container without the root privileges. However, this separation is not as strong as that of virtual machines, which run independent OS instances on top of a hypervisor without sharing the kernel with the underlying OS. It's not a good idea to run applications with different security profiles as containers on the same host, but there are security benefits to encapsulate different applications into containerized applications that would otherwise run directly on the same host.