Enable video recorder in Node/Standalone containers

[VietND96]

Introduction

Video recording is a feature that is useful for debugging and analyzing test execution remotely in a browser node in Selenium Grid. This feature is being enhanced in the project docker-selenium to make it more functional like an auto record, dynamic file name, and upload to cloud storages. However, it still has some limitations in terms of support and the way to deploy it. This article will discuss one limitation in deployment and how to optimize it.

Background

Tests execution can be recorded by using the selenium/video:latest Docker image. One video container is needed per each Node/Standalone container where a browser is running. This means if you are running 5 Node/Standalone containers, you will need 5 video containers, the mapping is 1-1. This was the support in project docker-selenium.

The way to do this mapping is manually (either starting the containers manually or through docker-compose). If you are using a docker compose file, it might be too long if you define lots of Nodes.

Motivation

If you have read the README of the project docker-selenium, you might see the statement We are iterating on this process, and probably this setup will be more simple in the future under the feature usage description. Also, another discussion ticket was opened SeleniumHQ/docker-selenium#2452 to ask for the optimization of the video recorder containers. Those are the motivations for improving the feature capability.

Identify the areas to improve

docker-selenium images hierarchy can be seen in the above diagram. On top of the hierarchy is the Ubuntu TLS image, and then we configure common dependencies, tools, non-root users, permissions, Selenium Server, etc., in the Base image. Then, based on corresponding roles and deployment modes, we have different reused layers and built images.

To reduce complexity in configuring and building FFmpeg, we reused the Docker image FFmpeg from other projects jrottenberg/ffmpeg and later linuxserver/docker-ffmpeg (since this supports multi-arch) as the base image, then repeat to configure dependencies, non-root user, permissions, etc. for recording and uploading in the video image.
However, the video image didn't use the same Base image we used to build Selenium Grid component images.

As part of optimization, we also tried to achieve that all images are built from the same Base image so that we can manage, reuse effectively, and reduce the complexity in the build process.

To include the video recording/uploading features in Nodes/Standalone images and keep the image size unchanged (or at least not too much increased). If we continue to use the FFmpeg image from other projects, it might have many more dependencies than we need since they built the FFmpeg full functionalities for different purposes.

So, we decided to own, configure, and compile FFmpeg as a static binary (keep it as minimal as possible, with enough codec and dependencies for recording x11 displays), then copy the binary into the video image (via multi-stage build). Similarly, Rclone binary (for uploading video to cloud storage), we also cloned a stable source and built the static binary. By doing this, we can proactively patch CVEs if any tool dependencies have vulnerabilities.

The trade-off is one more Dockerfile for FFmpeg to maintain. However, we keep it minimal and simple enough, and we can go with this approach in the long term.

Implementation

This is the new hierarchy of the docker-selenium images.

There is an image selenium/ffmpeg:latest that is a placeholder for FFmpeg, Rclone static binary. This image is built from this Dockerfile. This image only is rebuilt and deployed when FFmpeg, Rclone have new versions or we need to patch CVEs.

The size of binaries could be seen as minimal enough.

Now, the video image is built from the same Base image that we used to build Selenium Grid component images with copying FFmpeg, Rclone static binary from selenium/ffmpeg:latest image. This is done by multi-stage build in the Dockerfile, it looks like

ROM selenium/ffmpeg:latest AS source

FROM selenium/base:latest

USER root

COPY --from=source /usr/local/bin/ffmpeg /usr/local/bin/ffmpeg
COPY --from=source /usr/local/bin/rclone /usr/local/bin/rclone

...

The NodeBase image is built from the video to include recording/uploading features before going to configure and build common things for Node/Standalone browser images. The rest of images aren't changed.

The size of the NodeBase image before and after is built from the video image.

supervisord is used to control processes spawning in the container. Instead of letting the recording processes always run when the video container is started as usual, Now, in Node/Standalone containers, it is in standby mode and enabled via environment variable SE_RECORD_VIDEO (false by default, switch to true to enable) on user demand. Of course, this environment variable is true by default in the video container, so users are using the previous approach, and they're not affected. The supervisord config file looks like

[program:video-recording]
command=/opt/bin/video.sh
autostart=%(ENV_SE_RECORD_VIDEO)s
autorestart=%(ENV_SE_RECORD_VIDEO)s

Other environment variables to control and configure for feature uploading/recording are inherited in the Node/Standalone container. See more details in README.

Configuration

Now, get back to the situation that set up mapping 1-1 with 20 browser containers and 20 video containers. Instead of a too-long compose file defining 40 containers, we can define the number of replicas for a single service by using the deploy mode replicated in the compose file. The compose file looks like

services:
  chrome:
    deploy:
      mode: replicated
      replicas: 20
    image: selenium/node-chrome:latest
    shm_size: 2gb
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443
      - SE_ENABLE_TRACING=false
      - SE_RECORD_VIDEO=true
      - SE_VIDEO_FILE_NAME=auto
      - SE_NODE_GRID_URL=http://selenium-hub:4444

  selenium-hub:
    image: selenium/hub:latest
    container_name: selenium-hub
    environment:
      - SE_ENABLE_TRACING=false
    ports:
      - "4442:4442"
      - "4443:4443"
      - "4444:4444"

Conclusion

The change is available from the image release tag 4.27.0-20241225

This might not be the best optimization, but it is a step forward to optimize the video recorder approach in docker-selenium project by adding a simple way to enable/disable video recording in Nodes/Standalone containers besides the previous sidecar containers approach.

We are open to any feedback, suggestions, and contributions to make it better. Please feel free to raise a ticket in the project repository SeleniumHQ/docker-selenium.

---

Happy Testing!