我们将应用以Docker容器的方式部署到服务器上的时候，通常需要考虑两个方面的的问题：网络和存储。
网络方面，有些应用需要占用端口，而其中一部分应用甚至需要对外提供访问。
出于安全方面考虑，代理转发方式相对于直接开放防火墙端口方式更为合适。
存储方面，由于容器内部并不适合做数据持久化，所以一般通过挂载卷的方式将数据保存在服务器磁盘上。
但是服务器也不能保证绝对安全，所以数据也需要备份到云上。
代理转发
默认情况下容器之间的网络是互相隔离的，但是对于一些有关联的应用而言(web前端容器和服务端容器以及数据库容器)，一般会把它们划分到一个独立的桥接子网络(以下简称子网)，使得这些容器之间可以相互通信，但同时又与外部进行隔离。
对于需要对子网外部提供访问的容器，可以将端口映射到服务器主机上。整个结构大致如下：
上面的端口映射只解决了服务器(宿主机)访问容器网络服务的问题，如果我们要从本地机器上通过因特网访问服务器上的容器，一般是不行的，因为服务器除了安全考虑，默认情况下会启用防火墙，并只开放22等少数几个端口。
对于传统的网络进程，实现方式就是通过反向代理服务器来对网络请求进行转发，比如使用Nginx配置如下代理：
- # 针对不同路径进行转发
- server {
- listen 80;
- server_name www.xx.com;
- location /a {
- proxy_pass localhost:1234;
- }
- location /b {
- proxy_pass localhost:2234;
- }
- }
- # 针对不同域名进行转发
- server {
- listen 80;
- server_name www.yy.com;
- location / {
- proxy_pass localhost:1234;
- }
- }
那么此时问题似乎是解决了，但是如果Nginx也是在容器中运行呢?
刚才我们提到子网对于外部的容器是隔离的，那么Nginx容器将无法访问这些对外服务。
你可能很容想到把Nginx容器划分到对应的子网络这种方式，容器的确支持多个子网的配置，但是这种操作方式的麻烦在于，每次新增子网时都需要修改Nginx容器的网络配置并重启容器。
所以比较好的方式是将Nginx设置为HOST网络模式。放弃Nginx容器与服务器的隔离性，直接与服务器共享网络和端口。那么Nginx容器即可直接访问所有映射了端口的容器。
如下图所示：
数据备份
应用场景
考虑到速度和安全性方面的问题，通常公司会有一些只供内网访问的服务器。但是这些服务器上的数据包括服务器本身都是随时可能被修改或者发生故障的。
所以数据备份显得尤为重要。这里我们讨论体积较小的数据备份。
以我最近为团队搭建的知识库服务器为例。
该web应用是一个小型的python服务，以容器的形式部署在内网服务器上，支持在线编辑功能，以md文件的形式保存数据。
因为容器一旦发生故障则内部数据无法再访问，所以直接放在容器中肯定是不安全的，只能通过挂载文件的方式让容器和服务器共享数据读写。
那么通过什么方式对数据进行备份呢?这里我们选择GitHub的私有仓库来进行保存。原因有3个：
- 安全。数据不容易丢失和窃取。
- 方便，只需要通过git命令即可备份。
- 快速。由于备份的数据体积和数量并不大。
虽然方式已经确定，但要实现还有两个问题：
- 向GitHub仓库需要进行权限认证。
- 如何定时或自动提交数据到GitHub。
实现方法
首先按照容器单一指责的原则，我们应该创建一个新的容器用来执行备份任务。
这里我们我可以使用docker-compose或者其它编排工具来创建多个容器。
然后就是权限认证，在本机创建ssh key并加入到GitHub的设置中，这样使得容器可以推送文件到对应仓库。
不过现在只是服务器可以推送代码，容器还不行，所以还需要将.ssh文件拷贝到容器中。
最后是自动备份的实现，比较好的方式是每次文件有变动的时候提交并推送代码，但是目前并没有找到在容器中监听文件的简单方式，所以退而求其次，采用定时任务的策略，即每隔5分钟执行对应的git命令来提交和推送文件到仓库。
这里可以使用基于镜像busybox封装的轻量级的容器，将项目代码挂载到容器中保证文件的同步更新，然后启动cron服务来实现操作。
