Remote Executor Image Base OS Change: Migrating from Ubuntu to Wolfi (apt-get to apk) – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: Remote Executor Upgrade / Custom Dockerfile Migration

Issue

Starting with the v1.1.x-cloud release line, the DataHub Remote Executor image migrated its base OS from Ubuntu (ubuntu:24.04) to Wolfi (cgr.dev/chainguard/wolfi-base), a lightweight, security-focused Linux distribution. This is a breaking change for any deployment that extends the executor image with a custom Dockerfile or that relies on specific container startup commands. The migration affects three distinct areas: (1) package installation commands (apt-get no longer exists; apk must be used instead), (2) the removal of the dockerize executable from the image (which causes ECS and other container runtimes to fail at startup if the task definition still references it), and (3) which executor image variant includes the bundled virtual environment builder script. Deployments upgrading from any pre-v1.1.0-cloud image — including the v0.3.x-acryl and v1.0.x-cloud lines — are affected if they use custom Dockerfiles or explicit container startup commands.

Error Messages

/bin/sh: apt-get: not found
The command '/bin/sh -c apt-get ...' returned a non-zero code: 127
/bin/sh: 1: /usr/local/bin/build_bundled_venvs_unified.sh: not found
The command '/bin/sh -c /usr/local/bin/build_bundled_venvs_unified.sh' returned a non-zero code: 127
CannotStartContainerError: ResourceInitializationError: OCI runtime create failed: exec: "dockerize": executable file not found in $PATH
error: Failed to create virtual environment. Caused by: A virtual environment already exists at `/opt/datahub/venvs/s3-bundled`.

You Might Be Asking

Why did my Docker build stop working after upgrading the Remote Executor base image to v1.1.x-cloud?
Has the base OS of the Remote Executor image changed between v1.0.x-cloud and v1.1.x-cloud?
Why is apt-get not found in my custom Remote Executor Dockerfile after upgrading?
Why is dockerize no longer available in the v1.1.x-cloud executor image?
What ECS Task Definition or CloudFormation changes are required when upgrading the Remote Executor to v1.1.x-cloud?
Why is build_bundled_venvs_unified.sh not found when I use the slim-unbundled image variant?
Why does my bundled venv build fail with an "already exists" error for the s3-bundled virtual environment?

Solution

There are three independent changes required when upgrading to the v1.1.x-cloud Remote Executor image. Apply all that are relevant to your deployment.

Change 1 — Replace `apt-get` with `apk` in Custom Dockerfiles

Open your custom Dockerfile that extends the Remote Executor base image.

Replace all apt-get (or apt) invocations with their apk equivalents. The general pattern is:

# Before (Ubuntu/Debian — no longer works on v1.1.x-cloud)
RUN apt-get update && \
    apt-get install -y <package-name> && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

# After (Wolfi/Alpine — required for v1.1.x-cloud)
RUN apk add --no-cache <package-name>

Common package name mappings and Wolfi-specific equivalents are listed below. Most names carry over directly; the main exceptions are Java, network tooling, and third-party tools (such as mongosh) that do not have a Wolfi APK repository.

Ubuntu/Debian package	Wolfi/apk equivalent	Notes
`openjdk-17-jre-headless`	`openjdk-17-jre`	JAVA_HOME changes — see below
`build-essential`	`build-base`
`dnsutils`	`bind-tools`	Provides `dig`, `host`, `nslookup`
`telnet`	`netcat-openbsd`	No `telnet` package in Wolfi; use `nc` for port checks
`curl`	`curl`	Same name
`git`	`git`	Same name
`gnupg`	N/A	Not needed for binary installs
`libpq-dev`	`libpq-dev` or `postgresql-dev`	Check Wolfi registry for exact name
`python3-dev`	`python3-dev`	Same name

If you install Java, update the JAVA_HOME path — it differs between Ubuntu and Wolfi:

# Ubuntu path (no longer valid on v1.1.x-cloud)
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64

# Wolfi path (use this for v1.1.x-cloud)
RUN apk add --no-cache openjdk-17-jre
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk
ENV PATH="${JAVA_HOME}/bin:${PATH}"

If your Dockerfile installs mongosh via an apt repository (Debian approach), that method is not available on Wolfi. Install the official standalone binary instead, using an arch-aware approach:

USER root
ARG TARGETARCH
ARG MONGOSH_VERSION=2.5.6

RUN set -eux; \
    case "${TARGETARCH:-$(uname -m)}" in \
        amd64|x86_64) MARCH=x64 ;; \
        arm64|aarch64) MARCH=arm64 ;; \
        *) echo "unsupported arch: ${TARGETARCH}"; exit 1 ;; \
    esac; \
    curl -fsSL "https://downloads.mongodb.com/compass/mongosh-${MONGOSH_VERSION}-linux-${MARCH}.tgz" -o /tmp/mongosh.tgz; \
    mkdir -p /opt/mongosh; \
    tar -xzf /tmp/mongosh.tgz -C /opt/mongosh --strip-components=1; \
    ln -sf /opt/mongosh/bin/mongosh /usr/local/bin/mongosh; \
    rm -f /tmp/mongosh.tgz; \
    mongosh --version

