DEV Community: Sliplane

What's wrong with Docker?🐳

Jonas Scholz — Fri, 11 Aug 2023 00:11:47 +0000

I've worked a lot with Docker over the last 5+ years and have encountered weird behaviour, bugs, and people that hate Docker. What's the communities opinion of Docker here? What do you love, what do you hate, what have you never really understood?:D Maybe we can help each other out here :)

I will start: Why is Docker support for Windows so bad? Do you think it will ever get better? 🐳👀

5 Docker Commands You Don't Know Yet

Jonas Scholz — Thu, 10 Aug 2023 23:31:46 +0000

You just started with your Docker Journey and think you know everything? Strap in and learn some fancy new commands to impress your friends and boss with!

1. `docker system df`

If you're anything like me, you're probably building docker containers left and right without really thinking about where everything is stored. Want to find out how much storage your containers, images, volumes, and cache artifacts need? Simply run docker system df and be amazed at how much of your disk is just used for docker 🤓

PS: Too much space used? Try this: docker system prune --all

2. `docker stats`

Continuing with monitoring commands, did you know that you can see exactly how much resources each container is using? You can see the CPU, memory, and even network usage! Especially useful if you're running containers you haven't built yourself and you need to keep a close eye on them 👀

Simply run docker stats to see all the juicy details!

3. `docker build --cpu-quota=50000`

Everyone knows that Docker likes to use all of the available CPU resources, making everything else SUPER slow during the build process. But what if we could tell Docker how much of your available CPU to use? 🤔

The solution to this problem is the --cpu-quota flag of the docker build command which isn't even documented when executing docker build --help! The --cpu-quota flag allows you to define how much of your CPU cores can be used. Every core equals 100000. If you have a 4 core CPU and you want docker build to use a maximum of 80% of your CPU, you would need to calculate 4 * 100000 * 0.8 = 320000, and then set --cpu-quota 320000. On Linux or Macos you can also calculate it automatically:

# Linux
docker build --cpu-quota $(( $(grep -c ^processor /proc/cpuinfo) * 100000 * 8 / 10 )) -t your_image_name your_docker_directory

# MacOS
docker build --cpu-quota $(( $(sysctl -n hw.logicalcpu) * 100000 * 8 / 10 )) -t your_image_name your_docker_directory

4. `docker cp`

The docker cp command is useful for copying files or directories between a running Docker container and your local filesystem. This is especially handy when you need to extract logs or output files from a container. The command is quite simple: You need your containers name, the path of the file inside your container, and the path on your filesystem where the file should be copied to. Then combine it to get something like that:

5. `docker top`

Alright, last but not least we have docker top! docker top prints out the currently running processes inside a running container. If you start a container with --name myapp, simply run docker top myapp and you will see what is going on inside the container. This is especially great if you're debugging a container and you're not sure if your CMD command is correct!

Conclusion

I really hope you learned one or two new docker commands today! If you need any help, or have any questions about these commands, please write a comment! And if you want to deploy your own Dockerized Apps, check out Sliplane!

Understanding Next.JS Docker Images

Jonas Scholz — Mon, 07 Aug 2023 20:07:24 +0000

If you've tried to containerize a NextJS app, you've probably found the official documentation to be a bit lacking. Especially for beginners, the provided Dockerfile might be confusing. In this post, we'll go over the Dockerfile and explain what exactly is going on!

The Dockerfile

Let's start by looking at the Dockerfile provided by the wonderful NextJS team.

The Dockerfile can be broken down into 4 parts: the base image, the dependency installation, the build, and the runtime.

The Base Image

The first part (and first line!) of the Dockerfile is the base image that the Docker Image is built on top of. Similar to an operating system like Linux or Windows, the base image provides the foundation and structure for the rest of the image. In this case, we use node:18-alpine, which is a small but powerful image that contains NodeJS. The 18 refers to the version of NodeJS. If you want to use a different version, you could replace the 18 with a 16 or 20!

Dependency Installation

As always with Next.JS projects, we first need to install our dependencies. This is done in the next block. But before we install our dependencies, we see the line:

RUN apk add --no-cache libc6-compat

