As a platform engineer I want to improve de DX of the devteam, by creating an alternate way to build the project image, without the need of a Dockerfile, and also improve the control over the base images that the development teams can use inside their organization.
To achieve that we would need some refactor in config file to add new optional block for flavor:
fs_builder:
technology: spa-node:18-rev23
template: spa-rev3
template_args:
REWRITE_RULES : {}
extra_packages: ["git"] # Extra system packages to install
build_commands: [npm ci && npm run build] # commands to build the artifact to install in the image
build_args: ["VITE_API_URL=https://my-url"] # Arguments to pass to the build system
Also, this images, although can be based on the public ones, must be published in the org registry.
Template (type of component)
For the construction of the artifact, we need to know the type of artifact to build, and based on this, use a serie of related steps to get the image, according to the organization and the definitions made by the platform team.
For example to build a spa image we will use something like the following template:
FROM spa-node:18-rev23-build AS builder
ARG VITE_API_URL="https://my-dev-url"
WORKDIR /app
COPY code code
RUN npm ci && npm build
FROM spa-node:18-rev23-run # nginx-stable
RUN apt-get update && apt-get install git -y
COPY --from=builder /app/dist /app
COPY docker/default.conf /etc/nginx/conf.d/
RUN chown -R nginx:nginx /client && chmod -R 755 /app && \
chown -R nginx:nginx /var/cache/nginx && \
chown -R nginx:nginx /var/log/nginx && \
chown -R nginx:nginx /etc/nginx/conf.d
RUN touch /var/run/nginx.pid && \
chown -R nginx:nginx /var/run/nginx.pid
USER nginx
EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"]
What and why
Use case
As a platform engineer I want to improve de DX of the devteam, by creating an alternate way to build the project image, without the need of a Dockerfile, and also improve the control over the base images that the development teams can use inside their organization.
To achieve that we would need some refactor in config file to add new optional block for flavor:
How
Base images
The technology would define a pair of docker images, which the platform team will create and maintain: one for run and one for build (and for CI workflows, see https://github.com/prefapp/firestarter-workflows/blob/main/firestarter/tests/fixtures/workflow.yaml)
In the previous example:
Also, this images, although can be based on the public ones, must be published in the org registry.
Template (type of component)
For the construction of the artifact, we need to know the type of artifact to build, and based on this, use a serie of related steps to get the image, according to the organization and the definitions made by the platform team.
For example to build a spa image we will use something like the following template: