When building Docker images based on RHEL7, you might encounter the frustrating error /bin/sh: unzip: command not found despite the utility being available on your host system. This occurs because Docker builds start from minimal base images that often exclude common utilities to reduce image size.

RHEL7 Docker images typically use minimal installations by default. The unzip package isn't included in the @core package group that forms the base of these images. Even if your build host has unzip installed, Docker builds operate in isolated environments that don't inherit host system packages.

For environments without internet connectivity, you have several options:

1. Using RPM Package Directly

If you can access the unzip RPM package from another RHEL7 system:

# Copy the RPM into your build context first
COPY unzip-6.0-21.el7.x86_64.rpm /tmp/
RUN rpm -ivh /tmp/unzip-6.0-21.el7.x86_64.rpm && \
    rm -f /tmp/unzip-6.0-21.el7.x86_64.rpm

2. Alternative Tools in Minimal Images

Some minimal tools might already be available:

# Using bsdtar (often included in libarchive)
RUN bsdtar -xf myzipfile.zip

# Using Python (if Python is installed)
RUN python -c "import zipfile; zipfile.ZipFile('myzipfile.zip').extractall()"

For environments with controlled internet access, the cleanest solution is to properly declare dependencies:

RUN yum install -y unzip && \
    yum clean all && \
    rm -rf /var/cache/yum

If you need to maintain a small image size, consider multi-stage builds:

FROM rhel7 as builder
RUN yum install -y unzip
COPY myzipfile.zip .
RUN unzip myzipfile.zip

FROM rhel7
COPY --from=builder /output /app

For truly minimal environments where you can't install anything, you might need to:

1. Pre-unzip files in your build context
2. Use alternative archive formats like .tar.gz that can be handled by native tar
3. Include a static binary of unzip in your repository

Remember that Docker best practices recommend keeping images minimal, so evaluate whether you really need unzip in your final image or just during build.

---

When building Docker images based on RHEL7, you might encounter the frustrating error:

/bin/sh: unzip: command not found

This occurs because minimal RHEL7 Docker images don't include the unzip utility by default. While the host system may have it installed, the build environment is isolated.

The challenge becomes more complex when:

• You don't have internet access during build
• You lack permissions to install packages
• You want to maintain a minimal image footprint

Here are several approaches to handle ZIP files in your Docker builds:

1. Install unzip in your Dockerfile

The most straightforward solution if you have internet access:

RUN yum install -y unzip && \
    unzip myzipfile.zip && \
    yum remove -y unzip && \
    yum clean all

2. Use Python's zipfile module

If Python is available in your image:

RUN python -c "import zipfile; zipfile.ZipFile('myzipfile.zip').extractall()"

3. Pre-extract before COPY

For build-time extraction without runtime dependencies:

# On your host machine:
unzip myzipfile.zip -d extracted_files

# In Dockerfile:
COPY extracted_files/ /destination/

4. Use busybox unzip

If your image includes busybox:

RUN busybox unzip myzipfile.zip

5. Alternative compression formats

Consider using tar which is typically available:

RUN tar -xvzf myarchive.tar.gz

The best solution depends on your specific constraints:

Solution	Internet Required	Root Required	Image Size Impact
Install unzip	Yes	Yes	High
Python zipfile	No	No	Medium
Pre-extraction	No	No	None
Busybox	No	No	Low
Tar alternative	No	No	None

For production deployments, consider this pattern:

FROM rhel7 as builder
RUN yum install -y unzip && \
    unzip myzipfile.zip

FROM rhel7
COPY --from=builder /extracted_files /app

This keeps your final image clean while handling the extraction in a temporary builder image.

For most cases, I recommend either:

1. Using pre-extracted files if possible
2. Implementing a multi-stage build if you need the extraction during build

Remember that adding packages to your image increases both build time and potential security vulnerabilities.