Search code examples
dockersentry

Persist ENV in multi stage docker build


I have a Dockerfile specifying a multi-stage build like this:

FROM python:2.7.15-slim-jessie
RUN pip install devpi-client --index https://pypi.org/simple --proxy=myproxy.com
RUN devpi use http://proxyip/root/internal --set-cfg
ENV HTTP_PROXY="http://myproxy.com"
ENV HTTPS_PROXY="http://myproxy.com"


FROM sentry:9.0-onbuild

RUN apt-get -qq update && DEBIAN_FRONTEND=noninteractive apt-get install -y -q libxslt1-dev libxml2-dev libpq-dev libldap2-dev libsasl2-dev libssl-dev

COPY sentry.conf.py /etc/sentry/sentry.conf.py

COPY requirements.txt /tmp/

RUN pip install -r /tmp/requirements.txt

# cleanup
RUN apt-get remove -y -q libxslt1-dev libxml2-dev libpq-dev libldap2-dev libsasl2-dev libssl-dev
RUN rm -rf /var/lib/apt/lists/*
RUN rm /tmp/requirements.txt

`

The stage which inherits from sentry:9.0-onbuild has pip commands which fail during build since the ENV setting of the proxy for the pypi server is contained in the previous build stage. Is there a way to persist this ENV setting so the commands specified in the sentry:9.0-onbuild don't fail


Solution

  • Is there a way to persist this ENV setting [across build stages]

    No, there isn't.

    An option would be including a pair of ARG:

    ARG HTTP_PROXY=http://myproxy.com
    ENV $HTTP_PROXY
    
    ARG HTTPS_PROXY=https://myproxy.com
    ENV $HTTPS_PROXY
    

    in every stage. Not very elegant, but it would let you pass --build-arg HTTP_PROXY=http://whatever.com etc on the command line, just once, and it would be set for all stages.


    Another possibility, you could copy in a file from your host with these values defined:

    # proxy.env
    HTTP_PROXY=http://myproxy.com
    HTTPS_PROXY=https://myproxy.com
    

    And just source it as needed in each stage:

    FROM sentry:9.0-onbuild
    RUN source proxy.env && apt-get -qq update && DEBIAN_FRONTEND=noninteractive apt-get install -y -q libxslt1-dev libxml2-dev libpq-dev libldap2-dev libsasl2-dev libssl-dev
    

    Also kinda ugly, but at least you could keep the values consistent by defining them once somewhere, the file would be in VCS, and you wouldn't have to fool with passing --build-arg every build.