Why is this line here? Well, the node:18-alpine image is based on Alpine Linux, which is a very small Linux distribution. However, it is so small that it doesn't have all the libraries that some NodeJS packages need. The libc6-compat package provides some of these libraries, reducing the chance of errors when installing dependencies. This line isn't always needed, but it's a good idea to include it just in case. If you want a more in-depth explanation of why this might be needed, check out this Github Repo.

Now we can finally start working on our dependencies! To keep everything neat and tidy, we first create a new directory called /app and set it as our working directory. Then, we copy over the package.json, package-lock.json, yarn.lock, and pnpm-lock.yaml files.

Now you might be looking at your own Next.JS app and only see one or two of these files. That's okay! The Dockerfile is designed to work with all three of the most popular NodeJS package managers: npm, yarn, and pnpm.

Because this Dockerfile is designed to work with all three package managers, the next part is also a bit more complicated:

RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i --frozen-lockfile; \
  else echo "Lockfile not found." && exit 1; \
  fi

This block of code checks which package manager you're using by checking which lockfile exists. If you're using yarn, it will run yarn --frozen-lockfile. If you're using npm, it will run npm ci. If you're using pnpm, it will run yarn global add pnpm && pnpm i --frozen-lockfile. If you're using something else, it will print an error message and exit.

If you know which package manager you're using, you can simplify this part of the Dockerfile. For example, if you're using npm, you can remove the yarn.lock and pnpm-lock.yaml files and replace the entire block with:

COPY package.json package-lock.json* ./
RUN npm ci

Try it out and see if it works! If not, feel free to write a comment below and I'll be happy to help you out :)

The Build

The next part of the Dockerfile contains the actual build process where we compile our NextJS app.

As before, we first start a new image layer and set our working directory to /app. Then, we copy over the node_modules folder from our previous image layer. After copying the node_modules folder, we copy over the rest of our app. This is done in two steps to improve build times. If we copied over the entire app first, then every time we made a change to our app, we would have to reinstall our dependencies. By copying over the node_modules folder first, we can skip the dependency installation step if we haven't changed our dependencies! Smart, right?

Finally, we run yarn build to execute the command that is defined in our package.json file. This command is usually next build, but it can be changed to whatever you want. It doesn't really matter if we use yarn or npm here, because we already installed our dependencies in the previous step and the package manager doesn't really matter for the build process!

The Runtime

And finally, we are done with installing our dependencies and building our app! The last part of the Dockerfile is the runtime, where we actually run our app. This part is a bit longer, so let's go through it step by step.

Again, we start by creating a new image layer and setting our working directory to /app. We then set the NODE_ENV environment variable to PRODUCTION. This signals to NextJS that we are running in production mode, which will improve performance. This can also affect other parts of your app and NodeJS. Check out this awesome documentation page for more information!

Next, we create a new group and user. This is done to improve security. If we didn't do this, our app would run as root, which can be a security issue. Generally, you want to try to follow the "Principle of least privilege", which states that you should only give your app the permissions that it needs. In this case, our app doesn't need root permissions, so we create a new user and group for it. We then finally switch to this new user with USER nextjs.

Now we can finally copy over the build artifacts from the previous image layer. We first copy over the ./public folder which includes all of our static assets. Then, we copy over the ./.next/standalone and ./.next/static folders, which include all of our compiled code. This step will only work if you set your output mode in your Next.JS Config. If you don't set your output mode, your dependencies will not be included!

At this point we have improved security, enabled production mode, and copied over all the build artifacts. The next 3 lines are all about networking and making our Next.JS app available to the the network.

We first expose port 3000 to the network with EXPOSE 3000. This doesn't actually do anything, but it's a good practice to include it so that other developers know which port the Docker Container will be running on. Next, we set the PORT environment variable to 3000. This is used by NextJS to determine which port to run on. Finally, we set the HOST environment variable to localhost.

The last line is the actual command that is run when the Docker Container is started and is not executed during the image build process. Since we compiled the Next.JS app to a standalone file, we can simply start it with node server.js. That's it! We're done! 🎉🎉🎉

Conclusion

That was a long one, good job! I hope this post helped you understand the NextJS Dockerfile a bit better. If you have any questions, feel free to leave a comment below and I'll be happy to help you out! If you have any suggestions for future posts, I'd love to hear them as well. Thanks for reading! 😊

