tomav/docker-mailserver

Deployment exampleThere is nothing much in deploying mailserver to Kubernetes itself. The things are pretty same as in docker-compose.yml, but with Kubernetes syntax.kind: ServiceapiVersion: v1metad..

hxpjava1

52903人浏览 · 2018-06-12 17:28:38

hxpjava1 · 2018-06-12 17:28:38 发布

Deployment example

There is nothing much in deploying mailserver to Kubernetes itself. The things are pretty same as in docker-compose.yml, but with Kubernetes syntax.

kind: Service
apiVersion: v1
metadata:
  name: mailserver
  labels:
    app: mailserver
spec:
  selector:
    app: mailserver
  ports:
    - name: smtp
      port: 25
      targetPort: smtp
    - name: smtp-auth
      port: 587
      targetPort: smtp-auth
    - name: imap-secure
      port: 993
      targetPort: imap-secure

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: mailserver.config
  labels:
    app: mailserver
data:
  postfix-accounts.cf: |
    user1@example.com|{SHA512-CRYPT}$6$2YpW1nYtPBs2yLYS$z.5PGH1OEzsHHNhl3gJrc3D.YMZkvKw/vp.r5WIiwya6z7P/CQ9GDEJDr2G2V0cAfjDFeAQPUoopsuWPXLk3u1

  postfix-virtual.cf: |
    alias1@example.com user1@dexample.com

  SigningTable: |
    *@example.com mail._domainkey.example.com

  KeyTable: |
    mail._domainkey.example.com example.com:mail:/etc/opendkim/keys/example.com-mail.key

  TrustedHosts: |
    127.0.0.1
    localhost
      
---

kind: Secret
apiVersion: v1
metadata:
  name: mailserver.opendkim.keys
  labels:
    app: mailserver
type: Opaque
data:
  example.com-mail.key: 'base64-encoded-DKIM-key'

---

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: mailserver
  labels:
    app: mailserver
spec:
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mailserver
    spec:
      nodeSelector:
        has/mail-server: 'true'
      subdomain: mailserver
      containers:
        - name: mailserver
          image: tvial/docker-mailserver:2.1
          ports:
            - name: smtp
              containerPort: 25
            - name: smtp-auth
              containerPort: 587
            - name: imap-secure
              containerPort: 993
          env:
            - name: ONE_DIR
              value: '1'
          volumeMounts:
            - name: config
              subPath: postfix-accounts.cf
              mountPath: /tmp/docker-mailserver/postfix-accounts.cf
              readOnly: true
            - name: config
              subPath: postfix-virtual.cf
              mountPath: /tmp/docker-mailserver/postfix-virtual.cf
              readOnly: true
            - name: config
              subPath: SigningTable
              mountPath: /tmp/docker-mailserver/opendkim/SigningTable
              readOnly: true
            - name: config
              subPath: KeyTable
              mountPath: /tmp/docker-mailserver/opendkim/KeyTable
              readOnly: true
            - name: config
              subPath: TrustedHosts
              mountPath: /tmp/docker-mailserver/opendkim/TrustedHosts
              readOnly: true
            - name: opendkim-keys
              mountPath: /tmp/docker-mailserver/opendkim/keys
              readOnly: true
            - name: data
              mountPath: /var/mail
            - name: state
              mountPath: /var/mail-state
      volumes:
        - name: config
          configMap:
            name: mailserver.config
        - name: opendkim-keys
          secret:
            secretName: mailserver.opendkim.keys
        - name: data
          hostPath:
            path: /path/to/mailserver/data
        - name: state
          hostPath:
            path: /path/to/mailserver/state

Note: Any sensitive data (keys, etc) should be deployed via Secrets. Other configuration just fits well into ConfigMaps.

Note: Make sure that Pod is assigned to specific Node in case you're using volume for data directly with hostPath. Otherwise Pod can be rescheduled on a different Node and previous data won't be found. Except the case when you're using some shared filesystem on your Nodes.

Exposing to outside world

The hard part with Kubernetes is to expose deployed mailserver to outside world. Kubernetes provides multiple ways for doing that. Each has its downsides and complexity.

The major problem with exposing mailserver to outside world in Kubernetes is to preserve real client IP. Real client IP is required by mailserver for performing IP-based SPF checks and spam checks.

Preserving real client IP is relatively non-trivial in Kubernetes and most exposing ways do not provide it. So, it's up to you to decide which exposing way suits better your needs in a price of complexity.

