Page MenuHomeVyOS Platform

Containerized third-party applications for VyOS
Closed, ResolvedPublic


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
Issue type
Feature (new functionality)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes



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. A̶d̶d̶ ̶c̶h̶e̶c̶k̶s̶ ̶t̶o̶ ̶p̶r̶e̶v̶e̶n̶t̶ ̶s̶e̶t̶ ̶i̶p̶ ̶a̶d̶d̶r̶e̶s̶s̶ ̶f̶o̶r̶ ̶c̶o̶n̶t̶a̶i̶n̶e̶r̶ ̶o̶u̶t̶ ̶o̶f̶ ̶r̶a̶n̶g̶e̶ ̶"̶p̶r̶e̶f̶i̶x̶" done
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. R̶e̶p̶l̶a̶c̶e̶ ̶i̶p̶v̶4̶-̶p̶r̶e̶f̶i̶x̶ ̶=̶>̶ ̶p̶r̶e̶f̶i̶x done
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. R̶e̶w̶r̶i̶t̶e̶ ̶o̶p̶-̶m̶o̶d̶e̶ ̶t̶o̶ ̶p̶y̶t̶h̶o̶n done
  1. D̶i̶s̶a̶b̶l̶e̶ ̶o̶p̶-̶m̶o̶d̶e̶ ̶c̶o̶m̶m̶a̶n̶d̶s̶,̶ ̶i̶f̶ ̶w̶e̶ ̶d̶o̶n̶'̶t̶ ̶h̶a̶v̶e̶ ̶a̶n̶y̶ ̶c̶o̶n̶t̶a̶i̶n̶e̶r̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n. done
  2. Get container IP address from op-mode.
  3. Show statistics on commit (download image pull status)
  4. Impossible to bind ports to "--net host", works only for user defined networks
root@r6-roll:/home/vyos# podman run -dt --name c2 --net host -p 2222:2222 busybox
Port mappings have been discarded as one of the Host, Container, Pod, and None network modes are in use

@Viacheslav I seem to find a strange problem. If I run two containers of adguardhome and nginx, they seem to work normally in the same image. However, once I upgrade and boot the new system, these two containers will be abnormal and can only be restored manually (try to delete them first, then recommit them, and need to modify the program appropriately), This is a robustness problem, which needs to be confirmed. If there is a problem, it needs to be solved!

erkin set Issue type to Feature (new functionality).Aug 30 2021, 7:42 AM
erkin removed a subscriber: Active contributors.

Our container infeastructure is in place, any improvements should get their own tasks.