DEV Community: Nayan Patil

Best Security Practices for Docker in 2023

Nayan Patil — Sat, 15 Apr 2023 12:57:47 +0000

Node.js has become a popular choice for building fast and scalable applications. However, deploying and scaling Node.js apps can be challenging, especially as your application grows. This is where Docker comes in - by containerizing your Node.js application, you can ensure consistent deployments across different environments and scale your app more easily.

In this article, we'll walk you through the best practices for dockerizing your Node.js app, including optimizing container size, using environment variables, and multistage builds.

Introduction

What is Docker?

Docker is a software platform that allows you to build, test, and deploy applications quickly. Docker packages software into standardized units called containers that have everything the software needs to run including libraries, system tools, code, and runtime.

Prerequisites

You should have Docker installed on your system, you can follow this guide on official Docker docs.
Basic knowledge of how docker works.
Basic NodeJs Application. if you don't, follow my guide on How To create an API using Node.js, Express, and Typescript, and clone the starter project via this GitHub repository

Let's write a basic Dockerfile for this Nodejs application,

FROM node
COPY . .
RUN npm install
CMD ["npm", "start"]

Best Security Practices for Docker in 2023 -

Always use a specific version for the base image for Dockerfile

# Use specific version
FROM node:16:17.1

COPY . .
RUN npm install
CMD ["npm", "start"]

When creating Docker images, it is important to use specific base image versions in your Dockerfile. This is because using the latest version of a base image may introduce compatibility issues with your application or dependencies, leading to unexpected errors and security vulnerabilities.

By using a specific version of a base image, you can ensure that your application runs consistently and reliably across different environments. Additionally, using specific base image versions can also help you comply with security and regulatory requirements.

Optimize your docker image by using a smaller base image

# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine

COPY . .
RUN npm install
CMD ["npm", "start"]

Using smaller-size base images is a critical best practice for optimizing Docker images. Smaller images can have a significant impact on your application's performance, reduce your storage and bandwidth costs, and minimize the number of potential vulnerabilities.

When selecting a smaller base image, you can avoid unnecessary dependencies and configurations that are not relevant to your application, ultimately leading to faster build times and smaller image sizes. By using a smaller base image, you can also reduce the attack surface of your application and improve its overall security posture.

With this, you can create Docker images that are smaller, faster, and more secure, enabling you to deliver your application with confidence.

Specify the correct working directory in Dockerfile

# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine

#Specify working directory for application
WORKDIR /usr/app
COPY . .
RUN npm install
CMD ["npm", "start"]

When building Docker images, it is crucial to set the working directory to the appropriate location to ensure that your application's files and dependencies are correctly referenced. Setting the working directory to the wrong location can cause confusion and unexpected errors, which can delay development and deployment times.

By using the correct working directory, you can also improve the readability of your Dockerfile, making it easier for other developers to understand and maintain your code. Additionally, the correct working directory can help ensure that any subsequent commands are executed in the correct location, avoiding file path issues and other complications.

With this you can streamline your Docker workflow and reduce the risk of errors and delays, allowing you to focus on delivering high-quality applications.

Always use the .dockerignore file

# .dockerignore
node_modules
package-lock.json
yarn.lock
build
dist

This file allows you to specify files and directories that should be excluded from the build context, which can significantly reduce the build time and the size of the resulting image.

When Docker builds an image, it starts by creating a build context that includes all the files in the directory where the Dockerfile is located. This context is then sent to the Docker daemon, which uses it to build the image. However, not all files in the directory are necessary for the build, such as temporary files, log files, or cached dependencies. These files can cause the build to be slower and result in a larger image size.

To avoid this, you can create a .dockerignore file that lists the files and directories that should be excluded from the build context. This file uses the same syntax as .gitignore, allowing you to specify patterns of files or directories to exclude. For example, you might exclude all .log files, cache directories, or build artifacts.

Copying package.json Separate from Source Code

# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine

#Specify working directory for application
WORKDIR /usr/app

# Copy only files which are required to install dependencies
COPY package.json .
RUN npm install

#Copy remaining source code after installing dependancies
COPY . .
CMD ["npm", "start"]

