- Docker Container Linux
- Configure Docker Container To Start On Boot
- Configure Docker Container Box
- Kubernetes
- Configure Docker Container Network
Estimated reading time: 8 minutes
Docker includes multiple logging mechanisms to help youget information from running containers and services.These mechanisms are called logging drivers. Each Docker daemon has a defaultlogging driver, which each container uses unless you configure it to use adifferent logging driver, or “log-driver” for short.
As you see in the Console tab of the Debug tool window, the debugger runs also in the Docker container: But now this container has a different id, and hence - different name. You can see it in the Terminal: type the docker ps command and see the container id and name. Docker includes multiple logging mechanisms to help you get information from running containers and services. These mechanisms are called logging drivers. Each Docker daemon has a default logging driver, which each container uses unless you configure it to use a different logging driver, or “log-driver” for short.
As a default, Docker uses the json-file
logging driver, whichcaches container logs as JSON internally. In addition to using the logging driversincluded with Docker, you can also implement and use logging driver plugins.
Tip: use the “local” logging driver to prevent disk-exhaustion
By default, no log-rotation is performed. As a result, log-files stored by thedefault json-file
logging driver logging driver can cause a significant amount of disk space to be used for containers that generate muchoutput, which can lead to disk space exhaustion.
Docker Container Linux
Docker keeps the json-file logging driver (without log-rotation) as a defaultto remain backward compatibility with older versions of Docker, and for situationswhere Docker is used as runtime for Kubernetes.
For other situations, the “local” logging driver is recommended as it performslog-rotation by default, and uses a more efficient file format. Refer to theConfigure the default logging driversection below to learn how to configure the “local” logging driver as a default,and the local file logging driver page for more details about the“local” logging driver.
Configure the default logging driver
To configure the Docker daemon to default to a specific logging driver, set thevalue of log-driver
to the name of the logging driver in the daemon.json
configuration file. Refer to the “daemon configuration file” section in thedockerd
reference manualfor details.
The default logging driver is json-file
. The following example sets the defaultlogging driver to the local
log driver:
If the logging driver has configurable options, you can set them in thedaemon.json
file as a JSON object with the key log-opts
. The followingexample sets two configurable options on the json-file
logging driver:
Restart Docker for the changes to take effect for newly created containers.Existing containers do not use the new logging configuration.
Note
log-opts
configuration options in the daemon.json
configuration file mustbe provided as strings. Boolean and numeric values (such as the value formax-file
in the example above) must therefore be enclosed in quotes ('
).
If you do not specify a logging driver, the default is json-file
.To find the current default logging driver for the Docker daemon, rundocker info
and search for Logging Driver
. You can use the followingcommand on Linux, macOS, or PowerShell on Windows:
Note
Changing the default logging driver or logging driver options in the daemonconfiguration only affects containers that are created after the configurationis changed. Existing containers retain the logging driver options that wereused when they were created. To update the logging driver for a container, thecontainer has to be re-created with the desired options.Refer to the configure the logging driver for a containersection below to learn how to find the logging-driver configuration of acontainer.
Configure the logging driver for a container
When you start a container, you can configure it to use a different loggingdriver than the Docker daemon’s default, using the --log-driver
flag. If thelogging driver has configurable options, you can set them using one or moreinstances of the --log-opt <NAME>=<VALUE>
flag. Even if the container uses thedefault logging driver, it can use different configurable options.
The following example starts an Alpine container with the none
logging driver.
To find the current logging driver for a running container, if the daemonis using the json-file
logging driver, run the following docker inspect
command, substituting the container name or ID for <CONTAINER>
:
Configure the delivery mode of log messages from container to log driver
Docker provides two modes for delivering messages from the container to the logdriver:
- (default) direct, blocking delivery from container to driver
- non-blocking delivery that stores log messages in an intermediate per-containerring buffer for consumption by driver
The non-blocking
message delivery mode prevents applications from blocking dueto logging back pressure. Applications are likely to fail in unexpected ways whenSTDERR or STDOUT streams block.
Warning
When the buffer is full and a new message is enqueued, the oldest message inmemory is dropped. Dropping messages is often preferred to blocking thelog-writing process of an application.
The mode
log option controls whether to use the blocking
(default) ornon-blocking
message delivery.
The max-buffer-size
log option controls the size of the ring buffer used forintermediate message storage when mode
is set to non-blocking
. max-buffer-size
defaults to 1 megabyte.
The following example starts an Alpine container with log output in non-blockingmode and a 4 megabyte buffer:
Use environment variables or labels with logging drivers
Some logging drivers add the value of a container’s --env|-e
or --label
flags to the container’s logs. This example starts a container using the Dockerdaemon’s default logging driver (let’s assume json-file
) but sets theenvironment variable os=ubuntu
.
If the logging driver supports it, this adds additional fields to the loggingoutput. The following output is generated by the json-file
logging driver:
Supported logging drivers
The following logging drivers are supported. See the link to each driver’sdocumentation for its configurable options, if applicable. If you are usinglogging driver plugins, you maysee more options.
Driver | Description |
---|---|
none | No logs are available for the container and docker logs does not return any output. |
local | Logs are stored in a custom format designed for minimal overhead. |
json-file | The logs are formatted as JSON. The default logging driver for Docker. |
syslog | Writes logging messages to the syslog facility. The syslog daemon must be running on the host machine. |
journald | Writes log messages to journald . The journald daemon must be running on the host machine. |
gelf | Writes log messages to a Graylog Extended Log Format (GELF) endpoint such as Graylog or Logstash. |
fluentd | Writes log messages to fluentd (forward input). The fluentd daemon must be running on the host machine. |
awslogs | Writes log messages to Amazon CloudWatch Logs. |
splunk | Writes log messages to splunk using the HTTP Event Collector. |
etwlogs | Writes log messages as Event Tracing for Windows (ETW) events. Only available on Windows platforms. |
gcplogs | Writes log messages to Google Cloud Platform (GCP) Logging. |
logentries | Writes log messages to Rapid7 Logentries. |
Note
Configure Docker Container To Start On Boot
When using Docker Engine 19.03 or older, the docker logs
commandis only functional for the local
, json-file
and journald
logging drivers.Docker 20.10 and up introduces “dual logging”, which uses a local buffer thatallows you to use the docker logs
command for any logging driver. Refer toreading logs when using remote logging drivers for details.
Limitations of logging drivers
- Reading log information requires decompressing rotated log files, which causesa temporary increase in disk usage (until the log entries from the rotatedfiles are read) and an increased CPU usage while decompressing.
- The capacity of the host storage where the Docker data directory residesdetermines the maximum size of the log file information.
Introduction
PyCharm integration with Docker allows you to run your applications in the variously configured development environments deployed in Docker containers.
Prerequisites
Make sure that the following prerequisites are met:
Docker is installed, as described on the page Docker Docs. You can install Docker on the various platforms, but here we'll use the Windows installation.
Note that you might want to repeat this tutorial on different platforms; then use Docker installations for macOS and Linux (Ubuntu, other distributions-related instructions are available as well).
You have a stable Internet connection.
Ensure that you have a stable Internet connection, so that PyCharm can download and run
busybox:latest
. Once you have successfully configured Docker, you can go offline.Before you start working with Docker, make sure that the Docker plugin is enabled. The plugin is bundled with PyCharm and is activated by default. If the plugin is not activated, enable it on the Plugins page of the Settings/Preferences dialog Ctrl+Alt+S as described in Manage plugins.
If you are using Docker for Windows, enable the Expose daemon on tcp://localhost:2375 without TLS option in the General section of your Docker settings.
Also, for Windows, right-click the Docker whale icon, choose Settings from the context menu, and in the General page select the Expose daemon... checkbox:
Note that you cannot install any Python packages into Docker-based project interpreters.
Preparing an example
Configure Docker Container Box
Create a Python project QuadraticEquation
, add the Solver.py file and enter the following code:
Configuring Docker as a remote interpreter
Now that we've prepared our example, let's define a Docker-based remote interpreter.
Ensure that you have downloaded and installed Python on your computer.
Open the Add Python Interpreter dialog by either way:
When you're in the Editor, the most convenient way is to use the Python Interpreter widget in the Overview of the user interface. Click the widget and select Add Interpreter ...
If you are in the Settings/Preferences dialog Ctrl+Alt+S, select Project <project name> | Python Interpreter. Click the icon and select Add.
In the dialog that opens, select the Docker option, from the drop-down lists select the Docker server (if the server is missing, click New... ), and specify the image name.
Python interpreter path should have the default value:
As a result, in the Settings dialog, you should see something like this:
Click OK to apply changes and close the dialog.
Running your application in a Docker container
In the left gutter, next to the main
clause, click the button, and choose Run 'Solver.py' command. You see that your script runs in the Docker container:
As you can see, the prefix in the Run tool window shows the container ID.
Debugging your application in a Docker container
Next, let's debug our application. For that, let's put a breakpoint on the line that calculates d
, then click and choose Debug 'Solver'.
As you see in the Console tab of the Debug tool window, the debugger runs also in the Docker container:
But now this container has a different id, and hence - different name. You can see it in the Terminal: type the docker ps
command and see the container id and name:
It's important that PyCharm creates a new container, when an application is executed in any way. Whether it's running, debugging, running with coverage, testing - each execution requires a new container!
Docker tool window
Kubernetes
But is it possible to see all the containers without the Terminal? PyCharm says - yes. You can use the Docker tab in the Services tool window as the UI for the Docker command-line client.
If you have configured Docker as a remote interpreter, you will see the Services tool window button at the bottom side of the main PyCharm window. Click this button and see the docker containers:
Let's look at this tool window more attentively. What do we see here?
First, we are connected to a Docker daemon:
Second, if we open the Run tool window, we'll see that the Docker prefix corresponds to the container ID in the Properties tab of the Docker tool window:
Third, if we open the Debug tool window, we'll see that the Docker prefix (another one!) corresponds to the another container ID in the Properties tab of the Docker tool window:
And finally, we see the strange names of the containers - they are human-readable and generated by Docker itself.
Summary
Let's summarize what has been done with the help of PyCharm:
Configure Docker Container Network
We created a project and added a Python script.
We configured the remote interpreter.
We ran and debugged our script in the Docker containers.
Finally, we launched the Docker tool window and saw all the details visible in the Terminal.