Introduction
The daemon.json file is a crucial configuration file for Docker that allows administrators to customize various aspects of the Docker daemon’s behavior. Here’s the purpose of this file, common configuration options, and best practices for optimizing Docker performance and security.
The Need for daemon.json
The daemon.json file serves several important purposes:
-
Centralized Configuration: It provides a centralized location for Docker daemon settings, making it easier to manage and version control configurations.
-
Persistence: Unlike command-line flags, settings in
daemon.jsonpersist across Docker daemon restarts. -
Flexibility: It allows for easy modification of Docker’s behavior without changing startup scripts or systemd unit files.
-
Standardization: In multi-host environments, it enables consistent configuration across multiple Docker hosts.
Location and Format
On Linux systems, the daemon.json file is typically located at /etc/docker/daemon.json. If it doesn’t exist, you can create it. The file uses JSON format, which is easy to read and modify.
Rootless Docker Configuration
When using rootless Docker, the location of the daemon.json file is different. For rootless mode, the configuration file is located at ~/.config/docker/daemon.json in the user’s home directory. This separate location ensures that rootless Docker configurations don’t interfere with system-wide Docker settings and allows individual users to have their own custom Docker daemon configurations. Remember to create this file if it doesn’t exist, and ensure it has the correct permissions for the user running rootless Docker.
Common Configuration Options
Let’s explore some common options that can be set in the daemon.json file, along with their purposes and examples:
1. Storage Driver
{ "storage-driver": "overlay2"}-
Purpose: Specifies the storage driver used by Docker.
-
Options:
overlay2,btrfs,zfs,fuse-overlayfs,vfs(the oldaufsanddevicemapperdrivers were removed from recent Docker Engine releases, don’t reach for them) -
Best Practice:
overlay2is recommended for most Linux distributions due to its performance and stability. -
Pros: Can impact container performance and resource usage.
-
Cons: Changing the storage driver requires recreating all containers and images.
2. Live Restore
{ "live-restore": true}-
Purpose: Keeps containers running during Docker daemon downtime.
-
Pros: Improves container availability during daemon updates or crashes.
-
Cons: May lead to inconsistent state if daemon is down for extended periods.
3. DNS Settings
{ "dns": ["8.8.8.8", "1.1.1.1"]}-
Purpose: Specifies DNS servers for Docker to use.
-
Pros: Allows custom DNS configuration, useful in corporate networks or for privacy.
-
Cons: Incorrect settings can lead to name resolution issues.
4. Logging
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" }}-
Purpose: Configures Docker’s logging behavior.
-
Options: Various drivers like
json-file,syslog,journald, etc. -
Pros: Helps manage log storage and rotation.
-
Cons: Incorrect settings might lead to disk space issues or loss of log data.
5. Registry Mirrors
{ "registry-mirrors": ["https://mirror.gcr.io"]}-
Purpose: Specifies alternative Docker registry mirrors.
-
Pros: Can improve pull speeds and reliability.
-
Cons: Misconfiguration might lead to failed pulls or security risks.
6. Insecure Registries
{ "insecure-registries": ["myregistry.example.com:5000"]}-
Purpose: Allows connection to registries without HTTPS.
-
Pros: Useful for testing or internal registries.
-
Cons: Reduces security; should not be used in production without careful consideration.
7. Default Address Pools
{ "default-address-pools": [ {"base":"172.80.0.0/16","size":24}, {"base":"172.90.0.0/16","size":24} ]}-
Purpose: Configures the IP address range for network creation.
-
Pros: Helps avoid IP conflicts in complex networking setups.
-
Cons: Incorrect configuration can lead to network issues.
My Production Configuration
Now, let’s examine the configuration I use in my production machines and discuss why these settings make sense for a production environment:
{ "storage-driver": "overlay2", "live-restore": true, "dns": ["9.9.9.10", "1.1.1.1", "8.8.8.8"], "max-concurrent-downloads": 5, "max-concurrent-uploads": 5, "log-driver": "json-file", "log-opts": { "max-size": "5m", "max-file": "3" }}Whats in this Configuration:
-
Storage Driver: Using
overlay2is a good choice for most modern Linux systems due to its performance and stability. -
Live Restore: Enabling this feature helps maintain high availability of containers during daemon updates or restarts.
-
DNS: Multiple DNS servers are specified, providing redundancy. The chosen servers (Quad9, Cloudflare, and Google) are reliable and widely used.
-
Concurrent Operations: Limiting concurrent downloads and uploads to 5 helps prevent resource exhaustion while still allowing parallel operations.
-
Logging: The
json-filedriver with size and file count limits helps prevent log files from consuming too much disk space.
This configuration in my opinion demonstrates a focus on performance, stability, and efficient resource management, which are crucial in a production environment.
Best Practices
-
Version Control: Keep your
daemon.jsonfile in version control to track changes and help rollbacks if needed. -
Regular Reviews: Periodically review and update your Docker daemon configuration to ensure it aligns with current best practices and your evolving needs.
-
Testing: Always test configuration changes in a non-production environment before applying them to production systems.
-
Documentation: Maintain documentation explaining the rationale behind your configuration choices.
-
Security: Be cautious with settings that might impact security, such as
insecure-registries. -
Monitoring: Implement monitoring to track the impact of your Docker daemon configuration on system performance and stability.
Conclusion
The daemon.json file is a powerful tool for customizing Docker’s behavior to suit your specific needs. By understanding the available options and following best practices, you can optimize Docker’s performance, security, and resource usage in your environment. Regular review and thoughtful configuration of this file can enhance your Docker experience, whether you’re a system administrator, DevOps professional, or developer.
Common Questions
Where is the Docker daemon.json file located?
The daemon.json file lives at /etc/docker/daemon.json on Linux, and you create it if it does not exist. Rootless Docker reads ~/.config/docker/daemon.json in the user’s home directory instead. Create that file too if it is missing, with correct permissions for the user running rootless Docker.
How do I stop Docker logs from filling my disk?
Set the json-file log driver with max-size and max-file under log-opts. The production configuration uses 5m and 3. Size and file count limits help prevent log files from consuming too much disk space. Incorrect values can still lead to disk space issues or loss of log data, so set both options.
Can I change the Docker storage driver without recreating containers?
No. Changing the storage driver requires recreating all containers and images. The post recommends overlay2 for most Linux distributions because of its performance and stability. The older aufs and devicemapper drivers were removed from recent Docker Engine releases, so avoid them.
What does live-restore do in Docker?
The live-restore option keeps containers running while the Docker daemon is down. Container availability improves during daemon updates or crashes. The downside is that live-restore may leave Docker with an inconsistent state if the daemon stays down for an extended period.