Copying package.json separately from the source code is a best practice for optimizing your Docker builds. By separating your application's dependencies from the source code, you can avoid unnecessary rebuilds and save time and resources.

When building a Docker image, copying the entire source code directory can be time-consuming and wasteful, especially if the source code changes frequently. Instead, by copying only the package.json file separately, Docker can leverage its layer caching capabilities to only rebuild the image when the dependencies change.

Use non root user

# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine

#Specify working directory for application
WORKDIR /usr/app

# Copy only files which are required to install dependencies
COPY package.json .
RUN npm install

# Use non root user
USER node

# Copy remaining source code after installing dependancies
# Use chown on copy command to set file permissions
COPY --chwon=node:node . .
CMD ["npm", "start"]

Running applications as root can increase the risk of unauthorized access and compromise the security of your containerized applications. By creating and running containers with non-root users, you can significantly reduce the attack surface of your applications and limit the potential damage in case of a security breach.

In addition to improving security, using non-root users can also help ensure that your Docker containers are compliant with industry security standards and regulations. For example, using non-root users is a requirement for compliance with the Payment Card Industry Data Security Standard (PCI DSS).

After using a non-root user, we need to permit to access our code files, as shown in the above example, we are using chown for copying files, this will give the non-root user to access the source code.

Multistage build for production

By using multiple stages in your Docker build process, you can reduce the size of your final image and improve its performance.

In a multistage build, each stage represents a different phase of the build process, allowing you to optimize each stage for its specific task. For example, you can use one stage for compiling your application code and another for running your application. By separating these tasks into different stages, you can eliminate unnecessary dependencies and files, resulting in a smaller, more efficient final image.

In addition to reducing image size, multistage builds can also improve security by eliminating unnecessary packages and files. This can reduce the attack surface of your Docker image and help ensure that only essential components are included.

# Stage 1: Build the application
# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine AS build

#Specify working directory for application
WORKDIR /usr/app

# Copy only files which are required to install dependencies
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Run the application
FROM node:16.17.1-alpine 

WORKDIR /usr/app

# set production environment
ENV NODE_ENV production

# copy build files from build stage
COPY  --from=build /usr/app/build .

# Copy necessary files
COPY  --from=build /usr/app/package.json .
COPY --from=build /usr/app/.env .

# Use chown command to set file permissions 
RUN chown -R node:node /usr/app

# Install production dependencies only
RUN npm install --omit=dev

# Use non root user
USER node

CMD ["npm","run", "start:prod"]

In this example, the first stage (named "build") installs the necessary dependencies, copies the source code, and builds the application. The resulting artefacts are then copied to the second stage (named "run"), which only includes the necessary dependencies to run the application in production. This separation of stages helps reduce the size of the final image and ensures that only essential components are included.

Note that the --from the flag in the second COPY command refers to the first stage, allowing us to copy only the built artefacts into the final image. This is an example of how multistage builds can be used to optimize the Docker build process.

Exposing port in Dockerfile

# Stage 1: Build the application
# Use specific version
# Use alpine for smaller base image
FROM node:16.17.1-alpine AS build

#Specify working directory for application
WORKDIR /usr/app

# Copy only files which are required to install dependencies
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Run the application
FROM node:16.17.1-alpine 

WORKDIR /usr/app

# set production environment
ENV NODE_ENV production

# copy build files from build stage
COPY  --from=build /usr/app/build .

# Copy necessary files
COPY  --from=build /usr/app/package.json .
COPY --from=build /usr/app/.env .

# Use chown command to set file permissions 
RUN chown -R node:node /usr/app

# Install production dependencies only
RUN npm install --omit=dev

# Use non root user
USER node

# Exposing port 8080
EXPOSE 8080

CMD ["npm","run", "start:prod"]

By exposing the ports that your application uses, you allow other services to communicate with your container.

To export a port in Docker, you need to use the EXPOSE instruction in your Dockerfile. This instruction informs Docker that the container will listen on the specified network ports at runtime. Note that this instruction does not publish the port, but rather documents the ports that the container is expected to use.

To export the port, you need to use the -p option when running the container, specifying the external port and the internal port where your application is listening. For example, docker run -p 8080:80 my-image will publish port 80 inside the container to port 8080 on the host machine.

