google / google/gvisor

Make gVisor installation process support sidecar binaries

Open
#13,718 2 comments 0 reactions 0 assignees View on GitHub
type: enhancement
Dominant language
Go
Stars
19.3k
Forks
2k
Avg merge
3d 5h
Merged PRs (30d)
264

Description

### Description

The gVisor installation process today involves downloading `runsc` (and the containerd shim binary) and putting it in `/usr/bin` or the like. This makes installation easy, the tradeoff being that `runsc` has to come as a single monolithic binary.

This has had maintainability implications (look at https://github.com/google/gvisor/tree/master/tools/embeddedbinary for illustrations as to why), and also has performance implications. It makes the gVisor binary size quite large (most of the `runsc` binary size comes from embedded binary). Extraction at runtime costs CPU and I/O, and is too expensive to work when on the sandbox startup hot path.

### Do you have a specific solution in mind?

We should move to an installation process that supports multiple files at once.

The downloadable artifact should be a single tarball named `gvisor.tar.bz2` that contains `runsc` and any supporting binaries in a `gvisor/` subdirectory next to it. We can then have a `gvisorartifacts` package that deals with resolving the path to the files therein (sibling of `runsc` as resolved through `specutils.ExePath` → `gvisor/` → filename) that we can then replace existing usages of `embeddedbinary` with. `containerd-shim-runsc-v1` should remain top-level, as it needs to be on `$PATH` for containerd.

One potential goal is to keep `runsc install` as a subcommand that can automatically download and "fill in" the rest of the binaries that existing automated installation deployments (that just download `runsc` and then call `runsc install`) can keep working, so long as they run in an environment that has Internet access and that allows writing next to `runsc` (the latter should be the case for existing usages, since it overwrites the Docker system-wide config so likely runs as root).

The repo's `README` should be updated to have users build the whole release rather than just `runsc`, and the instructions in the website install guide also need to be updated accordingly.

Contributor guide

Open the contributing guide

Research direction

Start by reading tools/embeddedbinary and the existing runsc installation and release flow. Trace how specutils.ExePath resolves runsc, then inspect the proposed gvisorartifacts package boundary and the runsc install behavior. Done means releases contain gvisor.tar.bz2 with the required files, containerd-shim-runsc-v1 remains top-level, and README and the website install guide describe the full release.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, go
Domain
build-system, devops, documentation, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.