Add replicaCount for admin, dovecot, webmail and oletools

[Deltachaos]

In general those services can easily deployed with multiple replicas, when the storage is shared, without any issues. So why not be able to configure them?

[fastlorenzo]

We'd need to test this in length in term of session management.
However, as stated in #304 , there is potential issues with running 2 dovecot instances on the same backend storage.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[nextgens]

That is definitely broken. The only things you can safely scale up are: unbound, oletools, clamav, tika and webmail; All the other containers can't^wshoudn't be scaled up without changes in Mailu

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[Deltachaos]

@nextgens why should admin not be scaled up? i run this setup since a few months and have not experienced any problems.

Regarding postfix the interesting point would be what problems do you expect there? If they dont share storage, but instead all have there own storage, then one mail should be randomly delivered to one of the postfixes and send from there.

I also have not experienced any issue with this so far.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[nextgens]

@nextgens why should admin not be scaled up? i run this setup since a few months and have not experienced any problems.

Because until 2024.06 it had some shared state. I don't think that's true anymore so it is probably okay to do so now.

The imap container (running dovecot) is still problematic. To scale that up you should find a way to emulate what 'dovecot director' does: ensure that all clients sharing the same username are steered towards the same dovecot backend regardless of the protocol they use. Failing to do so means that indexes will never be kept up to date across backends ... and that will put the underlying FS under a lot of strain and will get you terrible performance. A basic implementation of this is trivial to do (probably 3 lines of code); the devil is in the detail. To do it right you probably need to have visibility on the healthchecks of the various backends... which means reinventing the wheel in a docker-compose context. Is there a standardized way of doing it in k8s land?

[nextgens]

Correcting myself above: webmails cannot be safely scaled as is. PHP sessions and whatknot are not in redis; If requests are load-balanced across instances it will break.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.