Docker / Docker Swarm with GitLab CI/CD Build jobs running very long

Discord Q&A deployment-questions
1

Hey,
im currently deploying my strapi app with docker swarm (Isnt part of the problem. the deployment job itself only takes 20 seconds). CI/CD is running on a gitlab runner at hetzner. Im curious if there are options to optimise build time. By know it takes between 6 and 16 minutes (Local builds on MacBook with docker-compose taking about 1 minute). I basically use the dockerfiles generated by https://github.com/strapi-community/strapi-tool-dockerize/ → strapi-tool-dockerize/templates/Dockerfile-prod.liquid at main · strapi-community/strapi-tool-dockerize · GitHub.
They haven’t worked out-of-the-box as i ran in to timeouts. Only started working after i gave my runner instance more computing power and switched to kaniko instead of docker-in-docker. therefore i separated the file generated by dockerize in two images to make kaniko caching more effective.
Have a feeling that RUN yarn config set network-timeout 600000 -g && yarn install --production --frozen-lockfile && yarn cache clean is the bottleneck.

Anyone a clue or similar problems?

# Docker.deps

FROM node:18-alpine
RUN apk update && apk add --no-cache build-base gcc autoconf automake zlib-dev libpng-dev vips-dev > /dev/null 2>&1
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}

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

FROM registry.gitlab.com/[***]/deps:latest as build

# Creating final production image
FROM node:18-alpine
RUN apk add --no-cache vips-dev
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}
WORKDIR /opt/
COPY --from=build /opt/node_modules ./node_modules
WORKDIR /opt/app
COPY --from=build /opt/app ./
ENV PATH /opt/node_modules/.bin:$PATH

RUN chown -R node:node /opt/app
USER node
EXPOSE 1337
CMD ["yarn", "start"]

This topic has been created from a Discord post (1243478012897263616) to give it more visibility.
It will be on Read-Only mode here.
Join the conversation on Discord

2

Hi,

Just caught my eye that you are still using Swarm :smile: Same we do. Either way, I don’t see a big deal with 6 min, but in this case, one thing that tends to make builds long is copying content inside the container. I can see you use COPY . . Something that might be able to help is creating a tar and unzipping inside, or reducing the amount of data that you copy.

But as said, it can be wrong, there are too many things that vary the time taken. Just as an idea usually runners and your local dev machine cannot be compared as CPU, and other specs are totally different. Either way, I think you might want to seek help outside here, as your problem is more related to Docker than Strapi.

3

Thanks for reply. Yes we used swarm as a starting point in favour of AWS bills for no reason :sweat_smile:
The thing is that I just havent that much content. Just some content types by now. Thats why i was wondering if something is strange in general.
The 6 mins are only achieved when kaniko chaches a warm otherwise its more like 20 mins… maaaah

I decided to be okay with it by now. Not sure if its really docker related cause its definitely the yarn install which takes the biggest amount of build time. So i guess there is some “heavier” stuff going on that somehow belongs to strapi / its deps.

If somehow I will make a deeper dive on that in future a will keep it posted here.

4

Can I ask a question?

I have been wanting to use strapi for a large project and I need to save costs with hosting. Do you think self hosting is best way looking at 5 years time