前言
我們將應用以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服務來實現操作。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
