-
-
Notifications
You must be signed in to change notification settings - Fork 1
Networking
How containers reach each other by name.
network: app-tier
dependencies:
app: { image: your/image:tag }
redis: { image: redis:latest }Every entry under dependencies: joins this one network, so the app can connect to redis://redis:6379
using the dependency name as the hostname — the same way Compose service names resolve.
network: is optional. Leave it out and containers are created without --network, which means
they get whatever default wslc gives them and generally cannot resolve each other by name.
If your app talks to a sidecar, set it.
At wip up, and only if it doesn't already exist:
$ wip up -d
wip: creating network 'app-tier'wip lists existing networks first and matches on exact name. Creation failure is non-fatal — the
boot continues, and the subsequent run will surface the real error.
wip down stops and removes containers, but leaves the network in place. Networks are cheap,
shared, and may be referenced by containers wip doesn't manage; tearing one down as a side effect
of wip down would be surprising. Remove it yourself if you need to:
wslc network remove app-tierThere is no network: key here — setting one alongside compose: is a ConfigError. Instead wip
creates one project network for every service, named:
-
compose.project, if set - otherwise the basename of the directory holding
wip.yml
compose:
service: app
project: myapp # → network "myapp"This gives the same guarantee real Compose's per-project network does: every service in the file can reach every other by service name.
networks: inside a compose service is accepted and ignored — every service already shares
the one project network. Top-level networks: is ignored outright. See
Compose File Support.
Under mode: compose, the external compose binary owns networking entirely. wip
never passes --network, and network: in wip.yml is rejected as mutually exclusive with
compose:.
Publishing is per-entry, not per-network:
dependencies:
app:
ports:
- "3000:3000"Ports are applied when a container is created (wip up, wip run) — not on wip exec, which
attaches to an already-running container and therefore never re-publishes anything. If you added a
port to wip.yml and it isn't listening, the container predates the change: wip down && wip up -d.
Introduction
Modes
Configuration
- Configuration Reference
- Config File Discovery
- Dependencies
- Networking
- Interactions
- Restart Policies
- Env Files
- Secret Masking
- Dockerignore
- Shadow Build Context
- Source Sync
- Sync Modes
compose.yml support
- Compose File Support
- Compose Build
- Compose Depends On
- Compose Profiles
- Compose Variable Interpolation
Commands
- CLI Command Reference
- wip init
- wip version
- wip doctor
- wip config
- wip build
- wip up
- wip stop
- wip down
- wip exec
- wip run
- wip shell
- wip logs
- wip sync
- wip dispatch
- Global Options
- Debug Output
- TTY Allocation
Guides
- Guides
- Migrating from dip
- Reusing an Existing compose.yml
- Fixing a Slow Boot
- Continuous Sync
- Auto Restarting Containers
- Multi Arch Images
- Using wip in CI
Troubleshooting
- Troubleshooting & FAQ
- FAQ
- Configuration Errors
- WSLC Not Found
- Registry Authentication
- Architecture Mismatch
- Volume Limit Reached
- rsync Not Found
- Reporting Issues
Comparison
Project