Would love to hear if anyone has extended out postal to a HA setup. With the postal install looking for IPs bound locally, that causes some issue.
Extending out the database/queues shouldn't be too hard but comes down to how mail is sent.
Having single reliance on a VM/server running postal is always a worry. Whilst the underlying hardware (for us) has resilience, there is still the single point of the machine instance itself (crashing badly, software corruption etc etc).
Maybe atech have some secret sauce for when they had a commercial intent for the product to span more than one running/active server.
I originally posted this in #41, so more than a re-post, wondering if anyone has managed it. It has been asked a few times so the question is to the wider community.... or maybe adamcooke (not tagging to avoid pesky emails) has any secret docs for achieving it :)
It would certainly be good to get some official feedback on the matter.
Postal will send from any IP it can see by default so I presume you're trying to use IP pools so you're worried about IP addresses from that perspective?
It is probably not recommended behaviour but I have had a little mess around with the Procfile to turn off some parts of Postal and fit everything I wanted to test in a low-resources test server and I'm interested in running high availability ingress at least so our systems can at least queue up the email, even if it isn't sent immediately.
Pretty much (in reference to the IPs). We only use internally so would like a specific brand to go out via specific IP(s). i.e some sort of IP matrix where you assign an IP each node to use for each brand. That itself is probably fairly complex.
However, for anyone just using postal as an app based mailer, that probably isn't too much of a concern. Although it would still be nice to have pools of IPs on each node to be specific to marketing, transactional and X, Y, Z mails.
I've been playing with running Postal on Kubernetes which means that potential issues with an HA deployment will be raised quite quickly. I'll let you know how I get on.
@adamcooke, thanks for the update. Sounds exciting! :)
@adamcooke Any progress on that awesome matters?
Kubernetes is the way to go :)
wow... im hunting for a k8s emails sever solution and found this... does it work ? or still a work in progress?
It should work for the most part however there are reports of problems with newer OpenSSL versions (#999 and linked issues) so you may encounter some problems but it depends which features you are using.
i found the postal hippo/helm chart works at https://github.com/postalhq/k8s-hippo last night and it did deploy on kubernetes successfully
welp thats a fail.... seesm hippo-k8s postal requires LoadBalancer which seems broken on kubespray with ipvs and layer 2 .... so how can i deploy this on k8s now?
That repository also includes YAML files which look like they would work directly with kubectl and could be modified to suit your particular configuration style.
As you can see from those files, you essentially just need to run this repo with a config directory appropriately filled in and preferably a separate deployment for each command.
one would thing ingress-nginx would be able to proxy smtp right ?? if it was properly configured
I believe it is capable of proxying port 25 to the SMTP server deployment but I am not sure how it would work if you want to use port 25 for different applications in the same cluster, you may need a second load balancer or whatever to give you a separate route if that makes sense.
@adamcooke A standard helm chart with official image on docker hub would be awesome
I was looking into the Hippo repository, but all links to Hippo seems to be offline. What is Hippo and is there some documentation regarding it? Otherwise a Helm chart would be awesome.
Most helpful comment
Pretty much (in reference to the IPs). We only use internally so would like a specific brand to go out via specific IP(s). i.e some sort of IP matrix where you assign an IP each node to use for each brand. That itself is probably fairly complex.
However, for anyone just using postal as an app based mailer, that probably isn't too much of a concern. Although it would still be nice to have pools of IPs on each node to be specific to marketing, transactional and X, Y, Z mails.