Gro 109#24961
Conversation
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
/review |
| ## Network drivers: bridge vs host | ||
|
|
||
| ## Link containers | ||
| Compose supports multiple network drivers. The two most common are `bridge` and `host`. |
There was a problem hiding this comment.
I'm not sure if host is most common, and not sure if we should encourage users to use it; using host networking reduces the container's sandbox, and usually is reserved for expert use-cases where containers should not have a security boundary for networking.
Using host networking means that the container also won't have its own IP-address, and resolving containers won't be possible (as they share the host's IP-address.
| image: postgres:18 | ||
| image: postgres:latest |
There was a problem hiding this comment.
Curious why this was switched to :latest (it's less maintenance, but not usually best-practice to use :latest - even more so for database containers, as updates to (in this case PostgreSQL) usually involves a migration step.
![docker-agent[bot]](https://avatars.githubusercontent.com/in/2787757?s=60&v=4){kind=small}
| [network](/reference/cli/docker/network/create/) for your app. Each | ||
| container for a service joins the default network and is both reachable by | ||
| other containers on that network, and discoverable by the service's name. | ||
| Compose handles networking for you by default, but gives you fine-grained control when you need it. This page explains how the default network works and how containers discover each other by name. It also covers when and how to define custom networks, choose between network drivers, connect services across separate Compose projects, map custom hostnames, and debug connectivity issues. |
There was a problem hiding this comment.
MEDIUM: Meta-commentary opener — state the content directly
The sentence This page explains how the default network works… describes the page rather than delivering information. Per the Docker style guide, meta-commentary ("This page explains…", "It's worth noting that…", etc.) should be replaced by stating the information directly.
Consider removing or restructuring this sentence so the paragraph opens with the actual concept.
| - "8001:5432" | ||
| ``` | ||
|
|
||
| Since `networks` is empty or absent from the Compose file, Compose considers an implicit definition for the service to be connected to the default network. |
There was a problem hiding this comment.
MEDIUM: Confusing phrasing — 'Compose considers an implicit definition'
The phrasing "Compose considers an implicit definition for the service to be connected to the default network" is awkward and unclear. It seems to mean that when no networks key is present, all services are automatically connected to the default network.
Consider rewriting as: "When no networks are specified, Compose automatically connects all services to the default network."
| Your app's network is given a name based on the "project name", which is based on the name of the directory it lives in. You can override the project name with either the [`--project-name` flag](/reference/cli/docker/compose/) or the [`COMPOSE_PROJECT_NAME` environment variable](environment-variables/envvars.md#compose_project_name). | ||
|
|
||
| ## Update containers on the network | ||
| It is important to note the distinction between `HOST_PORT` and `CONTAINER_PORT`. In the example above, for `db`, the `HOST_PORT` is `8001` and the container port is `5432` (the Postgres default). Networked service-to-service communication uses the `CONTAINER_PORT`. The host port is only used when accessing the service from outside the network. |
There was a problem hiding this comment.
MEDIUM: Banned phrase — 'It is important to note'
"It is important to note" is explicitly banned by the Docker style guide (equivalent to "It's worth noting that…" and "Keep in mind that…"). State the information directly instead.
For example: "The HOST_PORT and CONTAINER_PORT serve different purposes: …"
| With this example, you can test network isolation by running the following: | ||
|
|
||
| ```bash | ||
| # Bridge mode: can't access host services directly |
There was a problem hiding this comment.
MEDIUM: Misleading code comment — bridge mode does not block all host access
The comment # Bridge mode: can't access host services directly overstates the limitation. In bridge mode, containers can reach host services — they just need to use the host gateway IP (e.g. via host-gateway or the bridge IP such as 172.17.0.1), not localhost. The failure shown is specific to localhost resolving to the container's own loopback.
Consider: # localhost resolves to the container's own loopback in bridge mode, not the host
|
|
||
| > [!IMPORTANT] | ||
| > | ||
| > The external network must exist before you run `docker compose up`. If it doesn't, Compose fails with a **network not found** error. Always create it first with `docker network create`. |
There was a problem hiding this comment.
MEDIUM: Bold used for an error message string, not a UI element
**network not found** uses bold formatting on an error message. Per the Docker style guide, bold is reserved exclusively for UI elements (buttons, menus, field labels). Error messages should use inline code backticks instead: network not found.
2 participants
Description
Compose networking refresh
Related issues or tickets
Reviews