Skip to content

Commit b7dd2a3

Browse files
authored
Merge pull request #21962 from docker/published-update
publish updates from main
2 parents bb3cdd2 + 64b1d41 commit b7dd2a3

File tree

7 files changed

+217
-21
lines changed

7 files changed

+217
-21
lines changed
Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
---
2+
description: Build images for services with shared definition
3+
keywords: compose, build
4+
title: Build dependent images
5+
weight: 50
6+
---
7+
8+
To reduce push/pull time and image weight, a common practice for Compose applications is to have services
9+
share base layers as much as possible. You will typically select the same operating system base image for
10+
all services. But you also can get one step further sharing image layers when your images share the same
11+
system packages. The challenge to address is then to avoid repeating the exact same Dockerfile instruction
12+
in all services.
13+
14+
For illustration, this page assumes you want all your services to be built with an `alpine` base
15+
image and install system package `openssl`.
16+
17+
## Multi-stage Dockerfile
18+
19+
The recommended approach is to group the shared declaration in a single Dockerfile, and use multi-stage features
20+
so that service images are built from this shared declaration.
21+
22+
23+
Dockerfile:
24+
25+
```dockerfile
26+
FROM alpine as base
27+
RUN /bin/sh -c apk add --update --no-cache openssl
28+
29+
FROM base as service_a
30+
# build service a
31+
...
32+
33+
FROM base as service_b
34+
# build service b
35+
...
36+
```
37+
38+
Compose file:
39+
40+
```yaml
41+
services:
42+
a:
43+
build:
44+
target: service_a
45+
b:
46+
build:
47+
target: service_b
48+
```
49+
50+
## Use another service's image as the base image
51+
52+
A popular pattern is to reuse a service image as a base image in another service.
53+
As Compose does not parse the Dockerfile, it can't automatically detect this dependency
54+
between services to correctly order the build execution.
55+
56+
57+
a.Dockerfile:
58+
59+
```dockerfile
60+
FROM alpine
61+
RUN /bin/sh -c apk add --update --no-cache openssl
62+
```
63+
64+
b.Dockerfile:
65+
66+
```dockerfile
67+
FROM service_a
68+
# build service b
69+
```
70+
71+
Compose file:
72+
73+
```yaml
74+
services:
75+
a:
76+
image: service_a
77+
build:
78+
dockerfile: a.Dockerfile
79+
b:
80+
image: service_b
81+
build:
82+
dockerfile: b.Dockerfile
83+
```
84+
85+
86+
Legacy Docker Compose v1 used to build images sequentially, which made this pattern usable
87+
out of the box. Compose v2 uses BuildKit to optimise builds and build images in parallel
88+
and requires an explicit declaration.
89+
90+
The recommended approach is to declare the dependent base image as an additional build context:
91+
92+
Compose file:
93+
94+
```yaml
95+
services:
96+
a:
97+
image: service_a
98+
build:
99+
dockerfile: a.Dockerfile
100+
b:
101+
image: service_b
102+
build:
103+
context: b/
104+
dockerfile: b.Dockerfile
105+
additional_contexts:
106+
# `FROM service_a` will be resolved as a dependency on service a which has to be built first
107+
service_a: "service:a"
108+
```
109+
110+
111+
## Build with Bake
112+
113+
Using [Bake](/manuals/build/bake/_index.md) let you pass the complete build definition for all services
114+
and to orchestrate build execution in the most efficient way.
115+
116+
To enable this feature, run Compose with the `COMPOSE_BAKE=true` variable set in your environment.
117+
118+
```console
119+
$ COMPOSE_BAKE=true docker compose build
120+
[+] Building 0.0s (0/1)
121+
=> [internal] load local bake definitions 0.0s
122+
...
123+
[+] Building 2/2 manifest list sha256:4bd2e88a262a02ddef525c381a5bdb08c83 0.0s
124+
✔ service_b Built 0.7s
125+
✔ service_a Built
126+
```
127+
128+
Bake can also be selected as the default builder by editing your `$HOME/.docker/config.json` config file:
129+
```json
130+
{
131+
...
132+
"plugins": {
133+
"compose": {
134+
"build": "bake"
135+
}
136+
}
137+
...
138+
}
139+
```

content/manuals/desktop/features/gordon/_index.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,8 @@ params:
77
badge:
88
color: blue
99
text: Beta
10+
aliases:
11+
- /desktop/features/gordon/
1012
---
1113

1214
{{< summary-bar feature_name="Ask Gordon" >}}

content/manuals/desktop/features/kubernetes.md

Lines changed: 12 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -10,12 +10,14 @@ aliases:
1010
weight: 60
1111
---
1212

13-
Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration, enabling local Kubernetes development and testing directly on your machine.
13+
Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration, enabling local Kubernetes development and testing directly on your machine.
1414

