Skip to content

[Bug]: General improvements to the example dockerfile #2577

@icefo

Description

@icefo

Link to the documentation page or resource

https://docs-v4.strapi.io/dev-docs/installation/docker

Describe the bug

Use yarn install --frozen-lockfile

As per their documentation:

If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.

Let sharp download the pre-built binaries it needs

Sharp has prebuilt binaries for it's dependencies for pretty much every sensible OS & architecture combination. If someone has to compile from source because he's running strapi from a 32 bit RISC board I think that's fine and it cuts down imagine build size & time for everyone else.

Prebuilt binaries

Ready-compiled sharp and libvips binaries are provided for use on the most common platforms:

macOS x64 (>= 10.15)
macOS ARM64
Linux ARM (glibc >= 2.31)
Linux ARM64 (glibc >= 2.26, musl >= 1.2.2)
Linux ppc64 (glibc >= 2.31)
Linux s390x (glibc >= 2.31)
Linux x64 (glibc >= 2.26, musl >= 1.2.2, CPU with SSE4.2)
Windows x64
Windows x86
Windows ARM64 (experimental, CPU with ARMv8.4 required for all features)

This provides support for the JPEG, PNG, WebP, AVIF (limited to 8-bit depth), TIFF, GIF and SVG (input) image formats.

DNS bugs in the alpine base image

I had terrible DNS bugs using the alpine node image given in the example in the gitea CI that went away by using the node:20-slim (debian based) image. I suppose it works fine in github & gitlab but I would at least add a warning for other users.

#8 76.81 sharp: Downloading https://github.com/lovell/sharp-libvips/releases/download/v8.14.2/libvips-8.14.2-linuxmusl-x64.tar.br
#8 76.81 sharp: Installation error: getaddrinfo ENOTFOUND github.com

Yarn install proceeded fine (until that point), I could also ping and make DNS requests from the alpine image. Only sharp or node-gyp had issues. I agree it's not a strapi bug but it still prevented the installation to proceed.

This specific bug is caused by sharp trying to download dependencies not installed globally but I had the same issue with node-gyp when building from source.

Additional context

No response

Suggested improvements or fixes

This is the Dockerfile I'm currently using:

FROM node:20-slim

ARG NODE_ENV=development
ENV NODE_ENV=${NODE_ENV}

WORKDIR /opt/
COPY package.json yarn.lock ./
RUN yarn config set network-timeout 600000 -g && yarn install --frozen-lockfile
ENV PATH=/opt/node_modules/.bin:$PATH

WORKDIR /opt/app
COPY . .

RUN chown -R node:node /opt/app
USER node

EXPOSE 1337
VOLUME /opt/app/src
VOLUME /opt/app/public
RUN ["yarn", "build"]
EXPOSE 1337
CMD ["yarn", "develop"]

The two VOLUME directives are necessary for our use case but feel free to remove them.

Related issue(s)/PR(s)

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions