LNST in containers

LNST supports running agents in containers at the host machine. Containers and networks are dynamically created based on recipe requirements. Containers are also automatically connected to networks.


The first requirement is Podman, follow installation steps on official Podman installation page.

Configure Podman to use CNI

If you use Podman 4.0+ you need to change default network backend from netavark to CNI as LNST supports CNI only. If your Podman is already running, stop it.

  1. Remove all the LNST’s leftovers from /etc/cni/net.d/lnst_*.conflist if you already tried to run LNST

2. Set default network backend to cni, add following block to containers.conf - documentation:

  1. Install CNI plugins:
dnf install containernetworking-plugins
  1. Start your Podman instance

Podman API is also required, follow the steps below:

Enabling Podman API service:

systemctl enable --now podman.socket

and get socket URL:

systemctl status podman.socket | grep "Listen:"

Starting Podman API manually:

If you don’t want to run Podman API as a service, you can start it manually. Don’t forget to run the command below with root privileges.

podman system service --timeout 0 --log-level=debug

Socket URL could be found at the top of logs generated by this command.

The usual URL is unix:/run/podman/podman.sock

Build LNST agent image

Currently, LNST does not support automated building, so build LNST agent machine image.

Podman uses different storage locations for root-full and root-less images, so make sure you build image to root-full storage. LNST currently uses the default storage location. Build context should be a directory, where your LNST project is located.

Your local copy of LNST is used by agents in containers.

Use -t argument to name your image, this name is later used.

cd your_lnst_project_directory
podman build . -t lnst -f container_files/Dockerfile

Now is everything ready to run LNST in containers. For testing purposes, we can use HelloWorldRecipe from Creating an executable “HelloWorld” test script.

Only initialization of Controller() object has to be changed:

from lnst.Controller.MachineMapper import ContainerMapper
from lnst.Controller.ContainerPoolManager import ContainerPoolManager

podman_uri = ""  # podman URI from installation step above
image_name = ""  # name of image from build step above
ctl = Controller(poolMgr=ContainerPoolManager, mapper=ContainerMapper, podman_uri=podman_uri, image=image_name)

And run the script.

Classes documentation

class lnst.Controller.MachineMapper.ContainerMapper

Implements simple matching algorithm that maps containers to requirements. Containers are created in lnst.Controller.ContainerPoolManager.ContainerPoolManager using requirements.


1:1 mapping of containers to requirements


lnst.Controller.MachineMapper.ContainerMapper does not support multiple pools but it requires pool manager.

class lnst.Controller.ContainerPoolManager.ContainerPoolManager(pools, msg_dispatcher, ctl_config, podman_uri, image, pool_checks=True)

This class implements managing containers and networks. It uses Podman API to handle operations with containers, the API needs to be running with root privileges.

  • pools (dict) – Dictionary that contains pools. In lnst.Controller.ContainerPoolManager.ContainerPoolManager are pools dynamically created based on recipe requirements. That means this parameter is not used but it is needed to keep parameters of this class and lnst.Controller.AgentPoolManager.AgentPoolManager the same.
  • msg_dispatcher (lnst.Controller.MessageDispatcher.MessageDispatcher) –
  • ctl_config (lnst.Controller.Config.CtlConfig) –
  • pool_checks (boolean (default True)) – if False, will disable checking the online status of Agents
  • podman_uri (str) – Mandatory parameter
  • image (str) – Mandatory parameter
process_reqs(mreqs: dict)

This method is called by lnst.Controller.MachineMapper.ContainerMapper, it is responsible for creating containers and networks.