15-
The Kubernetes server runs as a single or multi-node cluster within a Docker container. This lightweight setup helps you explore Kubernetes features, test workloads, and work with container orchestration in parallel with other Docker functionalities.
15+
The Kubernetes server runs as a single or multi-node cluster, within Docker container(s). This lightweight setup helps you explore Kubernetes features, test workloads, and work with container orchestration in parallel with other Docker functionalities.
1616

1717
Kubernetes on Docker Desktop runs alongside other workloads, including Swarm services and standalone containers.
1818

19+
![k8s settings](../images/k8s-settings.png)
20+
1921
## What happens when I enable Kubernetes in Docker Desktop?
2022

2123
When you enable Kubernetes in Docker Desktop, the following actions are triggered in the Docker Desktop backend and VM:
@@ -30,18 +32,18 @@ Turning the Kubernetes server on or off in Docker Desktop does not affect your o
3032
## Install and turn on Kubernetes
3133

3234
1. Open the Docker Desktop Dashboard and navigate to **Settings**.
33-
2. Select the **Kubernetes** tab.
35+
2. Select the **Kubernetes** tab.
3436
3. Toggle on **Enable Kubernetes**.
35-
4. Choose your cluster provisioning method. You can choose either **Kubeadm** or **kind** if you are signed in and are using Docker Desktop version 4.38 or later.
37+
4. Choose your cluster provisioning method. You can choose either **Kubeadm** or **kind** if you are signed in and are using Docker Desktop version 4.38 or later.
3638

37-
If you select **kind** you can also choose the Kubernetes version and the number of nodes.
39+
If you select **kind** you can also choose the Kubernetes version and the number of nodes.
3840
5. Select **Apply & Restart** to save the settings. This sets up the images required to run the Kubernetes server as containers, and installs the `kubectl` command-line tool on your system at `/usr/local/bin/kubectl` (Mac) or `C:\Program Files\Docker\Docker\Resources\bin\kubectl.exe` (Windows).
3941

4042
> [!NOTE]
4143
>
4244
> Docker Desktop for Linux does not include `kubectl` by default. You can install it separately by following the [Kubernetes installation guide](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/). Ensure the `kubectl` binary is installed at `/usr/local/bin/kubectl`.
4345
44-
When Kubernetes is enabled, its status is displayed in the Docker Desktop Dashboard footer and the Docker menu.
46+
When Kubernetes is enabled, its status is displayed in the Docker Desktop Dashboard footer and the Docker menu.
4547

4648
You can check which version of Kubernetes you're on with:
4749

@@ -53,7 +55,7 @@ $ kubectl version
5355

5456
#### Kubernetes dashboard
5557

56-
Once Kubernetes is installed and set up, you can select the **Deploy the Kubernetes Dashboard into cluster** setting so you can manage and monitor your Kubernetes clusters and applications more easily.
58+
Once Kubernetes is installed and set up, you can select the **Deploy the Kubernetes Dashboard into cluster** setting so you can manage and monitor your Kubernetes clusters and applications more easily.
5759

5860
#### Viewing system containers
5961

