Skip to content

publish updates from main #22595

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
May 6, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions content/manuals/desktop/release-notes.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,18 @@ For more frequently asked questions, see the [FAQs](/manuals/desktop/troubleshoo
>
> If you're experiencing malware detection issues on Mac, follow the steps documented in [docker/for-mac#7527](https://github.com/docker/for-mac/issues/7527).

## 4.41.2

{{< release-date date="2025-05-06" >}}

{{< desktop-install-v2 all=true beta_win_arm=true version="4.41.2" build_path="/191736/" >}}

### Bug fixes and enhancements

#### For all platforms

- Fixed an issue where the `Models` menu was displayed in the GUI even when Docker Model Runner was not supported or not enabled.

## 4.41.1

{{< release-date date="2025-04-30" >}}
Expand Down
12 changes: 6 additions & 6 deletions content/manuals/engine/containers/resource_constraints.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,8 +69,8 @@ You can mitigate the risk of system instability due to OOME by:

Docker can enforce hard or soft memory limits.

- Hard limits lets the container use no more than a fixed amount of memory.
- Soft limits lets the container use as much memory as it needs unless certain
- Hard limits let the container use no more than a fixed amount of memory.
- Soft limits let the container use as much memory as it needs unless certain
conditions are met, such as when the kernel detects low memory or contention on
the host machine.

Expand Down Expand Up @@ -162,7 +162,7 @@ a container. Consider the following scenarios:
an OOM error. If the kernel memory limit is higher than the user memory
limit, the kernel limit doesn't cause the container to experience an OOM.

When you enable kernel memory limits, the host machine tracks "high water mark"
When you enable kernel memory limits, the host machine tracks the "high water mark"
statistics on a per-process basis, so you can track which processes (in this
case, containers) are using excess memory. This can be seen per process by
viewing `/proc/<PID>/status` on the host machine.
Expand All @@ -186,7 +186,7 @@ the container's cgroup on the host machine.
| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `--cpus=<value>` | Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set `--cpus="1.5"`, the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting `--cpu-period="100000"` and `--cpu-quota="150000"`. |
| `--cpu-period=<value>` | Specify the CPU CFS scheduler period, which is used alongside `--cpu-quota`. Defaults to 100000 microseconds (100 milliseconds). Most users don't change this from the default. For most use-cases, `--cpus` is a more convenient alternative. |
| `--cpu-quota=<value>` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative. |
| `--cpu-quota=<value>` | Impose a CPU CFS quota on the container. The number of microseconds per `--cpu-period` that the container is limited to before being throttled. As such acting as the effective ceiling. For most use-cases, `--cpus` is a more convenient alternative. |
| `--cpuset-cpus` | Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be `0-3` (to use the first, second, third, and fourth CPU) or `1,3` (to use the second and fourth CPU). |
| `--cpu-shares` | Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. `--cpu-shares` doesn't prevent containers from being scheduled in Swarm mode. It prioritizes container CPU resources for the available CPU cycles. It doesn't guarantee or reserve any specific CPU access. |

Expand Down Expand Up @@ -234,7 +234,7 @@ for real-time tasks per runtime period. For instance, with the default period of
containers using the real-time scheduler can run for 950000 microseconds for every
1000000-microsecond period, leaving at least 50000 microseconds available for
non-real-time tasks. To make this configuration permanent on systems which use
`systemd`, create a systemd unit file for the `docker` service. For an example,
`systemd`, create a systemd unit file for the `docker` service. For example,
see the instruction on how to configure the daemon to use a proxy with a
[systemd unit file](../daemon/proxy.md#systemd-unit-file).

Expand Down Expand Up @@ -343,6 +343,6 @@ environment variables. More information on valid variables can be found in the
[nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html)
documentation. These variables can be set in a Dockerfile.

You can also use CUDA images which sets these variables automatically. See the
You can also use CUDA images, which set these variables automatically. See the
official [CUDA images](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda)
NGC catalog page.
11 changes: 11 additions & 0 deletions content/manuals/engine/network/packet-filtering-firewalls.md
Original file line number Diff line number Diff line change
Expand Up @@ -126,6 +126,17 @@ the source and destination. For instance, if the Docker host has addresses
`2001:db8:1111::2` and `2001:db8:2222::2`, you can make rules specific to
`2001:db8:1111::2` and leave `2001:db8:2222::2` open.

You may need to allow responses from servers outside the permitted external address
ranges. For example, containers may send DNS or HTTP requests to hosts that are
not allowed to access the container's services. The following rule accepts any
incoming or outgoing packet belonging to a flow that has already been accepted
by other rules. It must be placed before `DROP` rules that restrict access from
external address ranges.

```console
$ iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT
```

`iptables` is complicated. There is a lot more information at [Netfilter.org HOWTO](https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html).

### Direct routing
Expand Down
Loading