By exporting ports in Docker, you enable seamless communication between your container and other services, both within and outside of your Docker environment. This best practice can help ensure that your application can be accessed by other services and that it can be easily integrated into a larger system.

Conclusion

In conclusion, Docker is a powerful tool for optimizing and scaling your Node.js application.

By following these best practices for Dockerizing your Node.js app, you can create images that are optimized for performance, security, and scalability. By using a specific base image version, a smaller base image size, the correct working directory, and a non-root user, you can ensure that your images are secure and optimized for production use. Using multistage builds, configuring your app for production, and exporting ports can also help ensure that your application can be easily scaled and integrated into a larger system.

In summary, Dockerizing your Node.js app using these best practices can help you create a containerized environment that is secure, scalable, and optimized for production use. By taking advantage of Docker's powerful tools and optimizing your images, you can ensure that your Node.js app runs smoothly and efficiently, allowing you to focus on building the features and functionality that your users need. So go ahead and Dockerize your Node.js app today, and experience the benefits of a containerized environment for yourself!

How To create an API using Node.js, Express, and Typescript

Nayan Patil — Sat, 06 Nov 2021 13:30:55 +0000

In this article, we will learn to create an API server using the Express framework and Typescript.

What is API?

An API (Application Programming Interface) is a way of interacting with a service, through a series of predefined requests.

Express

Express is an open-source web framework, for Node.js, designed to make developing websites, web apps, and API's easier.

Typescript

TypeScript is JavaScript with syntax for types, it is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale.

so let's dive into the tutorial,

Prerequisite:

Basic knowledge of NodeJs and Javascript
Basics of TypeScript

Step 1: Initialize the npm project

To initialize the project in the working directory and create a package.json file by running the below command in terminal

npm init -y

After running this command it will create the package.json file in the working directory

Step 2: Installing the dependencies

Now we have to install the required dependencies to create this API

npm install express dotenv

Dotenv - Dotenv is a zero-dependency module that loads environment variables from a .env file into process.env

Now we need to install the dev dependencies for typescript support
using --save-dev flag

npm install @types/node @types/express nodemon ts-node --save-dev

Now create a tsconfig.json file and save it with the below code

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "rootDir": "./",
    "outDir": "./build",
    "esModuleInterop": true,
    "strict": true
  }
}

Step 3: Add scripts in package.json file to run file

  "scripts": {
    "start": "ts-node server.ts",
    "dev": "nodemon --exec ts-node server.ts"
  },

Note - server.ts file which we will create in the next step

Step 4: Create a .env file

There are some details like port number, database URLs, username etc. which should be hidden and not to be exposed to public

so create a .env file and declare the port number

PORT=8080

Step 5: Create a server.ts file

Now comes an interesting part, creating server.ts file in root folder

first, we will import the packages

import Express from "express"
import dotenv from "dotenv"

Now get the port number from .env file

dotenv.config()
const PORT = process.env.PORT

Now the most important part, declaring '/' endpoint

const app : Express.Application = Express()

app.get("/", (req: Express.Request, res: Express.Response) => {
    res.send("Hello world")
})

app.listen(PORT, () => {
    console.log(`Server is listening on ${PORT}`)
})

we define a / endpoint, that will return the text Hello World!, and run our application on port 8080.

Note that the / endpoint will only match for GET requests, as we've defined it using the app.get method.

Step 6: Running our API

In your terminal, run the following command to start the application:

npm run dev

if you see the output like below

➜  express-typescript npm run dev

> express-typescript@1.0.0 dev
> nodemon --exec ts-node server.ts

[nodemon] 2.0.14
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: ts,json
[nodemon] starting `ts-node server.ts`
Server is listening on 8080

Great! now open your browser and navigate to localhost:8080. If everything worked successfully, "Hello World" should be displayed in your browser.

Congratulations, You have created API using express and typeScript

Full code -

import Express from "express"
import dotenv from "dotenv"

dotenv.config()

const PORT = process.env.PORT

const app : Express.Application = Express()

app.get("/", (req: Express.Request, res: Express.Response) => {
    res.send("Hello worrld")
})

app.listen(PORT, () => {
    console.log(`Server is listening on ${PORT}`)
})

Loved the article?
Follow me on -
Twitter