簡要的線上環境部署概覽
談到線上環境，一般開發同學，不太容易接觸到。即使接觸到，也只是其中的冰山一角！
所以，其實說起線上環境的部署，咱們好像都有點懂，但是又都不一定完全懂！網上的知識無窮無盡，但往往都是各司一職，對於普通同學，很難窺其全貌！
所以，我今天就來說說，一些普通的線上環境的部署步驟，和一些指令碼小技巧吧。只希望通過這篇文章，能夠讓大家有一個運維的全域性！
我將會分幾條線來整理咱們的運維思路！
一、從理論上講，我們應該怎麼做？
1. 針對的是什麼樣的使用者群體，體量大量會有多少？
這是一個部署規劃的前題。為啥呢？
一、如果你針對的是後臺管理員，人數也不多，那麼你可能只需要一個伺服器就可以了，前後端也都可以部署在同一臺伺服器上；如果稍微考慮下單點故障問題，則頂多兩臺伺服器搞定！
二、如果針對的是前端普通使用者，那麼，往往就會考慮多機部署，前後端分離，單點問題，負載均衡了；至於具體要部署多少臺，則要根據你的使用者情況來定了，當然，前期一般水需要多少臺！只要能持橫向擴充套件，則短期內，往往不太關心效能和架構問題！
2. 為支援預估的使用者量，大概需要多少的頻寬？
有訪問就會有流量產生，而預估的使用者量，則是一個頻寬資源需求的一個決斷依據！
一般針對前期使用者不太確定的場景，可以先買個 10M 左右的共享頻寬，基本能夠應付；經過一段時間的觀察後，再進行頻寬的變更也可以；
當然，考慮頻寬，自然也會存在一個公網IP的問題，因為流量是從IP進來的。
而在IP之前，則是域名的訪問。
公網IP可以是直接指向機器的，也可以是指向負載均衡器的。如果想要支援橫向擴充套件，則IP的指向一定是一個負載均衡器。因為只有這樣，當遇到流量突增，或者做活動的時候，才能更快速的進行擴容！
3. 資料庫規劃如何？
資料在當下時代，算是重中之重了。機器沒了可以再買，程式碼沒了可以再寫，但是資料沒了就完蛋了！
資料庫一般要新人兩個基本原則: 一、頻寬要大； 二、運算速度要快； 三、要能承受足夠大的運算空間；
所以，一般不要在資料庫上省錢，能多點就多點！
另外，也不要什麼樣的資料都往資料庫（關係型資料庫）存，搞清楚各型別資料庫的強項與弱項，做出明智的選擇。否則會帶來很多不必要的麻煩！
4. 應用要基於系統來部署還是基於容器來部署？
這是個決策性的問題！基於系統的部署，是一種比較傳統和常見的部署方式。優點是，很多系統工具都是完善的，只要你大概知道要部署什麼，部署下來一般不會有太多問題，因為這是個完整的系統。
但是，由於系統與系統之間可能不能完全一致，有各種各樣的差異，所以，你在這個機器上執行成功的東西，在另外的機器上則不一定能成功。因此，基於系統的部署將會使我人們的問題排查難度大大增加，而且移值性會很差。比如你在機器A上安裝了10個軟體，你可能配置了n個選項，但是，你在安裝B機器的時候，你並不能很好的利用原有的配置，你還得從頭一個個地來！
因此，有另一個部署方案，基於容器的部署（我這裡是基於docker容器的部署）。docker就類似於一個個的虛擬機器，但是它更加輕量級，當一個docker部署好後，你可以任意複製到其他機器上執行，看起來很誘人吧。不過，docker只是入門級容器，對於大量叢集容器的管理，還是顯得力不從心，當然你很容易找到另一個方案: Kubernetes (K8s); 你只要花上少許的時間瞭解下，你就可以應用了！當然了，使用容器的方案，有沒有什麼缺點呢？應該是有的，比如本來可以基於系統的監控方案，因為接入容器後，監控指標則不一定適用了，當然現成的方案還是有的，不過得另外再花點時間研究了。再比如：如果容器出了問題，是否能排查出來，這也是另一個問題！
5. 都有些什麼樣的基礎設施或者中介軟體？
想要執行應用程式，自然是先考慮執行環境的。比如：應用需要 nginx 來做http伺服器，用 tomcat 來做java web應用伺服器，用redis來做快取中介軟體，用zk來做應用協調中介軟體，用rabbitmq來做訊息中介軟體，等等！
因此，要在程式碼跑起來之前，先要把這些環境給準備好咯。
準備這些中介軟體或基礎設施之前，也要問下當下的形勢，比如：是否需要叢集部署，或者單機部署？往往叢集部署又會依賴其他的中介軟體！也更復雜！
當然，這些都不是事。事兒是在出問題之後，能夠有意識，能夠猜測到問題發生的點！
6. 應用程式碼應該怎樣部署？
當基礎環境就緒後，就應該讓主角上場了。應用程式碼怎麼部署？
最簡單的: 通過ftp上傳程式碼到伺服器上後，一個個部署！這種方案是最原始的，也是在沒有辦法搞更好的方案的時候使用的，不應長期使用；
稍微好點的: 使用整合工具(如jenkins)進行打包，然後上傳一個私有yum映象伺服器（yum 源）。然後線上進行yum 安裝；這種方式，藉助了整合工具，三個好處:
1. 可以檢測程式碼有改動做留檔；
2. 減少了手動上傳導致的包破壞的可能性；
3. 適合大規模應用；
再成熟點的: 再往後面，手動 yum 安裝也已經太累了，所以急需一個部署平臺，實現自動化部署；（這裡的自動化部署可能就是基於CI整合部署的一種升級版）。總之，大大減小了人工參與程式，提升了效率，同時也保證了質量！當然，這種部署平臺已經經過了嚴格的測試，出錯的可能性也比較小了！
8. 伺服器的安全性？
不考慮伺服器的安全性的應用，無異於自暴自棄。黑客無處不在，不過幸好現在系統也是越來越完善，只要稍加控制，即不那麼容易被攻破了。但是如果放棄安全防護，則隨便來一個菜鳥程式設計師就把你搞死了，那時的損失就大了。
網路安全是個很專業的領域，不過我們可以簡單的做下防護: 如防火牆、授權操作、病毒庫等等。當然，如果使用xx雲服務，則輕鬆方便多了，在後臺點點設定幾下搞定！
9. 服務的可監控性？
無監控，不上線！
這是一個警示，如果線上服務沒有監控，則所有線上的東西，都成了盲區，這對程式設計師GG們來說，簡直太糟糕了，雖然他們很自信！
監控分兩個方面： 一是系統級別的監控；二是應用級別的監控；(一般忽略其他監控: 如網路)
系統級別的監控一般可以安裝第三方的軟體來解決: 如 zabbix, grafana ...
而應用級別的監控，則需要自己擁有一套監控程式碼了，而這對初期專案，則往往比較吃力。
而如果使用xx雲服務，則往往都會自帶伺服器監控的，可以很方便地檢視到伺服器情況，站在高層次預估應用是否存在潛藏的問題！
如上，就是一些個人覺得的在部署一整套線上環境的時候，需要考慮的事項！從理論上講解了下個人見解，不對之處，請賜教！
二、接下來，我將給到一些實際的操作捷徑或提示？(linux)
1. 免密登入伺服器？
在n伺服器之間跳轉，如果每次都要求輸入密碼，那確實太煩了。尤其在密碼一般還很不容易記住的情況下！
所以，可以將一臺伺服器作為跳板機，在這臺伺服器上，可以免密地登入到允許的n臺子伺服器；
操作步驟有二：
# 1. 先使用 ssh-keygen 生成本機的key ssh-keygen -t rsa# 如果已生成不要重複生成 # 2. 使用 ssh-copy-id 將梧桐的 key 傳送到需要免密登入的伺服器，首頁copy時會要求輸入密碼，後續則免密了 ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]
2. 伺服器之間檔案（夾）拷貝？
拷貝檔案的目的有很多，比如：程式碼同步，檔案同步。。。
# 1. 使用scp 拷貝檔案 scp /home/ol-web.war [email protected]:/www/tomcat/wepapps/# 從本機拷貝到遠端 scp /home/ol-web.war [email protected]:/www/tomcat/wepapps/# 從遠端拷貝到本機 scp -r /www/nginx/html/ root@$1.2.3.2:/www/nginx/html/# 從本機拷貝資料夾到遠端 # 2. 使用 rsync 同步檔案，（可能需要安裝 rsync 服務） rsync -av --delete /www/nginx/html/ root@$1.2.3.1:/www/nginx/html/# 同步所有屬性，本地刪除的檔案也同步遠端刪除
3. 快捷使用 ssh 等等命令，使用 tab 鍵進行資訊補全？
當使用 ssh / scp 等等命令操作的時候，其操作物件往往 123這樣的ip顯示，如果不能友好點，那確實太累了！我們可以如下操作，以實現 ssh 也能更好的記憶：
# 在檔案 /root/.bashrc 中，新增指令碼如下，使自動補全新增 ssh # auto complete ... complete -W "$(echo $(grep -v '^$|#' .ssh/config | sort -u | sed 's/^ssh //'))" ssh # 在檔案 /root/.ssh/config 中，新增需要自動補全的伺服器， Host 172.2.3.5 server-api-01 Host 172.2.3.6 server-api-02 # 以上伺服器名字需要在 /etc/hosts 檔案中新增相應解析 # 而登入 server時，只需， ssh server-api-01 即可
如上補全工作，無需在所有伺服器上進行操作，只需在相應的跳板機上提供功能即可！
4. 簡要 salt 搭建指南？
salt 是個方便易用的叢集管理工具，比如你可以用於批量重啟服務，全域性搜尋日誌等等；
# 1. 安裝, 僅需到相應機器上安裝即可 yum install salt-master salt-minion # 2. 配置 /etc/salt/master /etc/salt/minion, 最簡單的，只需修改 minion 配置，指向 master 的ip即可； #指定master，冒號後有一個空格, minion master: 172.1.2.22 id: server-api-01 user: root # 3. 啟動所有節點, status, restart systemctl start salt-master# 162機器可用 systemctl start salt-minion /etc/init.d/salt-master start# 155機器可用 /etc/init.d/salt-minion start # 4. 將所有salt-minion 新增到 master 叢集管理 salt-key -A # 5. 登入跳板機 api_01, 執行salt 操作，執行叢集管理工作 salt server-api-02 cmd.run 'lsof -i:80' salt '*' test.ping
5. 簡要叢集複製shell指令碼？
有時，你可能需要將你的應用釋出到n臺服務中，你可以直接改如下shell,也可以依賴於salt這樣的高階工具進行釋出！shell 參考如下：
#!/bin/bash
# find out my ip to exclude...
MY_MERCHINE_IP=`ifconfig eth0 |awk -F "[: ]+" '/inet addr/{print $4}'`;
MERCHINE_IP_LIST="172.1.2.7 172.1.3.4";
for m_ip in $MERCHINE_IP_LIST;
do
if [[ $m_ip != $MY_MERCHINE_IP ]]; then
echo "- Installing apps to mechine@${m_ip} ...";
# install api apps
scp /www/test/hello-1.0.0-SNAPSHOT.jar root@${m_ip}:/www/test/
rsync -av --delete /www/html/ root@${m_ip}:/www/html/
echo "- Install apps to merchine@${m_ip} done.";
fi;
done;
6. 簡要docker搭建指南？
docker 作為一個容器化的基石，一出世就被追棒。包括現在的 k8s ，也是基於docker的。docker 可以讓你在一處搭建，處處執行，從而避免每次新買機器就要搞很久的尷尬局面；其搭建也是很簡單的（簡單應用）：
為方便任意發揮，我們可以基於centos這種系統級別的映象進行建立自己的image;
# docker 安裝: yum install docker service docker start # 拉取 centos6 的 docker 映象 docker pull centos:6 docker images # 構建一個 image, 建立空目錄，編輯 Dockerfile vim Dockerfile# 內容可變 FROM centos:6 MAINTAINER oom <[email protected]> # move all configuration files into container # RUN yum install -y lsof # EXPOSE 80 # CMD ["sh","-c","service httpd start;bash"] # 建立映象 docker build -t tmp_image:1.0 . # 建立並執行容器 docker run -h tmp_container -itd --name tmp_container -v /opt/docker/webapps:/www/webapp tmp_image:1.0 # 進入容器，相當於進入 centos 作業系統 docker exec -it tmp_container bash # 儲存容器修改到images docker commit -m 'web final.' 49d79fc19eaa tmp_image:1.2 # 備份容器修改後的docker映象 docker save > /opt/images/images_final/tmp_image.final.tar tmp_image:1.2
。。。