Skip to content

LXD

LXD Overview

Proxy requests through to a main container

It is possible to proxy all requests for a port through to a specific container. This allows you to create a single nginx gateway container to handle requests and pass them through to different project specific containers that have been created.

See here for a guide on how to do this

FirewallD config

LXD sets IPTable rules each time it is started, however by default these are not persisted which means they will be lost if IPTables is restarted. If this happens the containers can loose their connectivity and stop working.

The quickest way to fix this is to restart LXD after IPTables / FirewallD / etc is restarted. This can be enforced by creating an override for the LXD service using the following command

systemctl edit lxd.service

This will open a file where you can ensure that LXD will be restarted after your firewall, the following configuration can be used as a guide

[Unit]
# LXD sets firewall rules that override some of the standard ones. These are reapplied once it starts but don't
# get permenantly saved. This will make sure it restarts after the firewall is restarted to ensure they are in place
PartOf=firewalld.service
# The firewall command looks like it is reloaded after new config is put in place so we need to propegate the reload
# back to LXD as well, because PartOf only handles starts and restarts.
ReloadPropagatedFrom=firewalld.service

[Service]
# Of course the non snap version of LXD doesn't have a reload command so the propegation does absolutely nothing. To
# get around this we are going to get LXD to restart itself
ExecReload=/usr/bin/systemctl restart lxd.service
# The restart command can some times be called before iptables / firewalld has finished loading which means the rules
# can still get clobbered. We're using the arbitrary selected value of 3 seconds to ensure that the process is finished
ExecStartPre=/usr/bin/sleep 3
# As we're making changes let's ensure that LXD is always running
Restart=always

An alternative approach is to set the rules using FirewallD as outlined here, however this has not been tested and will need to be tweaked based on the specific setup.