The AS keyword is used to give the build stage a name.
Using a named build stage allows you to create multi-stage builds in Docker. With multi-stage builds, you can use one Dockerfile to define multiple stages of the build process, where each stage produces an intermediate image that is used as the base image for the next stage.
This can be useful for reducing the size of your final image, as well as for keeping your build process organized and easy to manage.
here's a simple example of using AS to create a multi-stage Docker build:
# Build stage
FROM node:14 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
# Final stage
FROM node:14
WORKDIR /app
COPY --from=build /app/dist ./dist
EXPOSE 3000
CMD ["node", "./dist/index.js"]
In this example, we're building a Node.js application that requires compilation before it can be run. The Dockerfile has two stages: a build stage and a final stage.
The build stage is based on the node:14 image, and is named "build" using AS.
The final stage is also based on the node:14 image, and copies the compiled output from the build stage using the COPY --from=build instruction. It sets the working directory to /app, and sets the command to run the application with node ./dist/index.js.
Using a multi-stage build like this allows us to keep the final image size small by only including the necessary files for running the application.
Skipping unnecessary build dependencies and artifacts
In this example, some of the unnecessary build dependencies and artifacts that we may want to exclude from the final image include:
Node.js development dependencies: When building a Node.js application, we may use certain development dependencies like nodemon or eslint that are not required for running the application in production. We can exclude these dependencies from the final image to reduce its size.
Build artifacts: When compiling a Node.js application, the output may include various intermediate files that are only required during the build process. These files can be safely excluded from the final image.
Caching dependencies: When building a Docker image, Docker will cache each step of the build process to speed up subsequent builds. However, this caching can also result in unused dependencies and files being included in the final image. To avoid this, we can use the --no-cache option when building the image to disable caching, or we can use multi-stage builds to separate the build dependencies from the final image.
By separating the build process into a separate build stage, we can ensure that the final image only includes the necessary files and dependencies required to run the application, without including any unnecessary artifacts or build dependencies.
Hope you found this helpful
let me know if you have any thoughts in the comments
HASH
Top comments (0)