You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@beam.apache.org by GitBox <gi...@apache.org> on 2020/12/04 21:59:01 UTC

[GitHub] [beam] emilymye commented on a change in pull request #13420: Rewrite container docs for custom containers

emilymye commented on a change in pull request #13420:
URL: https://github.com/apache/beam/pull/13420#discussion_r536408069



##########
File path: website/www/site/content/en/documentation/runtime/environments.md
##########
@@ -17,54 +17,175 @@ limitations under the License.
 
 # Container environments
 
-The Beam SDK runtime environment is isolated from other runtime systems because the SDK runtime environment is [containerized](https://s.apache.org/beam-fn-api-container-contract) with [Docker](https://www.docker.com/). This means that any execution engine can run the Beam SDK.
+The Beam SDK runtime environment can be [containerized](https://www.docker.com/resources/what-container) with [Docker](https://www.docker.com/) to isolate it from other runtime systems. To learn more about the container environment, read the Beam [SDK Harness container contract](https://s.apache.org/beam-fn-api-container-contract).
 
-This page describes how to customize, build, and push Beam SDK container images.
+Prebuilt SDK container images are released per supported language during Beam releases and pushed to [Docker Hub](https://hub.docker.com/search?q=apache%2Fbeam&type=image).
 
-Before you begin, install [Docker](https://www.docker.com/) on your workstation.
+## Custom container images
 
-## Customizing container images
+You may want to customize container images for many reasons, including:
 
-You can add extra dependencies to container images so that you don't have to supply the dependencies to execution engines.
+* Pre-installing additional dependencies
+* Launching third-party software in the worker environment
+* Further customizing the execution environment
 
-To customize a container image, either:
-* [Write a new](#writing-new-dockerfiles) [Dockerfile](https://docs.docker.com/engine/reference/builder/) on top of the original.
-* [Modify](#modifying-dockerfiles) the [original Dockerfile](https://github.com/apache/beam/blob/master/sdks/python/container/Dockerfile) and reimage the container.
+ This guide describes how to create and use customized containers for the Beam SDK.
 
-It's often easier to write a new Dockerfile. However, by modifying the original Dockerfile, you can customize anything (including the base OS).
+### Prerequisites
+
+* You will need to use Docker, either by [installing Docker tools locally](https://docs.docker.com/get-docker/) or using build services that can run Docker, such as [Google Cloud Build](https://cloud.google.com/cloud-build/docs/building/build-containers).
+* You will need to have a container registry accessible by your execution engine or runner to host a custom container image. Options include [Docker Hub](https://hub.docker.com/) or a "self-hosted" repository, including cloud-specific container registries like [Google Container Registry](https://cloud.google.com/container-registry) (GCR) or [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) (ECR).
+
+>  **NOTE**: On Nov 20, 2020, Docker Hub put [rate limits](https://www.docker.com/increase-rate-limits) into effect for anonymous and free authenticated use, which may impact larger pipelines that pull containers several times.
+
+For optimal user experience, we also recommend you use the latest released version of Beam.
+
+### Building and pushing custom container images
+
+Beam [SDK container images](https://hub.docker.com/search?q=apache%2Fbeam&type=image) are built from Dockerfiles checked into the [Github](https://github.com/apache/beam) repository and published to Docker Hub for every release. You can build customized containers in one of two ways:
+
+1. **[Writing a new](#writing-new-dockerfiles) Dockerfile based on a released container image**. This is sufficient for simple additions to the image, such as adding artifacts or environment variables.
+2. **[Modifying](#modifying-dockerfiles) a source Dockerfile in [Beam](https://github.com/apache/beam)**. This method requires building from Beam source but allows for greater customization of the container (including replacement of artifacts or base OS/language versions).
+
+#### Writing a new Dockerfile based on an existing published container image {#writing-new-dockerfiles}
+
+Steps:
+
+1. Create a new Dockerfile that designates a base image using the [FROM instruction](https://docs.docker.com/engine/reference/builder/#from). As an example, this `Dockerfile`:
+
+```
+FROM apache/beam_python3.7_sdk:2.25.0
+
+ENV FOO=bar
+COPY /src/path/to/file /dest/path/to/file/
+```
+
+uses the prebuilt Python 3.7 SDK container image [`beam_python3.7_sdk`](https://hub.docker.com/r/apache/beam_python3.7_sdk) tagged at (SDK version) `2.25.0`, and adds an additional environment variable and file to the image.
+
+
+2. [Build](https://docs.docker.com/engine/reference/commandline/build/) and [push](https://docs.docker.com/engine/reference/commandline/push/) the image using Docker.
 
-### Writing new Dockerfiles on top of the original {#writing-new-dockerfiles}
 
-1. Pull a [prebuilt SDK container image](https://hub.docker.com/search?q=apache%2Fbeam&type=image) for your [target](https://docs.docker.com/docker-hub/repos/#searching-for-repositories) language and version. The following example pulls the latest Python SDK:
 ```
-docker pull apache/beam_python3.7_sdk
+export BASE_IMAGE="apache/beam_python3.7_sdk:2.25.0"
+export IMAGE_NAME="myremoterepo/mybeamsdk"
+export TAG="latest"
+
+# Optional - pull the base image into your local Docker daemon to ensure
+# you have the most up-to-date version of the base image locally.
+docker pull "${BASE_IMAGE}"
+
+docker build -f Dockerfile -t "${IMAGE_NAME}:${TAG}" .
+docker push "${IMAGE_NAME}:${TAG}"
 ```
-2. [Write a new Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) that [designates](https://docs.docker.com/engine/reference/builder/#from) the original as its [parent](https://docs.docker.com/glossary/?term=parent%20image).
-3. [Build](#building-container-images) a child image.
 
-### Modifying the original Dockerfile {#modifying-dockerfiles}
+**NOTE**: After pushing a container image, you should verify the remote image ID and digest should match the local image ID and digest, output from `docker build` or `docker images`.
+
+#### Modifying a source Dockerfile in Beam {#modifying-dockerfiles}
+
+This method will require building image artifacts from Beam source. For additional instructions on setting up your development environment, see the [Contribution guide](contribute/#development-setup).
+
+1. Clone the `beam` repository. It is recommended that you start from a stable
+   release branch rather than from master for both customizing the Dockerfile
+   and building image artifacts, and that you use the same version of the SDK
+   to run your pipeline with a custom container image.
 
-1. Clone the `beam` repository:
 ```
+export BEAM_SDK_VERSION="2.26.0"
+
 git clone https://github.com/apache/beam.git
+git checkout origin/release-$BEAM_SDK_VERSION
+```
+
+3. Customize the `Dockerfile` for a given language. This file is typically in the `sdks/<language>/container` directory (e.g. the [Dockerfile for Python](https://github.com/apache/beam/blob/master/sdks/python/container/Dockerfile). If you're adding dependencies from [PyPI](https://pypi.org/), use [`base_image_requirements.txt`](https://github.com/apache/beam/blob/master/sdks/python/container/base_image_requirements.txt) instead.
+
+3. Navigate to the root directory of the local copy of your Apache Beam.
+
+4. Run Gradle with the `docker` target.
+
+
+```
+# The default repository of each SDK
+./gradlew :sdks:java:container:java8:docker
+./gradlew :sdks:java:container:java11:docker
+./gradlew :sdks:go:container:docker
+./gradlew :sdks:python:container:py36:docker
+./gradlew :sdks:python:container:py37:docker
+./gradlew :sdks:python:container:py38:docker
+
+# Shortcut for building all Python SDKs
+./gradlew :sdks:python:container buildAll
+```
+
+To examine the containers that you built, run `docker images`:
+
+```
+$> docker images
+REPOSITORY                         TAG                 IMAGE ID            CREATED           SIZE
+apache/beam_java8_sdk              latest              ...                 1 min ago         ...
+apache/beam_java11_sdk             latest              ...                 1 min ago         ...
+apache/beam_python3.6_sdk          latest              ...                 1 min ago         ...
+apache/beam_python3.7_sdk          latest              ...                 1 min ago         ...
+apache/beam_python3.8_sdk          latest              ...                 1 min ago         ...
+apache/beam_go_sdk                 latest              ...                 1 min ago         ...
+```
+
+If you did not provide a custom repo/tag as additional parameters (see below), you can retag the image and [push](https://docs.docker.com/engine/reference/commandline/push/) the image using Docker to a remote repository.
+
+```
+export BEAM_SDK_VERSION="2.26.0"
+export IMAGE_NAME="myrepo/mybeamsdk"
+export TAG="${BEAM_SDK_VERSION}-custom"
+
+docker tag apache/beam_python3.6_sdk "${IMAGE_NAME}:${TAG}"
+docker push "${IMAGE_NAME}:${TAG}"
+```
+
+**NOTE**: After pushing a container image, verify the remote image ID and digest matches the local image ID and digest output from `docker_images`
+
+##### Additional build parameters
+
+The docker Gradle task defines a default image repository and [tag](https://docs.docker.com/engine/reference/commandline/tag/) is the SDK version defined at [gradle.properties](https://github.com/apache/beam/blob/master/gradle.properties). The default repository is the Docker Hub `apache` namespace, and the default tag is the [SDK version](https://github.com/apache/beam/blob/master/gradle.properties) defined at gradle.properties.
+
+You can specify a different repository or tag for built images by providing parameters to the build task. For example:
+
 ```
-2. Customize the [Dockerfile](https://github.com/apache/beam/blob/master/sdks/python/container/Dockerfile). If you're adding dependencies from [PyPI](https://pypi.org/), use [`base_image_requirements.txt`](https://github.com/apache/beam/blob/master/sdks/python/container/base_image_requirements.txt) instead.
-3. [Reimage](#building-container-images) the container.
+./gradlew :sdks:python:container:py36:docker -Pdocker-repository-root="example-repo" -Pdocker-tag="2.26.0-custom"
+```
+
+builds the Python 3.6 container and tags it as `example-repo/beam_python3.6_sdk:2.26.0-custom`.
+
+From Beam 2.21.0 and later, a `docker-pull-licenses` flag was introduced to add licenses/notices for third party dependencies to the docker images. For example:
+
+```
+./gradlew :sdks:java:container:java8:docker -Pdocker-pull-licenses
+```
+creates a Java 8 SDK image with appropriate licenses in `/opt/apache/beam/third_party_licenses/`.
+
+By default, no licenses/notices are added to the docker images.
 
-### Testing customized images
 
-To test a customized image locally, run a pipeline with PortableRunner and set the `--environment_config` flag to the image path:
+## Using container images in pipelines
+
+The common method for providing a container image requires using the PortableRunner and setting the `--environment_config` flag to a given image path.
+Other runners, such as Dataflow, support specifying containers with different flags.
 
 {{< highlight class="runner-direct" >}}
+export IMAGE="my-repo/beam_python_sdk_custom"
+export TAG="X.Y.Z"
+
 python -m apache_beam.examples.wordcount \
 --input=/path/to/inputfile \
 --output /path/to/write/counts \
 --runner=PortableRunner \
 --job_endpoint=embed \
---environment_config=path/to/container/image
+--environment_config="${IMAGE}:${TAG}"
 {{< /highlight >}}
 
 {{< highlight class="runner-flink-local" >}}
+export IMAGE="my-repo/beam_python_sdk_custom"
+export TAG="X.Y.Z"
+
 # Start a Flink job server on localhost:8099

Review comment:
       We are probably waiting until early next week to merge in - probably better to use the more accurate version of commands. Do you have an example of recommended arguments with FlinkRunner for Python/is that supported? I couldn't find one in the docs. 
   
   Also, should we be doing the same things for spark? Based on a quick look it doesn't look like we have the same functionality for Spark, but I'm not very familiar with either Flink or Spark.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org