gvisor.dev/gvisor@v0.0.0-20240520182842-f9d4d51c7e0f/images/README.md (about)

     1  # Container Images
     2  
     3  This directory contains all images used by tests.
     4  
     5  Note that all these images must be pushed to the testing project hosted on
     6  [Google Container Registry][gcr]. This will happen automatically as part of
     7  continuous integration. This will speed up loading as images will not need to be
     8  built from scratch for each test run.
     9  
    10  Image tooling is accessible via `make`, specifically via `tools/images.mk`.
    11  
    12  ## Why make?
    13  
    14  Make is used because it can bootstrap the `default` image, which contains
    15  `bazel` and all other parts of the toolchain.
    16  
    17  ## Listing images
    18  
    19  To list all images, use `make list-all-images` from the top-level directory.
    20  
    21  ## Loading and referencing images
    22  
    23  To build a specific image, use `make load-<image>` from the top-level directory.
    24  This will ensure that an image `gvisor.dev/images/<image>:latest` is available.
    25  
    26  Images should always be referred to via the `gvisor.dev/images` canonical path.
    27  This tag exists only locally, but serves to decouple tests from the underlying
    28  image infrastructure.
    29  
    30  The continuous integration system can either take fine-grained dependencies on
    31  single images via individual `load` targets, or pull all images via a single
    32  `load-all-test-images` invocation.
    33  
    34  ## Adding new images
    35  
    36  To add a new image, create a new directory under `images` containing a
    37  Dockerfile and any other files that the image requires. You may choose to add to
    38  an existing subdirectory if applicable, or create a new one.
    39  
    40  All images will be tagged and memoized using a hash of the directory contents.
    41  As a result, every image should be made completely reproducible if possible.
    42  This means using fixed tags and fixed versions whenever feasible.
    43  
    44  Note that images should also be made architecture-independent if possible. The
    45  build scripts will handle loading the appropriate architecture onto the machine
    46  and tagging it with the single canonical tag.
    47  
    48  Add a `load-<image>` dependency in the Makefile if the image is required for a
    49  particular set of tests. This target will pull the tag from the image repository
    50  if available.
    51  
    52  ## Building and pushing images
    53  
    54  All images can be built manually by running `build-<image>` and pushed using
    55  `push-<image>`. Note that you can also use `build-all-images` and
    56  `push-all-images`. Note that pushing will require appropriate permissions in the
    57  project.
    58  
    59  The continuous integration system can either take fine-grained dependencies on
    60  individual `push` targets, or ensure all images are up-to-date with a single
    61  `push-all-images` invocation.
    62  
    63  ## Multi-Arch images
    64  
    65  By default, the image is built for host architecture. Cross-building can be
    66  achieved by specifying `ARCH` variable to make. For example:
    67  
    68  ```
    69  $ make ARCH=aarch64 rebuild-default
    70  ```