Want to host your next cool dockerized Next.JS project? Check out Sliplane!

Minimizing Nuxt 3 Docker Images

Jonas Scholz — Fri, 04 Aug 2023 22:55:02 +0000

You've just finished building an awesome Nuxt 3 application, but there's a catch – your Docker image is over 1 Gigabyte in size, your laptop is exploding trying to upload the image and deployment feels like a never-ending wait. Fear not, fellow Nuxt enthusiast! In this blog post, we'll dive into the art of minimizing Nuxt 3 Docker images, starting with a basic unoptimized image that is 1.4 Gigabyte large and ending with a image that's only 164 MB in size. That's a 850% reduction in size! Your boss and laptop will thank you :)

You can either follow along with your own Nuxt 3 project or just check out the final GitHub repository.

The Basic Nuxt 3 Docker Image

While I don't know the exact Docker Image you are using, I bet it looks something like this:

# Use any Node.js base image that you want!
FROM node:18

# Set the working directory to /app
WORKDIR /app

# Copy the package.json file into the working directory before copying the rest of the files to cache the dependencies
COPY package.json /app

# Install the dependencies, you might want to use yarn or pnpm instead
RUN npm install

# Copy the rest of the files into the working directory
COPY . /app

# Build the application, again, use yarn or pnpm if you want
RUN npm run build

# Start the application. This is the default command for Nuxt 3
CMD ["node", ".output/server/index.mjs"]

This Dockerfile is pretty straightforward. It starts with a Node.js 18 base image, copies the package.json file, installs the dependencies, copies the rest of the files, builds the application and finally starts the application. This is a great starting point, but it's not very optimized. This results in a 1.4 Gigabyte large Docker image. Let's see if we can do better!

Step 0: Using an Alpine base image

The first thing we can do is use an Alpine base image instead of a Debian base image. This will reduce the size of our Docker image by about 1 Gigabyte!. This is a very easy change, since Alpine images are provided by Docker. All we need to do is change the base image from node:18 to node:18-alpine:

# Use any Node.js base image that you want (as long as it's Alpine)!
FROM node:18-alpine

# Set the working directory to /app
WORKDIR /app

# Copy the package.json file into the working directory before copying the rest of the files to cache the dependencies
COPY package.json /app

# Install the dependencies, you might want to use yarn or pnpm instead
RUN npm install

# Copy the rest of the files into the working directory
COPY . /app

# Build the application, again, use yarn or pnpm if you want
RUN npm run build

# Start the application. This is the default command for Nuxt 3
CMD ["node", ".output/server/index.mjs"]

This is of course a tradeoff, since Alpine images come with less preinstalled software and have a different package manager among other things. But if we are just building a Nuxt 3 application, this is a great way to reduce the size of our Docker image and the change will probably not affect us at all.

Step 1: Ignoring unnecessary files

The next and probably easiest thing we can do is create a .dockerignore file and ignore all files that are not needed in the Docker image. This works similar to a .gitignore file you might already be familiar with. The .dockerignore file will simply tell Docker to ignore certain files and directories when building the image. This is highly dependent on your project, but here's an example of a .dockerignore file for a Nuxt 3 project:

node_modules
.output
.nuxt
.git
docs

This will ignore your installed node_modules folder, since we will install the dependencies in the Docker image. It will also ignore the .output and .nuxt folders, since we will build the application in the Docker image. Finally, it will ignore the .git folder and the docs folder, since we don't need them in the Docker image. Depending on your project, you might need to ignore more files and folders. For example, if you are using a CI/CD tool like GitHub Actions, you might want to ignore the .github folder. You get the idea. Go wild and try to ignore as many files and folders as possible. This will reduce the size of your Docker image and speed up the build process!

Step 2: Using a multi-stage build

The next thing we can do is use a multi-stage build. This is a very powerful feature of Docker that allows us to build our application in one Docker image and then copy the built application into a second Docker image. This allows us to use a very large Docker image to build our application, but then use a very small Docker image to run our application. This is a great way to reduce the size of our Docker image, since we don't need all the build tools in our final Docker image. Let's see how this works in practice:

