How to use docker to deploy front-end applications

Docker is becoming more and more popular. It can isolate the environment lightly and flexibly, expand capacity, and facilitate operation and maintenance management. It is also more convenient for developers to develop, test and deploy.
The most important thing is that when you are faced with an unfamiliar project, you can follow the Dockerfile and quickly get it running locally without even reading the documentation (the documentation may not be complete, and may not be correct).

The concept of devops is very emphasized nowadays. I put the five big words "devops" on my computer desktop and spent the whole day studying them. Suddenly it dawned on me that devops means writing a Dockerfile to run an application (just kidding.

Here we introduce how to use Docker to deploy front-end applications. A journey of a thousand miles begins with a single step. Step means to get it running first.

Let it run first

First, let's briefly introduce a typical front-end application deployment process.

1. npm install, install dependencies
2. npm run build, compile, package, generate static resources
3. Serve static resources

After introducing the deployment process, simply write a Dockerfile

FROM node:alpine

# Represents the production environment ENV PROJECT_ENV production
WORKDIR /code
ADD ./code
RUN npm install && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

Now the front-end service is running. You can then complete the other stages of deployment. Generally speaking, the following becomes the work of operation and maintenance, but it is always a good idea to expand the boundaries of your knowledge.

• Use nginx or traefik as reverse proxy
• Use kubernetes or compose for orchestration.
• Use gitlab ci or drone ci for CI/CD

There are two problems with the image at this time, which causes each deployment to take too long and is not conducive to the rapid delivery of the product.

• Building the image takes too long
• The size of the built image is too large, 1G+

Start with dependencies and devDependencies

Lu Xiaofeng once said that if a front-end programmer works eight hours a day, at least two hours are wasted. One hour for npm install and another hour for npm run build.

For each deployment, if you can reduce the download of useless packages, you can save a lot of image building time. Code style testing modules such as eslint, mocha, chai, etc. can be placed in devDependencies. Use npm install --production to install the package in a production environment.

For the difference between the two, please refer to the document https://docs.npmjs.com/files/package.json.html#dependencies

FROM node:alpine

ENV PROJECT_ENV production
WORKDIR /code
ADD ./code
RUN npm install --production && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

It seems to be a little bit faster.

We noticed that package.json is relatively stable compared to the source files of the project. If there is no new installation package to download, there is no need to reinstall the package when building the image again. You can save half the time on npm install.

Leveraging image caching

For ADD, if the content to be added has not changed, the cache can be used. It is a good idea to separate package.json from the source files and write them into the image. Currently, if there is no new installation package update, you can save half the time

FROM node:alpine

ENV PROJECT_ENV production

# http-server can also use cache if it does not change RUN npm install -g http-server

WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD ./code
RUN npm run build
EXPOSE 80

CMD http-server ./public -p 80

There are more details about using cache, which need special attention, such as the cache of RUN git clone <repo>

Refer to the official documentation https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache

Multi-stage builds

Thanks to caching, image build times are now much faster. However, the size of the image is still too large, which will increase the time of each deployment. Consider the process of each CI deployment.

1. Building images on a build server
2. Push the image to the image repository server,
3. Pull the image on the production server and start the container

Obviously, a large image size will result in low transmission efficiency and increase the delay of each deployment.

Even if the build server and the production server are on the same node, there is no delay issue. Reducing the size of the image can also save disk space

Regarding the excessive size of the image, a large part of it is due to the notorious size of node_modules.

But in the end we only need the contents under the public folder. The source files and files under node_modules take up too much space and are unnecessary, which causes waste.
At this point, you can use Docker's multi-stage build to extract only the compiled files

Refer to the official documentation https://docs.docker.com/develop/develop-images/multistage-build/

FROM node:alpine as builder

ENV PROJECT_ENV production

# http-server does not change and can also use cache WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD ./code
RUN npm run build

# Choose a smaller base image FROM nginx:alpine
COPY --from=builder /code/public /usr/share/nginx/html

At this point, the image size has increased from 1G+ to 50M+

Use CDN

Analyzing the image size of 50M+, the nginx:alpine image is 16M, and the remaining 40M is static resources.

If you upload static resources to CDN, there is no need to put them into the image. In this case, the image size will be controlled below 20M.

Regarding static resources, they can be classified into two parts

• /static, such files directly reference the root path in the project, are copied to /public during packaging, and need to be included in the image
• /build, such files need to be required, will be packaged by webpack and added with hash value, and the resource address can be modified through publicPath. Such files can be uploaded to CDN and permanently cached without the need to be mirrored.

FROM node:alpine as builder

ENV PROJECT_ENV production

# http-server does not change and can also use cache WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD ./code
# npm run uploadCdn is a script file that uploads static resources to the CDN. RUN npm run build && npm run uploadCdn


# Choose a smaller base image FROM nginx:alpine
COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
COPY --from=builder code/public/static /usr/share/nginx/html/static

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.