If you do not require SPF checks for incoming mails you may disable them in Postfix configurationby dropping following line (which removes check_policy_service unix:private/policyd-spfoption):

kind: ConfigMap
apiVersion: v1
metadata:
  name: mailserver.config
  labels:
    app: mailserver
data:
  postfix-main.cf: |
    smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net
# ...

---

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: mailserver
# ...
          volumeMounts:
            - name: config
              subPath: postfix-main.cf
              mountPath: /tmp/docker-mailserver/postfix-main.cf
              readOnly: true
# ...

External IPs Service

The simplest way is to expose mailserver as a Service with external IPs.

kind: Service
apiVersion: v1
metadata:
  name: mailserver
  labels:
    app: mailserver
spec:
  selector:
    app: mailserver
  ports:
    - name: smtp
      port: 25
      targetPort: smtp
# ...
  externalIPs: 
    - 80.11.12.10

Downsides

Real client IP is not preserved, so SPF check of incoming mail will fail.
Requirement to specify exposed IPs explicitly.

Proxy port to Service

The Proxy Pod helps to avoid necessity of specifying external IPs explicitly. This comes in price of complexity: you must deploy Proxy Pod on each Node you want to expose mailserver on.

Downsides

Real client IP is not preserved, so SPF check of incoming mail will fail.

Bind to concrete Node and use host network

The simplest way to preserve real client IP is to use hostPort and hostNetwork: true in the mailserver Pod. This comes in price of availability: you can talk to mailserver from outside world only via IPs of Node where mailserver is deployed.

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: mailserver
# ...
    spec:
      hostNetwork: true
# ...
      containers:
# ...      
          ports:
            - name: smtp
              containerPort: 25
              hostPort: 25
            - name: smtp-auth
              containerPort: 587
              hostPort: 587
            - name: imap-secure
              containerPort: 993
              hostPort: 993
# ...

Downsides

Not possible to access mailserver via other cluster Nodes, only via the one mailserver deployed at.

Proxy port to Service via PROXY protocol

This way is ideologically the same as using Proxy Pod but instead Proxy Pod you should use HAProxy image or Nginx Ingress Controller and proxy TCP traffic to mailserver Pod with PROXY protocol usage which does real client IP preservation.

This requires some additional mailserver configuration: you should enable PROXY protocol on ports that Postfix and Dovecot listen on for incoming connections.

kind: ConfigMap
apiVersion: v1
metadata:
  name: mailserver.config
  labels:
    app: mailserver
data:
  postfix-main.cf: |
    smtpd_upstream_proxy_protocol = haproxy
  dovecot.cf: |
    service imap-login {
      inet_listener imaps {
        haproxy = yes
      }
    }
# ...

---

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: mailserver
#...
          volumeMounts:
            - name: config
              subPath: postfix-main.cf
              mountPath: /tmp/docker-mailserver/postfix-main.cf
              readOnly: true
            - name: config
              subPath: dovecot.cf
              mountPath: /etc/dovecot/conf.d/zz-custom.cf
              readOnly: true
# ...

Downsides

Not possible to access mailserver via inner cluster Kubernetes DNS, as PROXY protocol is required for incoming connections.

Let's Encrypt certificates

Kube-Lego may be used for a role of Let's Encrypt client. It works with Kubernetes Ingress Resources and automatically issues/manages certificates/keys for exposed services via Ingresses.

kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: mailserver
  labels:
    app: mailserver
  annotations:
    kubernetes.io/tls-acme: 'true'
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: default-backend
              servicePort: 80
  tls:
    - secretName: mailserver.tls
      hosts:
        - example.com

Now, you can use Let's Encrypt cert and key from mailserver.tls Secret in your Pod spec.

# ...
          env:
            - name: SSL_TYPE
              value: 'manual'
            - name: SSL_CERT_PATH
              value: '/etc/ssl/mailserver/tls.crt'
            - name: SSL_KEY_PATH
              value: '/etc/ssl/mailserver/tls.key'
# ...
          volumeMounts:
            - name: tls
              mountPath: /etc/ssl/mailserver
              readOnly: true
# ...
      volumes:
        - name: tls
          secret:
            secretName: mailserver.tls
# ...

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

云原生

所有评论(0)

查看更多评论

hxpjava1

@hxpjava1

已为社区贡献35条内容