@@ -79,7 +81,7 @@ $ kubectl config use-context docker-desktop
7981
> [!TIP]
8082
>
8183
> If the `kubectl` config get-contexts command returns an empty result, try:
82-
>
84+
>
8385
> - Running the command in the Command Prompt or PowerShell.
8486
> - Setting the `KUBECONFIG` environment variable to point to your `.kube/config` file.
8587
@@ -111,13 +113,13 @@ Kubernetes clusters are not automatically upgraded with Docker Desktop updates.
111113
$ kubectl config use-context docker-desktop
112114
```
113115
You can then try checking the logs of the [Kubernetes system containers](#viewing-system-containers) if you have enabled that setting.
114-
- If you're experiencing cluster issues after updating, reset your Kubernetes cluster. Resetting a Kubernetes cluster can help resolve issues by essentially reverting the cluster to a clean state, and clearing out misconfigurations, corrupted data, or stuck resources that may be causing problems. If the issue still persists, you may need to clean and purge data, and then restart Docker Desktop.
116+
- If you're experiencing cluster issues after updating, reset your Kubernetes cluster. Resetting a Kubernetes cluster can help resolve issues by essentially reverting the cluster to a clean state, and clearing out misconfigurations, corrupted data, or stuck resources that may be causing problems. If the issue still persists, you may need to clean and purge data, and then restart Docker Desktop.
115117

116118
## Turn off and uninstall Kubernetes
117119

118120
To turn off Kubernetes in Docker Desktop:
119121

120122
1. From the Docker Desktop Dashboard, select the **Settings** icon.
121-
2. Select the **Kubernetes** tab.
123+
2. Select the **Kubernetes** tab.
122124
3. Deselect the **Enable Kubernetes** checkbox.
123125
4. Select **Apply & Restart** to save the settings. This stops and removes Kubernetes containers, and also removes the `/usr/local/bin/kubectl` command.

content/manuals/desktop/features/wsl/_index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -109,3 +109,4 @@ Docker Desktop does not require any particular Linux distributions to be install
109109
- [Explore best practices](best-practices.md)
110110
- [Understand how to develop with Docker and WSL 2](use-wsl.md)
111111
- [Learn about GPU support with WSL 2](/manuals/desktop/features/gpu.md)
112+
- [Custom kernels on WSL](custom-kernels.md)
Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
---
2+
title: Custom kernels on WSL
3+
description: Using custom kernels with Docker Desktop on WSL 2
4+
keywords: wsl, docker desktop, custom kernel
5+
tags: [Best practices, troubleshooting]
6+
---
7+
8+
Docker Desktop depends on several kernel features built into the default
9+
WSL 2 Linux kernel distributed by Microsoft. Consequently, using a
10+
custom kernel with Docker Desktop on WSL 2 is not officially supported
11+
and may cause issues with Docker Desktop startup or operation.
12+
13+
However, in some cases it may be necessary
14+
to run custom kernels; Docker Desktop does not block their use, and
15+
some users have reported success using them.
16+
17+
If you choose to use a custom kernel, it is recommended you start
18+
from the kernel tree distributed by Microsoft from their [official
19+
repository](https://github.com/microsoft/WSL2-Linux-Kernel) and then add
20+
the features you need on top of that.
21+
22+
It's also recommended that you:
23+
- Use the same kernel version as the one distributed by the latest WSL2
24+
release. You can find the version by running `wsl.exe --system uname -r`
25+
in a terminal.
26+
- Start from the default kernel configuration as provided by Microsoft
27+
from their [repository](https://github.com/microsoft/WSL2-Linux-Kernel)
28+
and add the features you need on top of that.
29+
- Make sure that your kernel build environment includes `pahole` and
30+
its version is properly reflected in the corresponding kernel config
31+
(`CONFIG_PAHOLE_VERSION`).
32+
135 KB
Loading

content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/faq.md

Lines changed: 31 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -69,22 +69,42 @@ See [ECI Docker socket mount permissions](config.md#docker-socket-mount-permissi
6969
Not yet. It protects all containers launched by users via `docker create` and
7070
`docker run`.
7171

72-
Prior to Docker Desktop 4.30, it did not protect containers implicitly used by
73-
`docker build` with the `docker` build driver (the default driver). Starting
74-
with Docker Desktop 4.30, it protects such containers, except for Docker Desktop
75-
on WSL 2 (Windows hosts).
72+
For containers implicitly created by `docker build` as well as Docker
73+
Desktop's integrated Kubernetes, protection varies depending on the Docker
74+
Desktop version (see the following two FAQs).
7675

77-
Note that ECI always protects containers used by `docker build`, when using the
78-
[docker-container build driver](/manuals/build/builders/drivers/_index.md), since Docker
79-
Desktop 4.19 and on all supported platforms (Windows with WSL 2 or Hyper-V, Mac,
80-
and Linux).
76+
ECI does not yet protect Docker Desktop Extension containers and
77+
[Dev Environments containers](/manuals/desktop/features/dev-environments/_index.md).
8178

82-
ECI does not yet protect Docker Desktop Kubernetes pods, Extension containers,
83-
and [Dev Environments containers](/manuals/desktop/features/dev-environments/_index.md).
79+
### Does ECI protect containers implicitly used by `docker build`?
80+
81+
Prior to Docker Desktop 4.19, ECI did not protect containers used implicitly
82+
by `docker build` during the build process.
83+
84+
Since Docker Desktop 4.19, ECI protects containers used by `docker build`
85+
when using the [Docker container build driver](/manuals/build/builders/drivers/_index.md).
86+
87+
In addition, since Docker Desktop 4.30, ECI also protects containers used by
88+
`docker build` when using the default "docker" build driver, on all
89+
platforms supported by Docker Desktop except Windows with WSL 2.
90+
91+
### Does ECI protect Kubernetes in Docker Desktop?
92+
93+
Prior to Docker Desktop 4.38, ECI did not protect the Kubernetes cluster
94+
integrated in Docker Desktop.
95+
96+
Since Docker Desktop 4.38, ECI protects the integreated Kubernetes cluster
97+
when using the new **kind** provisioner (see [Deploy On Kubernetes](/manuals/desktop/features/kubernetes.md)).
98+
In this case, each node in the multi-node Kubernetes cluster is actually an ECI
99+
protected container. With ECI disabled, each node in the Kubernetes cluster is
100+
a less-secure fully privileged container.
101+
102+
ECI does not protect the integrated Kubernetes cluster when using the
103+
older **Kubeadm** single-node cluster provisioner.
84104

85105
### Does ECI protect containers launched prior to enabling ECI?
86106

87-
No. Containers created prior to switching on ECI are not protected. Therefore, it is
107+
No. Containers created prior to switching on ECI are not protected. Therefore, it is
88108
recommended you remove all containers prior to switching on ECI.
89109

90110
### Does ECI affect the performance of containers?

0 commit comments

Comments
 (0)