USER datahub

For packages not listed above, search the Wolfi package registry at Chainguard's migration guide — Searching for packages to find the correct Wolfi package name.

Change 2 — Remove or Replace the `dockerize` Startup Command

The dockerize executable was removed from the Remote Executor image in the v1.1.x-cloud line. Its readiness-polling functionality has been reimplemented natively inside start_datahub_executor.sh using curl. Any ECS Task Definition, CloudFormation template, Kubernetes manifest, or Docker Compose file that references dockerize as the container command must be updated.

Preferred approach (ECS / CloudFormation): Remove the Command override entirely. ECS will then use the image's built-in CMD, which correctly invokes /start_datahub_executor.sh.

# Remove this from your ECS Task Definition or CloudFormation template:
# "command": ["dockerize", "./start_datahub_executor.sh"]

# Simply omit the Command field — the image default handles startup.

Alternative (if an explicit command is required): Set the command to the absolute path of the startup script. Do not use a relative path (./).

# Correct explicit command (absolute path):
"command": ["/start_datahub_executor.sh"]

# Incorrect — do not use:
# "command": ["dockerize", "./start_datahub_executor.sh"]
# "command": ["./start_datahub_executor.sh"]

For CloudFormation deployments, apply this change using a Change Set rather than manually editing the ECS Task Definition, to avoid bypassing CloudFormation state tracking. The official CloudFormation template for the Remote Executor is maintained at:
```
https://github.com/acryldata/datahub-cloudformation/blob/master/remote-executor/datahub-executor.ecs.template.yaml
```
Use the current master branch. All other parameters (VPC, subnets, IAM roles, security groups, CPU, memory, access token secret, executor pool configuration) are preserved through a standard CloudFormation stack update.

Change 3 — Use the Correct Image Variant for Bundled Virtual Environments

The build_bundled_venvs_unified.sh script (required to pre-build plugin virtual environments) is only present in the slim and full (non-unbundled) image variants. It is intentionally absent from *-slim-unbundled and *-unbundled variants. If your Dockerfile calls this script, your BASE_IMAGE must be the slim (or full) variant:
```
# Use the slim variant (includes bundled venv builder):
ARG BASE_IMAGE=docker.datahub.com/re/datahub-executor:v1.1.x-cloud-slim

# Do NOT use the unbundled variant if you call build_bundled_venvs_unified.sh:
# ARG BASE_IMAGE=docker.datahub.com/re/datahub-executor:v1.1.x-cloud-slim-unbundled
```
Replace v1.1.x-cloud with the specific version tag that matches your DataHub Cloud instance version (e.g., v1.1.3-cloud).
The builder script location remains /usr/local/bin/build_bundled_venvs_unified.sh — this path did not change with the Wolfi migration:
```
USER datahub
RUN /usr/local/bin/build_bundled_venvs_unified.sh
```

If you receive an error such as A virtual environment already exists at /opt/datahub/venvs/s3-bundled, this means the base image already ships a pre-built virtual environment for that plugin. Remove s3 (and any other pre-built plugins) from your BUNDLED_VENV_PLUGINS list — the pre-built venvs are still available at runtime; you simply do not need to rebuild them:

# Remove any plugins that are pre-built in the base image (e.g., s3):
ARG BUNDLED_VENV_PLUGINS=kafka,snowflake,iceberg,redshift,postgres,boto3,requests,\
pyopenssl,airflow,spark,athena,grafana,trino,tableau,glue,mongodb,sql-queries,\
kafka-connect,neo4j,loki,datahub_integrations,unity-catalog,mssql,superset,dynamodb
# Note: s3 omitted above — already pre-built in v1.1.x-cloud-slim base image

The BUNDLED_CLI_VERSION for plugin virtual environments is dictated by the base image's pinned acryl-datahub-cloud dependency, not by the version number in the release notes. Check the release notes for the specific version of acryl-datahub pinned by your target base image and use that value for BUNDLED_CLI_VERSION. Attempting to set a higher CLI version will result in an unsatisfiable dependency error during the venv build.

Additional Notes

The Ubuntu-to-Wolfi base OS migration was introduced as part of a security-motivated change (feat(docker): Wolfi migration) in the v1.1.0-cloud release. Chainguard/Wolfi base images have a significantly reduced CVE surface area compared to Ubuntu. This change affects all executor variants (full, slim, slim-unbundled, locked) in the