trent
/
trentdocs_website
mirror of https://github.com/TrentSPalmer/trentdocs_website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

extend docs/nspawn.md

This commit is contained in:
Trent Palmer 2017-06-29 16:11:32 -07:00
parent 09a172d608
commit 3f2df33444
4 changed files with 82 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/nspawn.md
View File

@ -2,6 +2,8 @@
[This Link For Arch Linux Wiki for Nspawn Containers](https://wiki.archlinux.org/index.php/Systemd-nspawn)
I like the idea of starting with the easy containers first.
### Create a FileSystem
```bash
@ -24,6 +26,15 @@ At this point you might want to copy over some configs to save time later.
```bash
systemd-nspawn -b -D <container>
passwd
# assuming you copied over /etc/locale.gen
locale-gen
# set timezone
timedatectl set-timezone <timezone>
# enable network time
timedatectl set-ntp 1
# enable networking
systemctl enable systemd-networkd
systemctl enable systemd-resolved
poweroff
# if you want to nat the container add *-n* flag
systemd-nspawn -b -D <container> -n
@ -32,6 +43,7 @@ systemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg
```
### Networking
Here's a link that skips ahead to [Automatically Starting the Container](#automatically-starting-the-container)
On Arch, assuming you have systemd-networkd and systemd-resolved
set up correctly, networking from the host end of things should
@ -52,7 +64,7 @@ Kind=bridge
Name=br0
[Network]
Address=10.0.55.1/24
Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste
DHCPServer=yes
IPMasquerade=yes
```
@ -70,6 +82,8 @@ systemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/p
```
### Automatically Starting the Container
Here's a link back up to [Networking](#networking)
in case you previously skipped ahead.
There are two ways to automate starting the container. You can override
`systemd-nspawn@.service` or create an *nspawn* file.
@ -112,6 +126,9 @@ machinectl shell <container>
bash
```
This would be a good time to check for network and name resolution,
symlink resolv.conf if need be.
### Initial Configuration Inside The Container
```bash
@ -131,3 +148,21 @@ ping -c 3 google.com
```
[If you want to change the locale](https://wiki.archlinux.org/index.php/locale)
## Final Observations
* You can start/stop nspawn containers with `machinectl` command.
* You can start nspawn containers with `systemd-nspawn` command.
* You can configure the systemd service for a container with @nspawn.service file override
* Or you can configure an nspawn container with a dot.nspawn file
But in regards to the above list
I have noticed differences in behaviour,
in some scenarios, concerning file attributes
for bind mounts.
Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,
they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might
be able to resolve each other if they are all connected to the same bridge interface or nspawn
network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,
or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers
to talk to each other. But I intend to look into this some more.

2
site/index.html
View File

@ -174,5 +174,5 @@
<!--
MkDocs version : 0.16.3
Build Date UTC : 2017-06-29 16:12:17
Build Date UTC : 2017-06-29 23:11:25
-->

15
site/mkdocs/search_index.json
View File

@ -142,12 +142,12 @@
},
{
"location": "/nspawn/",
"text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir <container>\n# use pacstrap to create a file system\npacstrap -i -c -d <container> base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D <container>\npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file. \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@<container>.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/<container>.nspawn\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash\n\n\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale",
"text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nI like the idea of starting with the easy containers first.\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir <container>\n# use pacstrap to create a file system\npacstrap -i -c -d <container> base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D <container>\npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone <timezone>\n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nHere's a link that skips ahead to \nAutomatically Starting the Container\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nHere's a link back up to \nNetworking\n\nin case you previously skipped ahead.\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file. \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@<container>.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/<container>.nspawn\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash\n\n\n\n\nThis would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale\n\n\nFinal Observations\n\n\n\n\nYou can start/stop nspawn containers with \nmachinectl\n command. \n\n\nYou can start nspawn containers with \nsystemd-nspawn\n command.\n\n\nYou can configure the systemd service for a container with @nspawn.service file override\n\n\nOr you can configure an nspawn container with a dot.nspawn file\n\n\n\n\nBut in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts.\n\n\nAnother curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.",
"title": "Nspawn"
},
{
"location": "/nspawn/#nspawn-containers",
"text": "This Link For Arch Linux Wiki for Nspawn Containers",
"text": "This Link For Arch Linux Wiki for Nspawn Containers I like the idea of starting with the easy containers first.",
"title": "Nspawn Containers"
},
{
@ -157,17 +157,17 @@
},
{
"location": "/nspawn/#first-boot-and-create-root-password",
"text": "systemd-nspawn -b -D <container>\npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg",
"text": "systemd-nspawn -b -D <container>\npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone <timezone>\n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D <container> -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg",
"title": "First boot and create root password"
},
{
"location": "/nspawn/#networking",
"text": "On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done. # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other. # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg",
"text": "Here's a link that skips ahead to Automatically Starting the Container On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done. # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other. # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pacman/pkg",
"title": "Networking"
},
{
"location": "/nspawn/#automatically-starting-the-container",
"text": "There are two ways to automate starting the container. You can override systemd-nspawn@.service or create an nspawn file. First enable machines.target # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service Edit /etc/systemd/system/systemd-nspawn@<container>.service to add the systemd-nspawn options\nyou want to the ExecStart command. Or create /etc/systemd/nspawn/<container>.nspawn # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0 # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though # in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash",
"text": "Here's a link back up to Networking \nin case you previously skipped ahead. There are two ways to automate starting the container. You can override systemd-nspawn@.service or create an nspawn file. First enable machines.target # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@<container>.service Edit /etc/systemd/system/systemd-nspawn@<container>.service to add the systemd-nspawn options\nyou want to the ExecStart command. Or create /etc/systemd/nspawn/<container>.nspawn # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0 # /etc/systemd/nspawn/<container>.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though # in either case\nsystemctl start/enable systemd-nspawn@<container>\n# to get a shell\nmachinectl shell <container>\n# and then to get an environment\nbash This would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.",
"title": "Automatically Starting the Container"
},
{
@ -175,6 +175,11 @@
"text": "# set time zone if you don't want UTC\ntimedatectl set-timezone <timezone>\n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com If you want to change the locale",
"title": "Initial Configuration Inside The Container"
},
{
"location": "/nspawn/#final-observations",
"text": "You can start/stop nspawn containers with machinectl command. You can start nspawn containers with systemd-nspawn command. You can configure the systemd service for a container with @nspawn.service file override Or you can configure an nspawn container with a dot.nspawn file But in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts. Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.",
"title": "Final Observations"
},
{
"location": "/arch_redis_nspawn/",
"text": "Quick Dirty Redis Nspawn Container on Arch Linux\n\n\nRefer to the \nNspawn\n page for setting up the nspawn container,\ninstall redis, and start/enable redis.service.\nOnce you have the container running, it seems all you have to do to get\nthings working in a container subnet is to change the bind address.\n\n\n# /etc/redis.conf\n# bind 127.0.0.1\nbind 0.0.0.0\n\n\n\n\nyou can nmap port 6379, be sure to restart redis\n\n\nAgain I would refer you to the Arch Wiki",

36
site/nspawn/index.html
View File

@ -76,6 +76,8 @@
<li><a class="toctree-l3" href="#initial-configuration-inside-the-container">Initial Configuration Inside The Container</a></li>
<li><a class="toctree-l3" href="#final-observations">Final Observations</a></li>
</ul>
@ -126,6 +128,7 @@
<h1 id="nspawn-containers">Nspawn Containers</h1>
<p><a href="https://wiki.archlinux.org/index.php/Systemd-nspawn">This Link For Arch Linux Wiki for Nspawn Containers</a></p>
<p>I like the idea of starting with the easy containers first.</p>
<h3 id="create-a-filesystem">Create a FileSystem</h3>
<pre><code class="bash">cd /var/lib/machines
# create a directory
@ -143,6 +146,15 @@ pacstrap -i -c -d &lt;container&gt; base --ignore linux
<h3 id="first-boot-and-create-root-password">First boot and create root password</h3>
<pre><code class="bash">systemd-nspawn -b -D &lt;container&gt;
passwd
# assuming you copied over /etc/locale.gen
locale-gen
# set timezone
timedatectl set-timezone &lt;timezone&gt;
# enable network time
timedatectl set-ntp 1
# enable networking
systemctl enable systemd-networkd
systemctl enable systemd-resolved
poweroff
# if you want to nat the container add *-n* flag
systemd-nspawn -b -D &lt;container&gt; -n
@ -151,6 +163,7 @@ systemd-nspawn -b -D &lt;container&gt; -n --bind=/var/cache/pacman/pkg
</code></pre>
<h3 id="networking">Networking</h3>
<p>Here's a link that skips ahead to <a href="#automatically-starting-the-container">Automatically Starting the Container</a></p>
<p>On Arch, assuming you have systemd-networkd and systemd-resolved
set up correctly, networking from the host end of things should
just work.<br />
@ -167,7 +180,7 @@ Kind=bridge
Name=br0
[Network]
Address=10.0.55.1/24
Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste
DHCPServer=yes
IPMasquerade=yes
</code></pre>
@ -183,6 +196,8 @@ systemd-nspawn -b -D &lt;container&gt; --network-bridge=br0 --bind=/var/cache/pa
</code></pre>
<h3 id="automatically-starting-the-container">Automatically Starting the Container</h3>
<p>Here's a link back up to <a href="#networking">Networking</a>
in case you previously skipped ahead.</p>
<p>There are two ways to automate starting the container. You can override
<code>systemd-nspawn@.service</code> or create an <em>nspawn</em> file. </p>
<p>First enable machines.target</p>
@ -217,6 +232,8 @@ machinectl shell &lt;container&gt;
bash
</code></pre>
<p>This would be a good time to check for network and name resolution,
symlink resolv.conf if need be.</p>
<h3 id="initial-configuration-inside-the-container">Initial Configuration Inside The Container</h3>
<pre><code class="bash"># set time zone if you don't want UTC
timedatectl set-timezone &lt;timezone&gt;
@ -234,6 +251,23 @@ ping -c 3 google.com
</code></pre>
<p><a href="https://wiki.archlinux.org/index.php/locale">If you want to change the locale</a></p>
<h2 id="final-observations">Final Observations</h2>
<ul>
<li>You can start/stop nspawn containers with <code>machinectl</code> command. </li>
<li>You can start nspawn containers with <code>systemd-nspawn</code> command.</li>
<li>You can configure the systemd service for a container with @nspawn.service file override</li>
<li>Or you can configure an nspawn container with a dot.nspawn file</li>
</ul>
<p>But in regards to the above list
I have noticed differences in behaviour,
in some scenarios, concerning file attributes
for bind mounts.</p>
<p>Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,
they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might
be able to resolve each other if they are all connected to the same bridge interface or nspawn
network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,
or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers
to talk to each other. But I intend to look into this some more.</p>
</div>
</div>