# Use a large Node.js base image to build the application and name it "build"
FROM node:18-alpine as build

# Exact same steps as before
WORKDIR /app

COPY package.json /app

RUN npm install

COPY . /app

RUN npm run build

# Create a new Docker image and name it "prod"
FROM node:18-alpine as prod

WORKDIR /app

# Copy the built application from the "build" image into the "prod" image
# This will only copy whatever is in the .output folder and ignore useless files like node_modules!
COPY --from=build /app/.output /app/.output

# Start is the same as before
CMD ["node", ".output/server/index.mjs"]

Step 3: Using a distroless image

Using a distroless image is another great way to reduce the size of your Docker image, but implies a few tradeoffs for relatively small gains (13 MB in our case). Distroless images are Docker images that don't contain any operating system packages. This means that you can't use any tools like bash or curl in your Docker image. For most applications, this is not a problem. The best way to find out if this works for you is to simply try it out. For that, you can just change the prodution image to a distroless image like this:

# Use a large Node.js base image to build the application and name it "build"
FROM node:18-alpine as build

WORKDIR /app

# Copy the package.json and package-lock.json files into the working directory before copying the rest of the files
# This will cache the dependencies and speed up subsequent builds if the dependencies don't change
COPY package*.json /app

# You might want to use yarn or pnpm instead
RUN npm install

COPY . /app

RUN npm run build

# Instead of using a node:18-alpine image, we are using a distroless image. These are provided by google: https://github.com/GoogleContainerTools/distroless
FROM gcr.io/distroless/nodejs:18 as prod

WORKDIR /app

# Copy the built application from the "build" image into the "prod" image
COPY --from=build /app/.output /app/.output

# Since this image only contains node.js, we do not need to specify the node command and simply pass the path to the index.mjs file!
CMD ["/app/.output/server/index.mjs"]

Note that we are using the node:18-alpine image for the build stage, since the gcr.io/distroless/nodejs:18 image doesn't contain any build tools.

Step 4: Using a CDN for static assets

If you have a lot of static assets such as images or videos in your application, you can use a CDN to serve those assets. This will reduce the size of your Docker image, since you don't need to copy the static assets into the Docker image. Instead, you can just reference the static assets from the CDN. This doesn't just decrease the size of your Docker image, but also speeds up your application and reduces the load on your server! To serve static assets from a CDN, you will need to configure your Nuxt App and upload the static assets to the CDN. How you upload your static assets to the CDN depends on what CDN you are using and goes beyond the scope of this blog post. What you will need to do in any case, is remove the static assets from your Docker image. You can do that by only copying the server files into your final production image like this:

FROM node:18-alpine as build

WORKDIR /app

COPY package.json /app

RUN npm install

COPY . /app

RUN npm run build

FROM gcr.io/distroless/nodejs:18 as prod

WORKDIR /app

COPY --from=build /app/.output/server /app/.output/server

EXPOSE 3000/tcp

CMD ["/app/.output/server/index.mjs"]

Final Result

Our final Docker image is only 164 MB in size, which is a 850% reduction! If you want to have a reproducible example, you can check out the GitHub repository.

What's next?

At this point your Docker image should be less than 200 MB in size, which is pretty good! Of course, you can always go further and optimize your Docker image even more. But at some point you are going to hit diminishing returns. If you are tired of optimizing Docker images and want to focus on shipping your product, check out Sliplane to host your next project without giving up control over your own infrastructure!

DEV Community: Sliplane

What's wrong with Docker?🐳

5 Docker Commands You Don't Know Yet

1. docker system df

2. docker stats

3. docker build --cpu-quota=50000

4. docker cp

5. docker top

Conclusion

Understanding Next.JS Docker Images

The Dockerfile

The Base Image

Dependency Installation

The Build

The Runtime

Conclusion

Minimizing Nuxt 3 Docker Images

The Basic Nuxt 3 Docker Image

Step 0: Using an Alpine base image

Step 1: Ignoring unnecessary files

Step 2: Using a multi-stage build

Step 3: Using a distroless image

Step 4: Using a CDN for static assets

Final Result

What's next?

1. `docker system df`

2. `docker stats`

3. `docker build --cpu-quota=50000`

4. `docker cp`

5. `docker top`