Skip to content

Conversation

@chrisblech
Copy link
Contributor

Upstream documentation tells to start postfix first, then email-, then job-runner container.
We add postgres as dependency to postfix, and add healthchecks to cert-exporter and postfix. So postfix will not start until certificate files are ready, and postfix-dependencies will wait until postfix is started and responding.

MTAs only use port 25 to exchange mails. As connecting/authenticating users (via mail-client and ESMTP submission-protocol) is not a use-case for this project, we do not need port 587.

…t 25

Upstream documentation tells to start postfix first, then email-, then job-runner container.
We add postgres as dependency to postfix, and add healthchecks
so postfix waits until certificate files are ready, and postfix-dependencies will wait until postfix is started and responding

MTAs only use port 25 to exchange mails. As connecting/authenticating users (via mail-client and ESMTP submission-protocol) is not a use-case for this project, we do not need port 587.
@springcomp
Copy link
Owner

@chrisblech

I suggest a simpler approach like thus:

├─ postgres (health: pg_isready?)
|  ├─ migration
│  └─ init
│     ├─ app
│     │  └─ traefik-certificate-exporter (health: are certificates are present?)
│     │     └─ postfix (health: can telnet to email handler?)
│     └─ email
│          └─ job_runner
├─ dns
|  └─ … postfix
└─ traefik (health: healthcheck --ping?)

In your contribution, email depends on postfix which means that it will start after anyway.
It could be argued that postfix depends on email to process incoming messages, whereas email depends on postfix to process outgoing and forwarding messages. My suggestion seems more incremental.

I think keeping this order makes is simpler. By the time postfix starts, most likely email handler has already started.

What do you think ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants