Page MenuHomeVyOS Platform

Containerized third-party applications for VyOS
Open, Requires assessmentPublic


VyOS makes it easy to build a custom image with any package in it, but it's an acceptable solution for people dedicated enough to create their own builds for every update.
For everyone else, installing third-party applications on VyOS is impractical because installed packages won't survive image updates. Even if people are willing to reinstall packages, the data will remain in the old image, and they'll have to move it over as well.

In some cases, it's also impractical to virtualize VyOS or install a second host for those applications. Think a wireless ISP's last mile installation: it usually has a rather small router and nothing else.

At the same time, many useful applications are not large or resource-intensive. Captive portals, monitoring clients etc. are all small and useful for some people, just not for a large enough number of people to warrant their inclusion in the mainline image.

For those cases, containerized installation can be a good compromise.

To implement that, we'll need at least:

  • A separate, persistent directory for third-parth applications. Unlike /config, it should be shared between images rather than copied over.
  • A kernel built with LXC support.
  • Container management tool (docker, I suppose, since it's most popular).

The container images and their data will be stored in the persistent directory, so that when a user installs a new image, containers start as if nothing happened.

We also need a family of op mode commands for installing those applications, and configuration subtree for autostart.

Integration with the VyOS config is a much harder question, but simply allowing persistent-third party apps may open up a whole range of use cases.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible

Event Timeline

+1 for this, it would be very useful for a lot of use cases, we wouldn't need to add everything to vyos-1x and the config syntax, but users could add "missing" services on their own. For example T2195



vyos@r11-roll:~$ add container image alpine
Using default tag: latest
latest: Pulling from library/alpine
Digest: sha256:3c7497bf0c7af93428242d6176e8f7905f2201d8fc5861f45be7a346b5f23436
Status: Image is up to date for alpine:latest
vyos@r11-roll:~$ show container image 

Conf mode, we can use the user-defined network for container or host network

set container name alp01 image 'alpine'
set container name alp01 network NET
set container network NET ipv4-prefix ''
set container name alp55 allow-host-networks
set container name alp55 image 'alpine'

I want to know the behavior of the implementation when upgrading the vyos version

Hi, how is the container support now

And related

Podman as container

set container name alp01 allow-host-networks
set container name alp01 image 'alpine'
set container name alp02 image 'alpine'
set container name alp02 network NET01
set container network NET01 ipv4-prefix ''

Check containers

vyos@r4-roll:~$ sudo podman ps
CONTAINER ID  IMAGE                            COMMAND  CREATED         STATUS             PORTS   NAMES
8996b679b0f9  /bin/sh  35 minutes ago  Up 29 minutes ago          alp01
066a283ef1f5  /bin/sh  35 minutes ago  Up 29 minutes ago          alp02
  1. Add checks to prevent set ip address for container out of range "prefix"
set container name alp02 image 'alpine'
set container name alp02 network NET01 address ''
set container network NET01 ipv4-prefix '


time="2021-04-14T00:52:03+03:00" level=error msg="Error adding network: failed to allocate all requested IPs:"
time="2021-04-14T00:52:03+03:00" level=error msg="Error while adding pod to CNI network \"NET01\": failed to allocate all requested IPs:"
Error: unable to start container "60f20a2b517b4f828bef5683cd8a20504aa984648a0911f7f8df5c1a064d2625": error configuring network namespace for container 60f20a2b517b4f828bef5683cd8a20504aa984648a0911f7f8df5c1a064d2625: failed to allocate all requested IPs:
  1. Replace ipv4-prefix => prefix
set container network NET01 ipv4-prefix '
  1. Disable by default podman.socket (which used for api), if we don't have any containers in configuration. Need to think, maybe we can create containers via API.
  1. Rewrite op-mode to python
  1. Disable op-mode commands, if we don't have any container configuration.