AWS Big Data Blog
Run Spark applications with Docker using Amazon EMR 6.0.0 (Beta)
The Amazon EMR team is excited to announce the public beta release of EMR 6.0.0 with Spark 2.4.3, Hadoop 3.1.0, Amazon Linux 2, and Amazon Corretto 8. With this beta release, Spark users can use Docker images from Docker Hub and Amazon Elastic Container Registry (Amazon ECR) to define environment and library dependencies. Using Docker, users can easily define their dependencies and use them for individual jobs, avoiding the need to install dependencies on individual cluster hosts.
This post shows you how to use Docker with the EMR release 6.0.0 Beta. You’ll learn how to launch an EMR release 6.0.0 Beta cluster and run Spark jobs using Docker containers from both Docker Hub and Amazon ECR.
Hadoop 3 Docker support
EMR 6.0.0 (Beta) includes Hadoop 3.1.0, which allows the YARN NodeManager to launch containers either directly on the host machine of the cluster, or inside a Docker container. Docker containers provide a custom execution environment in which the application’s code runs isolated from the execution environment of the YARN NodeManager and other applications.
These containers can include special libraries needed by the application, and even provide different versions of native tools and libraries such as R, Python, Python libraries. This allows you to easily define the libraries and runtime dependencies that your applications need, using familiar Docker tooling.
Clusters running the EMR 6.0.0 (Beta) release are configured by default to allow YARN applications such as Spark to run using Docker containers. To customize this, use the configuration for Docker support defined in the yarn-site.xml and container-executor.cfg files available in the /etc/hadoop/conf directory. For details on each configuration option and how it is used, see Launching Applications Using Docker Containers.
You can choose to use Docker when submitting a job. On job submission, the following variables are used to specify the Docker runtime and Docker image used:
-
- YARN_CONTAINER_RUNTIME_TYPE=docker
- YARN_CONTAINER_RUNTIME_DOCKER_IMAGE={DOCKER_IMAGE_NAME}
When you use Docker containers to execute your YARN applications, YARN downloads the Docker image specified when you submit your job. For YARN to resolve this Docker image, it must be configured with a Docker registry. Options to configure a Docker registry differ based on how you chose to deploy EMR (using either a public or private subnet).
Docker registries
A Docker registry is a storage and distribution system for Docker images. For EMR 6.0.0 (Beta), the following Docker registries can be configured:
- Docker Hub: A public Docker registry containing over 100,000 popular Docker images.
- Amazon ECR: A fully-managed Docker container registry that allows you to create your own custom images and host them in a highly available and scalable architecture.
Deployment considerations
Docker registries require network access from each host in the cluster, as each host downloads images from the Docker registry when your YARN application is running on the cluster. How you choose to deploy your EMR cluster (launching it into a public or private subnet) may limit your choice of Docker registry due to network connectivity requirements.
Public subnet
With EMR public subnet clusters, nodes running YARN NodeManager can directly access any registry available over the internet, such as Docker Hub, as shown in the following diagram.
Private Subnet
With EMR private subnet clusters, nodes running YARN NodeManager don’t have direct access to the internet. Docker images can be hosted in the ECR and accessed through AWS PrivateLink, as shown in the following diagram.
For details on how to use AWS PrivateLink to allow access to ECR in a private subnet scenario, see Setting up AWS PrivateLink for Amazon ECS, and Amazon ECR.
Configuring Docker registries
Docker must be configured to trust the specific registry used to resolve Docker images. The default trust registries are local (private) and centos (on public Docker Hub). You can override docker.trusted.registries in /etc/hadoop/conf/container-executor.cfg to use other public repositories or ECR. To override this configuration, use the EMR Classification API with the container-executor classification key.
The following example shows how to configure the cluster to trust both a public repository (your-public-repo) and an ECR registry (123456789123.dkr.ecr.us-east-1.amazonaws.com). When using ECR, replace this endpoint with your specific ECR endpoint. When using Docker Hub, please replace this repository name with your actual repository name.
To launch an EMR 6.0.0 (Beta) cluster with this configuration using the AWS Command Line Interface (AWS CLI), create a file named container-executor.json with the contents of the preceding JSON configuration. Then, use the following commands to launch the cluster:
Using ECR
If you’re new to ECR, follow the instructions in Getting Started with Amazon ECR and verify you have access to ECR from each instance in your EMR cluster.
To access ECR using the docker command, you must first generate credentials. To make sure that YARN can access images from ECR, pass a reference to those generated credentials using the container environment variable YARN_CONTAINER_RUNTIME_DOCKER_CLIENT_CONFIG.
Run the following command on one of the core nodes to get the login line for your ECR account.
$ aws ecr get-login --region us-east-1 --no-include-email
The get-login command generates the correct Docker CLI command to run to create credentials. Copy and run the output from get-login.
$ sudo docker login -u AWS -p <password> https://<account-id>.dkr.ecr.us-east-1.amazonaws.com
This command generates a config.json file in the /root/.docker folder. Copy this file to HDFS so that jobs submitted to the cluster can use it to authenticate to ECR.
Execute the commands below to copy the config.json file to your home directory.
$ mkdir -p ~/.docker
$ sudo cp /root/.docker/config.json ~/.docker/config.json
$ sudo chmod 644 ~/.docker/config.json
Execute the commands below to put the config.json in HDFS so it may be used by jobs running on the cluster.
$ hadoop fs -put ~/.docker/config.json /user/hadoop/
At this point, YARN can access ECR as a Docker image registry and pull containers during job execution.
Using Spark with Docker
With EMR 6.0.0 (Beta), Spark applications can use Docker containers to define their library dependencies, instead of requiring dependencies to be installed on the individual Amazon EC2 instances in the cluster. This integration requires configuration of the Docker registry, and definition of additional parameters when submitting a Spark application.
When the application is submitted, YARN invokes Docker to pull the specified Docker image and run the Spark application inside of a Docker container. This allows you to easily define and isolate dependencies. It reduces the time spent bootstrapping or preparing instances in the EMR cluster with the libraries needed for job execution.
When using Spark with Docker, make sure that you consider the following:
- The docker package and CLI are only installed on core and task nodes.
- The spark-submit command should always be run from a master instance on the EMR cluster.
- The Docker registries used to resolve Docker images must be defined using the Classification API with the container-executor classification key to define additional parameters when launching the cluster:
- docker.trusted.registries
- docker.privileged-containers.registries
- To execute a Spark application in a Docker container, the following configuration options are necessary:
- YARN_CONTAINER_RUNTIME_TYPE=docker
- YARN_CONTAINER_RUNTIME_DOCKER_IMAGE={DOCKER_IMAGE_NAME}
- When using ECR to retrieve Docker images, you must configure the cluster to authenticate itself. To do so, you must use the following configuration option:
- YARN_CONTAINER_RUNTIME_DOCKER_CLIENT_CONFIG={DOCKER_CLIENT_CONFIG_PATH_ON_HDFS}
- Mount the /etc/passwd file into the container so that the user running the job can be identified in the Docker container.
- YARN_CONTAINER_RUNTIME_DOCKER_MOUNTS=/etc/passwd:/etc/passwd:ro
- Any Docker image used with Spark must have Java installed in the Docker image.
Creating a Docker image
Docker images are created using a Dockerfile, which defines the packages and configuration to include in the image. The following two example Dockerfiles use PySpark and SparkR.
PySpark Dockerfile
Docker images created from this Dockerfile include Python 3 and the numpy Python package. This Dockerfile uses Amazon Linux 2 and the Amazon Corretto JDK 8.
SparkR Dockerfile
Docker images created from this Dockerfile include R and the randomForest CRAN package. This Dockerfile includes Amazon Linux 2 and the Amazon Corretto JDK 8.
For more information on Dockerfile syntax, see the Dockerfile reference documentation.
Using Docker images from ECR
Amazon Elastic Container Registry (ECR) is a fully-managed Docker container registry that makes it easy for developers to store, manage, and deploy Docker container images. When using ECR, the cluster must be configured to trust your instance of ECR, and you must configure authentication in order for the cluster to use Docker images from ECR.
In this example, our cluster must be created with the following additional configuration, to ensure the ECR registry is trusted. Please replace the 123456789123.dkr.ecr.us-east-1.amazonaws.com endpoint with your ECR endpoint.
Using PySpark with ECR
This example uses the PySpark Dockerfile. It will be tagged and upload to ECR. Once uploaded, you will run the PySpark job and reference the Docker image from ECR.
After you launch the cluster, use SSH to connect to a core node and run the following commands to build the local Docker image from the PySpark Dockerfile example.
First, create a directory and a Dockerfile for our example.
$ mkdir pyspark
$ vi pyspark/Dockerfile
Paste the contents of the PySpark Dockerfile and run the following commands to build a Docker image.
$ sudo docker build -t local/pyspark-example pyspark/
Create the emr-docker-examples ECR repository for our examples.
$ aws ecr create-repository --repository-name emr-docker-examples
Tag and upload the locally built image to ECR, replacing 123456789123.dkr.ecr.us-east-1.amazonaws.com with your ECR endpoint.
$ sudo docker tag local/pyspark-example 123456789123.dkr.ecr.us-east-1.amazonaws.com/emr-docker-examples:pyspark-example
$ sudo docker push 123456789123.dkr.ecr.us-east-1.amazonaws.com/emr-docker-examples:pyspark-example
Use SSH to connect to the master node and prepare a Python script with the filename main.py. Paste the following content into the main.py file and save it.
To submit the job, reference the name of the Docker. Define the additional configuration parameters to make sure that the job execution uses Docker as the runtime. When using ECR, the YARN_CONTAINER_RUNTIME_DOCKER_CLIENT_CONFIG must reference the config.json file containing the credentials used to authenticate to ECR.
When the job has completed, take note of the YARN application ID, and use the following command to obtain the output of the PySpark job.
Using SparkR with ECR
This example uses the SparkR Dockerfile. It will be tagged and upload to ECR. Once uploaded, you will run the SparkR job and reference the Docker image from ECR.
After you launch the cluster, use SSH to connect to a core node and run the following commands to build the local Docker image from the SparkR Dockerfile example.
First, create a directory and the Dockerfile for this example.
$ mkdir sparkr
$ vi sparkr/Dockerfile
Paste the contents of the SparkR Dockerfile and run the following commands to build a Docker image.
$ sudo docker build -t local/sparkr-example sparkr/
Tag and upload the locally built image to ECR, replacing 123456789123.dkr.ecr.us-east-1.amazonaws.com with your ECR endpoint.
$ sudo docker tag local/sparkr-example 123456789123.dkr.ecr.us-east-1.amazonaws.com/emr-docker-examples:sparkr-example
$ sudo docker push 123456789123.dkr.ecr.us-east-1.amazonaws.com/emr-docker-examples:sparkr-example
Use SSH to connect to the master node and prepare an R script with name sparkR.R. Paste the following contents into the sparkR.R file.
To submit the job, reference the name of the Docker. Define the additional configuration parameters to make sure that the job execution uses Docker as the runtime. When using ECR, the YARN_CONTAINER_RUNTIME_DOCKER_CLIENT_CONFIG must reference the config.json file containing the credentials used to authenticate to ECR.
When the job has completed, note the YARN application ID, and use the following command to obtain the output of the SparkR job. This example includes testing to make sure that the randomForest library, version installed, and release notes are available.
Using a Docker image from Docker Hub
To use Docker Hub, you must deploy your cluster to a public subnet, and configure it to use Docker Hub as a trusted registry. In this example, the cluster needs the following additional configuration to to make sure that the your-public-repo repository on Docker Hub is trusted. When using Docker Hub, please replace this repository name with your actual repository.
Beta limitations
EMR 6.0.0 (Beta) focuses on helping you get value from using Docker with Spark to simplify dependency management. You can also use EMR 6.0.0 (Beta) to get familiar with Amazon Linux 2, and Amazon Corretto JDK 8.
The EMR 6.0.0 (Beta) supports the following applications:
- Spark 2.4.3
- Livy 0.6.0
- ZooKeeper 3.4.14
- Hadoop 3.1.0
This beta release is supported in the following Regions:
- US East (N. Virginia)
- US West (Oregon)
The following EMR features are currently not available with this beta release:
- Cluster integration with AWS Lake Formation
- Native encryption of Amazon EBS volumes attached to an EMR cluster
Conclusion
In this post, you learned how to use an EMR 6.0.0 (Beta) cluster to run Spark jobs in Docker containers and integrate with both Docker Hub and ECR. You’ve seen examples of both PySpark and SparkR Dockerfiles.
The EMR team looks forward to hearing about how you’ve used this integration to simplify dependency management in your projects. If you have questions or suggestions, feel free to leave a comment.
About the Authors
Paul Codding is a senior product manager for EMR at Amazon Web Services.
Ajay Jadhav is a software development engineer for EMR at Amazon Web Services.
Rentao Wu is a software development engineer for EMR at Amazon Web Services.
Stephen Wu is a software development engineer for EMR at Amazon Web Services.