- User ID
- 1
- Joined
- 7 Jan 2019
- Messages
- 1,147
- Reaction score
- 58
- Points
- 48
Many people mistake Linux containers for merely lightweight virtual machines (VMs), thinking you can simply install Ubuntu inside one and call it a day. However, this oversimplification can lead to conceptual errors. Unlike a VM, which cannot operate without an entire operating system, a container might contain only a single static binary, launching just one program upon startup and ceasing once that program terminates.
In their most extreme form, these containers lack:
To modify a container to a more comprehensive Linux environment, one could change the Dockerfile from
Security trends in containerisation lean towards imposing more of these restrictions, not fewer. Notably, images from Chainguard and Google's distroless exemplify this approach, embracing nearly all the limitations listed.
RouterOS and Containers
Focusing specifically on RouterOS, its Containers feature primarily functions on MikroTik’s ARM hardware, which often has limited internal storage and lacks external storage options. Despite this, ARM-based routers like the RB5009 perform comparably to a Raspberry Pi 4 and can benefit from USB or NVMe expansions, supporting more capable container operations.
Practical Implications for RouterOS
RouterOS and its affinity for containers can be likened to the difference between owning a garden and owning a terrarium. Virtual Machines (VMs) are like gardens: they require continuous maintenance, personalisation, and hands-on care. On the other hand, containers resemble terrariums: they are self-contained environments that are designed from the outset to be low-maintenance, with all elements pre-configured and optimized for efficient functioning. This approach minimises the need for spontaneous adjustments, encouraging a focus on pre-scripting and thorough preparation of the Dockerfile and associated scripts, such as a Makefile, to facilitate a seamless deployment process.
Challenges and Misunderstandings
A common misconception is expecting a containerised Linux distro to behave like a full VM. For instance, the official Docker Ubuntu container is merely 29 MiB, starkly contrasted with a full Ubuntu Server ARM ISO of 1.3 GiB, because it only includes the essential runtime and package management necessary for basic operations.
Development and Deployment Recommendations
For container development, starting on a robust system like Ubuntu Desktop with Docker Engine is advisable. This setup facilitates debugging and optimising the container before deploying it to RouterOS. Testing locally on Docker Desktop can reveal issues that would also occur on RouterOS, avoiding unnecessary complications during deployment.
CHR and Container Deployment
Deploying containers directly on MikroTik’s Cloud Hosted Router (CHR) is generally inadvisable due to double virtualisation inefficiencies. Containers should instead be deployed on a dedicated container host OS like Flatcar on a bare-metal hypervisor, or tested thoroughly in a compatible VM environment before deployment on CHR.
Seeking Further Insights
For a broader perspective, consulting resources from major industry players like IBM, Red Hat, Microsoft, Docker Inc., and Cloud-Native Now can provide additional valuable insights into container technologies.
In their most extreme form, these containers lack:
- Systemd or any init systems
- A local or remote shell
- Package management tools
- Login daemons for local or remote access
- Device directories like /dev, /proc, or /sys
- Privileged utilities (e.g., ping)
- Any real users, including a heavily restricted "root"
- Foundational platform libraries like glibc
To modify a container to a more comprehensive Linux environment, one could change the Dockerfile from
FROM scratch… to FROM ubuntu:latest, adding capabilities like a shell and package manager upon rebuilding. However, this won't introduce a GUI or SSH daemon and maintains several limitations akin to operating in a traditional Unix single-user mode.Security trends in containerisation lean towards imposing more of these restrictions, not fewer. Notably, images from Chainguard and Google's distroless exemplify this approach, embracing nearly all the limitations listed.
RouterOS and Containers
Focusing specifically on RouterOS, its Containers feature primarily functions on MikroTik’s ARM hardware, which often has limited internal storage and lacks external storage options. Despite this, ARM-based routers like the RB5009 perform comparably to a Raspberry Pi 4 and can benefit from USB or NVMe expansions, supporting more capable container operations.
Practical Implications for RouterOS
RouterOS and its affinity for containers can be likened to the difference between owning a garden and owning a terrarium. Virtual Machines (VMs) are like gardens: they require continuous maintenance, personalisation, and hands-on care. On the other hand, containers resemble terrariums: they are self-contained environments that are designed from the outset to be low-maintenance, with all elements pre-configured and optimized for efficient functioning. This approach minimises the need for spontaneous adjustments, encouraging a focus on pre-scripting and thorough preparation of the Dockerfile and associated scripts, such as a Makefile, to facilitate a seamless deployment process.
Challenges and Misunderstandings
A common misconception is expecting a containerised Linux distro to behave like a full VM. For instance, the official Docker Ubuntu container is merely 29 MiB, starkly contrasted with a full Ubuntu Server ARM ISO of 1.3 GiB, because it only includes the essential runtime and package management necessary for basic operations.
Development and Deployment Recommendations
For container development, starting on a robust system like Ubuntu Desktop with Docker Engine is advisable. This setup facilitates debugging and optimising the container before deploying it to RouterOS. Testing locally on Docker Desktop can reveal issues that would also occur on RouterOS, avoiding unnecessary complications during deployment.
CHR and Container Deployment
Deploying containers directly on MikroTik’s Cloud Hosted Router (CHR) is generally inadvisable due to double virtualisation inefficiencies. Containers should instead be deployed on a dedicated container host OS like Flatcar on a bare-metal hypervisor, or tested thoroughly in a compatible VM environment before deployment on CHR.
Seeking Further Insights
For a broader perspective, consulting resources from major industry players like IBM, Red Hat, Microsoft, Docker Inc., and Cloud-Native Now can provide additional valuable insights into container technologies.