From cf21703244bc07449cf4d424598236e7eeadc3ef Mon Sep 17 00:00:00 2001 From: Annwan Date: Sun, 24 Mar 2024 22:25:53 +0100 Subject: [PATCH] Fix typos --- .../computers/20240324-containers-what-why-and-how/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/computers/20240324-containers-what-why-and-how/index.md b/content/computers/20240324-containers-what-why-and-how/index.md index d51a213..9d59ca8 100644 --- a/content/computers/20240324-containers-what-why-and-how/index.md +++ b/content/computers/20240324-containers-what-why-and-how/index.md @@ -48,15 +48,15 @@ But more crucially they also allow to isolate across cgroups, giving the illusio With those mechanisms (chroot, cgroups and namespaces) in place creating a container is conceptually relatively simple: -- First you populate the subtree that your container will have access too, ready to be chroot-ed in +- First you populate the subtree that your container will have access too, ready to be chroot'ed in - Then you create namespaces for all you need to isolate (this usually includes at least PID, UID, mountpoints and cgroups) -- Finally you run your containerized process within your namespaces, chroot'ed to it's subtree +- Finally you run your containerized process within your namespaces, chroot'ed to its subtree ## Conclusion {{}} -In practice you don't need to make them from scratch, people already have made systems for managing containers with nicer user interfaces those include Docker, LXC and systemd-nspawn just to name a few, and there is probably one just right for your use-case. +In practice you don't need to make them from scratch, people already have made systems for managing containers with nicer user interfaces. Those include Docker, LXC and systemd-nspawn just to name a few, and there is probably one just right for your use-case. ## Sources