Age | Commit message (Collapse) | Author |
|
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.
|