- Home
- >
- Software Development
- >
- How to Create a Bridged Network for LXD Containers – InApps Technology 2022
How to Create a Bridged Network for LXD Containers – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn How to Create a Bridged Network for LXD Containers – InApps Technology in today’s post !
Read more about How to Create a Bridged Network for LXD Containers – InApps Technology at Wikipedia
You can find content about How to Create a Bridged Network for LXD Containers – InApps Technology from the Wikipedia website
When it comes to containers, LXD might not be at the forefront of your mind. That’s a shame because this tool is an outstanding route for developers to begin working with containers, in a virtual machine kind of way. LXD is an image-based container deployment platform that bears some resemblance to Ubuntu’s Multipass. In fact, if you’ve used Multipass, you’ll feel right at home with LXD. The biggest difference is that LXD gives you a few more environment options to play with.
The one drawback to using such a tool (instead of working directly with, say, Docker) is similar to that of Kubernetes — accessing the actual containers from your LAN. With Kubernetes, you must deploy special services to reach those containers. With LXD, on the other hand, in order to reach those virtualized containers you need to create a network bridge.
How you do this will depend on the host you’re using to deploy LXD. I’m going to walk you through this process using Ubuntu Server 18.04. This particular Linux distribution uses Netplan to configure networking devices. Netplan configuration files are YAML-based, so anyone that’s worked with Docker or Kubernetes should be instantly familiar with the layout of these files.
In order to make this work, you’ll need to have LXD up and running and a container deployed. For this, you’ll want to give my article “How to Deploy Containers with LXD” a read.
With that out of the way, let’s make this happen.
Create a Netplan Bridge
The first thing you must do is create a bridge using Netplan. This is done on the host computer. Netplan uses configuration files found in /etc/netplan. We’re going to edit the existing file and add the bridge to that. Before you touch that file, you’ll want to back it up.
Find out the name of the Netplan file with the command:
ls /etc/netplan/
You’ll see something like 01-netcfg.yaml (or maybe 50-cloud-init.yaml) listed. Back that file up with the command:
sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak
Now that you have your Netplan file backed up, let’s open it for editing with the command:
sudo nano /etc/netplan/01-netcfg.yaml
That file will look something like:
network: version: 2 renderer: networkd ethernets: ens5: dhcp4: no addresses: [192.168.1.222/24] gateway4: 192.168.1.1 nameservers: addresses: [8.8.4.4,8.8.8.8] |
As I mentioned earlier, this is a YAML file, so you must pay close attention to the indentation.
The first thing we’ll do is comment out everything below the dhcp4 line, so the file will now look like this:
network: version: 2 renderer: networkd ethernets: ens5: dhcp4: no # addresses: [192.168.1.222/24] # gateway4: 192.168.1.1 # nameservers: # addresses: [8.8.4.4,8.8.8.8] |
We now set dhcp6 to no and create a bridge (named br0) with a section in the file that looks like:
<i> </i><i> </i>dhcp6: no
bridges: br0: interfaces: [ens5] addresses: [192.168.1.222/24] gateway4: 192.168.1.1 mtu: 1500 nameservers: addresses: [8.8.8.8] parameters: stp: true forward–delay: 4 |
You’ll want to make sure to change the IP addresses above to match your network topology. Save and close the file.
The entire file should now look like:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | network: version: 2 renderer: networkd ethernets: ens5: dhcp4: no dhcp6: no # addresses: [192.168.1.222/24] # gateway4: 192.168.1.1 # nameservers: # addresses: [8.8.4.4,8.8.8.8]
bridges: br0: interfaces: [ens5] addresses: [192.168.1.222/24] gateway4: 192.168.1.1 mtu: 1500 nameservers: addresses: [8.8.8.8] parameters: stp: true forward–delay: 4 |
Other than the bridge name, the only difference to the new configuration is that we’ve added the following options:
- stp – which enables the Spanning Tree Protocol.
- forward-delay – which defines the period of time the bridge will remain in both the Listening and Learning states before it moves to the Forwarding state.
Now we use the netplan command to generate the configuration with the command:
sudo netplan generate
Finally, apply the configuration with the command:
sudo netplan apply
Your Netplan bridge is now ready to use with LXD.
How to Use the Bridge with LXD
Let’s deploy a new container with the command:
lxc launch ubuntu:20.04
Once the container launches you’ll see it listed (along with its internal IP address) with the command:
lxc list
You should see something like that shown in Figure 1.
The problem is, the container has been issued an internal IP address of 10.25.79.150, which we cannot reach from our LAN. That’s why we’ve created the bridge. What we want to do is assign the br0 bridge to the immune-whale (a random name generated by LXD) container.
In order to attach the container to the bridge, we’ll issue the command:
lxc config device add immune-whale eth0 nic nictype=bridged parent=br0 name=eth0
As you can see, in the command above, we’ve assigned the br0 bridge to the eth0 device of the immune-whale container. After you issue the command, give LXD time to deploy the new IP address. To view the newly-assigned LAN-based IP address, issue the command:
lxc list
Eventually, the immune-whale container will pick up an IP address reachable by your LAN (Figure 2).
At this point, you can now reach the container from your LAN, and you can start developing with it. Say, for instance, you want to develop a web app for NGINX. You can gain access to the container with the command:
lxc exec immune-whale /bin/bash
Once at the container prompt, install NGINX with the commands:
apt–get update apt–get install nginx –y |
You should be able to reach the webserver by pointing a web browser to the IP address of your container.
And that’s all there is to creating a network bridge so you can access containers deployed using the LXD platform. This is a great way for developers to begin leveraging containers, without having to deal with the complexity of Kubernetes. Yes, at some point you will have to work with Kubernetes, but when you’re either taking your first steps with containers or experimenting with container development, you might want to use a platform like LXD to get your footing.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.