| I don't think so. Instead we created an artifact which can live inside an OS, but cannot see and touch to the rest of the OS. CGroups is a deceptively powerful mechanism. You can isolate a process resource wise (X cores, Y amount of memory, Z amount of swap), network wise (a different virtual network adapter with its own IP, bandwidth limits, etc.) and FS wise (running in its own filesystem with devices it can see). It can keep your system tidy by encapsulating elaborate stacks which makes system management painful, allows deterministic operation and image generation if you tag everything with version. Downside is you can do bad things with it like terminating HTTPS with a gateway container and talk HTTP among your backend instead of configuring tools, or writing shoddy software, and getting away with it because it works, or gets automatically restarted when it crashes 6 times a day. I don't run every service as a container, because some services suffocate when they are in a container, but for short running things which needs system-wide changes to function, or test-driving small services before fully committing, it's a good tool to have. However, it's abused with no end, and their popular use leaves a bad taste in your mouth. |
If you have a statically linked executable, setup the cgroup for it as you will. No containers needed. You can namespace is as well.
No `FROM X` `RUN Y` dockerfile stuff needed.