Wietse Venema via Postfix-users <postfix-users@postfix.org> writes:
> Nico Schottelius via Postfix-users: >> >> Marvin, >> >> Marvin Renich via Postfix-users <postfix-users@postfix.org> writes: >> > [...] >> >> - Rerun a docker build & docker push as soon as the underlying OS's >> >> update their package repository >> >> - Update the Dockerfile once the depending operating system updates >> >> their image (i.e. The debian based postfix image could have been based >> >> on 12.7 and the included postfix version was 3.7.11. Now Debian bumps >> >> to 12.8 and the included postfix version is 3.7.20. Then the postfix >> >> Dockerfile would change "FROM debian:12.7" to "FROM debian:12.8" and >> >> the resulting image tag would change from postfix:3.7.11-debian12.7 >> >> to postfix:3.7.20-debian12.8. >> > >> > I don't understand why you think either of these approaches should be >> > done by postfix devs. >> >> Because the purpose of the container is to run postfix. Not Debian w/ >> postfix nor alpine with Postfix. Maybe postfix *based* on Debian or >> postfix on Alpine, because we have a slight preference over one or the >> other, but the main purpose is "run postfix". >> >> In the container world you usually run applications, not Linux >> distributions. > > There can be no such thing as a distribution-less Postfix container > image. And I am not advocating it. I'm stating that the focus is on the application, not on the distribution it happens to come with. > There is always going to be a dependency on a distribution > of some kind, and that should a supported distribution. That's fair and reasonable. >> Btw, dovecot *does* actually have an official image (on hub.docker.com) > > That is NOT an official image. The web page even has a very clear > disclaimer: > > Note that these images come with absolutely no warranty or support. > > In other words, don't use these images for mission-critical applications, > such as providing an email service that other people can depend on. I tend to disagree in the that it is an official image. The disclaimer seems to be merely a standard one, such as " EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. " But let's not focus on that and say we disagree. > Coming back to Postfix documentation, I have a few questions. > > Question 1: What would a basic Dockerfile look like? > > FROM debian:latest I'd recommend debian:VERSION, such as debian:12.7 so that the resulting image contains a specific postfix version in the end as well. > RUN apt-get update && \ > apt-get install -y postfix && \ > rm -rf /var/lib/apt/lists/* looks good. > RUN postconf maillog_file=/dev/stdout && \ > postconf -F "*/*/chroot=n" looks good. > ENTRYPOINT ["postfix", "start-fg"] looks good. > (The exec form avoids a shell process that would otherwise get > PID 1 and mess up the handling of zombie processes) Fair. Just one note: the entrypoint is the *default* executable taken. It can be overriden by the "command" argument in kubernetes and same in docker. Don't think of it as "that is the program that always runs", but more in the sense of "As a maintainer I believe that is the sane thing to run" > Question 2: Any suggestions to "docker run -v" volume-mount into > /etc/postfix, /var/spool/postfix, and maybe, /var/lib/postfix? > I see web posts that mount configuration but not the mail queue. > (example: https://www.frakkingsweet.com/postfix-in-a-container/) So for /ect/postfix you'd probably mount a local directory. If you think in docker-compose, you'd usually have a directory tree such as: docker-compose.yml postfix/ main.cf ... other sample configs and you'd specific the local postfix directory to be mounted on /etc/postfix. For /var/spool/postfix the situation is different. You don't want to provide defaults, but ensure that data is not lost if the container is destroyed. Thus you'd specify a named volume, and don't really care what or where it is. Taking a modified example from an example from [0]: -------------------------------------------------------------------------------- services: postfix: image: postfix/postfix:3.9.0 volumes: - queue:/var/spool/postfix - ./postfix:/etc/postfix:ro volumes: queue: -------------------------------------------------------------------------------- In this example /etc/postfix would even be read only, sourced from the local directory ./postfix > Question 3: What do the file/directory permissions and ownerships > of those volumes look like on the non-container environment? For the named volume queue, that is hidden somewhere in the docker tree, so tbh, I don't know. For the "postfix" configuration directory, it is whatever you create. >> As mentioned before, I/we can volunteer to building the image(s) and >> rebuilding them on a new release, if the added workload is a concern. >> Personally I think the work associated with it is minusucle. > > As we're not distributing binaries, there is no release build > infrastructure, and therefore releasing container images would not > be a minuscule effort. That's a good point. Let me come back to this in the next mail to Ralph, because he's good a good point over there. -- Sustainable and modern Infrastructures by ungleich.ch _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
