Same Dockerfile gives different outcomes during build

1
votes

I am refactoring an angular application to switch from a VM architecture to Docker containers.

While building the container for Angular I came up with a Dockerfile to use as a builder in the multistage build. I worked like a charm on my Mac so i pushed it to our company github to be consumed by my colleagues.

The problem rise up when a colleague pulled from the repo and tried to build on his Mac (different models but more or less comparable, mine is a 2015, his is a 2016, both running Mojave).

This is the content of the dockerfile that is erroring:

# base image
FROM node:9.6.1 as builder

# install chrome for protractor tests
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
RUN sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
RUN apt-get update 
RUN apt-get install -y software-properties-common
RUN add-apt-repository -y ppa:fontforge/fontforge
RUN apt-get install -y google-chrome-stable
RUN apt-get install -y  fontforge ttfautohint gettext

I was assuming it to build fine as it was on my laptop but when he tries to launch the build he receives some errors in the step RUN apt-get update

The container gets a 404 while trying to update systemd and exits.

We tried also to spin up a new container FROM THE SAME image docker run --rm -it node:9.6.1 /bin/bash and copy-pasting all the instructions manually in the command line and it worked fine.

1. Why two different outcomes in two very similar but still different machines?

The entire point of docker containers should be abstracting the environment and create standalone environments for your applications, so why the same Dockerfile blueprints work perfectly on my machine and do not on his? Also the docker demon runs fine and it starts the container, the issue we have is during the system upgrade inside the container build.

2. Why on the same machine, the Dockerfile build fails while the same steps succeed if run manually?

This completely blew up my mind, i may even understand the two different machines issue, but i cannot find any logical explanation to this one: same commands fed to command line work while they don't if executed via script.

1
dockerdockerfile
A 404 error indicates an external problem. Maybe some mirror was used that temporarily did not have the requested file. - Henry
if the problem persist try tor run the build with --no-cache - gaber84
I would normally think the same but then how do you explain the fact that the VERY SAME commands (so the very same mirrors) succeed if manually run in the command line of a fresh container? - Marco Nicotra

1 Answers

0
votes

apt-get update, in particular, generates results that vary over time. These include URLs to Debian packages, and standard Debian package management practice is to remove a package from the repository listings as soon as there’s a newer version.

If you previously ran the Dockerfile up through the RUN apt-get update, and then later changed what specific packages get installed, you could wind up in a state where Docker cached the results of the update operation, but they’re no longer valid.

The usual answer to this is to make sure to run apt-get update && apt-get install in a single RUN step:

RUN apt-get update \
 && apt-get install -y software-properties-common
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
RUN echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list
RUN add-apt-repository -y ppa:fontforge/fontforge
RUN apt-get update \
 && apt-get install -y google-chrome-stable fontforge ttfautohint gettext