kevinpollet.dev

Introducing seel

Thu, 17 Oct 2019 00:00:00 +0000

I’m impatient and thrilled to introduce seel, a command-line tool to containerize your Node.js application without effort. Not all developers are Docker/container experts and containerizing an application is not a simple task. For example, you will have to:

Write a Dockerfile
Follow the security best practices
Build the smallest image possible
Optimize the Docker build cache
Define a tagging strategy (e.g. semantic versioning, git commit hash)
Write and maintain build and publish scripts

Focus on your application, seel takes care of the containerization

To simplify this seel uses opinionated, but configurable, defaults based on the properties defined in the application package.json (e.g. name, version, bin/main scripts, description, …).

The following screencast shows the containerization of an application created from scratch with npm (more examples are available here).

Some features

Tree shaking, only the entry module dependencies are packaged
Automatic image tagging with semantic versioning
Automatic image labelling (description, maintainer, version)
Secure private package registry configuration
Optimized Docker build cache

What’s next?

seel is actively developed and at its early stages. If you want to test it, file bugs, request a feature or contribute some code, go to the GitHub repository and don’t miss to give some 💚 and support with a ⭐.

How to use your .dockerignore as a whitelist

Sat, 10 Aug 2019 00:00:00 +0000

Many tools use ignore files to exclude files from build, process or publish steps (e.g. .npmignore for npm, .gitignore for Git and .dockerignore for Docker). As your project grows, evolves, it can be hard to maintain the exclusion patterns and, as a side effect, you can expose unwanted or sensitive files. Using your .dockerignore as a whitelist can be an elegant option to avoid these mistakes and to reduce the effort to keep things up to date.

What’s the .dockerignore for?

When you’re creating a Docker image, the very first step is to define the build instructions in a Dockerfile. The second step is to run the docker build PATH command from the Docker CLI. The PATH argument is the path to the folder containing your Dockerfile. As a result, the Docker CLI will send the build context to the Docker daemon.

The build context

Every file and folder within the given PATH are tard by the Docker CLI and sent to the Docker daemon. These files and folders compose the build context. Your Docker image will be built with this context, so unwanted files sent to the daemon can be packaged by error in the final image with the ADD or COPY instructions.

Also, the Docker daemon can be executed on a remote machine, so it’s better to avoid sending large, unnecessary and sensitive files to it.

Remember, ADD and COPY instructions are run by the daemon and never by the CLI, so they are not used to remove unwanted files from the build context.

Exclude files from the build context

When you invoke the docker build command, the Docker CLI looks for a file named .dockerignore in the root folder of the build context (i.e. in the root folder of the given PATH). If this file exists, every file and folder matching the exclusion patterns will not be included in the tar archive sent to the Docker daemon. The Docker build will be faster and the risk of packaging unwanted files reduced.

For example, if you want to exclude the .git folder and all markdown files from the build context, add the following content to your .dockerignore:

.git
*.md

Use your .dockerignore as a whitelist

Blacklist vs whitelist is a long debate and, I think, both types have its use case. From my experience, you’ll have more files to exclude from your build context than to include, so to keep things clean and secure, whitelisting files is less error-prone.

If you’ve read the .dockerignore documentation, you may have noticed the following lines:

Finally, you may want to specify which files to include in the context, rather than which to exclude. To achieve this, specify * as the first pattern, followed by one or more! exception patterns.

Pretty easy!

As an example, the following .dockerignore instructs the Docker CLI to exclude everything excepted the JS files within the lib folder from the build context:

# Ignore everything
*
# Allow files and folders with a pattern starting with !
!lib/**/*.js

With a whitelist it’s also possible to publish unwanted or sensitive files from a whitelisted folder but, in my opinion, this issue is minor.

Summary

Now that you know how to blacklist or whitelist files with your .dockerignore, choose the best option for your use case. To conclude, using your .dockerignore as a whitelist allows to:

Exclude by default everything from the build context
Reduce the size of the tar archive sent to the Docker daemon
Reduce the risk of packaging unwanted or sensitive files in your Docker image
Reduce the effort to keep exclusion patterns up to date

PS: You can use the same trick with your .gitignore or .npmignore. For npm, the best practice is to use the files property in your package.json instead of a .npmignore file.

The beginning of my blogging journey

Sun, 28 Jul 2019 00:00:00 +0000

As said in the description, every journey has a beginning and here is a little write-up for the beginning of my blogging journey. In the past I’ve created many blogs but nothing was publicly available or updated because I was not satisfied by the result. As a therapy and to improve my writing skills, I will try to post articles on a regular basis on things I’ve learned or hacked during my developer journey, which have started 10 years ago, even if it’s not perfect in my point of view.

The best is the enemy of the good — Voltaire

About Me

Mon, 01 Jan 0001 00:00:00 +0000

Hey, I am Kevin, an enthusiast open-source developer, currently working at Traefik Labs. I am working on Traefik Proxy and Traefik Mesh and multiple things to make networking boring.

I have been programming for a long time, and I am passionate about everything related to Go, Network, Containers, Cloud, and Distributed systems.

Last but not least, I am also a space cat lover!