User-defined networks
Give related services a shared network
Lesson 8 of 20 · 12 min · Module 3: Persistence and a first project
Service-to-service communication belongs on an intentional network.
Start this lesson →Free. No installation: you write and run the code in your browser, and it is checked automatically.
By the end, you’ll be able to…
- Use service identity inside the network
- Keep localhost in its context
The idea
Container operations change instances and their attached configuration. Inspect the resulting state as well as the command sequence.
01Use service identity inside the network
User-defined Docker networks support discovery by container name. A client can refer to cache instead of depending on a changing container address.
02Keep localhost in its context
Inside api, localhost refers to api itself. It does not refer to a different cache container or automatically to the host.
03Expose only the intended entry point
A backend need not publish a host port merely to communicate with another container on its network. Publishing is a separate access decision.
Your turn
What the checks look for
- Both services share app-net
- API addresses cache by name
- Cache has no published ports
Take this with you
Separate internal discovery from external access.
Go a little further
Try attaching a service to a network that has not been created.