Nico Schottelius: > > 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 > [generic warranty disclaimer]
Evidently, Dovecot has support, but explicitly, these container images do not. > > 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. That's a maintenance nightmare. Documentation rots unless there is a trigger to update it, and the primary trigger is a code change. I'm purging Postfix documentation that has no update trigger, so let's not add new ones. As there is no universal use case, I prefer to give a basic Dockerfile example plus hints for improvement: - Use debian:latest in the basic example, and suggest that users 'pin' the build to a specific distribution (debian or other) if one is concerned about behavior changes. - Use no host:container mounts in the basic example, and suggest that users import all or parts of /etc/postfix for configuration management, and /var/spool/postfix for data persistence. The basic image may be useful for basic tests, as long as the container runtime provides working DNS. > > 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. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
