前言

我們將應(yīng)用以Docker容器的方式部署到服務(wù)器上的時(shí)候，通常需要考慮兩個(gè)方面的的問題：網(wǎng)絡(luò)和存儲(chǔ)。

網(wǎng)絡(luò)方面，有些應(yīng)用需要占用端口，而其中一部分應(yīng)用甚至需要對(duì)外提供訪問。

出于安全方面考慮，代理轉(zhuǎn)發(fā)方式相對(duì)于直接開放防火墻端口方式更為合適。

存儲(chǔ)方面，由于容器內(nèi)部并不適合做數(shù)據(jù)持久化，所以一般通過(guò)掛載卷的方式將數(shù)據(jù)保存在服務(wù)器磁盤上。

但是服務(wù)器也不能保證絕對(duì)安全，所以數(shù)據(jù)也需要備份到云上。

代理轉(zhuǎn)發(fā)

默認(rèn)情況下容器之間的網(wǎng)絡(luò)是互相隔離的，但是對(duì)于一些有關(guān)聯(lián)的應(yīng)用而言（web前端容器和服務(wù)端容器以及數(shù)據(jù)庫(kù)容器），一般會(huì)把它們劃分到一個(gè)獨(dú)立的橋接子網(wǎng)絡(luò)（以下簡(jiǎn)稱子網(wǎng)），使得這些容器之間可以相互通信，但同時(shí)又與外部進(jìn)行隔離。

對(duì)于需要對(duì)子網(wǎng)外部提供訪問的容器，可以將端口映射到服務(wù)器主機(jī)上。整個(gè)結(jié)構(gòu)大致如下：

上面的端口映射只解決了服務(wù)器（宿主機(jī)）訪問容器網(wǎng)絡(luò)服務(wù)的問題，如果我們要從本地機(jī)器上通過(guò)因特網(wǎng)訪問服務(wù)器上的容器，一般是不行的，因?yàn)榉?wù)器除了安全考慮，默認(rèn)情況下會(huì)啟用防火墻，并只開放22等少數(shù)幾個(gè)端口。

對(duì)于傳統(tǒng)的網(wǎng)絡(luò)進(jìn)程，實(shí)現(xiàn)方式就是通過(guò)反向代理服務(wù)器來(lái)對(duì)網(wǎng)絡(luò)請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)，比如使用Nginx配置如下代理：

# 針對(duì)不同路徑進(jìn)行轉(zhuǎn)發(fā)
server {
 listen  80;               
 server_name www.xx.com;            

 location /a {
  proxy_pass localhost:1234;
 }
 location /b {
  proxy_pass localhost:2234;
 }
}
# 針對(duì)不同域名進(jìn)行轉(zhuǎn)發(fā)
server {
 listen  80;               
 server_name www.yy.com;            

 location / {
  proxy_pass localhost:1234;
 }
}

那么此時(shí)問題似乎是解決了，但是如果Nginx也是在容器中運(yùn)行呢？

剛才我們提到子網(wǎng)對(duì)于外部的容器是隔離的，那么Nginx容器將無(wú)法訪問這些對(duì)外服務(wù)。

你可能很容想到把Nginx容器劃分到對(duì)應(yīng)的子網(wǎng)絡(luò)這種方式，容器的確支持多個(gè)子網(wǎng)的配置，但是這種操作方式的麻煩在于，每次新增子網(wǎng)時(shí)都需要修改Nginx容器的網(wǎng)絡(luò)配置并重啟容器。

所以比較好的方式是將Nginx設(shè)置為HOST網(wǎng)絡(luò)模式。放棄Nginx容器與服務(wù)器的隔離性，直接與服務(wù)器共享網(wǎng)絡(luò)和端口。那么Nginx容器即可直接訪問所有映射了端口的容器。

如下圖所示：

數(shù)據(jù)備份

應(yīng)用場(chǎng)景

考慮到速度和安全性方面的問題，通常公司會(huì)有一些只供內(nèi)網(wǎng)訪問的服務(wù)器。但是這些服務(wù)器上的數(shù)據(jù)包括服務(wù)器本身都是隨時(shí)可能被修改或者發(fā)生故障的。

所以數(shù)據(jù)備份顯得尤為重要。這里我們討論體積較小的數(shù)據(jù)備份。

以我最近為團(tuán)隊(duì)搭建的知識(shí)庫(kù)服務(wù)器為例。

該web應(yīng)用是一個(gè)小型的python服務(wù)，以容器的形式部署在內(nèi)網(wǎng)服務(wù)器上，支持在線編輯功能，以md文件的形式保存數(shù)據(jù)。

因?yàn)槿萜饕坏┌l(fā)生故障則內(nèi)部數(shù)據(jù)無(wú)法再訪問，所以直接放在容器中肯定是不安全的，只能通過(guò)掛載文件的方式讓容器和服務(wù)器共享數(shù)據(jù)讀寫。

那么通過(guò)什么方式對(duì)數(shù)據(jù)進(jìn)行備份呢？這里我們選擇GitHub的私有倉(cāng)庫(kù)來(lái)進(jìn)行保存。原因有3個(gè)：

• 安全。數(shù)據(jù)不容易丟失和竊取。
• 方便，只需要通過(guò)git命令即可備份。
• 快速。由于備份的數(shù)據(jù)體積和數(shù)量并不大。

雖然方式已經(jīng)確定，但要實(shí)現(xiàn)還有兩個(gè)問題：

• 向GitHub倉(cāng)庫(kù)需要進(jìn)行權(quán)限認(rèn)證。
• 如何定時(shí)或自動(dòng)提交數(shù)據(jù)到GitHub。

實(shí)現(xiàn)方法

首先按照容器單一指責(zé)的原則，我們應(yīng)該創(chuàng)建一個(gè)新的容器用來(lái)執(zhí)行備份任務(wù)。

這里我們我可以使用docker-compose或者其它編排工具來(lái)創(chuàng)建多個(gè)容器。

然后就是權(quán)限認(rèn)證，在本機(jī)創(chuàng)建ssh key并加入到GitHub的設(shè)置中，這樣使得容器可以推送文件到對(duì)應(yīng)倉(cāng)庫(kù)。

不過(guò)現(xiàn)在只是服務(wù)器可以推送代碼，容器還不行，所以還需要將.ssh文件拷貝到容器中。

最后是自動(dòng)備份的實(shí)現(xiàn)，比較好的方式是每次文件有變動(dòng)的時(shí)候提交并推送代碼，但是目前并沒有找到在容器中監(jiān)聽文件的簡(jiǎn)單方式，所以退而求其次，采用定時(shí)任務(wù)的策略，即每隔5分鐘執(zhí)行對(duì)應(yīng)的git命令來(lái)提交和推送文件到倉(cāng)庫(kù)。

這里可以使用基于鏡像busybox封裝的輕量級(jí)的容器，將項(xiàng)目代碼掛載到容器中保證文件的同步更新，然后啟動(dòng)cron服務(wù)來(lái)實(shí)現(xiàn)操作。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)腳本之家的支持。