Hi
Is this container able to work in swarm mode, since the --hostname param in not supported by docker service create?
Hi @AndrewMoneronGenex, you're the first asking for Swarm information 馃槃
In the documentation, it seems supported.
The best thing to do is to try it out.
@AndrewMoneronGenex Have a look @ #509
EDIT: Oh, i do not follow the link above :) :)
It does work in swarm, however its not possible to scale the container.. :(
allinone:
image: tvial/docker-mailserver:2.1
ports:
- 25:25
- 143:143
- 587:587
- 993:993
volumes:
- maildata:/var/mail
- mailstate:/var/mail-state
- config:/tmp/docker-mailserver
- ssl:/tmp/ssl
environment:
- ENABLE_SPAMASSASSIN=1
- ENABLE_CLAMAV=0
- ONE_DIR=0
- ENABLE_FETCHMAIL=0
- OVERRIDE_HOSTNAME=mail.berndklaus.at
- [email protected]
- SSL_TYPE=manual
- DMS_DEBUG=0
- SSL_CERT_PATH=/tmp/ssl/cert/public.crt
- SSL_KEY_PATH=/tmp/ssl/private/private.key
deploy:
replicas: 1
update_config:
parallelism: 1
delay: 30s
monitor: 10s
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 10
window: 60s
healthcheck:
test: ["CMD", "curl", "-f", "localhost:143"]
interval: 20s
timeout: 10s
retries: 3
logging:
driver: json-file
@Berndinox Why it fails to scale?
Are there specific components that fail?
@AndrewMoneronGenex is the hostname still an issue?
Have not looked too deep into it, i'll check it the next days.
It preserves the state on restart documentation. It will run with 0 just fine but a restart of the container will lose some state like virusmails, fail2ban and postgrey states.
Has anyone tried this? There's a problem with SPF validation where you need to run docker in host mode to get correct IPs. I need to be able to run in global mode on the swarm to make sure that I have failover.
With regards to scaling. The biggest issue is always managing state. Because we have the user details and mailboxes in there I would treat this pretty much the same way as I would treat scaling up a database. Unless it uses extremely well tested industry-standard sharding, replication, leader-election, discovery, self-healing, consistency semaphores and so on... I wouldn't touch the scaling options with a 10ft pole.
Part of the reason why piecing all the different components together is such a pain, is because people with scaling needs are going to have to pick them apart and build performant pipelines out of this, rather than bundling it up in a single easy container.
I'd have a long think about why you need to scale your service. If it's for uptime you may want to look at the docker healthcheck features instead to detect issues sooner and have it restart. If it's for throughput maybe you want to look at the specific bottleneck you're having.
@Berndinox how did you configure DNS to make this work?
fail2ban doesn't work with swarm mode.
as a matter of fact "hostname" parameter and .env config do not work with a docker-compose.yml in swarm mode, because .env file are not supported and the method suggested by Berndinox is a workaround using domain overriding
I'm not sure about scaling as I deployed to only one node in my swarm...
But for what it worth, everything seems to work well without the hostname key in docker-compose.yml .
Regarding the .env file, docker-compose will automatically load the .env file residing in the same directory as the docker-compose.yml file, docker stack on the other end, does not do that.
But that's easily fixed by adding the following key to the service configuration:
mailserver:
env_file: .env
@tomav
I just recently bumped into this project while searching for dockerized mail services solution.
This is an amazing project, thank you very much for sharing!