Age | Commit message (Collapse) | Author |
|
Update the debugging example to use make to make sure the debuggable `runsc`
binary is installed as a docker runtime before attempting to start a container.
Also use nginx as an example container and Accept as an example break point
since it's easy to trigger.
PiperOrigin-RevId: 379393892
|
|
Fixes #6084
PiperOrigin-RevId: 376293659
|
|
This adds a new short tutorial on how to run Knative services in gVisor by
enabling the runtime class feature flag for Knative.
Fixes #3634
PiperOrigin-RevId: 374999528
|
|
Fixes #5170
PiperOrigin-RevId: 371007691
|
|
PiperOrigin-RevId: 364931406
|
|
Fixes #5703
PiperOrigin-RevId: 364492235
|
|
PiperOrigin-RevId: 355449206
|
|
|
|
The current version of FAQ.md contains an incorrect example of how to instruct kubelet to prefer containerd over docker. More specifically, it refers to a non-existent `--cni-socket` flag whereas it should have been `--cri-socket`.
The suggested PR fixes that.
|
|
PiperOrigin-RevId: 353340554
|
|
gvisor-containerd-shim is not compatible with containerd 1.1 or earlier.
Starting from containerd 1.2, shim v2 is the preferred interface.
PiperOrigin-RevId: 351485556
|
|
This change works around an issue in rules_pkg, described here:
https://github.com/bazelbuild/rules_pkg/pull/263
PiperOrigin-RevId: 350869030
|
|
PiperOrigin-RevId: 342662753
|
|
- Add log statements in service entry points.
- Propagate `-debug` flag from shim invokation to the service
- Load options when shim process is invoked to ensure runsc commands
use the correct set of options, e.g. --debug --debug-logs=...
- Add debug options to the shim configuration directly, so it doesn't
rely on containerd configuration (and restart) to enable shim debug.
- Save shim logs to dedicated file, so it's easier to read logs. They
would be mixed with containerd logs and hard to distinguish
otherwise.
PiperOrigin-RevId: 342179868
|
|
PiperOrigin-RevId: 339182137
|
|
- Formatting on the most recent blog post
- Add a link to faq from containerd docs
- Fix code in FAQ
PiperOrigin-RevId: 337001738
|
|
PiperOrigin-RevId: 335702168
|
|
Streamline instruction for the common case.
PiperOrigin-RevId: 332488910
|
|
Fixes #3277
PiperOrigin-RevId: 330853338
|
|
PiperOrigin-RevId: 330745430
|
|
Adds a Docker Compose tutorial to the website that shows how to start a
Wordpress site and includes information about how to get DNS working.
Fixes #115
PiperOrigin-RevId: 330652842
|
|
Update the cniVersion used in the CNI tutorial so that it works with
containerd 1.2. Containerd 1.2 includes a version of the cri plugin
(release/1.2) that, in turn, includes a version of the
cni library (0.6.0) that only supports up to 0.3.1.
https://github.com/containernetworking/cni/blob/v0.6.0/pkg/version/version.go#L38
PiperOrigin-RevId: 329837188
|
|
Add three new doc pages to the website.
- A containerd quick start covering containerd 1.2. This is limited to shim v2
and runtime class as the docs would get too complicated explaining all the
combinations that are possible. We want folks to use shim v2 and runtime
class anyway.
- An advanced configuration page. This covers containerd and
containerd-shim-runsc-v1's configuration options.
- A page for old versions (i.e. containerd 1.1). Notes that this is deprecated
and supported on a best-effort basis.
Fixes #3279
PiperOrigin-RevId: 324775563
|
|
Groups subcategories and sorts their pages by weight properly. Subcategories
are sorted by name. Pages within subcategories are sorted by weight.
PiperOrigin-RevId: 324766128
|
|
PiperOrigin-RevId: 321053634
|
|
The go.mod dependency tree for the shim was somehow contradictory. After
resolving these issues (e.g. explicitly imported k8s 1.14, pulling a
specific dbus version), and adding all dependencies, the shim can now be
build as part of the regular bazel tree.
As part of this process, minor cleanup was done in all the source files:
headers were standardized (and include "The gVisor Authors" in addition
to the "The containerd Authors" if originally derived from containerd
sources), and comments were cleaned up to meet coding standards.
This change makes the containerd installation dynamic, so that multiple
versions can be tested, and drops the static installer for the VM image
itself.
This change also updates test/root/crictl_test.go and related utilities,
so that the containerd tests can be run on any version (and in cases
where it applies, they can be run on both v1 and v2 as parameterized
tests).
|
|
Adds a netns flag to runsc spec that allows users to specify a network
namespace path when creating a sample config.json file. Also, adds the ability
to specify the command arguments used when running the container.
This will make it easier for new users to create sample OCI bundles without
having to edit the config.json by hand.
PiperOrigin-RevId: 320486267
|
|
Neither myself nor bhaskerh@ can consistently remember how to do this.
PiperOrigin-RevId: 320407005
|
|
Removing the link to the netstack repo as the netstack code is now part of gVisor.
|
|
The existing gvisor.dev/faq link returns 404 because the full URL has
mistakenly been capitalized.
PiperOrigin-RevId: 319233173
|
|
|
|
PiperOrigin-RevId: 312573487
|
|
* Aggregate architecture Overview in "What is gVisor?" as it makes more sense
in one place.
* Drop "user-space kernel" and use "application kernel". The term "user-space
kernel" is confusing when some platform implementation do not run in
user-space (instead running in guest ring zero).
* Clear up the relationship between the Platform page in the user guide and the
Platform page in the architecture guide, and ensure they are cross-linked.
* Restore the call-to-action quick start link in the main page, and drop the
GitHub link (which also appears in the top-right).
* Improve image formatting by centering all doc and blog images, and move the
image captions to the alt text.
PiperOrigin-RevId: 311845158
|
|
PiperOrigin-RevId: 311744091
|
|
PiperOrigin-RevId: 311184385
|
|
|
|
|
|
This adapts the merged website repository to use the image and bazel
build framework. It explicitly avoids the container_image rules provided
by bazel, opting instead to build with direct docker commands when
necessary.
The relevant build commands are incorporated into the top-level
Makefile.
|