decode html entities from imported files
[homepage.git] / src / _posts / 2018-07-04-bare-bone-containers-with-systemd-nspawn.md
index 98281a8..d7f35d5 100644 (file)
@@ -62,13 +62,13 @@ Furthermore, what even is an application? Is it a single program or daemon? Or a
 
 #### How to NOT use a container?
 
-Sometimes (web)developers see the Linux systems that run their (web)applications as a house of card that they better not touch or they don’t want to deal with security and quality policies of various Linux distributions. The reason being, that if it works for them, it should work just like that for the end-user. Conveniently containers now allow us to package an applications plus the whole linux ecosystem around it. Unfortunately this just makes everything worse. It makes it harder to actually secure and separate applications from each other while providing a false semblance of security.
+Sometimes (web)developers see the Linux systems that run their (web)applications as a house of card that they better not touch or they don’t want to deal with security and quality policies of various Linux distributions. The reason being, that if it works for them, it should work just like that for the end-user. Conveniently containers now allow us to package an applications plus the whole linux ecosystem around it. Unfortunately this just makes everything worse. It makes it harder to actually secure and separate applications from each other while providing a false semblance of security.
 
-### What is chroot and what can and can’t it do?
+### What is chroot and what can and can’t it do?
 
 A chroot is a root file system (e.g. a whole Linux distribution) inside your host root file system in which a program runs.
   
-The idea being that a chrooted application can not access any file outside it’s chroot.
+The idea being that a chrooted application can not access any file outside it’s chroot.
   
 Obviously then you have to provide (duplicate) all the tools and applications that will be needed inside the chroot filesystem.
   
@@ -80,33 +80,33 @@ E.g. The root user inside a chroot can easly read harddisk device or re-mount it
 
 ### Links to some great introduction to cgroups I came across
 
-The RedHat-blog has some very good hands-on introduction articles on cgroups called “World domination with Cgroups” I suggest you read them:
+The RedHat-blog has some very good hands-on introduction articles on cgroups called “World domination with Cgroups” I suggest you read them:
 
   * <p class="hero1-title">
-      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-1-cgroup-basics">Part 1 &#8211; Cgroup basics</a>
+      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-1-cgroup-basics">Part 1 – Cgroup basics</a>
     </p>
 
   * <p class="hero1-title">
-      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-2-turning-knobs">Part 2 &#8211; Turning Knobs</a>
+      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-2-turning-knobs">Part 2 – Turning Knobs</a>
     </p>
 
   * <p class="hero1-title">
-      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-3-thanks-memories">Part 3 &#8211; Thanks for the memories</a>
+      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-3-thanks-memories">Part 3 – Thanks for the memories</a>
     </p>
 
   * <p class="hero1-title">
-      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-4-all-ios">Part 4 &#8211; All the I/Os</a>
+      <a href="https://www.redhat.com/en/about/blog/world-domination-cgroups-part-4-all-ios">Part 4 – All the I/Os</a>
     </p>
 
-&nbsp;
 
 ### Restrict services using systemd unit files
 
-Sometimes you just want to contain a single executable. In that case you might not truly need a full machine, you can chroot a service and restrict it just using it&#8217;s .service file.
+Sometimes you just want to contain a single executable. In that case you might not truly need a full machine, you can chroot a service and restrict it just using it’s .service file.
 
 My favorite: <tt>SystemCallFilter</tt>! it filters what syscalls a process is allowed to use.
 
-e.g. you could run a program or bunch of programs with _strace -c &#8212; <cmd>_ and put the list of syscalls at the end in the systemd unit file.
+e.g. you could run a program or bunch of programs with _strace -c — <cmd>_ and put the list of syscalls at the end in the systemd unit file.
 
 Other extremely useful directives you should read up on:
 
@@ -127,7 +127,7 @@ MountFlags=
 AmbientCapabilities=\r
 CapabilityBoundingSet=</pre>
 
-&nbsp;
 
 chroot:
 
@@ -135,7 +135,7 @@ chroot:
 
 ### What about containers as virtual machines replacement? Enter systemd-nspawn
 
-systemd-nspawn is systemd&#8217;s tool to run containers like you would a virtual machine. Thus &#8216;nspawn containers are called &#8220;machines&#8221; and are managed with the tool <tt>machinectl</tt>. Actually machinectl interfaces not only with systemd-nspawn but also rkt, docker, libvirt and others, thus providing a convenient place to manage all your running virtualisations at once.
+systemd-nspawn is systemd’s tool to run containers like you would a virtual machine. Thus ‘nspawn containers are called “machines” and are managed with the tool <tt>machinectl</tt>. Actually machinectl interfaces not only with systemd-nspawn but also rkt, docker, libvirt and others, thus providing a convenient place to manage all your running virtualisations at once.
 
 ### Putting our application into an container.