-
Notifications
You must be signed in to change notification settings - Fork 2
feat: make bridge network mode default #9
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| # Alternative compose override for host networking mode, giving direct network access to the container. | ||
| # | ||
| # Run with: docker compose -f docker-compose.yaml -f docker-compose.host-mode.yaml up | ||
|
|
||
| services: | ||
| chatmail: | ||
| network_mode: "host" | ||
| # Host mode requires cgroup:host for systemd. | ||
| cgroup: host | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,15 +2,8 @@ | |
| # volumes, env overrides) in docker-compose.override.yaml instead. | ||
| # See docker-compose.override.yaml.example in this directory for a starting point. | ||
| # | ||
| # Security notes: this container uses | ||
| # - network_mode:host chatmail needs many ports (25, 53, 80, 143, 443, 465, | ||
| # 587, 993, 3340, 8443) and needs to operate from the real IP, which bridging | ||
| # would make tricky | ||
| # - cgroup:host (required for systemd). | ||
| # Together these give the container near-host-level access. This is acceptable | ||
| # for a dedicated mail server, but be aware that the container can bind any | ||
| # port and see all host network traffic. | ||
|
|
||
| # Network mode: Bridged with port mappings | ||
| # cgroup:host required for systemd. | ||
| services: | ||
| chatmail: | ||
| build: | ||
|
|
@@ -40,7 +33,15 @@ services: | |
| environment: | ||
| MAIL_DOMAIN: $MAIL_DOMAIN | ||
| ACME_EMAIL: ${ACME_EMAIL:-} | ||
| network_mode: "host" | ||
| ports: | ||
| - "25:25" | ||
| - "80:80" | ||
| - "143:143" | ||
| - "443:443" | ||
| - "465:465" | ||
| - "587:587" | ||
| - "993:993" | ||
| - "3340:3340" | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @j4n looks like you aren't exposing the turn port you want something like this: then in reason: turn will start to enumerate ports so it's best practice allow large udp ranges for this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @j4n also it's best practice if you're going to use bridge-mode explicitly define the bridge this network can be whatever you want namespace wise ie |
||
| volumes: | ||
| ## system (required) | ||
| - /sys/fs/cgroup:/sys/fs/cgroup:rw | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@j4n after some thought from our chats, my research, and things i've ran into. i think it's likely a better approach to just use
network_mode: hostfor a singular compose stack vs giving user options of bridging.reason: bridging can get complex really fast with something like chatmail. plus without manipulating the daemon you theoretically lose the client-ip.