面试相关东东
故障案例
https://blog.csdn.net/wuxingge/article/details/106345081
dns
yum install bind -ydns主配置文件
vim /etc/named.conf
listen-on port 53 { 10.4.7.11; }; allow-query { any; }; forwarders { 10.4.7.254; }; dnssec-enable no; dnssec-validation no;修改完配置文件檢查配置文件
named-checkconf
dns區域配置文件
vim /etc/named.rfc1912.zones
最后添加 zone "host.com" IN {type master;file "host.com.zone";allow-update { 10.4.7.11; }; };zone "od.com" IN {type master;file "od.com.zone";allow-update { 10.4.7.11; }; };配置區域數據文件
配置主機域數據文件
vim /var/named/host.com.zone
配置業務域數據文件
cat /var/named/od.com.zone
啟動dns
systemctl start named systemctl enable named查看解析
dig -t A hdss7-21.host.com @10.4.7.11 +shortzookeeper
https://blog.csdn.net/java_66666/article/details/81015302
分布式服務框架,是Apache Hadoop 的一個子項目
它主要是用來解決分布式應用中經常遇到的一些數據管理問題,如:
- 統一命名服務
- 狀態同步服務、
- 集群管理、
- 分布式應用配置項的管理等
上面的解釋有點抽象,簡單來說zookeeper=文件系統+監聽通知機制
3個端口的作用
-
1、2181:對cline端提供服務
-
2、3888:選舉leader使用
-
3、2888:集群內機器通訊使用(Leader監聽此端口)
Kafka
https://blog.csdn.net/wuxingge/article/details/106346823
-
Kafka利用ZooKeeper保存相應元數據信息,Kafka元數據信息包括如代理節點信息、Kafka集群信息、舊版消費者信息及其消費偏移量信息、主題信息、分區狀態信息、分區副本分配方案信息、動態配置信息等。
-
Kafka在啟動或運行過程當中會在ZooKeeper上創建相應節點來保存元數據信息,Kafka通過監聽機制在這些節點注冊相應監聽器來監聽節點元數據的變化,從而由ZooKeeper負責管理維護Kafka集群,同時通過ZooKeeper我們能夠很方便地對Kafka集群進行水平擴展及數據遷移
kafka默認端口號:9092
hadoop
https://blog.csdn.net/wuxingge/article/details/106319013
https://blog.csdn.net/gwd1154978352/article/details/81095592
需要連接zookeeper
2個主節點namenode
5個datanode
hadoop的核心
- 1.HDFS: Hadoop Distributed File System 分布式文件系統
- 2.YARN: Yet Another Resource Negotiator 資源管理調度系統
- 3.Mapreduce:分布式運算框架
配置:
- env
- core-site
- yarn-site
- hdfs-site
- mapred-site
HDFS的架構
主從結構
- 主節點, namenode
- 從節點,有很多個: datanode
namenode負責:
- 接收用戶操作請求
- 維護文件系統的目錄結構
- 管理文件與block之間關系,block與datanode之間關系
Secondary NameNode負責:
- 合并fsimage和edits文件來更新NameNode的metedata
datanode負責:
- 存儲文件
- 文件被分成block存儲在磁盤上
- 為保證數據安全,文件會有多個副本
端口 | 程序 | 說明
- | - | -
50070 |namenode |web瀏覽器訪問端口
50010 |datanode |web瀏覽器訪問端口,用于數據傳輸
50090 |secondarynamenode | web瀏覽器訪問端口
8088 | resourcemanager | web瀏覽器訪問端口
8032 | | RM的application master端口
19888 | jobhistory server |歷史服務器的訪問端口
9000 | | file system默認端口號,內部通訊端口
8020 | | namenode節點active狀態下的端口號,用于獲取文件系統metadata信息
hbase
https://blog.csdn.net/wuxingge/article/details/106319013
需要連接zookeeper
- HMaster
- HRegionServer
Hbase web頁面http://192.168.1.101:16030
Hbase Master URL:http://192.168.1.101:60010
spark
https://blog.csdn.net/wuxingge/article/details/106319013
http://192.168.1.101:8080/
docker
https://blog.csdn.net/wuxingge/article/details/106398121
- namespace----資源隔離
- cgroup ----資源限制
namespace
隔離內容 | 內核版本
- | -
PID | 2.6.24
IPC 信號量、消息隊列、共享內存 | 2.6.19
MOUNT 文件系統,掛載點 | 2.4.19
NET | 2.6.29
UTS 主機名和主機域 | 2.6.19
USER 用戶和組 | 3.8.x
docker鏡像特性
- docker鏡像位于bootfs之上
- 每一層鏡像的下面一層稱為其父鏡像
- 第一層鏡像為Base Image
- 容器在最頂層
- 其下的所有層都為readonly
- docker將readonly的FS層稱作 “image”
容器的生命周期
- docker客戶端連接docker daemon,請求運行容器
- docker daemon 檢查本地是否存在鏡像,如果不存在則從遠端倉庫檢索
- 利用鏡像啟動容器
- 分配一個文件系統,并在只讀的鏡像層外掛載一層可讀寫層
- 從宿主機配置的網橋接口中橋接一個虛擬接口到容器
- 從地址池配置一個ip地址給容器
- 執行用戶指定的指令
- 執行完畢后容器終止
docker網絡
- NAT(默認)
- None
- Host
- 聯合網絡
docker run -it --rm --name lhwl2 --network container:c31d45c54227 wuxingge/nginx:curl /bin/bash
Dockerfile
COPY指令
- src是目錄,其內部文件和目錄都復制,但src目錄自身不會被復制
- 如果有多個src,則dest必須以/結尾
ADD
-
src為url且dest不以/結尾, 則src指定的文件被下載并直接創建為dest
-
dest以/結尾,則下載文件并保存為dest/filename
-
src為本地tar文件,則自動解壓為一個目錄;
-
但通過url獲取到的tar文件不會自動解壓
Docker容器化封裝應用程序的意義(好處)
-
docker引擎統一了基礎設施環境 - docker環境
- 硬件的配置
- 操作系統的版本
- 運行時環境的異構
-
docker引擎統一了程序打包(裝箱)方式 - docker鏡像
- Java程序
- python程序
- nodejs程序
-
docker引擎統一了程序部署(運行)方式 - docker容器
- java -jar … -> docker run …
- python manage.py runserver … -> docker run …
- npm run dev -> docker run …
docker容器化封裝應用程序的缺點(壞處)
- 單機使用,無法有效集群
- 隨著容器數量的上升,管理成本攀升
- 沒有有效的容災/自愈機制
- 沒有預設編排模板,無法實現快速、大規模容器調度
- 沒有統一的配置管理中心工具
- 沒有容器生命周期的管理工具
- 沒有圖形化運維管理工具
基于docker容器引擎的開源容器編排工具
- docker compose 、 docker swarm
- Mesosphere + Marathon
- Kubernetes(K8S)
kubernetes
概念
https://blog.csdn.net/wuxingge/article/details/106423699
部署、架構
https://blog.csdn.net/wuxingge/article/details/106428257
k8s驅逐pod
#設置不可調度 kubectl cordon node07-ingress#取消節點不可調度 kubectl uncordon node07-ingress#驅逐節點的pod kubectl drain --ignore-daemonsets node07-ingress #kubectl drain --ignore-daemonsets --delete-local-data node07-ingress#刪除節點 kubectl delete node node07-ingresselasticsearch
https://blog.csdn.net/wuxingge/article/details/106867654
https://mp.weixin.qq.com/s?__biz=MzA4MzIwNTc4NQ==&mid=2247484685&idx=3&sn=236c717eb042cbfb27514811afb5476a&chksm=9ffb4efba88cc7ed629b7ebb66c8499b63a1a01d65c68ef50c6118892861c9cf4f34bc6ea711&mpshare=1&scene=24&srcid=&sharer_sharetime=1590102825036&sharer_shareid=9d93d05defb8fa7a91ab0e64cf1ae1e7&key=b6ae2d62a5369f548b7773d8c73625ec272553cb0755b35eef4110f0721682c9760a0b7f8974947f1c323bb30a1dbeab83dec3f06c7708b9b9a59a47fc4747daeedac0d32a530289d7c9cd2302e2f40f&ascene=14&uin=OTcwNDkxODIx&devicetype=Windows+10+x64&version=62090070&lang=zh_CN&exportkey=AXJm0Gns3MrF7LEYL%2B770Ek%3D&pass_ticket=WCOZ08w%2FgCankpBnKsry2IXxIU26yiXBpP7owio3FU7%2B0Y3UEGLbX4yQwJi%2FSAS%2B
集群搭建
https://mp.weixin.qq.com/s?__biz=MzAwMjg1NjY3Nw==&mid=2247488940&idx=1&sn=2d7f4104bc8eddcc2d2ed4a00c395e28&chksm=9ac55626adb2df304ee889f3c568993afc736a8a2a20e0e884c33af49bb990eebf4f52ee4523&mpshare=1&srcid=&sharer_sharetime=1586232206997&sharer_shareid=887d1df6558c0f63ce1b55e742a9e563&from=timeline&scene=2&subscene=1&clicktime=1586232405&enterid=1586232405&key=b6ae2d62a5369f54d1f9cc9f22d4b042fee51bfe5abd2e5c2288b6c963282e7ceb85e9c71d87fbedba9d583642a3f752508d7fbca8dda4f7e6234d44d5b894738a2fa54722a1d3f5e706f9e682c3d86b&ascene=14&uin=OTcwNDkxODIx&devicetype=Windows+10+x64&version=62090070&lang=zh_CN&exportkey=ASImoKzqB5p4OkMX0u4K5XY%3D&pass_ticket=WCOZ08w%2FgCankpBnKsry2IXxIU26yiXBpP7owio3FU7%2B0Y3UEGLbX4yQwJi%2FSAS%2B
Elastic Stack應用場景
- 網站搜索、代碼搜索等(例如生產環境的日志收集 ——格式化分析——全文檢索——系統預警)
- 日志管理與分析、應用系統性能分析、安全指標監控等
基本概念
文檔(Document)
Elasticsearch面向文檔性,文檔就是所有可搜索數據的最小單位。比如,一篇PDF中的內容,一部電影的內容等,文檔會被序列化成JSON格式,保存在Elasticsearch中,必不可少的是每個文檔都會有自己的唯一標識,可以自己指定,也可以由Elasticsearch幫你生成。類似數據庫的一行數據
元數據(標注文檔信息)
"_index" : "user", "_type" : "_doc", "_id" : "l0D6UmwBn8Enzbv1XLz0", "_score" : 1.6943597, "_source" : {"user" : "mj","sex" : "男","age" : "18" }- _index:文檔所屬的索引名稱。
- _type:文檔所屬的類型名。
- _id:文檔的唯一標識。
- _version:文檔的版本信息。
- _score:文檔的相關性打分。
- _source:文檔的原始JSON內容。
索引(index)
索引是文檔的容器,是一類文檔的集合,類似關系數據庫中的表,索引體現的是一種邏輯空間的概念,每個索引都應該有自己的Mapping定義,用于定義包含文檔的字段名和字段類型。其中Shard(分片)體現的是物理空間的一種概念,就是索引中的數據存放在Shard上,因為有集群,要保證高可用,當其中一個機器崩潰中,保存在它上的分片數據也能被正常訪問,因此,存在分片副本。
索引中有兩個重要的概念,Mapping和Setting
- Mapping定義的是文檔字段和字段類型
- Setting定義的是數據的不同分布
類型(Type)
在7.0之前,一個index可以創建多個Type。
之后就只能一個index對應一個Type
節點(Node)
一個節點就是一個Elaseticsearch實例,本質就是一個JAVA進程。每一個節點啟動后,默認就是一個master eligible節點。就是具備成為master資格的節點,你也可以狠心的指定它沒有這個資格(node.master:false)
第一個節點啟動后,他就選自己成為Master節點類,每一個節點上都保存了集群狀態,但是,只有Master才能修改集群狀態信息。集群狀態信息就比如:
- 所有的節點信息。
- 所有的索引信息,索引對應的mapping信息和setting信息。
- 分片的路由信息。
分片(shard)
-
主分片:用于解決數據的水平擴展問題,通過主分片就數據分布在集群內的不同節點上,主分片在創建索引的時候就指定了,后面就不允許修改,除非重新定義Index。
-
副本:用于解決高可用的問題,分片是主分片的拷貝。副本分片數可以動態的調整,增加副本數量可以在一定的程度上提高服務的可用性。關于主分片的理解可以如下圖,看是怎樣實現高可用的
倒排索引
正排索引:就是文檔ID到文檔內容的索引,簡單講,就是根據ID找文檔。
文檔ID | 文檔內容
- | -
1101 | Elasticsearch Study
1102 | Elasticsearch Server
1103 | master Elasticsearch
倒排索引:就是根據文檔內容找文檔。
倒排索引包含如下信息:
- 單詞詞典:用于記錄所有文檔的單詞,以及單詞到倒排列表的關聯關系。
- 倒排列表:記錄的是單詞對應的文檔集合,由倒排索引項組成,其中包含
- 文檔ID
- 單詞出現的次數,用于相關性的評分
- 單詞出現的位置
- 偏移量,用于記錄單詞的開始位置和結束位置,用于單詞的高亮顯示
文檔ID(Doc ID) | 出現次數(TF) | 位置(Position) | 偏移量(Offset)
- | - | - | -
1101 | 1 | 0 | <0,13>
1102 | 1 | 0 | <0,13>
1103 | 1 | 1 | <7,20>
Elasticsearch中的每一個字段都有自己的倒排索引,
也可以指定某些字段不做索引,可以節省存儲空間,缺點就是不能被搜索到。
Analyzer分詞
Analysis:文本分析,就是將文本轉換為單詞(term或者token)的過程,其中Analyzer就是通過Analysis實現的,Elasticsearch給我們內置很多分詞器。
- Standard Analyzer:默認的分詞器,按照詞切分,并作大寫轉小寫處理
- Simple Analyzer:按照非字母切分(符號被過濾),并作大寫轉小寫處理
- Stop Anayzer:停用詞(the、is)切分,并作大寫轉小寫處理
- Whitespace Anayzer:空格切分,不做大寫轉小寫處理
- IK:中文分詞器,需要插件安裝
- ICU:國際化的分詞器,需要插件安裝
- jieba:時下流行的一個中文分詞器。安裝方法見附錄
PS:Elasticsearch 安裝插件,./bin/elasticsearch-plugin install analysis-icu
查看已經安裝的插件:./bin/elasticsearch-plugin list
Search API
在ES中,我們可以使用URL Search和Request Body Search進行相關的查詢操作
URL 查詢
使用基本的查詢
GET /user/_search?q=2012&df=title&sort=year:desc&from=0&size=10 {"profile": true }- 使用q指定查詢的字符串
- 使用df指定查詢的字段
- 使用sort進行排序,使用from和size指定分頁
- 使用profile可以查詢查詢是如何進行查詢的
指定所有字段的泛查詢
GET /user/_search?q=2012 {"profile":"true" }指定字段的查詢
GET /user/_search?q=title:2012&sort=year:desc&from=0&size=10&timeout=1s {"profile":"true" }Term查詢
GET /user/_search?q=title:Beautiful Mind {"profile":"true" }- 上例中的Beautiful和Mind就是兩個Term,Term是查詢中最小的單位。
- Term查詢是OR的關系,在上例中就是title字段包含Beautiful或者包含Mind都會被檢索到。
Phrase查詢
GET /user/_search?q=title:"Beautiful Mind" {"profile":"true" }- 使用引號表示Phrase查詢
- Phrase查詢表示的不僅是And的關系,即Title字段中不僅要包含Beautiful Mind,而且。順序還要一致。
分組查詢
GET /user/_search?q=title:(Beautiful Mind) {"profile":"true" }- 使用中括號表示分組查詢,一般使用Term查詢的時候都會帶上分組查詢。
布爾查詢
- 使用 AND、OR、NOT或者||、&&、!
- 還可以使用+(表示must),使用-(表示must_not)
- 需要注意的是必須大寫
PS:%2B表示的就是+,上例子表示的就是title字段中既要包含Beautiful,也要包含Mind字段
范圍查詢
GET /user/_search?q=title:beautiful AND age:[2002 TO 2018%7D {"profile":"true" }- 使用[ ]表示閉區間,使用{ }表示開區間,例如age :[* TO 56]
- 使用算術符表示范圍,例如year :>=2019 && <=1970
PS:URL Search還有很多查詢方式。例如通配符查詢,正則插敘,模糊匹配,相似查詢,其中通配符查詢不建議使用。
Request Body 查詢
將查詢的條件參數放在Request Body中,調用查詢接口,就是Request Body查詢
基本 的查詢
POST /movies,404_idx/_search?ignore_unavailable=true {"profile": true,"query": {"match_all": {}} }- 使用gnore_unavailable=true可以避免索引404_idx不存在導致的報錯
- profile和URL Search查詢一樣,可以看到查詢的執行方式
分頁查詢
POST /movies/_search {"from":10,"size":20,"query":{"match_all": {}} }排序查詢
POST /movies/_search {"sort":[{"order_date":"desc"}],"query":{"match_all": {}} }過濾要查詢的字段
POST /movies/_search {"_source":["order_date"],"query":{"match_all": {}} }- 如果一個文檔中的字段太多,我們不需全部字段顯示,就可以使用_source指定字段。可以使用通配符。
使用腳本查詢
- 將ES中的文檔字段進行一定的處理后,再根據這個新的字段進行排序,
Term查詢
POST /movies/_search {"query": {"match": {"title": "last christmas"}} }POST movies/_search {"query": {"match": {"title": {"query": "last christmas","operator": "and"}}} }- 使用match,表示的就是OR的關系
- 使用operator,表示查詢方式
Math_phrase查詢
POST movies/_search {"query": {"match_phrase": {"title":{"query": "one love","slop": 4}}} }Dynamic Mapping
Mapping可以簡單的理解為數據庫中的Schema定義,用于定義索引中的字段的名稱,定義字段的類型,字段的倒排索引,指定字段使用何種分詞器等。Dynamic Mapping意思就是在我們創建文檔的時候,如果索引不存在,就會自動的創建索引,同時自動的創建Mapping,ElasticSearch會自動的幫我們推算出字段的類型,當然,也會存在推算不準確的時候,就需要我們手動的設置。
常用的字段類型如下:
- 簡單類型:Text、Date、Integer、Boolean等
- 復雜類型:對象類型和嵌套類型。
我們可以使用GET /shgx/_mapping查詢索引的Mapping的設置,需要注意的是以下幾點:
- 當我們對索引中的文檔新增字段時候,希望可以更新索引的Mapping就可以可以設置Dynamic:true。
- 對于已經有數據的字段,就不再允許修改其Mapping,因為Lucene生成的倒排索引后就不允許修改。
Dynamic Mapping可以設置三個值,分別是:
- true:文檔可被索引,新增字段也可被索引,Mapping也會被更新。
- false:文檔可被索引,新增字段不能被索引,Mapping不會被更新。
- strict:新增字段寫入,直接報錯
如何寫Mapping
第一種方式是參考官方API,純手工寫,也可以先創建一個臨時的Index讓ElasticSearch自動當我們推斷出基本的Mapping,然后自己在改吧改吧,最后把臨時索引刪掉就是啦。
下面列舉一些常用的Mapping設置屬性:
- index:可以設置改字段是否需要被索引到。設置為false就不會生成倒排索引,節省磁盤開銷
- null_value:可以控制NULL是否可以被索引
- cope_to:將字段值放在一個新的字段中,可以使用新的字段- search,但這個字段不會出現在_source中。
- anaylzer:指定字段的分詞器
- search_anaylzer:指定索引使用的分詞器
- index_options:控制倒排索引的生成結構,有四種情況
- docs:倒排索引只記錄文檔ID
- freqs:記錄文檔ID和Term
- positions:記錄文檔ID、Term和Term Position
- offsets:記錄文檔ID、Term、Term Position和offsets
PS:Text類型的字段默認的是Position,其它類型默認的是docs,記錄的越多,占用的存儲空間就越大
Aggregation聚合分析
ElasticSearch不僅僅是搜索強大,他的統計功能也是相當的強大的,聚合分析就是統計整個數據的一個分類數量等,例如武侯區有多少新樓盤。天府新區有多少新樓盤,通過聚合分析我們只需要寫一條語句就可以得到。在加上Kibana的可視化分析,簡直就是清晰,高效。
常用的集合有以下幾種:
- Bucket Aggregation:滿足特定條件的一些集合,使用關鍵字terms
- Metric Aggregation:簡單的數學運算,對字段進行統計分析,使用關鍵字min、max、sum、avg等,使用關鍵字aggs
- Pipeline Aggregation:二次聚合
- Matrix Aggregation:對多個字段進行操作,提供一個結果矩陣
Bucket分析示例
GET kibana_sample_data_flights/_search {"size": 0,"aggs":{"flight_dest":{"terms":{"field":"DestCountry"}}} }Metric分析示例
GET kibana_sample_data_flights/_search {"size": 0,"aggs":{"flight_dest":{"terms":{"field":"DestCountry"},"aggs":{"avg_price":{"avg":{"field":"AvgTicketPrice"}},"max_price":{"max":{"field":"AvgTicketPrice"}},"min_price":{"min":{"field":"AvgTicketPrice"}}}}} }beat
- FileBeat收集數據源為文件的數據
- TopBeat來收集系統中的監控信息
/etc/filebeat.yaml
filebeat.inputs: - type: logfields_under_root: truefields:topic: logm-${PROJ_NAME}paths:- /logm/*.log- /logm/*/*.log- /logm/*/*/*.log- /logm/*/*/*/*.log- /logm/*/*/*/*/*.logscan_frequency: 120smax_bytes: 10485760multiline.pattern: '$MULTILINE'multiline.negate: truemultiline.match: aftermultiline.max_lines: 100 - type: logfields_under_root: truefields:topic: logu-${PROJ_NAME}paths:- /logu/*.log- /logu/*/*.log- /logu/*/*/*.log- /logu/*/*/*/*.log- /logu/*/*/*/*/*.log- /logu/*/*/*/*/*/*.log output.kafka:hosts: ["10.4.7.11:9092"]topic: k8s-fb-$ENV-%{[topic]}version: 2.0.0required_acks: 0max_message_bytes: 10485760logstash
/etc/logstash/logstash-test.conf
input {kafka {bootstrap_servers => "10.4.7.11:9092"client_id => "10.4.7.200"consumer_threads => 4group_id => "k8s_test"topics_pattern => "k8s-fb-test-.*"} }filter {json {source => "message"} }output {elasticsearch {hosts => ["10.4.7.12:9200"]index => "k8s-test-%{+YYYY.MM.DD}"} }內核參數優化
cat >>/etc/sysctl.conf<<EOF net.ipv4.tcp_fin_timeout = 2 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_keepalive_time = 600 net.ipv4.ip_local_port_range = 4000 65000 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.tcp_max_tw_buckets = 36000 net.ipv4.route.gc_timeout = 100 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_synack_retries = 1 net.core.somaxconn = 16384 net.core.netdev_max_backlog = 16384 net.ipv4.tcp_max_orphans = 16384net.nf_conntrack_max = 25000000 net.netfilter.nf_conntrack_max = 25000000 net.netfilter.nf_conntrack_tcp_timeout_established = 180 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 EOFNginx
nginx是多進程,每個進程中有一個線程
https://blog.csdn.net/wuxingge/article/details/103380195
模塊
- ngx_http_core_module
- ngx_http_index_module
- ngx_http_log_module
- ngx_http_proxy_module
- ngx_http_rewrite_module
- ngx_http_stub_status_module
- ngx_http_upstream_module
- ngx_http_ssl_module
- ngx_http_access_module
- ngx_http_limit_conn_module
- ngx_http_limit_req_module
- ngx_http_index_module
- ngx_http_referer_module
- ngx_http_autoindex_module
- ngx_http_headers_module
nginx狀態
Active connections
The current number of active client connections including Waiting connections.
當前活動的客戶端連接數,包括Waiting連接數
accepts
The total number of accepted client connections.
接受的客戶端連接總數
handled
The total number of handled connections. Generally, the parameter value is the same as accepts unless some resource limits have been reached (for example, the worker_connections limit).
已處理的連接總數
requests
The total number of client requests.
客戶端請求總數
Reading
The current number of connections where nginx is reading the request header.
nginx正在讀取請求標頭的當前連接數
Writing
The current number of connections where nginx is writing the response back to the client.
nginx正在將響應寫回到客戶端的當前連接數
Waiting
The current number of idle client connections waiting for a request.
當前等待請求的空閑客戶端連接數
優化
https://blog.csdn.net/wuxingge/article/details/106492341
Nginx安全優化
- 隱藏nginx版本信息
- 上傳文件大小的限制
- 禁止非法域名解析
- 圖片及目錄防盜鏈(invalid_referer)
- 錯誤頁面友好顯示
- 防爬蟲(http_user_agent)
Nginx性能優化
- 調整worker進程
- worker進程最大打開文件數
- 單個進程允許的客戶端最大連接數
- 優化nginx事件處理模型
- gzip壓縮
- 開啟高效傳輸模式
nginx跨域
https://blog.csdn.net/wuxingge/article/details/106317469
通過定義我們可以,簡單請求與復雜請求的差別是復雜請求會自動發出一個 OPTIONS 的預檢請求,當請求得到確認后,才開始真正發送請求
tomcat
安全優化
-
關閉管理端口保護 8005 SHUTDOWN
-
ajp連接端口保護 8009 注釋
-
禁用管理端 刪除tomcat自帶的管理程序
-
降權啟動 降低用戶權限啟動
-
版本信息隱藏
conf/web.xml error-page設置 -
文件列表訪問控制
conf/web.xml 中default部分listings的配置必須為false -
起停腳本權限回收
性能優化
-
開啟壓縮功能
各種文本文件壓縮 -
調整運行模式
Nio2模式
apr模式 -
內存使用的限制
httpd
三次握手
內核控制
重試次數
網絡情況不好,調大一些
網絡好的時候,調小一些
通常情況下,調小
Httpd MPM多處理模型
prefork:進程模型,兩級結構,主進程master負責生成子進程,每個子進程負責響應一個請求
worker:線程模型,三級結構,主進程master負責生成子進程,每個子進程負責生成多個線程,每個線程響應一個請求
event:線程模型,三級結構,主進程master負責生成子進程,每個子進程響應多個請求(有一個監控線程)監聽線程(沒有安全性)
連接(established)
keepalive on 開長連接
超時時間盡量調小
KeepAliveTimeout 5
net.ipv4.tcp_keepalive_time = 600斷開
net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1壓縮
vim /etc/httpd/conf.d/deflate.conf
<Ifmodule mod_deflate.c> DeflateCompressionLevel 6 AddOutputFilterByType DEFLATE text/html </Ifmodule>緩存
vim /etc/httpd/conf.d/exp.conf
<IfModule mod_expires.c> ExpiresActive On ExpiresByType text/css "now plus 1 month" ExpiresByType application/x-javascript "now plus 5 day" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/bmp "access plus 1 month" ExpiresByType image/x-icon "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" </IfModule>zabbix
https://blog.csdn.net/wuxingge/article/details/106239510
| 硬件監控 | 1、通過遠程控制卡:dell的iDRAC,HP的ILO,IBM的IMM等 2、使用IPMI來完成物理設備的監控工作。通常必須要監控的就是溫度、風扇轉速、硬盤故障等 3、路由器,交換機(端口、光衰、日志),打印機等 |
|:----|:----😐:----|:----😐
| 系統監控 | CPU、內存、磁盤的剩余空間/利用率和I/O、swap使用率、系統uptime、進程數、負載 |
| 網絡監控 | 端口,ping包,IDC帶寬網絡流量,網絡流出流入速率,網絡入流量,網絡出流量,網絡使用率,SMTP, POP3 |
| 流量分析 | pv、uv,并發連接數,獨立IP數 常見工具:piwik,友盟+,百度統計 |
| 業務監控 | 用戶登錄失敗次數,用戶登錄網站次數,輸入驗證碼失敗次數,網絡連接數,電商網站訂單,支付交易的數量,總訂單數,平均訂單數 |
| URL監控 | 監測指定URL訪問過程中的返回碼、下載時間及文件大小,支持內容匹配 |
| 數據庫 | 監測數據庫中指定的表空間、數據庫的游標數、session數、事務數、死鎖數、緩沖池命中率、庫cache命中率、當前連接數、進程的內存利用率等性能參數 |
| 服務監控 | 端口和內存使用率、CPU使用率、服務狀態、請求數、并發連接數、消息隊列的字節數、client事務處理數等 |
| 日志監控 | 系統日志,訪問日志、錯誤日志,運行日志特定字符串匹配 |
| 安全監控 | nginx+lua編寫了一個WAF通過kibana可以圖形化的展示不同的攻擊類型的統計 |
| 文件監控 | 監控文件大小、hash值,匹配查詢、字符串存在與否 |
所有監控范疇都可以整合到zabbix中
- 硬件監控:zabbix IPMI interface
- 系統監控:zabbix agent interface
- Java監控:zabbix JMX interface
- 網絡設備監控:zabbix SNMP interface
- 應用服務監控:zabbix agent UserParameter
- MySQL數據庫監控:percona-monitoring-plugins
- URL監控:zabbix web監控
tcp狀態監控
監控腳本
vim /etc/zabbix/scripts/tcp_status.sh
自定義監控項
vim /etc/zabbix/zabbix_agentd.d/tcp.conf
UserParameter=tcp_status[*],/bin/bash /etc/zabbix/scripts/tcp_status.sh “$1”
nginx狀態監控
[root@web03 zabbix_agentd.d]# cat nginx.conf
UserParameter=nginx_status[*],/bin/bash /etc/zabbix/scripts/nginx_status.sh “$1”
cat /etc/zabbix/scripts/nginx_status.sh
#!/bin/bash NGINX_COMMAND=$1 NGINX_PORT=80nginx_active(){/usr/bin/curl -s "http://127.0.0.1:"$NGINX_PORT"/nginx_status/" |awk '/Active/ {print $NF}' }nginx_reading(){/usr/bin/curl -s "http://127.0.0.1:"$NGINX_PORT"/nginx_status/" |awk '/Reading/ {print $2}' }case $NGINX_COMMAND inactive)nginx_active;;;reading)nginx_reading;;;*)echo $"USAGE:$0 {active|reading|writing|waiting|accepts|handled|requests}" esacRedis監控
yum install redis
/etc/redis.conf
requirepass 123456
監聽地址
bind 127.0.0.1
yum install php php-fpm php-mysql php-pdo php-pecl-redis
連接redis
config/config_global.php
[root@web03 ~]# find /code/ -type f |xargs grep -l “discuz.gtimg.cn”
/code/api/manyou/cloud_channel.htm
/code/source/plugin/cloudcaptcha/seccode/seccode_cloudcaptcha.php
/code/source/plugin/cloudsearch/template/module.htm
/code/source/plugin/manyou/Service/DiscuzTips.php
/code/source/plugin/manyou/Service/Doctor.php
查看redis信息
redis-cli -a 123456 info
mkdir -p /etc/zabbix/scripts
vim /etc/zabbix/scripts/redis_status.sh
zabbix 版本升級 2.4遷移 zabbix 3.0
項目背景:由于zabbix2.4 已經停止更新,性能低,界面丑,功能少
項目步驟:
項目實施結果:性能更好
項目背景:zabbix出現性能瓶頸,zabbix圖形出現斷斷續續,zabbix報警延遲
1)針對mysql,寫多讀少 mariadb 5.5 innodb 升級 mysql 5.7 tokudb
2)去掉無用監控項,增加監控項的取值間隔,減少歷史數據保存周期
3)把**被動模式修改為主動模式,**增加zabbix-proxy
4)針對于zabbix-server進程調優,誰忙,就加大它的進程數量
5)針對于zabbix-server緩存調優,誰的剩余內存少,就加大它的緩存值
6)針對zabbix 歷史數據和趨勢圖的表,進行周期性分表
CI/CD
創建項目
general
- 項目名稱
- 參數化構建
源碼管理
配置代碼倉庫地址
構建
編寫shell腳本進行構建(包括配置,編譯,打包,推送,部署)
構建后
- jenkins 連接gitlab API, 通知給gitlab
- 郵件通知
- 釘釘通知
ansible
ansible架構
- user
- inventory
- modules (core modules, custom modules)
- playbook
- plugin
- connection plugin
- public/private
ansible配置文件讀取順序
- ANSIBLE_CONFIG (如果設置了環境變量)
- ansible.cfg (工作目錄中)
- ~/.ansible.cfg (家目錄中)
- /etc/ansible/ansible.cfg
完整的ansible工作目錄
[root@m01 ansible]# ll total 24 -rw-r--r-- 1 root root 20318 Mar 6 12:32 ansible.cfg -rw-r--r-- 1 root root 1015 Jun 17 16:01 hosts drwxr-xr-x 2 root root 32 Jun 17 18:33 inventory drwxr-xr-x 3 root root 41 Jun 17 18:59 playbooks drwxr-xr-x 6 root root 73 Jun 18 09:29 roles ├── ansible.cfg ├── hosts ├── inventory │ ├── part1 │ └── part2 ├── playbooks │ ├── group_vars │ └── nginx.yml └── roles├── common├── nfs├── nginx├── rsync└── site.ymlAd-Hoc
inventory
模塊
playbooks
- hosts
- vars
- tasks
- 模塊
- notify
- handlers
roles
├── nginx │ ├── files │ ├── handlers │ ├── meta (角色依賴) │ ├── tasks │ ├── templates │ └── vars變量
- facts變量
- 主機[組]變量
- roles變量
group_vars/和host_vars/目錄可以存在于playbooks目錄或inventory目錄中。如果兩個路徑都存在,則playbook目錄中的變量將覆蓋inventory目錄中設置的變量
ansible-galaxy
iptables
- iptables主要工作在OSI七層的二、三、四層
iptables 企業應用場景
- 1、主機防火墻(filter表的INPUT鏈)
- 2、局域網共享上網(nat表的POSTROUTING鏈)
- 3、端口及IP(一對一)映射(nat表的PREROUTING鏈)
iptables默認配置
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPTkeepalived 防火墻策略
centos 6下面修改防火墻
vi /etc/sysconfig/iptables 增加這個
centos7下面改防火墻
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface enp4s0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT firewall-cmd --reloadnat 表
-
共享上網
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j SNAT --to-source 10.0.0.5
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE -
端口映射
iptables -t nat -A PREROUTING -d 10.0.0.61 -p tcp --dport 8080 -j DNAT --to-destination 172.16.1.31:22 -
映射多個外網IP上網
iptables -t nat -A POSTROUTING -s 10.0.1.0/255.255.240.0 -o eth0 -j SNAT --to-source 124.42.60.11-124.42.60.16 -
syn-flood攻擊防范
iptables -N syn-flood
iptables -A INPUT -i eth0 -syn -j syn-flood
iptables -A syn-flood -m limit -limit 5000/s -limit-burst 200 -j RETURN
iptables -A syn-flood -j DROP
MySQL
mysql數據庫管理系統構成
1、實例:
mysqld后臺守護進程
線程(master thread+Read thread
write thread)+預分配的內存空間
數據庫管理系統=實例+數據
2、數據
mysqld守護進程的構成及原理
select user,host,password from mysql.user;
mysql -uroot -p123
體系結構
目的:清楚數據庫的工作機制和功能
- C/S
連接層
1、提供通信協議
TCP/IP
socket
2、用戶驗證
用戶的合法性:用戶名(user+host)、密碼(password)------->mysql.user
3、master thread分配一個專用線程(A thread)接收后續的用戶請求(查詢),但并沒有能力直接處理SQL,會將接收到SQL,轉給SQL層繼續處理
SQL層
1、接收上層轉發過來的SQL。
2、語法檢查
3、語義檢查(檢查是什么類型的SQL),以Select為例,檢查到時一個DQL,交給專用的解析器
注:SQL主要包含:DCL、DDL、DML、DQL
3.1、權限驗證
4、解析器 將SQL解析成SQL接口能夠識別方式(執行計劃explain),解析完成后,交給執優化器進行優化
5、優化器,做判斷,選擇一個他認為成本最低執行計劃,交給執行器
6、執行器執行 explain,生成執行結果(去將A個數據文件的第N個數據頁把我需要的數據給我取出來)
7、把執行結果交給下層(存儲引擎層)繼續處理
8、查詢緩存(query_cache)
存儲引擎層
1、接收上層的執行結果
2、取出磁盤文件的相應數據
3、返回給SQL層,結構化之后(生成表格),由專用線程 A thread,返回給客戶端
select user,password from mysql.user where id=1; hash運算后的結果+存儲引擎層返回的結果放到緩存中
select user,password from mysql.user where id=2;
MySQL邏輯結構
- 庫
- 表
- 記錄
- 字段
- 元數據 列+其它屬性
行、頁、區、段
- 行
- 頁(16KB):mysql 存儲最小分配單元 (類似 block)
- 區:一個或多個連續的頁構成
- 段:多個區構成,一張表認為是一個段
索引
主鍵索引
唯一索引
前綴索引
聯合索引
常見索引類型
- index
- range
- ref
- eq_ref
- const
- system
- Null
innodb和myisam的區別:
物理上:
myisam:
cd /application/mysql/data/
[root@db01 mysql]# ls -l user.*
-rw-rw---- 1 mysql mysql 10684 Jun 19 15:32 user.frm
-rw-rw---- 1 mysql mysql 464 Jun 21 17:26 user.MYD
-rw-rw---- 1 mysql mysql 2048 Jun 21 17:49 user.MYI
innodb:
-rw-rw---- 1 mysql mysql 8710 Jun 25 16:25 city.frm
-rw-rw---- 1 mysql mysql 671744 Jun 25 16:25 city.ibd
Innodb 核心特性
- MVCC
- 事務
- 行級鎖
- 熱備份
- Crash Safe Recovery(異常宕機安全恢復)
事務:ACID特性
-
Atomic(原子性)
所有語句作為一個單元全部成功執行或全部取消。 -
Consistent(一致性) (undo)
如果數據庫在事務開始時處于一致狀態,則在執行該事務期間將保留一致狀態。
InnoDB 雙寫緩沖區
InnoDB 崩潰恢復 -
Isolated(隔離性) (鎖和隔離級別)
事務之間不相互影響。 -
Durable(持久性) (redo)
事務成功完成后,所做的所有更改都會準確地記錄在數據庫中。所做的更改不會丟失
多版本并發控制(MVCC)
1)體現在了保證多事務工作期間的,數據查詢不會被阻塞(undo 快照)
2)樂觀鎖的機制(誰先提交誰為準)
Innodb架構
日志
- 錯誤日志
- 二進制日志
- 慢日志
- 一般查詢日志
MySQL備份
- 邏輯備份
myIsam引擎備份
mysqldump -uroot -poldboy123 -S /data/3306/mysql.sock -A -B -R --master-data=2 -x |gzip >/opt/alL__$(date +%F).sql.sql.gz
Innodb引擎備份
mysqldump -A -B -R --triggers -E --master-data=2 --single-transaction |gzip >/opt/alL__$(date +%F).sql.sql.gz
MySQL優化
連接層
max_connections 最大連接數 *********
max_connect_errors 最大錯誤連接數 *******
max_user_connections 最大用戶連接數 *******
skip-name-resolve 跳過域名解析 *******
connect_timeout 連接超時
wait_timeout 等待超時
back_log 可以在堆棧中的連接數量
SQL層
query_cache_size 查詢緩存 — Redis jd — taobao Tair
log_bin=
binlog_format=row
max_binlog_cache_size
max_binlog_size
存儲引擎層
default-storage-engine
innodb_buffer_pool_size **********
innodb_buffer_pool_size=64G (不要超過物理內存的70%,50-65%)
innodb_file_per_table=(1,0) 獨立表空間
innodb_flush_log_at_trx_commit=(0,1,2) ***************
最安全模式:
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
最高性能模式:
innodb_flush_log_at_trx_commit=0
innodb_flush_method=fdatasync
性能與安全,一般偏向于安全
“雙一標準”
innodb_flush_log_at_trx_commit=1
sync_binlog=1
redis
https://blog.csdn.net/wuxingge/article/details/106487649
持久化
- RDB 持久化可以在指定的時間間隔內生成數據集的時間點快照
- AOF 持久化記錄服務器執行的所有寫操作命令
主的關閉持久化
從的上面開啟持久化
數據類型
- 字符串
- 哈希
- 列表
- 集合
- 有序集合
redis事務
0-15 共16個庫
切換庫
select 1
redis 主從復制
1.從節點發送同步請求到主節點
2.主節點接收到從節點的請求之后,做了如下操作
- ?即執?bgsave將當前內存?的數據持久化到磁盤上
- 持久化完成之后,將rdb?件發送給從節點
3.從節點從主節點接收到rdb?件之后,做了如下操作
- 清空??的數據
- 載?從主節點接收的rdb?件到??的內存?
sentinel
Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案,當用Redis做Master-slave的高可用方案時,假如master宕機了,Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換,而Redis-sentinel本身也是一個獨立運行的進程,它能監控多個master-slave集群,發現master宕機后能進行自動切換。
功能
監控(Monitoring): Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒(Notification): 當被監控的某個 Redis 服務器出現問題時, Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移(Automatic failover): 當一個主服務器不能正常工作時, Sentinel 會開始一次自動故障遷移操作, 它會將失效主服務器的其中一個從服務器升級為新的主服務器, 并讓失效主服務器的其他從服務器改為復制新的主服務器; 當客戶端試圖連接失效的主服務器時, 集群也會向客戶端返回新主服務器的地址, 使得集群可以使用新主服務器代替失效服務器
哨兵,實現redis主從高可用
構建1主2從redis主從復制
redis集群
- 運行機制
- 所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.
- 節點的fail是通過集群中超過半數的master節點檢測失效時才生效.
- 客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可
- 把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->key
./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
slots from 1 to 16384
mongodb
https://blog.csdn.net/wuxingge/article/details/106487422
數據邏輯結構
- 數據庫(database) — 庫
- 集合(collection) ---- 表
- 文檔(document) ------ 行
復制集(1主2從)
分片集群
-
mongos 路由
提供對外應用訪問,所有操作均通過mongos執行。一般有多個mongos節點。數據遷移和數據自動平衡 -
config server
存儲集群所有節點、分片數據路由信息。默認需要配置3個ConfigServer節點 -
mongod
存儲應用數據記錄。一般有多個Mongod節點,達到數據分片目的
分片鍵
- 范圍片鍵
- 哈希片鍵
備份工具
-
mongoexport / mongoimport 導出 json 或 csv
-
mongodump和mongorestore bson文件 產生的備份不一定是數據庫的實時快照
spring boot
Spring Boot的哲學就是約定大于配置。既然很多東西都是一樣的,為什么還要去配置。
Spring boot可以離開Spring Cloud獨立使用開發項目,但是Spring Cloud離不開Spring boot,屬于依賴的關系
springcloud
微服務架構集大成者,云計算最佳業務實踐
https://spring.io/projects/spring-cloud
https://www.springcloud.cc/
Spring Cloud Config
Spring
配置管理工具包,讓你可以把配置放到遠程服務器,集中化管理集群配置,目前支持本地存儲、Git以及Subversion。
Spring Cloud Bus
Spring
事件、消息總線,用于在集群(例如,配置變化事件)中傳播狀態變化,可與Spring Cloud Config聯合實現熱部署。
Eureka
Netflix
云端服務發現,一個基于 REST 的服務,用于定位服務,以實現云端中間層服務發現和故障轉移。
Hystrix
Netflix
熔斷器,容錯管理工具,旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
Zuul
Netflix
Zuul 是在云平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當于是設備和 Netflix 流應用的 Web 網站后端所有請求的前門。
Archaius
Netflix
配置管理API,包含一系列配置管理API,提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。
Consul
HashiCorp
封裝了Consul操作,consul是一個服務發現與配置工具,與Docker容器可以無縫集成。
Ribbon
Netflix
提供云端負載均衡,有多種負載均衡策略可供選擇,可配合服務發現和斷路器使用。
Turbine
Netflix
Turbine是聚合服務器發送事件流數據的一個工具,用來監控集群下hystrix的metrics情況。
FastDFS
FastDFS簡介
Fastdfs是一個開源的輕量級分布式文件系統,只能通過專有的api訪問(C,
java,php), 主要解決了海量數據存儲問題,特別適合以文件為主體的在線服務,如相冊的網站,視頻網站,聽書,組成部分:1.由跟蹤服務器(tracker server),2.存儲服務器(storage server)3.客戶端(client)三部分組成,應用場景特別適合中小文件(>4kb <500MB)
FastDFS組成部分
小結:
Tracker-Server
負責保存storager的元信息,以及調度的工作,在訪問上起到了負載均衡的作用,在內存中記錄集群group和storage的狀態信息,Tracker Server的性能非常高,一個大的集群(比如上百個group),一般倆臺就夠了
Storage
數據存儲位置,存儲的時候可以分成多個group,會按照原來的文件方式存儲,只不過追蹤服務器會把文件名重命名,每個group里面的數據都是相同的,相當于read1,各個group是不通信的,追蹤服務器可以起多個
上傳原理
下載原理
nginx 添加第三方模塊 fastdfs-nginx-module
kvm
1:老物理機虛擬化,項目背景,老舊服務器隨時都可以掛掉,性能非常差,功耗大
項目實施步驟:
1:準備好新服務器,安裝好KVM虛擬化管理軟件
2:安裝vmware converter,將物理機轉換成vmware虛擬機
3:導出vmware虛擬機,轉換成kvm虛擬機
4:導入kvm,開機啟動測試
5:測試一段時間之后,下架老服務
項目實施效果:再也不擔心老服務隨時會宕機,后期方便升級配置
2:將ESXI的虛擬機全部遷移到KVM,項目背景,既有ESXI,又有KVM,為了統一管理,方便后期遷移openstack 項目步驟:
1:將ESXI虛擬機導出為OVA文件到指定目錄
2:開始ESXI的ssh服務,使用scp拉取ova文件
3:批量將ova轉換為kvm虛擬機
4:批量修改橋接網卡的名稱
5:批量導入kvm虛擬機
6:批量啟動虛擬機,并測試
項目效果:實現了虛擬機的統一管理,方便后期遷移到openstack私有云平臺
3:將KVM的虛擬機全部遷移到ESXI,項目背景:既有ESXI,又有KVM,為了減少人員維護成本,后期使用vcenter集中管理
項目步驟:
1:批量將kvm虛擬機的磁盤文件轉換為vmdk
2:開始ESXI的ssh服務,使用scp推送vmdk文件到ESXI指定目錄
3:創建一臺空系統的ESXI虛擬機,替換磁盤文件
4:啟動虛擬機測試
5:安裝vcenter,并將ESXI加入到vcenter管理
項目實行效果:使用vcenter集中管理ESXI虛擬機,大大減少人工維護成本
openstack
5:使用openstack管理開發環境和測試環境
項目背景:為了減少運維重復搭建測試環境,為開發提供學習環境
項目步驟:
1:安裝openstack控制節點
2:將所有的測試環境物理服務器安裝計算節點的服務
3:制作各種openstack鏡像
4:為開發創建賬號密碼
5:為所有開發人員培訓openstack的使用方法并編寫使用文檔
項目實行效果:再也不用重復為開發人員搭建開發環境
6:openstack集群服務遷移項目:
項目背景:所有openstack控制節點是一個all-in-one,性能達到瓶頸,需要擴展為集群
項目步驟:
1:將mysql遷移出來,并搭建mysql高可用集群MHA
2:將rabbitmq獨立出來,并搭建rabbitmq集群
3:將鏡像glance服務遷移出來
4:將nova服務遷移出來
5:將neutron服務遷移出來
6:dashboard開啟https
項目實施結果:openstack集群支持的規模更大,更安全
docker
7: 將傳統業務容器化
項目背景:docker容器輕量級,啟動快,性能高,損耗少,更快恢復業務故障
項目實施步驟:
1:安裝部署docker
2:將每一個服務手動制作成docker鏡像
3:使用dockerfile自動構建docker鏡像
4:使用macvlan實現docker容器跨宿主機訪問通信
5:啟動容器,并測試訪問
6:監控每一個容器的狀態(docker stats)docker info
項目實現結果:節省了成本,縮短了故障恢復的時間,方便后期遷移到k8s
8:將docker的私有倉庫Registry遷移到harbor
總結
- 上一篇: 有什么真无线蓝牙耳机推荐?2022蓝牙耳
- 下一篇: uboot启动流程详细分析(基于i.m6