In your question you did not specify which files are "inaccessible" and where you expect them to be. But your Dockerfile
has some suspicious statements which won't work like you seem to expect them to work, e.g.:
RUN ng build
COPY dist /app/public
So you seemingly want to copy the results of ng build
from the dist
directory to /app/public
.
But the COPY
command actually copies files from the build context into the image, i.e., (in most cases) your current directory on the host!
What you want to do instead is to copy/move the files within the container, so you should be using the RUN
command:
RUN ng build
RUN mv dist /app/public/
(An even better solution would probably be to configure your ng build
such that it places the build results in public/
automatically)
Furthermore:
COPY start /app
# [...]
RUN ["chmod", "+x", "/app/start.sh"]
CMD [ "/bin/sh", "-c" , "/app/start.sh"]
The first command would copy a file start
from the build context as /app/start
into the image, but the latter commands reference a file /app/start.sh
, so the file names seem to be wrong here.
Also: have a look into the --chmod=
flag of the COPY
command.
Besides answering your question, here are some more comments on possible best practices:
RUN npm install
RUN npm ci
npm ci
will install the same packages again. You should only use one or the other. For building a docker image npm ci
is recommended; but then you also need to add the package-lock.json
earlier:
WORKDIR /app
COPY package.json package-lock.json .
RUN npm ci
See also What is the difference between "npm install" and "npm ci"?
Then:
RUN npm install -g @angular/cli
Better: include @angular/cli
in your installed packages in package.json
/package-lock.json
. That way you can pin the version of the package and make the build more reproducible - and @angular/cli
may be already included in your installed packages anyway.
You can then run the build using npx
with npx ng build
, or when configured as npm
script with npm run build
.
COPY . .
This will copy all files from the build context into the image. This should make all subsequent COPY
s redundant because all files then are already included in the image, e.g., start
/start.sh
, too.