databricks/rules_docker

databricks/rules_docker

Description: Rules for building and handling Docker images with Bazel

Language: Python

License: Apache-2.0

Stars: 5

Forks: 6

Open issues: 2

Created: 2017-11-22T22:50:45Z

Pushed: 2024-11-19T13:22:05Z

Default branch: master

Fork: yes

Parent repository: bazelbuild/rules_docker

Archived: no

README:

Bazel Container Image Rules

Travis CI | Bazel CI :---: | :---:  | 

Basic Rules

• [container_image](#container_image-1) ([example](#container_image))
• [container_bundle](#container_bundle-1) ([example](#container_bundle))
• [container_import](#container_import)
• [container_load](#container_load)
• [container_pull](#container_pull-1) ([example](#container_pull))
• [container_push](#container_push-1) ([example](#container_push))

These rules used to be docker_build, docker_push, etc. and the aliases for these (mostly) legacy names still exist largely for backwards-compatibility. We also have early-stage oci_image, oci_push, etc. aliases for folks that enjoy the consistency of a consistent rule prefix. The only place the format-specific names currently do any more than alias things is in foo_push, where they also specify the appropriate format as which to publish the image.

Overview

This repository contains a set of rules for pulling down base images, augmenting them with build artifacts and assets, and publishing those images. These rules do not require / use Docker for pulling, building, or pushing images. This means:

• They can be used to develop Docker containers on Windows / OSX without

boot2docker or docker-machine installed.

• They do not require root access on your workstation.

Also, unlike traditional container builds (e.g. Dockerfile), the Docker images produced by container_image are deterministic / reproducible.

__NOTE:__ container_push and container_pull make use of google/containerregistry for registry interactions.

Language Rules

• [cc_image](#cc_image) ([signature](

https://docs.bazel.build/versions/master/be/c-cpp.html#cc_binary))

• [go_image](#go_image) ([signature](

https://github.com/bazelbuild/rules_go#go_binary))

• [py_image](#py_image) ([signature](

https://docs.bazel.build/versions/master/be/python.html#py_binary))

• [py3_image](#py3_image) ([signature](

https://docs.bazel.build/versions/master/be/python.html#py_binary))

• [java_image](#java_image) ([signature](

https://docs.bazel.build/versions/master/be/java.html#java_binary))

• [war_image](#war_image) ([signature](

https://docs.bazel.build/versions/master/be/java.html#java_library))

• [scala_image](#scala_image) ([signature](

https://github.com/bazelbuild/rules_scala#scala_binary))

• [groovy_image](#groovy_image) ([signature](

https://github.com/bazelbuild/rules_groovy#groovy_binary))

• [rust_image](#rust_image) ([signature](

https://github.com/bazelbuild/rules_rust#rust_binary))

• [d_image](#d_image) ([signature](

https://github.com/bazelbuild/rules_d#d_binary))

Overview

In addition to low-level rules for building containers, this repository provides a set of higher-level rules for containerizing applications. The idea behind these rules is to make containerizing an application built via a lang_binary rule as simple as changing it to lang_image.

By default these higher level rules make use of the [distroless]( https://github.com/googlecloudplatform/distroless) language runtimes, but these can be overridden via the base="..." attribute (e.g. with a container_pull or container_image target).

Setup

Add the following to your WORKSPACE file to add the external repositories:

git_repository(
name = "io_bazel_rules_docker",
remote = "https://github.com/bazelbuild/rules_docker.git",
tag = "v0.3.0",
)

load(
"@io_bazel_rules_docker//container:container.bzl",
"container_pull",
container_repositories = "repositories",
)

# This is NOT needed when going through the language lang_image
# "repositories" function(s).
container_repositories()

container_pull(
name = "java_base",
registry = "gcr.io",
repository = "distroless/java",
# 'tag' is also supported, but digest is encouraged for reproducibility.
digest = "sha256:deadbeef",
)

Using with Docker locally.

Suppose you have a container_image target //my/image:helloworld:

container_image(
name = "helloworld",
...
)

You can load this into your local Docker client by running: bazel run my/image:helloworld.

For the lang_image targets, this will also run the container to maximize compatibility with lang_binary rules. You can suppress this behavior by passing the single flag: bazel run :foo -- --norun

Alternatively, you can build a docker load compatible bundle with: bazel build my/image:helloworld.tar. This will produce the file: bazel-genfiles/my/image/helloworld.tar, which you can load into your local Docker client by running: docker load -i bazel-genfiles/my/image/helloworld.tar. Building this target can be expensive for large images.

These work with both container_image, container_bundle, and the lang_image rules. For everything except container_bundle, the image name will be bazel/my/image:helloworld. For container_bundle, it will apply the tags you have specified.

Authorization

You can use these rules to access private images using standard Docker authentication methods. e.g. to utilize the [Google Container Registry]( https://gcr.io) [credential helper]( https://github.com/GoogleCloudPlatform/docker-credential-gcr):

$ gcloud components install docker-credential-gcr

$ docker-credential-gcr configure-docker

See also:

• [Amazon ECR Docker Credential Helper](

https://github.com/awslabs/amazon-ecr-credential-helper)

• [Azure Docker Credential Helper](

https://github.com/Azure/acr-docker-credential-helper)

Varying image names

A common request from folks using container_push or container_bundle is to be able to vary the tag that is pushed or embedded. There are two options at present for doing this.

Stamping

The first option is to use stamp = True.

# A common pattern when users want to avoid trampling
# on each other's images during development.
container_push(
name =…