Optimize Your Experience with Containers. Make Your Containers Better, Smaller, More Secure and Do Less to Get There (free and open source!)

Note that DockerSlim is now just Slim (SlimToolkit is the full name, so it's easier to find it online) to show its growing support for additional container tools and runtimes in the cloud native ecosystem.

Slim is now a CNCF Sandbox project. It was created by Kyle Quest and it's been improved by many contributors. The project is supported by Root.io (formerly known as Slim.AI).

Here's how Slim and Root work together: Slim helps you build optimized containers, while Root.io automatically fixes vulnerabilities without disrupting your workflows. Use Slim's open source toolkit to optimize containers, then keep them secure with Root's automated vulnerability remediation – from optimization to continuous security in one seamless journey. Learn more at www.root.io.

Overview

SlimToolkit allows developers to inspect, optimize and debug their containers using its xray, lint, build, debug, run, images, merge, registry, vulnerability (and other) commands. It simplifies and improves your developer experience building, customizing and using containers. It makes your containers better, smaller and more secure while providing advanced visibility and improved usability working with the original and minified containers.

Don't change anything in your container image and minify it by up to 30x making it secure too! Optimizing images isn't the only thing it can do though. It can also help you understand and author better container images.

Keep doing what you are doing. No need to change anything. Use the base image you want. Use the package manager you want. Don't worry about hand optimizing your Dockerfile. You shouldn't have to throw away your tools and your workflow to have small container images.

Don't worry about manually creating Seccomp and AppArmor security profiles. You shouldn't have to become an expert in Linux syscalls, Seccomp and AppArmor to have secure containers. Even if you do know enough about it wasting time reverse engineering your application behavior can be time-consuming.

SlimToolkit will optimize and secure your containers by understanding your application and what it needs using various analysis techniques. It will throw away what you don't need, reducing the attack surface of your container. What if you need some of those extra things to debug your container? You can use dedicated debugging side-car containers for that (more details below).

SlimToolkit has been used with Node.js, Python, Ruby, Java, Go, Rust, Elixir and PHP (some app types) running on Ubuntu, Debian, CentOS, Alpine and even Distroless.

Note that some application stacks do require advanced container probing to make sure that all dynamically loaded components are detected. See the --http-probe* flags for more details to know how you can define custom probe commands. In some cases you might also need to use the --include-path flag to make sure everything your application needs is included (e.g., ubuntu.com python SPA app container image example where the client side template files are explicitly included).

It's also a good idea to use your app/environment tests when you run the Slim app. See the --continue-after flag for more details about integrating your tests with the temporary container Slim creates when it's doing its dynamic analysis. Running tests in the target container is also an option, but it does require you to specify a custom ENTRYPOINT/CMD with a custom wrapper to start your app and to execute your tests.

Interactive CLI prompt screencast:

Watch this screencast to see how an application image is minified by more than 30x.

When you run the build or profile commands in Slim it gives you an opportunity to interact with the temporary container it creates. By default, it will pause and wait for your input before it continues its execution. You can change this behavior using the --continue-after flag.

If your application exposes any web interfaces (e.g., when you have a web server or an HTTP API), you'll see the port numbers on the host machine you will need to use to interact with your application (look for the port.list and target.port.info messages on the screen). For example, in the screencast above you'll see that the internal application port 8000 is mapped to port 32911 on your host.

Note that Slim will interact with your application for you when HTTP probing is enabled (enabled by default; see the --http-probe* flag docs for more details). Some web applications built with scripting languages like Python or Ruby require service interactions to load everything in the application. Enable HTTP probing unless it gets in your way.

You can also interact with the temporary container via a shell script or snippet using --exec-file or --exec. For example, you can create a container which is only capable of using curl.

>> docker pull archlinux:latest
...

>> slim build --target archlinux:latest --tag archlinux:curl --http-probe=false --exec "curl checkip.amazonaws.com"
...

>> docker run archlinux:curl curl checkip.amazonaws.com
...

>> docker images
archlinux                 curl                ...        ...         17.4MB
archlinux                 latest              ...        ...         467MB
...

Community

Feel free to join any of these channels or just open a new Github issue if you want to chat or if you need help.

• CNCF Slack channel
• Discord server
• Discussions
• Twitter

SlimToolkit on the Internet

Books:

• Everyone's Docker/Kubernetes (Japanese)
• Docker in Practice (2nd edition)
• Docker/Kubernetes Security Practice Guide (Japanese)

Minification Examples

You can find the examples in a separate repository: https://github.com/slimtoolkit/examples

Node.js application images:

• from ubuntu:14.04 - 432MB => 14MB (minified by 30.85X)
• from debian:jessie - 406MB => 25.1MB (minified by 16.21X)
• from node:alpine - 66.7MB => 34.7MB (minified by 1.92X)
• from node:distroless - 72.7MB => 39.7MB (minified by 1.83X)

Python application images:

• from ubuntu:14.04 - 438MB => 16.8MB (minified by 25.99X)
• from python:2.7-alpine - 84.3MB => 23.1MB (minified by 3.65X)
• from python:2.7.15 - 916MB => 27.5MB (minified by 33.29X)
• from centos:7 - 647MB => 23MB (minified by 28.57X)
• from centos/python-27-centos7 - 700MB => 24MB (minified by 29.01X)
• from python2.7:distroless - 60.7MB => 18.3MB (minified by 3.32X)

Ruby application images:

• from ubuntu:14.04 - 433MB => 13.8MB (minified by 31.31X)
• from ruby:2.2-alpine - 319MB => 27MB (minified by 11.88X)
• from ruby:2.5.3 - 978MB => 30MB (minified by 32.74X)

Go application images:

• from golang:latest - 700MB => 1.56MB (minified by 448.76X)
• from ubuntu:14.04 - 531MB => 1.87MB (minified by 284.10X)
• from golang:alpine - 258MB => 1.56MB (minified by 165.61X)
• from centos:7 - 615MB => 1.87MB (minified by 329.14X)

Rust application images:

• from rust:1.31 - 2GB => 14MB (minified by 147.16X)

Java application images:

• from ubuntu:14.04 - 743.6 MB => 100.3 MB

PHP application images:

• from php:7.0-cli - 368MB => 26.6MB (minified by 13.85X)

Haskell application images:

• (Scotty service) from haskell:8 - 2.09GB => 16.6MB (minified by 125.32X)
• (Scotty service) from haskell:7 - 1.5GB => 21MB (minified by 71X)

Elixir application images:

• (Phoenix service) from elixir:1.6 - 1.1 GB => 37 MB (minified by 29.25X)

---

• RECENT UPDATES
• INSTALLATION
• BASIC USAGE INFO
• COMMANDS
• USAGE DETAILS
  • LINT COMMAND OPTIONS
  • XRAY COMMAND OPTIONS
  • BUILD COMMAND OPTIONS
  • DEBUG COMMAND OPTIONS
  • RUN COMMAND OPTIONS
  • REGISTRY COMMAND OPTIONS
  • VULNERABILITY COMMAND OPTIONS
• RUNNING CONTAINERIZED
• DOCKER CONNECT OPTIONS
• HTTP PROBE COMMANDS
• DEBUGGING MINIFIED CONTAINERS
• MINIFYING COMMAND LINE TOOLS
• QUICK SECCOMP EXAMPLE
• USING AUTO-GENERATED SECCOMP PROFILES
• ORIGINAL DEMO VIDEO
• DEMO STEPS
• FAQ
  • Is it safe for production use?
  • How can I contribute if I don't know Go?