Page MenuHomeVyOS Platform

Containerized third-party applications for VyOS
Open, Requires assessmentPublic

Description

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.

Details

Difficulty level
Unknown (require assessment)
Version
-
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

PR https://github.com/vyos/vyos-build/pull/137
PR https://github.com/vyos/vyos-1x/pull/651

Op-mode

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:~$ 
vyos@r11-roll:~$ 
vyos@r11-roll:~$ show container image 
alpine
vyos@r11-roll:~$

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 '10.0.3.0/24'
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