過年回家好多人買了哈弗和眾泰，到底該不該也買一輛？

發佈日期: 2020-12-16 作者: admin

再舉個生動栗子，的朋友陳二狗是一個下水道維修人員，經過幾年的艱苦工作，終於存夠錢買車了，但是不知道買什麼車。然鵝看到了隔壁的老王買了一台新車，外觀挺好看的，坐進去看起來配置也不錯，問一下價格竟然還不貴。

春節回家過年，是我們中國人傳統的習俗。過年除了回家探望親人，最大的目的還是在“炫耀”上，中國人都存在一種攀比的心理，比誰混得更好是春節回家的一個必備項目。汽車是一件“奢飾品”，作為身份的象徵，不少人都會在過年前買一台小汽車，開回老家彰顯身份。

也正是有這樣的“攀比”心理，導致中國人買車變得極度不理性。說實話“沒主見”是最主要的因素之一。因為購車所需要考慮的因素很多，不管你對車輛熟不熟悉，到了真正購車時，購車前所有的準備都煙消雲散，到了4S店你也只會一味地跟着銷售的套路走下去。

為什麼消費者的購車思想都不理性？

影響消費者買車的因素有很多，像車型的品牌、車型的顏值、車型的配置、汽車的售價/優惠幅度、提車時間等，另外消費者們還有一個最為致命的共通點：就是跟風消費。

舉個栗子，就像哈弗H6那樣，每個月都有幾萬的銷量，一年能賣上幾十萬台的車型，難道就真的這麼多人買？那是肯定的，就好比國家在發展，人們的生活質量日益提高，所以不少家庭都開始將購車的計劃提上了議程。相對於一線大城市，在汽車保有量方面已經趨向於飽和甚至是過剩的狀態，所以目前銷售主力主要集中在二三線甚至是更偏的城市，而其中絕大部分的人都是首次購車的消費者。

其實大部分人都是和一樣的普通人，如果不是專業做汽車，也不知道買什麼車才是最好的選擇。對於自己本身來說，大多都是靠自己的努力辛辛苦苦存錢買車，很重視汽車的價格以及優惠幅度。也可以這樣說，如果是比較極端的消費者，在15萬以內的購車預算，兩個相差不大的競品車型，也許是因為某個車型有更多的優惠、價格更低。於是選擇了這台車。

再舉個生動栗子，的朋友陳二狗是一個下水道維修人員，經過幾年的艱苦工作，終於存夠錢買車了，但是不知道買什麼車。然鵝看到了隔壁的老王買了一台新車，外觀挺好看的，坐進去看起來配置也不錯，問一下價格竟然還不貴。再過了两天同村的老李又買了輛一模一樣的車，哇！同村這麼多人都買這車，質量肯定可以了，於是二狗高高興興地又買了一輛，於是他們愉快地創辦了二貨村殺馬特車友會。

其實大家都一樣，往往容易被表面迷惑，買車大多是看外觀數配置，這也是目前眾多車型品牌在追求的一個東西，外觀越來越大氣、配置越來越高，價格也越來越低了。這也是為什麼能夠火了部分喜歡“山寨”的品牌，譬如最近新出的保時泰SR9，10多萬的售價竟然有百萬級SUV的外觀，不僅如此連內飾的設計都有極高的相似度。當然消費者對於保時泰SR9的熱情是非常高的，關鍵是逼格夠高。還得說一下，能不能開上蘭博基尼就得看眾泰了。

只不過買這些車的人在選擇的時候壓根就沒有想過這車的質量到底行不行，至於眾泰這個品牌的質量能不能過關？還是建議去看一下車主的口碑，不是說質量不行，只是車型整體故障率還是比較高的。不過這類山寨車型還有一個好處呀，我還能剩下一大筆的設計費呀！

看得見的地方給到你逼格十足的感覺，但是在看不到不知道的地方就給你各方面的減配，你覺得這樣真的好嗎？為了降低成本，同一個部位的零件，哪個供應商便宜選哪個，就算質量差一點也是沒所謂，這樣的行為見得太多了！當然，這樣的行為不僅出現在國產品牌中，更有出現在合資品牌上。不過厚道的汽車廠家不少，只是消費者們不懂得識別，這也是目前我國消費者在購車方面最大的囧況。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

解Bug之路-記一次存儲故障的排查過程

發佈日期: 2020-12-15 作者: admin

解Bug之路-記一次存儲故障的排查過程

高可用真是一絲細節都不得馬虎。平時跑的好好的系統，在相應硬件出現故障時就會引發出潛在的Bug。偏偏這些故障在應用層的表現稀奇古怪，很難讓人聯想到是硬件出了問題，特別是偶發性出現的問題更難排查。今天，筆者就給大家帶來一個存儲偶發性故障的排查過程。

Bug現場

我們的積分應用由於量非常大，所以需要進行分庫分表，所以接入了我們的中間件。一直穩定運行，但應用最近確經常偶發連接建立不上的報錯。報錯如下:

GetConnectionTimeOutException

而筆者中間件這邊收到的確是:

NIOReactor - register err java.nio.channels.CloasedChannelException

這樣的告警。整個Bug現場如下圖所示:

偶發性錯誤

之前出過類似register err這樣的零星報警，最後原因是安全掃描，並沒有對業務造成任何影響。而這一次，類似的報錯造成了業務的大量連接超時。由於封網，線上中間件和應用已經穩定在線上跑了一個多月，代碼層面沒有任何改動！突然出現的這個錯誤感覺是環境出現了某些問題。而且由於線上的應用和中間件都是集群，出問題時候都不是孤立的機器報錯，沒道理所有機器都正好有問題。如下圖所示:

開始排查是否網絡問題

遇到這種連接超時，筆者最自然的想法當然是網絡出了問題。於是找網工進行排查，
在監控裏面發現網絡一直很穩定。而且如果是網絡出現問題，同一網段的應用應該也都會報錯
才對。事實上只有對應的應用和中間件才報錯，其它的應用依舊穩穩噹噹。

又發生了兩次

就在筆者覺得這個偶發性問題可能不會再出現的時候，又開始抖了。而且是一個下午連抖了兩次。臉被打的啪啪的，算了算了，先重啟吧。重啟中間件后，以為能消停一會，沒想到半個小時之內又報了。看來今天不幹掉這個Bug是下不了班了!

開始排查日誌

事實上，筆者一開始就發現中間件有調用後端數據庫慢SQL的現象，由於比較偶發，所以將這個現象發給DBA之後就沒有繼續跟進,DBA也反饋SQL執行沒有任何異常。筆者開始認真分析日誌之後，發現一旦有中間件的register err 必定會出現中間件調用後端數據庫的sql read timeout的報錯。
但這兩個報錯完全不是在一個線程裏面的，一個是處理前端的Reactor線程，一個是處理後端SQL的Worker線程，如下圖所示:

這兩個線程是互相獨立的，代碼中並沒有發現任何機制能讓這兩個線程互相影響。難道真是這些機器本身網絡出了問題？前端APP失敗，後端調用DB超時，怎麼看都像網絡的問題！

進一步進行排查

既然有DB(數據庫)超時，筆者就先看看調用哪個DB超時吧，畢竟後面有一堆DB。筆者突然發現，和之前的慢SQL一樣，都是調用第二個數據庫超時，而DBA那邊卻說SQL執行沒有任何異常，

筆者感覺明顯SQL執行有問題，只不過DBA是採樣而且將採樣耗時平均的，偶爾的幾筆耗時並不會在整體SQL的耗時裏面有所體現。

只能靠日誌分析了

既然找不到什麼頭緒，那麼只能從日誌入手，好好分析推理了。REACTOR線程和Worker線程同時報錯，但兩者並無特殊的關聯，說明可能是同一個原因引起的兩種不同現象。筆者在線上報錯日誌裏面進行細細搜索，發現在大量的

NIOReactor-1-RW register err java.nio.channels.CloasedChannelException

日誌中會摻雜着這個報錯:

NIOReactor-1-RW Socket Read timed out
	at XXXXXX . doCommit
	at XXXXXX Socket read timedout

這一看就發現了端倪，Reactor作為一個IO線程，怎麼會有數據庫調用呢?於是翻了翻源碼，原來，我們的中間件在處理commit/rollback這樣的操作時候還是在Reactor線程進行的！很明顯Reactor線程卡主是由於commit慢了!筆者立馬反應過來,而這個commit慢也正是導致了regsiter err以及客戶端無法創建連接的元兇。如下面所示:

由於app1的commit特別慢而卡住了reactor1線程，從而落在reactor1線程上的握手操作都會超時！如下圖所示:

為什麼之前的模擬宕機測試發現不了這一點

因為模擬宕機的時候，在事務開始的第一條SQL就會報錯，而執行SQL都是在Worker線程裏面，
所以並不會觸發reactor線程中commit超時這種現象，所以測試的時候就遺漏了這一點。

為什麼commit會變慢?

系統一直跑的好好的，為什麼突然commit就變慢了呢，而且筆者發現，這個commit變慢所關聯的DB正好也是出現慢SQL的那個DB。於是筆者立馬就去找了DBA,由於我們應用層和數據庫層都沒有commit時間的監控(因為一般都很快，很少出現慢的現象)。DBA在數據庫打的日誌裏面進行了統計，發現確實變慢了，而且變慢的時間和我們應用報錯的時間相符合！
順藤摸瓜，我們又聯繫了SA，發現其中和存儲相關的HBA卡有報錯！如下圖所示:

報錯時間都是一致的！

緊急修復方案

由於是HBA卡報錯了，屬於硬件故障，而硬件故障並不是很快就能進行修復的。所以DBA做了一次緊急的主從切換，進而避免這一問題。

一身冷汗

之前就有慢sql慢慢變多，而後突然數據庫存儲hba卡宕機導致業務不可用的情況。
而這一次到最後主從切換前為止，報錯越來越頻繁，感覺再過一段時間,HBA卡過段時間就完全不可用，重蹈之前的覆轍了！

中間件修復

我們在中間件層面將commit和rollback操作挪到Worker裏面。這樣，commit如果卡住就不再會引起創建連接失敗這種應用報錯了。

總結

由於軟件層面其實是比較信任硬件的，所以在硬件出問題時，就會產生很多詭異的現象，而且和硬件最終的原因在表面上完全產生不了關聯。只有通過抽絲剝繭，慢慢的去探尋現象的本質才會解決最終的問題。要做到高可用真的是要小心評估各種細節，才能讓系統更加健壯！

公眾號

關注筆者公眾號，獲取更多乾貨文章:

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

Netty 中的內存分配淺析

發佈日期: 2020-12-15 作者: admin

Netty 出發點作為一款高性能的 RPC 框架必然涉及到頻繁的內存分配銷毀操作，如果是在堆上分配內存空間將會觸發頻繁的GC，JDK 在1.4之後提供的 NIO 也已經提供了直接直接分配堆外內存空間的能力，但是也僅僅是提供了基本的能力，創建、回收相關的功能和效率都很簡陋。基於此，在堆外內存使用方面，Netty 自己實現了一套創建、回收堆外內存池的相關功能。基於此我們一起來看一下 Netty 是如何實現內存分配的。

1. Netty 中的數據容器分類

談到數據保存肯定要說到內存分配，按照存儲空間來劃分，可以分為堆內存和堆外內存；按照內存區域連貫性來劃分可以分為池化內存和非池化內存。這些劃分在 Netty 中的實現接口分別是：

按照底層存儲空間劃分：

堆緩衝區：HeapBuffer；
直接緩衝區：DirectBuffer。

按照是否池化劃分：

池化：PooledBuffer；
非池化：UnPooledBuffer。

默認使用 PoolDireBuf 類型的內存, 這些內存主要由 PoolArea 管理。另外 Netty 並不是直接對外暴露這些 API，提供了 Unsafe 類作為出口暴露數據分配的相關操作。

小知識：

什麼是池化？

一般申請內存是檢查當前內存哪裡有適合當前數據塊大小的空閑內存塊，如果有就將數據保存在當前內存塊中。

那麼池化想做的事情是：既然每次來數據都要去找內存地址來存，我就先申請一塊內存地址，這一塊就是我的專用空間，內存分配、回收我全權管理。

池化解決的問題：

內存碎片：

內碎片

內碎片就是申請的地址空間大於真正數據使用的內存空間。比如固定申請1M的空間作為某個線程的使用內存，但是該線程每次最多只佔用0.5M，那麼每次都有0.5M的碎片。如果該空間不被有效回收時間一長必然存在內存空洞。

外碎片

外碎片是指多個內存空間合併的時候發現不夠分配給待使用的空間大小。比如有一個 20byte，13byte 的連續內存空間可以被回收，現在有一個 48byte 的數據塊需要存儲，而這兩個加起來也只有 33byte 的空間，必然不會被使用到。

如何實現內存池？

鏈表維護空閑內存地址

最簡單的就是弄一個鏈表來維護當前空閑的內存空間地址。如果有使用就從鏈表刪除，有釋放就加入鏈表對應位置。這種方式實現簡單，但是搜索和釋放內存維護的難度還是比較大，不太適合。
定長內存空間分配

維護兩個列表，一個是未分配內存列表，一個是已分配內存列表。每個內存塊都是一樣大小，分配時如果不夠就將多個塊合併到一起。這種方式的缺點就是會浪費一定的內存空間，如果有特定的場景還是沒有問題。
多段定長池分配

在上面的定長分配基礎上，由原來的固定一個長度分配空間變為按照不同對象大小(8，16，32，64，128，256，512，1k…64K)，的方式分配多個固定大小的內存池。每次要申請內存的時候按照當前對象大小去對應的池中查找是否有剩餘空間。

Linux 本身支持動態內存分配和釋放，對應的命令為：malloc/free。malloc 的全稱是 memory allocation，中文叫動態內存分配，用於申請一塊連續的指定大小的內存塊區域以void*類型返回分配的內存區域地址。

malloc / free的實現過程：
1. 空閑存儲空間以空閑鏈表的方式組織（地址遞增），每個塊包含一個長度、一個指向下一塊的指針以及一個指向自身存儲空間的指針。（因為程序中的某些地方可能不通過 malloc 調用申請，因此 malloc 管理的空間不一定連續）
2. 當有申請請求時，malloc 會掃描空閑鏈表，直到找到一個足夠大的塊為止（首次適應）(因此每次調用malloc 時並不是花費了完全相同的時間）
3. 如果該塊恰好與請求的大小相符，則將其從鏈表中移走並返回給用戶。如果該塊太大，則將其分為兩部分，尾部的部分分給用戶，剩下的部分留在空閑鏈表中（更改頭部信息）。因此 malloc 分配的是一塊連續的內存。
4. 釋放時首先搜索空閑鏈表，找到可以插入被釋放塊的合適位置。如果與被釋放塊相鄰的任一邊是一個空閑塊，則將這兩個塊合為一個更大的塊，以減少內存碎片。

2. Netty 中的內存分配

Netty 採用了 jemalloc 的思想，這是 FreeBSD 實現的一種併發 malloc 的算法。jemalloc 依賴多個 Arena(分配器) 來分配內存，運行中的應用都有固定數量的多個 Arena，默認的數量與處理器的個數有關。系統中有多個 Arena 的原因是由於各個線程進行內存分配時競爭不可避免，這可能會極大的影響內存分配的效率，為了緩解高併發時的線程競爭，Netty 允許使用者創建多個分配器（Arena）來分離鎖，提高內存分配效率。

線程首次分配/回收內存時，首先會為其分配一個固定的 Arena。線程選擇 Arena 時使用 round-robin 的方式，也就是順序輪流選取。

每個線程各種保存 Arena 和緩存池信息，這樣可以減少競爭並提高訪問效率。Arena 將內存分為很多 Chunk 進行管理，Chunk 內部保存 Page，以頁為單位申請。申請內存分配時，會將分配的規格分為幾類：TINY，SAMLL，NORMAL 和 HUGE，分別對應不同的範圍，處理過程也不相同。

tiny 代表了大小在 0-512B 的內存塊；

small 代表了大小在 512B-8K 的內存塊；

normal 代表了大小在 8K-16M 的內存塊；

huge 代表了大於 16M 的內存塊。

每個塊裏面又定義了更細粒度的單位來分配數據：

Chunk：一個 Chunk 的大小是 16M，Chunk 是 Netty 對操作系統進行內存申請的單位，後續所有的內存分配都是在 Chunk 裏面進行操作。
Page：Chunk 內部以 Page 為單位分配內存，一個 Page 大小為 8K。當我們需要 16K 的空間時，Netty 就會從一個 Chunk 中找到兩個 Page 進行分配。
Subpage 和 element：element 是比 Page 更小的單位，當我們申請小於 8K 的內存時，Netty 會以 element 為單位進行內存分配。element 沒有固定大小，具體由用戶的需求決定。Netty 通過 Subpage 管理 element，Subpage 是由 Page 轉變過來的。當我們需要 1K 的空間時，Netty 會把一個 Page 變成 Subpage，然後把 Subpage 分成 8 個 1K 的 element 進行分配。

Chunk 中的內存分配

線程分配內存主要從兩個地方分配: PoolThreadCache 和 Arena。其中 PoolThreadCache 線程獨享, Arena 為幾個線程共享。

初次申請內存的時候，Netty 會從一整塊內存（Chunk）中分出一部分來給用戶使用，這部分工作是由 Arena 來完成。而當用戶使用完畢釋放內存的時候，這些被分出來的內存會按不同規格大小放在 PoolThreadCache 中緩存起來。當下次要申請內存的時候，就會先從 PoolThreadCache 中找。

Chunk、Page、Subpage 和 element 都是 Arena 中的概念，Arena 的工作就是從一整塊內存中分出合適大小的內存塊。Arena 中最大的內存單位是 Chunk，這是 Netty 向操作系統申請內存的單位。而一塊 Chunk（16M）申請下來之後，內部會被分成 2048 個 Page（8K），當用戶向 Netty 申請超過 8K 內存的時候，Netty 會以 Page 的形式分配內存。

Chunk 內部通過夥伴算法管理 Page，具體實現為一棵完全平衡二叉樹：

二叉樹中所有子節點管理的內存也屬於其父節點。當我們要申請大小為 16K 的內存時，我們會從根節點開始不斷尋找可用的節點，一直到第 10 層。那麼如何判斷一個節點是否可用呢？Netty 會在每個節點內部保存一個值，這個值代表這個節點之下的第幾層還存在未分配的節點。比如第 9 層的節點的值如果為 9，就代表這個節點本身到下面所有的子節點都未分配；如果第 9 層的節點的值為 10，代表它本身不可被分配，但第 10 層有子節點可以被分配；如果第 9 層的節點的值為 12，此時可分配節點的深度大於了總深度，代表這個節點及其下面的所有子節點都不可被分配。下圖描述了分配的過程：

對於小內存（小於4096）的分配還會將 Page 細化成更小的單位 Subpage。Subpage 按大小分有兩大類：

Tiny：小於 512 的情況，最小空間為 16，對齊大小為 16，區間為[16,512)，所以共有 32 種情況。
Small：大於等於 512 的情況，總共有四種，512,1024,2048,4096。

PoolSubpage 中直接採用位圖管理空閑空間（因為不存在申請 k 個連續的空間），所以申請釋放非常簡單。

第一次申請小內存空間的時候，需要先申請一個空閑頁，然後將該頁轉成 PoolSubpage，再將該頁設為已被佔用，最後再把這個 PoolSubpage 存到 PoolSubpage 池中。這樣下次就不需要再去申請空閑頁了，直接去池中找就好了。Netty 中有 36 種 PoolSubpage，所以用 36 個 PoolSubpage 鏈表表示 PoolSubpage 池。

因為單個 PoolChunk 只有 16M，這遠遠不夠用，所以會很很多很多 PoolChunk，這些 PoolChunk 組成一個鏈表，然後用 PoolChunkList 持有這個鏈表。

我們先從內存分配器 PoolArena 來分析 Netty 中的內存是如何分配的，Area 的工作就是從一整塊內存中協調如何分配合適大小的內存給當前數據使用。PoolArena 是 Netty 的內存池實現抽象類，其內部子類為 HeapArena 和 DirectArena，HeapArena 對應堆內存（heap buffer），DirectArena 對應堆外直接內存(direct buffer)，兩者除了操作的內存（byte[]和ByteBuffer）不同外其餘完全一致。

從結構上來看，PoolArena 中主要包含三部分子內存池：

tinySubpagePools；

smallSubpagePools；

一系列的 PoolChunkList。

tinySubpagePools 和 smallSubpagePools 都是 PoolSubpage 的數組，數組長度分別為 32 和 4。

PoolChunkList 則主要是一個容器，其內部可以保存一系列的 PoolChunk 對象，並且，Netty 會根據內存使用率的不同，將 PoolChunkList 分為不同等級的容器。

abstract class PoolArena<T> implements PoolArenaMetric {

   enum SizeClass {
        Tiny,
        Small,
        Normal
    }
  // 該參數指定了tinySubpagePools數組的長度，由於tinySubpagePools每一個元素的內存塊差值為16，
	// 因而數組長度是512/16，也即這裏的512 >>> 4
  static final int numTinySubpagePools = 512 >>> 4;
	//表示該PoolArena的allocator
  final PooledByteBufAllocator parent;
  //表示PoolChunk中由Page節點構成的二叉樹的最大高度，默認11
  private final int maxOrder;
  //page的大小，默認8K
  final int pageSize;
  // 指定了恭弘=叶 恭弘節點大小8KB是2的多少次冪，默認為13，該字段的主要作用是，在計算目標內存屬於二叉樹的
	// 第幾層的時候，可以藉助於其內存大小相對於pageShifts的差值，從而快速計算其所在層數
  final int pageShifts;
  //默認16MB
  final int chunkSize;
  // 由於PoolSubpage的大小為8KB=8196，因而該字段的值為
	// -8192=>=> 1111 1111 1111 1111 1110 0000 0000 0000
	// 這樣在判斷目標內存是否小於8KB時，只需要將目標內存與該数字進行與操作，只要操作結果等於0，
	// 就說明目標內存是小於8KB的，這樣就可以判斷其是應該首先在tinySubpagePools或smallSubpagePools
	// 中進行內存申請
  final int subpageOverflowMask;
  // 該參數指定了smallSubpagePools數組的長度，默認為4
  final int numSmallSubpagePools;
  //tinySubpagePools用來分配小於512 byte的Page
  private final PoolSubpage<T>[] tinySubpagePools;
  //smallSubpagePools用來分配大於等於512 byte且小於pageSize內存的Page
  private final PoolSubpage<T>[] smallSubpagePools;
  //用來存儲用來分配給大於等於pageSize大小內存的PoolChunk
  //存儲內存利用率50-100%的chunk
  private final PoolChunkList<T> q050;
  //存儲內存利用率25-75%的chunk
  private final PoolChunkList<T> q025;
  //存儲內存利用率1-50%的chunk
  private final PoolChunkList<T> q000;
  //存儲內存利用率0-25%的chunk
  private final PoolChunkList<T> qInit;
  //存儲內存利用率75-100%的chunk
  private final PoolChunkList<T> q075;
  //存儲內存利用率100%的chunk
  private final PoolChunkList<T> q100;
	//堆內存(heap buffer)
  static final class HeapArena extends PoolArena<byte[]> {
  
  }
   //堆外直接內存(direct buffer)
  static final class DirectArena extends PoolArena<ByteBuffer> {
    
  }
  
  
}

如上所示，PoolArena 是由多個 PoolChunk 組成的大塊內存區域，而每個 PoolChun k則由多個 Page 組成。當需要分配的內存小於 Page 的時候，為了節約內存採用 PoolSubpage 實現小於 Page 大小內存的分配。在PoolArena 中為了保證 PoolChunk 空間的最大利用化，按照 PoolArena 中各個PoolChunk 已使用的空間大小將其劃分為 6 類：

qInit：存儲內存利用率 0-25% 的 chunk；
q000：存儲內存利用率 1-50% 的 chunk；
q025：存儲內存利用率 25-75% 的 chunk；
q050：存儲內存利用率 50-100% 的 chunk；
q075：存儲內存利用率 75-100%的 chunk；
q100：存儲內存利用率 100%的 chunk。

PoolArena 維護了一個 PoolChunkList 組成的雙向鏈表，每個 PoolChunkList 內部維護了一個 PoolChunk 雙向鏈表。分配內存時，PoolArena 通過在 PoolChunkList 找到一個合適的 PoolChunk，然後從 PoolChunk 中分配一塊內存。

下面來看 PoolArena 是如何分配內存的：

private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
  // 將需要申請的容量格式為 2^N
  final int normCapacity = normalizeCapacity(reqCapacity);
  // 判斷目標容量是否小於8KB，小於8KB則使用tiny或small的方式申請內存
  if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
    int tableIdx;
    PoolSubpage<T>[] table;
    boolean tiny = isTiny(normCapacity);
    // 判斷目標容量是否小於512字節，小於512字節的為tiny類型的
    if (tiny) { // < 512
      // 將分配區域轉移到 tinySubpagePools 中
      if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      // 如果無法從當前線程緩存中申請到內存，則嘗試從tinySubpagePools中申請，這裏tinyIdx()方法
      // 就是計算目標內存是在tinySubpagePools數組中的第幾號元素中的
      tableIdx = tinyIdx(normCapacity);
      table = tinySubpagePools;
    } else {
      // 如果目標內存在512byte~8KB之間，則嘗試從smallSubpagePools中申請內存。這裏首先從
      // 當前線程的緩存中申請small級別的內存，如果申請到了，則直接返回
      if (cache.allocateSmall(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      tableIdx = smallIdx(normCapacity);
      table = smallSubpagePools;
    }
		// 獲取目標元素的頭結點
    final PoolSubpage<T> head = table[tableIdx];

    // 這裏需要注意的是，由於對head進行了加鎖，而在同步代碼塊中判斷了s != head，
    // 也就是說PoolSubpage鏈表中是存在未使用的PoolSubpage的，因為如果該節點已經用完了，
    // 其是會被移除當前鏈表的。也就是說只要s != head，那麼這裏的allocate()方法
    // 就一定能夠申請到所需要的內存塊
    synchronized (head) {
      // s != head就證明當前PoolSubpage鏈表中存在可用的PoolSubpage，並且一定能夠申請到內存，
      // 因為已經耗盡的PoolSubpage是會從鏈表中移除的
      final PoolSubpage<T> s = head.next;
      // 如果此時 subpage 已經被分配過內存了執行下文，如果只是初始化過，則跳過該分支
      if (s != head) {
        // 從PoolSubpage中申請內存
        assert s.doNotDestroy && s.elemSize == normCapacity;
        // 通過申請的內存對ByteBuf進行初始化
        long handle = s.allocate();
        assert handle >= 0;
        // 初始化 PoolByteBuf 說明其位置被分配到該區域，但此時尚未分配內存
        s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
				// 對tiny類型的申請數進行更新
        if (tiny) {
          allocationsTiny.increment();
        } else {
          allocationsSmall.increment();
        }
        return;
      }
    }
    // 走到這裏，說明目標PoolSubpage鏈表中無法申請到目標內存塊，因而就嘗試從PoolChunk中申請
    allocateNormal(buf, reqCapacity, normCapacity);
    return;
  }
   // 走到這裏說明目標內存是大於8KB的，那麼就判斷目標內存是否大於16M，如果大於16M，
  // 則不使用內存池對其進行管理，如果小於16M，則到PoolChunkList中進行內存申請
  if (normCapacity <= chunkSize) {
    // 小於16M，首先到當前線程的緩存中申請，如果申請到了則直接返回，如果沒有申請到，
    // 則到PoolChunkList中進行申請
    if (cache.allocateNormal(this, buf, reqCapacity, normCapacity)) {
      // was able to allocate out of the cache so move on
      return;
    }
    allocateNormal(buf, reqCapacity, normCapacity);
  } else {
    // 對於大於16M的內存，Netty不會對其進行維護，而是直接申請，然後返回給用戶使用
    allocateHuge(buf, reqCapacity);
  }
}

所有內存分配的 size 都會經過 normalizeCapacity() 進行處理，申請的容量總是會被格式為 2^N。主要規則如下：

如果目標容量小於 16 字節，則返回 16；
如果目標容量大於 16 字節，小於 512 字節，則以 16 字節為單位，返回大於目標字節數的第一個 16 字節的倍數。比如申請的 100 字節，那麼大於 100 的 16 整數倍最低為： 16 * 7 = 112，因而返回 112；
如果目標容量大於 512 字節，則返回大於目標容量的第一個 2 的指數冪。比如申請的 1000 字節，那麼返回的將是：2^10 = 1024。

PoolArena 提供了兩種方式進行內存分配：

PoolSubpage 用於分配小於 8k 的內存
- tinySubpagePools：用於分配小於 512 字節的內存，默認長度為 32，因為內存分配最小為 16，每次增加16，直到512，區間[16，512)一共有 32 個不同值；
- smallSubpagePools：用於分配大於等於 512 字節的內存，默認長度為 4；

tinySubpagePools 和 smallSubpagePools 中的元素默認都是 subpage。

poolChunkList 用於分配大於 8k 的內存

上面已經解釋了 q 開頭的幾個變量用於保存大於 8k 的數據。

默認先嘗試從 poolThreadCache 中分配內存，PoolThreadCache 利用 ThreadLocal 的特性，消除了多線程競爭，提高內存分配效率；

首次分配時，poolThreadCache 中並沒有可用內存進行分配，當上一次分配的內存使用完並釋放時，會將其加入到 poolThreadCache 中，提供該線程下次申請時使用。

如果是分配小內存，則嘗試從 tinySubpagePools 或 smallSubpagePools 中分配內存，如果沒有合適 subpage，則採用方法 allocateNormal 分配內存。

如果分配一個 page 以上的內存，直接採用方法 allocateNormal() 分配內存，allocateNormal()則會將申請動作交由 PoolChunkList 進行。

private synchronized void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
  //如果在對應的PoolChunkList能申請到內存，則返回
  if (q050.allocate(buf, reqCapacity, normCapacity) || q025.allocate(buf, reqCapacity, normCapacity) ||
      q000.allocate(buf, reqCapacity, normCapacity) || qInit.allocate(buf, reqCapacity, normCapacity) ||
      q075.allocate(buf, reqCapacity, normCapacity)) {
    ++allocationsNormal;
    return;
  }

  // Add a new chunk.
  PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);
  long handle = c.allocate(normCapacity);
  ++allocationsNormal;
  assert handle > 0;
  c.initBuf(buf, handle, reqCapacity);
  qInit.add(c);
}

首先將申請動作按照 q050->q025->q000->qInit->q075 的順序依次交由各個 PoolChunkList 進行處理，如果在對應的 PoolChunkList 中申請到了內存，則直接返回。

如果申請不到，那麼直接創建一個新的 PoolChunk，然後在該 PoolChunk 中申請目標內存，最後將該 PoolChunk 添加到 qInit 中。

上面說過 Chunk 是 Netty 向操作系統申請內存塊的最大單位，每個 Chunk 是16M，PoolChunk 內部通過 memoryMap 數組維護了一顆完全平衡二叉樹作為管理底層內存分佈及回收的標記位，所有的子節點管理的內存也屬於其父節點。

關於 PoolChunk 內部如何維護完全平衡二叉樹就不在這裏展開，大家有興趣可以自行看源碼。

對於內存的釋放，PoolArena 主要是分為兩種情況，即池化和非池化，如果是非池化，則會直接銷毀目標內存塊，如果是池化的，則會將其添加到當前線程的緩存中。如下是 free()方法的源碼：

public void free(PoolChunk<T> chunk, ByteBuffer nioBuffer, long handle, int normCapacity,
     PoolThreadCache cache) {
  // 如果是非池化的，則直接銷毀目標內存塊，並且更新相關的數據
  if (chunk.unpooled) {
    int size = chunk.chunkSize();
    destroyChunk(chunk);
    activeBytesHuge.add(-size);
    deallocationsHuge.increment();
  } else {
    // 如果是池化的，首先判斷其是哪種類型的，即tiny，small或者normal，
    // 然後將其交由當前線程的緩存進行處理，如果添加成功，則直接返回
    SizeClass sizeClass = sizeClass(normCapacity);
    if (cache != null && cache.add(this, chunk, nioBuffer, handle,
          normCapacity, sizeClass)) {
      return;
    }

    // 如果當前線程的緩存已滿，則將目標內存塊返還給公共內存塊進行處理
    freeChunk(chunk, handle, sizeClass, nioBuffer);
  }
}

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

分享我在前後端分離項目中Gitlab-CI的經驗

發佈日期: 2020-12-15 作者: admin

長話短說，今天分享我為前後端分離項目搭建Gitlab CI/CD流程的一些額外經驗。

Before

Gitlab-ci是Gitlab提供的CI/CD特性，結合Gitlab簡單友好的配置界面，能愉悅的在Gitlab界面查看管道執行流程，並自然流暢的推動敏捷開發流程。
Gitlab-CI/CD的核心是搭建Gitlab Runner、編寫.gitlab-ci.yaml文件。
詳細示例請參考：Gitlab CI/CD+ASP.NETCore.

本次前後端兩個項目使用同一個Gitlab Runner(shell模式)，前端項目的gitlab-ci.yaml構建Job如圖：

Round 1

單個Gitlab Runner可為多個項目提供構建服務，

gitlab-Runner register命令只能接受一個註冊token，當時為支持多個項目，花了不少冤枉心思倒騰Gitlab Runner.

你可以為註冊的項目解鎖Runner，這樣Girlab Runner就可以為其他項目提供構建：

Round 2

使用Runner緩存加快前端構建過程
大家都知道npm_module被前端開發者詬病為毒瘤，而Gitlab runner執行每次構建job之前都會清場，pull/fetch指定的代碼再執行job, 這就導致每次build job會耗時很久(要拉取毒瘤)。

#!/bin/bash

cd   packages/event-analysis
yarn config set registry http://registry.npm.gridsum.com &&  yarn --prefer-offline --frozen-lockfile
npm run build

以上是build任務的腳本frontend.sh，總耗時3m33s，其中yarn命令拉取npm_modules耗時172.52s

gitlab runner支持緩存
在.gitlab-ci.yaml 文件中定義cache指令:
cache被用來在job之間緩存文件，更強大的是可以定義文件依賴緩存：

build:
  stage: build
  cache:
    key:
      files:
        - packages/event-analysis/package.json
    paths:
      - node_modules
  script: 
    - ./frontend.sh
  tags:
    - my-tag

緩存key是yarn命令要用到的package.json，緩存內容是npm_modules;
只要這個package.json文件未變更，後續任務就會使用緩存的npm_modules，而不用重建npm_modules依賴。

使用runner緩存優化后build任務總耗時1m18s，其中yarn命令耗時22.83s:

以上針對Gitlab-CI的使用經驗點到為止，足夠應對我當前項目，更多請關注：

Reference

https://docs.gitlab.com/ee/ci/runners/#prevent-a-specific-runner-from-being-enabled-for-other-projects
https://docs.gitlab.com/ee/ci/caching/

Devops的圈子很大，上面的Gitlab-ci也只是點到為止，應付我當前的前後端分離項目.. 歡迎大家來捶我。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

博客園自用主題美化 – Light

發佈日期: 2020-12-15 作者: admin

事件背景

之前做過幾個主題，但是都有些看膩了，然後就想着啥時候重構一下，於是就有了現在的新樣式：

https://github.com/KU4NG/CNBLOG-Theme-Light

當然，如果你對之前的感興趣，也可以查看之前的分享：

https://github.com/KU4NG/CNBlog-Theme

裡面包含幾個主題，但是我是有些懶得維護了，太忙了，感興趣的自己去改改 CSS 就行了！

新主題配置方法

1. 基礎配置：

前往博客園設置頁面，就行配置，需要注意的是：

a. 博客標題就是最終你博客的 logo，所以選你喜歡的。

b. 我博客標題中的來自 windows 10 系統輸入法旁邊的表情。

c. 基礎主題選：SimpleMemory，這一步很重要，因為我得樣式都是根據該主題的 HTML 結構寫的。

2. 配置樣式：

將本文中提供的 CSS 代碼或者 github 上面 css 目錄下 style.css 文件中的內容粘貼到此處。

*{margin:0;padding:0;font-weight:normal;letter-spacing:1.5px;font-family:PingFangSC-Regular,HelveticaNeue-Light,'Helvetica Neue Light','Microsoft YaHei',sans-serif,Simsun}div{border-radius:0!important}a{text-decoration:none!important}a:link{text-decoration:none!important}a:visited{text-decoration:none!important}a:hover{text-decoration:none!important}a:active{text-decoration:none!important}body{background-color:#eee}#header{min-width:1200px;height:50px;width:100%;display:block;background-color:white;box-shadow:0 1px 2px 0 rgba(0,0,0,.05)}#header *{color:#333!important}#header h1{float:left;width:200px;padding-left:20px}#header h1 a{height:46px;line-height:46px;font-size:18px!important;font-weight:bolder!important;letter-spacing:3px!important}#header #lnkBlogLogo{display:none}#header h2{display:none}#header li{list-style:none;float:right;height:50px;line-height:50px;position:relative}#header li:hover{cursor:pointer}#header li a{font-size:12px;letter-spacing:2px;padding:0 20px}#header li a::before,#header li a::after{position:absolute;top:0;right:0;bottom:0;left:0;content:'';opacity:0;pointer-events:none;-webkit-transition:opacity .4s,-webkit-transform .4s;transition:opacity .4s,transform .4s}#header li a::before{border-top:2px solid #333;-webkit-transform:scale(0,1);transform:scale(0,1)}#header li:hover a::before,#header li:hover a::after{opacity:1;-webkit-transform:scale(1);transform:scale(1)}#header .blogStats{display:none}#header #navigator{margin-right:200px}#sidebar_search{display:block;width:200px;position:absolute;top:0;right:0;height:48px;line-height:48px}#sidebar_search h3{display:none}#sidebar_search .div_my_zzk{margin-top:0;margin-bottom:0}#sidebar_search .input_my_zzk{display:inline-block;vertical-align:middle;padding:0 10px;border:0;cursor:text;font-size:12px}#sidebar_search .btn_my_zzk{background-color:#009688;color:#fff!important;white-space:nowrap;text-align:center;cursor:pointer;padding-left:10px;padding-right:10px}#sidebar_search input:focus{outline:0}#sidebar_search input{outline:0;border:0}#main{width:1200px;margin:10px auto}#main #mainContent{width:960px;background-color:white;padding:20px;float:left}#main #mainContent .day{position:relative;border:1px dashed lightgrey;padding:15px;margin:0 0 15px 0}#main #mainContent .day .dayTitle{position:absolute;top:-1px;right:-1px;background-color:#eee;width:110px;text-align:right;padding:0 10px 3px 10px}#main #mainContent .day .dayTitle a{font-size:12px;color:#333;opacity:.6}#main #mainContent .day .postTitle a{position:relative;left:-18px;border-left:4px solid #dc3545;padding-left:20px;font-size:18px;font-weight:bolder!important;color:#333}#main .postTitle span{font-weight:bolder!important}#main #mainContent .day .postTitle a:hover{color:#036}#main #mainContent .day .postCon{padding:10px}#main #mainContent .day .postCon .c_b_p_desc{font-size:12px;letter-spacing:2px;opacity:.6;line-height:2;width:900px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}#main #mainContent .day .postDesc{font-size:12px;opacity:.6;text-align:right}#main #mainContent .day .postDesc a{font-size:12px;color:#dc3545}#main #mainContent .day .postSeparator{height:15px;border-top:1px dashed lightgrey;border-bottom:1px dashed lightgrey;border-left:2px solid white;border-right:2px solid white;margin:15px -17px}#main #mainContent #nav_next_page a{font-size:12px;color:#333}#main #mainContent .topicListFooter{margin-right:0}#main #mainContent .pager{font-size:12px;color:#dc3545;text-align:right}#main #mainContent .pager a{font-size:12px;color:gray;border:1px solid lightgray}#main #mainContent #homepage_top_pager{display:none}#sideBar{width:200px;float:right}#sideBar #sideBarMain{width:190px;float:right}#sideBar #sideBarMain *{color:#333;font-size:12px;letter-spacing:2px}#sideBar #sideBarMain #sidebar_news{background-color:white}#sideBar #sideBarMain #sidebar_news h3{background-color:#dc3545;color:white;border-bottom:1px solid #eee;padding:5px 15px;font-size:14px}#sideBar #sideBarMain #sidebar_news #blog-news{padding:15px 15px 0 15px}#sideBar #sideBarMain #sidebar_news #blog-news *{line-height:25px}#sideBar #sideBarMain #sidebar_news #blog-news #profile_block{margin-top:0}#sideBar #sideBarMain #sidebar_categories{background-color:white}#sideBar #sideBarMain #sidebar_categories h3{padding:20px 15px 5px 15px}#sideBar #sideBarMain #sidebar_categories ul{list-style:none;counter-reset:headings;padding:0 15px 15px 15px}#sideBar #sideBarMain #sidebar_categories ul li{line-height:30px;border-bottom:1px dashed #eee}#sideBar #sideBarMain #sidebar_categories ul li:before{counter-increment:headings;content:counter(headings,decimal) ".";font-family:"Bree Serif",serif}#sideBar #sideBarMain #sidebar_categories ul li a{letter-spacing:1px}#sideBar #sideBarMain #sidebar_categories ul li a:hover{color:#dc3545}#footer{font-size:12px;text-align:center;line-height:25px;margin-top:20px;margin-bottom:20px;color:#036}
#footer br{display:none}#main #mainContent .entrylist h1{font-size:18px;font-weight:bolder;text-align:center;margin-top:15px;margin-bottom:30px}#main #mainContent .entrylistItem{position:relative;border:1px dashed lightgrey;padding:15px;margin:0 0 15px 0}#main #mainContent .entrylistItem .entrylistPosttitle a{position:relative;left:-18px;border-left:4px solid #dc3545;padding-left:20px;font-size:18px;font-weight:bolder;color:#333}#main #mainContent .entrylistItem .entrylistPosttitle a:hover{color:#036}#main .entrylistPosttitle span{font-weight:bolder}#main #mainContent .entrylistItem .entrylistPostSummary{padding:10px}#main #mainContent .entrylistItem .entrylistPostSummary .c_b_p_desc{font-size:12px;letter-spacing:2px;opacity:.6;line-height:2;width:900px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}#main #mainContent .entrylistItem .entrylistItemPostDesc{font-size:12px;opacity:.6;text-align:right}#main #mainContent .entrylistItem .entrylistItemPostDesc a{font-size:12px;color:#dc3545}#main #post_detail{padding:30px;position:relative}#main #post_detail .postTitle{padding:0 0 50px 0;text-align:center;border-bottom:1px dotted #ccc}#main #post_detail .postTitle a{font-size:20px;color:#333;font-weight:bolder}#main #post_detail .postDesc{position:absolute;width:calc(100% - 60px);top:85px;text-align:center}#main #post_detail .postDesc{font-size:12px;line-height:25px;color:#333;opacity:.7}#main #post_detail .postDesc *{font-size:12px;color:#333;opacity:.7}#main #post_detail .postBody #cnblogs_post_body{margin-top:30px;padding:15px}#main #post_detail .postBody #cnblogs_post_body p,#main #post_detail .postBody #cnblogs_post_body span{letter-spacing:1.5px;line-height:30px;font-size:14px;font-family:SimHei;margin:0;opacity:.9}#main #post_detail .postBody #cnblogs_post_body img{margin:15px 0;max-width:880px}#main #post_detail .postBody #cnblogs_post_body table{width:100%;margin:15px 0}#main #post_detail .postBody #cnblogs_post_body table *{font-size:12px}#main #post_detail .postBody #cnblogs_post_body table th{padding:6px 10px!important;text-align:left;background-color:#1c2b36;color:white;border-color:#1c2b36}#main #post_detail .postBody #cnblogs_post_body table td{padding:6px 10px!important;text-align:left}#main #post_detail .postBody #cnblogs_post_body .cnblogs_code{padding:15px 20px;border:0}#main #post_detail .postBody #cnblogs_post_body .cnblogs_code_toolbar{display:none}#main #post_detail .postBody #cnblogs_post_body blockquote{border:0;background-color:#eee;border-left:5px solid #009688}#main #post_detail .postBody #cnblogs_post_body blockquote *{font-size:12px;color:#333}#main #post_detail .postBody #blog_post_info_block{padding:15px}#main #post_detail .postBody #blog_post_info_block *{font-size:12px;color:#333}#main #post_detail .postBody #blog_post_info_block #author_profile_info{display:none}#main #post_detail .postBody #blog_post_info_block #author_profile_detail{display:none}#main #post_detail .postBody #blog_post_info_block #blog_post_info #green_channel{float:left;border:0}#main #post_detail .postBody #blog_post_info_block #blog_post_info #div_digg{float:right}#main #comment_form{padding:45px!important}#main #comment_form *{font-size:12px}#main #comment_form .comment_textarea{width:100%}#main #blog-comments-placeholder{padding:0 45px!important}#main #blog-comments-placeholder *{font-size:12px;color:#333}#main #blog-comments-placeholder .feedbackItem{padding:15px 0;border-bottom:1px dashed #eee}#main #blog-comments-placeholder .feedbackListSubtitle{line-height:30px}#main #blog-comments-placeholder a{color:#009688}#main #blog-comments-placeholder div{line-height:30px}#main #blog-comments-placeholder .feedbackManage{float:right}#main #blog-comments-placeholder .feedbackListSubtitle .layer{color:#036;font-weight:bolder}#main #blog-comments-placeholder .feedbackListSubtitle .louzhu{color:white;background-color:#1c2b36;padding:0 10px;margin:0 -8px}#main #blog-comments-placeholder br{display:none;padding-left:20px}#main #commentbox_opt #btn_comment_submit{background-color:#009688;color:#fff!important;white-space:nowrap;text-align:center;cursor:pointer;padding-left:10px;padding-right:10px;border:0;width:auto}#main #commentbox_opt a{color:#dc3545}.my-title{font-size:18px!important;font-weight:bolder;font-family:simsun!important;border-left:5px solid #dc3545;padding-left:10px;line-height:20px!important;position:relative;left:-15px}#comment_nav{display:none}#ad_t2{display:none}.c_ad_block{display:none}#under_post_news{display:none}

注意，一定要選擇禁用默認的樣式，否則可能樣式衝突！

3. 配置側邊欄：

代碼如下：

<div style="width: 100%;text-align: center;">
    <img style="border-radius: 50%;border: 1px solid #eee;" src="https://pic.cnblogs.com/face/979767/20180915094029.png" alt="">
</div>
<div>聯繫： Q-1214966109</div>

值得注意的是：

a. 頭像的連接可以在自己的博客中找到，如：

b. 聯繫方式可以寫自己，如果你還需要其它項目，繼續添加 div 即可！

最終的效果就是我的效果：

4. 配置首頁按鈕和 GITHUB 鏈接：

代碼如下：

<script>
    // 菜單新加標籤
    var indexEle = '<li><a target="_blank" class="menu" href="https://www.cnblogs.com/Dy1an">首頁</a></li>';
    var githubEle = '<li><a target="_blank" class="menu" href="https://github.com/KU4NG">GITHUB</a></li><li><a target="_blank" class="menu" href="https://github.com/KU4NG">主題</a></li>';
    document.getElementById('navList').insertAdjacentHTML("beforeEnd", indexEle);
    document.getElementById('navList').insertAdjacentHTML("afterBegin", githubEle);
</script>

需要注意的是：

a. 首頁鏈接記得換成自己的，當然你要是直接用我的我也是不會介意的。

b. GITHUB 你可以選擇換成其它的自己的一些資源。

c. 主題鏈接建議不要去掉，這裏吸波粉，讓我看到到底有多少人是支持這個項目的！

最終效果如下：

5. 配置搜索框：

這裏沒有需要修改的，直接粘貼就行，代碼如下：

<script>
    window.onload =  function() {
        var ele = document.getElementById('q');
        console.log(ele);
        ele.setAttribute("placeholder","搜索相關博客...");
        ele.setAttribute("autocomplete","off");
    }
</script>

最終效果：

已知問題：

由於網絡原因可能導致沒有加載或者加載不完全，刷新頁面即可！

6. 配置菜單：

想要以我的博客效果显示，則需要配置菜單：

在選項配置中選擇配置！

特殊用法說明

1. 段落標題：

文中出現段落標題需要瘦動修改 HTML：

增加樣式：

代碼：

class="my-title"

2. 表格：

表格同樣需要以 html 格式插入：

<table>
    <thead>
        <th>
            <td>標題</td>
            <td>標題</td>
            <td>標題</td>
        </th>
    </thead>
    <tbody>
        <tr>
            <td>數據行</td>
            <td>數據行</td>
            <td>數據行</td>
        </tr>
        <tr>
            <td>數據行</td>
            <td>數據行</td>
            <td>數據行</td>
        </tr>
    </tbody>
</table>

效果如下：

3. 圖片：

最後就是截圖，文中的截圖建議大小不超過 870px，865px最佳，否則圖片會壓縮，影響體驗！

意見和建議

最後就是幾點說明：

1. 如果遇到樣式問題，歡迎反饋，QQ，留言，GITHUB 都可以。

2. 如果覺得可以，可以去 GITHUB star 支持一下，也可以在本文中頂一下！

3. 最後吹一波博客園！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

docker registry 鏡像同步

發佈日期: 2020-12-15 作者: admin

docker registry 鏡像同步

Intro

之前我們的 docker 鏡像是保存在 Azure 的 Container Registry 里的，最近我們自己搭建了一個 docker registry，我們想把之前保存的 Azure 的 Container Registry 的 docker 鏡像同步到我們自己的 docker registry 里

實現思路

我們的做法比較簡單也比較LOW，但是基本可以滿足要求，

我們的做法是

首先獲取到源 Registry 里的所有鏡像列表
然後逐個獲取鏡像的 tags
然後依次遍歷將對應的鏡像拉到本地，然後 docker tag 一下，命名為新的 registry 鏡像名稱
然後 push docker 鏡像到新的 registry
刪除下載到本地的鏡像和推送到新的 registry 的鏡像

後來突然想起來阿里雲好像有一個鏡像同步工具，https://github.com/AliyunContainerService/image-syncer image-syncer 是一個docker鏡像同步工具，可用來進行多對多的鏡像倉庫同步，支持目前絕大多數主流的docker鏡像倉庫服務，看介紹還是很棒的，有需要 registry 之間同步鏡像的可以試試這個工具，看介紹這個工具不會拉取到本地磁盤，從源 registry 獲取鏡像數據之後直接就推送到新的 registry 里了，效率會高很多

Docker-Registry API

docker registry 有一套規範，可以查閱 https://docs.docker.com/registry/spec/api/ 了解更多

獲取所有鏡像

docker registry v2 新增了一個 _catalog 的 api 可以獲取所有的鏡像，v1 可以用 _search 來代替

語法如下：

GET /v2/_catalog

默認最多返回100條記錄，多餘 100 可以通過參數 n 指定返回數量，分頁的話可以指定另外一個參數 last指定完上一頁返回的最後一個鏡像，舉個栗子： http://example.com/v2/_catalog?n=20&last=b

獲取鏡像的 tag

獲取 docker 鏡像的 tag 列表可以使用 GET /v2/<repository-name>/tags/list 來獲取，也可以分頁，類似於上面獲取鏡像列表，可以通過 n 和 last 來實現分頁加載

操作示例

在本地部署了一個測試用的 docker registry 來做演示，我這裏用 httpie 來做測試

獲取鏡像列表：

調用 _catalog 接口來獲取鏡像列表

http :5000/v2/_catalog

獲取鏡像的 tag 列表

調用 tags/list 接口獲取鏡像的 tag

http :5000/v2/busybox/tags/list
http :5000/v2/redis/tags/list

PowerShell 腳本

一切不是自動化的運維都是耍流氓，很有可能以後會有類似的需求，不如寫個腳本自動化的跑吧

下面的腳本做了一些簡化，因為我們的 azure container registry 上的數量不多，只有五六十個鏡像，而且鏡像只有 latest 的 tag，沒有其他 tag ，所以把上面的步驟做了簡化，並沒有分頁獲取所有的鏡像，也沒有獲取所有的 tag，實際使用的話還請自行修改后使用

# variables
$srcRegUser = "xxx"
$srcRegPwd = "111111"
$srcRegHost = "xxx.azurecr.cn"
$destRegUser = "yyy"
$destRegPwd = "222"
$destRegHost = "registry.xxx.com"


# get repositories from source registry
# httpie
$response = (http -b -a "${srcRegUser}:${srcRegPwd}" "https://${srcRegHost}/v2/_catalog") | ConvertFrom-Json
# curl
#$response = (curl -u "${srcRegUser}:${srcRegPwd}" "https://${srcRegHost}/v2/_catalog") | ConvertFrom-Json
# repository
$repositories = $response.repositories

#
Write-Host $repositories

# login source registry
docker login $srcRegHost -u $srcRegUser -p $srcRegPwd
# login dest registry
docker login $destRegHost -u $destRegUser -p $destRegPwd

# sync
foreach($repo in $repositories)
{
    Write-Host "sync $repo begin"

    $srcTag = "${srcRegHost}/${repo}:latest"
    $destTag = "${destRegHost}/${repo}:latest"

    Write-Host "source image tag: $srcTag"
    Write-Host "dest image tag $destTag"

    Write-Host "docker pull $srcTag begin"

    docker pull $srcTag

    Write-Host "docker pull $srcTag completed"

    Write-Host "docker tag $srcTag $destTag ing"

    docker tag $srcTag $destTag

    Write-Host "docker push $destTag begin"

    docker push $destTag

    Write-Host "docker push $destTag completed"
    
    Write-Host "docker rmi $srcTag $destTag begin"

    docker rmi $srcTag $destTag

    Write-Host "docker rmi $srcTag $destTag end"

    Write-Host "sync $repo completed"
}

Write-Host "Completed..."

如果要同步的鏡像比較多，考慮使用阿里雲的鏡像同步工具去同步

Reference

https://stackoverflow.com/questions/31251356/how-to-get-a-list-of-images-on-docker-registry-v2
https://github.com/AliyunContainerService/image-syncer
https://docs.docker.com/registry/spec/api/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

寫一個擴展性較強的搜索主頁

發佈日期: 2020-12-14 作者: admin

前置

點擊按鈕切換搜索引擎
搜索框跟隨切換改變樣式
使用 vue 最快了

template

為了方便擴展，使用 v-for 循環渲染出按鈕，綁定切換搜索引擎的 method ，傳入不同名稱以區別搜索引擎。按鈕的樣式也動態綁定。

輸入框動態綁定樣式，在點擊按鈕切換搜索引擎時，搜索框綁定的樣式對應的 data 改變。

<template>
  <section id="search-wrapper">
    <el-row class="search-wrapper-row">
      <el-row style="margin-bottom: 10px">
        <el-button
          size="mini"
          type="primary"
          v-for="(item, index) in source"
          @click="changeSource(item.name)"
          :key="index"
          :style="
                        `background:${item.color};border-color:${item.color}`
                    "
          >{{ item.name }}</el-button
        >
      </el-row>
      <el-input :placeholder="searchbarStyle.placeholder" :class="searchbarStyle.className" v-model="searchValue" clearable>
        <el-button @click="submit" slot="append" icon="el-icon-search"></el-button>
      </el-input>
    </el-row>
  </section>
</template>

script

data

baseUrl 搜索引擎地址
searchValue input v-model 綁定的搜索內容
searchbarStyle 搜索框對應的樣式，值類型為 Object, 方便擴展不同搜索框樣式
source 按鈕的樣式即名稱，數組對象, 方便按鈕擴展

methods

changeSource 點擊按鈕時觸發，接收搜索引擎 name，內部使用 Map，匹配對應的函數，在函數中更改 baseUrl 和 searchbarStyle，由於在 template 動態綁定了 searchbarStyle，這樣就能根據所選擇的搜索類型改變搜索框的樣式了。

代碼塊較長，我將它摺疊

export default {
  data() {
    return {
      baseUrl: 'https://www.baidu.com/s?ie=UTF-8&wd=',
      searchValue: '',
      searchbarStyle: {
        className: 'baidu',
        placeholder: '百度一下，你就知道',
      },
      source: [
        {
          name: '百度',
          color: '#2932E1',
        },
        {
          name: '必應',
          color: '#0c8484',
        },
        {
          name: '搜狗',
          color: '#FF6F17',
        },
        {
          name: '谷歌',
          color: '#4285F4',
        },
        {
          name: 'NPM',
          color: '#EA4335',
        },
      ],
    }
  },
  methods: {
    changeSource(name) {
      const actions = new Map([
        [
          '百度',
          () => {
            this.baseUrl = 'https://www.baidu.com/s?ie=UTF-8&wd='
            this.searchbarStyle = {
              className: 'baidu',
              placeholder: '百度一下，你就知道',
            }
          },
        ],
        [
          '必應',
          () => {
            this.baseUrl = 'https://cn.bing.com/search?FORM=BESBTB&q='
            this.searchbarStyle = {
              className: 'bing',
              placeholder: '必應搜索',
            }
          },
        ],
        [
          '搜狗',
          () => {
            this.baseUrl = 'https://www.sogou.com/web?query='
            this.searchbarStyle = {
              className: 'sougou',
              placeholder: '搜狗搜索',
            }
          },
        ],
        [
          '谷歌',
          () => {
            this.baseUrl = 'https://www.google.com/search?q='
            this.searchbarStyle = {
              className: 'google',
              placeholder: 'Google Search',
            }
          },
        ],
        [
          'NPM',
          () => {
            this.baseUrl = 'https://www.npmjs.com/search?q='
            this.searchbarStyle = {
              className: 'npm',
              placeholder: 'Search Packages',
            }
          },
        ],
      ])
      actions.get(name)()
    },
    submit() {
      const url = this.baseUrl + this.searchValue
      window.open(url)
    },
  },
}

style

在 searchbarStyle 對象中有個 className 字段，input 會動態綁定與之對應的 css class。比如選擇百度時對應 .baidu, 選擇必應時對應 .bing etc. 由於使用了 scss 預處理器，通過 @each 循環它們就好了。

$sources-color: (
  baidu: #2932e1,
  bing: #0c8484,
  sougou: #ff6f17,
  google: #4285f4,
  npm: #ea4335,
);

$source-list: baidu bing sougou google npm;

@each $source in $source-list {
  .#{$source} {
    .el-input-group__append,
    input {
      border-color: map-get($sources-color, $source);
      &:hover {
        border-color: map-get($sources-color, $source);
      }
    }
    .el-icon-search {
      color: map-get($sources-color, $source);
      &:hover {
        border-color: map-get($sources-color, $source);
      }
    }
  }
}

最後

搜索引擎在搜索時並不是簡單的 baseUrl + 搜索內容的形式，url 中還攜帶了其他參數。

數據可以單獨抽離，使用 export 導出並引入，這樣 .vue 看起來不會太長，易於維護。

可以綁定按下 enter 時發起搜索。

預覽地址

如果你有建議歡迎指教，謝謝

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※產品缺大量曝光嗎?你需要的是一流包裝設計!

SpringBoot後端系統的基礎架構

發佈日期: 2020-12-14 作者: admin

前言

前段時間完成了畢業設計課題——《基於Spring Boot + Vue的直播後台管理系統》，項目名為LBMS，主要完成了對直播平台數據的可視化展示和分級的權限管理。雖然相當順利地通過了答辯，但是由於時間以及本人水平的不足，其實後端系統的代碼還僅僅停留在“能跑就行”。因此這篇文章主要也是為了反思一下項目中亟待完善的地方，我後續也會考慮在此基礎上編寫一個後端管理系統的通用架構模板。

2020/6/10 這個模板項目已經在做了：common-MS
2020/6/12 完成了日誌處理、異常處理、結果封裝、參數校驗模塊

日誌處理

日誌框架

Java中可用的日誌框架有很多，並且通常都有着抽象層＋實現層的結構，在實際應用中，只需要考慮抽象層提供的功能接口而不用了解實現層的具體結構。Spring Boot默認的日誌框架為Slf4j + logback。在我的畢設項目中，雖然引入了日誌框架，但是卻很少使用。

Slf4j的輸出級別有5種：trace、debug、info、warn、error，可以通過在properties或yml文件中通過logging.level.root參數指定日誌輸出的級別，其中root代表配置對整個項目生效，可以修改為其他路徑進行自定義配置

日誌代碼的簡化

使用lombok可以簡化代碼的編寫：

Logger logger = LoggerFactory.getLogger(MyLog.class);
logger.info("logger info test");

@Slf4j
// ...
log.info("lombok info test")

對於日誌信息中的變量，建議使用佔位符形式而非字符串拼接

log.info(time + " " + methodName + "is invoked");

log.info("{} {} is invoked", time, methodName)

將日誌輸出到文件

這裏用了某位大牛寫的logback-spring.xml進行配置（可以訪問我的Github獲取具體文件），配置完成后可以將日誌按級別的不同輸出到指定目錄下的不同文件，並且對每天的日誌分開保存，日誌文件大小超過100MB時，還可以自動分塊。

基於AOP的日誌處理

之前用DRF做一個項目時，發現它很貼心地在控制台展示了每個請求的參數、返回狀態碼等信息，SpringBoot當然也可以實現類似的功能。

想要實現上述需求，毫無疑問要在Controller層使用AOP了。對每個請求，我想要輸出對應的URL、請求方法、參數、返回狀態碼等信息。

AOP的切點切面：

@Pointcut("execution(* priv.zzz.controller..*.*(..))")
public void controllerAspect() {}

@Before("controllerAspect()")
public void before(JoinPoint joinPoint){
    log.info(getRequestMessage(joinPoint));
}

@AfterReturning(pointcut = "controllerAspect()", returning = "returnValue")
public void after(JoinPoint joinPoint, Object returnValue){
    if (returnValue instanceof Result){
            log.info(getResponseMessage(joinPoint, ((Result) returnValue).getStatus()));
    }
    if (returnValue instanceof ResultSet){
        log.info(getResponseMessage(joinPoint, ((ResultSet) returnValue).getStatus()));
    }
}

URL、rquestMethod：

private String getBaseMessage(JoinPoint joinPoint) {

    HttpServletRequest request = ((ServletRequestAttributes)(Objects.requireNonNull(RequestContextHolder.getRequestAttributes()))).getRequest();
    String url = request.getRequestURI();
    String requestMethod = request.getMethod();
    String datetime = DateFormatter.format(new Date());

    return datetime + " " + url + " " + requestMethod;
}

請求參數：

private String getRequestMessage(JoinPoint joinPoint) {
    MethodSignature methodSignature = (MethodSignature)joinPoint.getSignature();
    Object[] args = joinPoint.getArgs();
    String[] parameters = methodSignature.getParameterNames();

    StringBuilder stringBuilder = new StringBuilder();
    for (int i = 0; i < Math.min(args.length, parameters.length); i++){
        stringBuilder.append(parameters[i]).append(":").append(args[i]).append(" ");
    }
    String params = "{ "+stringBuilder.toString()+"}";

    return this.getBaseMessage(joinPoint) + " " + params;
}

private String getResponseMessage(JoinPoint joinPoint, int status) {
    return this.getBaseMessage(joinPoint) + " " + status;
}

最終效果：

2020-06-11 13:10:32 /log GET { name:test number:1 }
2020-06-11 13:10:32 /log GET 200

結果封裝

前後端分離的情況下前後端一般都是通過Json數據進行交互，使用@RestController註解可以將返回的對象轉為Json格式，在那之前，我們需要對返回的結果封裝為Result對象。Result中主要要包含的字段有status、message和data，對於status和message，我使用枚舉類型ResultCode進行封裝，其中包含SUCCESS、NOT_FOUND、UNAUTHORIZED等常見狀態碼。data要考慮返回的數據是否是一個列表，如果是列表，還需要實現分頁功能。

在LBMS中，我將這兩種結果集（單個對象和列表對象）封裝為同一個結果集，在新的模板項目中，我嘗試使用Result和ResultSet兩種結果集進行封裝。這樣做的好處是返回結果更加清晰，缺點是有些地方可能需要一些額外的處理，比如在日誌模塊獲取controller返回的狀態碼時，具體的優劣有待更加深入的使用。

Result示例：

{
  "timestamp": "2020-06-12T15:44:02.106+08:00",
  "status": 200,
  "message": "success",
  "data": 123,
  "path": "/result"
}

ResultSet示例：

{
  "timestamp": "2020-06-12T15:38:01.130+08:00",
  "total": 2,
  "status": 200,
  "message": "success",
  "list": [
    {
      "username": "Alice",
      "age": 20,
      "sex": 0,
      "email": "12345@qq.com"
    },
    {
      "username": "Eric",
      "age": 21,
      "sex": 1,
      "email": "12345@163.com"
    }
  ],
  "path": "/result/set"
}

結果封裝還要考慮的一個問題是對異常的處理，這個我在異常處理章節會談到。

參數校驗

上一個項目中的參數校驗做的相當有限，目前Spring Boot主流的參數校驗方式有hibernate-validator、Assert等。使用validator參數校驗的位置可以在實體類字段處，也可以在Controller傳參處。

網上大部分文章說spring-boot-starter-web已經包含了hibernate-validator，但我不知道為什麼無法直接使用@NotNull等註解，因此手動引入validator：

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.1.5.Final</version>
</dependency>

一個簡單的例子：

@Data
@AllArgsConstructor
@NoArgsConstructor
public class TestUser {

    @NotNull(message = "用戶名不能為空")
    @NotBlank(message = "用戶名不能為空")
    @Length(max = 20, message = "用戶名過長")
    private String username;

    @Min(0)
    private Integer age;

    @Range(min = 0, max = 1)
    private Integer sex;

    @Email(message = "郵箱格式錯誤")
    private String email;

}

使用Assert進行校驗：

Assert.notNull(user.getUsername(), "用戶名不能為空");

validator校驗失敗時，會拋出MethodArgumentNotValidException異常。

Assert校驗失敗時會拋出IllegalArgumentException。

實際應用中我們可以靈活使用這兩種校驗方式，並且可以通過ExceptionHandler對這些異常進行捕獲和統一處理。

異常處理

LBMS中，我的異常處理採用的是自定義異常+@ResponseStatus註解的方式，在特定的地方拋出異常，交給ResponseStatusExceptionResolver去處理。

@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "無法識別的操作")
public class BadOperationException extends Exception {

    public BadOperationException(){
        super();
    }

    public BadOperationException(String msg){
        super(msg);
    }
}

在common-MS中，異常處理採用@ControllerAdvice+@ExceptionHandler實現，@ControllerAdvice將一個類標註為全局的異常處理類，@ExceptionHandler用於捕獲不同的異常進行對應處理。同理，對於異常的返回結果也與正常返回結果格式保持一致，使用Result封裝。

例如，捕獲上述validator拋出的MethodArgumentNotValidException異常並進行處理的代碼為：

@ExceptionHandler(value = { MethodArgumentNotValidException.class })
public Result<String> validatorException(HttpServletResponse response, MethodArgumentNotValidException e) {
    // validator設置了message時返回message，未設置則返回“非法參數”
    FieldError error = e.getBindingResult().getFieldError();
    String message = "非法參數";
    if(error != null){
        message = error.getField() + error.getDefaultMessage();
    }
    response.setStatus(400);
    return Result.failure(400, message);
}

當提交的郵箱格式錯誤時返回：

{
  "timestamp": "2020-06-12T15:45:07.874+08:00",
  "status": 400,
  "message": "email郵箱格式錯誤",
  "data": null,
  "path": "/user"
}

同理，還可以對自定義的異常進行處理：

public class ExampleException extends Exception{

    public ExampleException() {super();}

    public ExampleException(String message) {
        super(message);
    }
}

使用時直接拋出異常即可：

@RequestMapping(value = "exception", method = RequestMethod.GET)
public Result exampleException() throws ExampleException {
    throw new ExampleException("這是一個測試異常");
}

如果需要修改Response的狀態碼而不僅僅是使用自定義的status，可以在@ExceptionHandler註解的方法內引入並使用

response.setStatus(400);

待續~

todo：Shiro、分頁功能、Redis等。

完整代碼移步Github：common-MS

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※產品缺大量曝光嗎?你需要的是一流包裝設計!

【K8S】基於Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持續集成交付環境（環境搭建篇）

發佈日期: 2020-12-14 作者: admin

環境搭建概述

1.K8S是什麼？

K8S全稱是Kubernetes，是一個全新的基於容器技術的分佈式架構領先方案，基於容器技術，目的是實現資源管理的自動化，以及跨多個數據中心的資源利用率的最大化。

如果我們的系統設計遵循了kubernetes的設計思想，那麼傳統系統架構中那些和業務沒有多大關係的底層代碼或功能模塊，都可以使用K8S來管理，我們不必再費心於負載均衡的選型和部署實施問題，不必再考慮引入或自己開發一個複雜的服務治理框架，不必再頭疼與服務監控和故障處理模塊的開發。總之，使用kubernetes提供的解決方案，會大大減少開發成本，同時可以將精力更加集中於業務本身，而且由於kubernetes提供了強大的自動化機制，所以系統後期的運維難度和運維成本大幅降低。

2.為什麼要用K8S?

Docker 這個新興的容器化技術當前已經被很多公司所採用，其從單機走向集群已成必然，而雲計算的蓬勃發展正在加速這一進程。Kubernetes 作為當前唯一被業界廣泛認可和看好的 Docker 分佈式系統解決方案。可以預見，在未來幾年內，會有大量的新系統選擇它，不管是運行在企業本地服務器上還是被託管到公有雲上。

3.使用K8S有哪些好處？

使用Kubernetes就是在全面部署微服務架構。微服務架構的核心就是將一個巨大的單體應用分解為很多小的互相連接的微服務，一個微服務背後可能有多個實例副本在支撐，副本的數量可能會隨着系統的負荷變化而進行調整，內嵌的負載均衡器在 k8s 平台中有多個實例副本在支撐，副本的數量可能會隨着系統的負荷變化而進行調整，內嵌的負載均衡器在k8s 平台中發揮了重要的作用。微服務架構使得每個服務都可以由專門的開發團隊來開發，開發者可以自由選擇開發技術，這對於大規模團隊來說很有價值。另外，每個微服務獨立開發、升級、擴展，使得系統具備很高的穩定性和快速迭代進化能力。

4.環境構成

整套環境的搭建包含：Docker環境的搭建、docker-compose環境的搭建、K8S集群的搭建、GitLab代碼倉庫的搭建、SVN倉庫的搭建、Jenkins自動化部署環境的搭建、Harbor私有倉庫的搭建。

本文檔中，整套環境的搭建包括：

安裝Docker環境
安裝docker-compose
安裝K8S集群環境
重啟K8S集群引起的問題
K8S安裝ingress-nginx
K8S安裝gitlab代碼倉庫
安裝Harbor私有倉庫
安裝Jenkins
物理機安裝SVN（推薦）
物理機安裝Jenkins（推薦）
配置Jenkins運行環境
Jenkins發布Docker項目到K8S

服務器規劃

IP	主機名	節點	操作系統
192.168.0.10	test10	K8S Master	CentOS 8.0.1905
192.168.0.11	test11	K8S Worker	CentOS 8.0.1905
192.168.0.12	test12	K8S Worker	CentOS 8.0.1905

安裝環境版本

軟件名稱	軟件版本	說明
Docker	19.03.8	提供容器環境
docker-compose	1.25.5	定義和運行由多個容器組成的應用
K8S	1.18.2	是一個開源的，用於管理雲平台中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。
GitLab	12.1.6	代碼倉庫
Harbor	1.10.2	私有鏡像倉庫
Jenkins	2.222.3	持續集成交付

安裝Docker環境

Docker 是一個開源的應用容器引擎，基於 Go 語言並遵從 Apache2.0 協議開源。

Docker 可以讓開發者打包他們的應用以及依賴包到一個輕量級、可移植的容器中，然後發布到任何流行的 Linux 機器上，也可以實現虛擬化。

本文檔基於Docker 19.03.8 版本搭建Docker環境。

在所有服務器上創建install_docker.sh腳本，腳本內容如下所示。

#使用阿里雲鏡像中心
export REGISTRY_MIRROR=https://registry.cn-hangzhou.aliyuncs.com
#安裝yum工具
dnf install yum*
#安裝docker環境
yum install -y yum-utils device-mapper-persistent-data lvm2
#配置Docker的yum源
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
#安裝容器插件
dnf install https://mirrors.aliyun.com/docker-ce/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.13-3.1.el7.x86_64.rpm
#指定安裝docker 19.03.8版本
yum install -y docker-ce-19.03.8 docker-ce-cli-19.03.8
#設置Docker開機啟動
systemctl enable docker.service
#啟動Docker
systemctl start docker.service
#查看Docker版本
docker version

在每台服務器上為install_docker.sh腳本賦予可執行權限，並執行腳本，如下所示。

# 賦予install_docker.sh腳本可執行權限
chmod a+x ./install_docker.sh
# 執行install_docker.sh腳本
./install_docker.sh

安裝docker-compose

Compose 是用於定義和運行多容器 Docker 應用程序的工具。通過 Compose，您可以使用 YML 文件來配置應用程序需要的所有服務。然後，使用一個命令，就可以從 YML 文件配置中創建並啟動所有服務。

注意：在每台服務器上安裝docker-compose

1.下載docker-compose文件

#下載並安裝docker-compose
curl -L https://github.com/docker/compose/releases/download/1.25.5/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

2.為docker-compose文件賦予可執行權限

#賦予docker-compose可執行權限
chmod a+x /usr/local/bin/docker-compose

3.查看docker-compose版本

#查看docker-compose版本
[root@binghe ~]# docker-compose version
docker-compose version 1.25.5, build 8a1c60f6
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

安裝K8S集群環境

Kubernetes是一個開源的，用於管理雲平台中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

本文檔基於K8S 1.8.12版本來搭建K8S集群

安裝K8S基礎環境

在所有服務器上創建install_k8s.sh腳本文件，腳本文件的內容如下所示。

#################配置阿里雲鏡像加速器開始########################
mkdir -p /etc/docker
tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"]
}
EOF
systemctl daemon-reload
systemctl restart docker
######################配置阿里雲鏡像加速器結束#########################
#安裝nfs-utils
yum install -y nfs-utils
#安裝wget軟件下載命令
yum install -y wget

#啟動nfs-server
systemctl start nfs-server
#配置nfs-server開機自啟動
systemctl enable nfs-server

#關閉防火牆
systemctl stop firewalld
#取消防火牆開機自啟動
systemctl disable firewalld

#關閉SeLinux
setenforce 0
sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config

# 關閉 swap
swapoff -a
yes | cp /etc/fstab /etc/fstab_bak
cat /etc/fstab_bak |grep -v swap > /etc/fstab

############################修改 /etc/sysctl.conf開始###########################
# 如果有配置，則修改
sed -i "s#^net.ipv4.ip_forward.*#net.ipv4.ip_forward=1#g"  /etc/sysctl.conf
sed -i "s#^net.bridge.bridge-nf-call-ip6tables.*#net.bridge.bridge-nf-call-ip6tables=1#g"  /etc/sysctl.conf
sed -i "s#^net.bridge.bridge-nf-call-iptables.*#net.bridge.bridge-nf-call-iptables=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.all.disable_ipv6.*#net.ipv6.conf.all.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.default.disable_ipv6.*#net.ipv6.conf.default.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.lo.disable_ipv6.*#net.ipv6.conf.lo.disable_ipv6=1#g"  /etc/sysctl.conf
sed -i "s#^net.ipv6.conf.all.forwarding.*#net.ipv6.conf.all.forwarding=1#g"  /etc/sysctl.conf
# 可能沒有，追加
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-ip6tables = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.lo.disable_ipv6 = 1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 1"  >> /etc/sysctl.conf
############################修改 /etc/sysctl.conf結束###########################
# 執行命令使修改后的/etc/sysctl.conf文件生效
sysctl -p

################# 配置K8S的yum源開始#############################
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
       http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF
################# 配置K8S的yum源結束#############################

# 卸載舊版本K8S
yum remove -y kubelet kubeadm kubectl

# 安裝kubelet、kubeadm、kubectl，這裏我安裝的是1.18.2版本，你也可以安裝1.17.2版本
yum install -y kubelet-1.18.2 kubeadm-1.18.2 kubectl-1.18.2

# 修改docker Cgroup Driver為systemd
# # 將/usr/lib/systemd/system/docker.service文件中的這一行 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
# # 修改為 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd
# 如果不修改，在添加 worker 節點時可能會碰到如下錯誤
# [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". 
# Please follow the guide at https://kubernetes.io/docs/setup/cri/
sed -i "s#^ExecStart=/usr/bin/dockerd.*#ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --exec-opt native.cgroupdriver=systemd#g" /usr/lib/systemd/system/docker.service

# 設置 docker 鏡像，提高 docker 鏡像下載速度和穩定性
# 如果訪問 https://hub.docker.io 速度非常穩定，也可以跳過這個步驟，一般不需配置
# curl -sSL https://kuboard.cn/install-script/set_mirror.sh | sh -s ${REGISTRY_MIRROR}

# 重新加載配置文件
systemctl daemon-reload
#重啟 docker
systemctl restart docker
# 將kubelet設置為開機啟動並啟動kubelet
systemctl enable kubelet && systemctl start kubelet
# 查看docker版本
docker version

在每台服務器上為install_k8s.sh腳本賦予可執行權限，並執行腳本

# 賦予install_k8s.sh腳本可執行權限
chmod a+x ./install_k8s.sh
# 運行install_k8s.sh腳本
./install_k8s.sh

初始化Master節點

只在test10服務器上執行的操作。

1.初始化Master節點的網絡環境

注意：下面的命令需要在命令行手動執行。

# 只在 master 節點執行
# export 命令只在當前 shell 會話中有效，開啟新的 shell 窗口后，如果要繼續安裝過程，請重新執行此處的 export 命令
export MASTER_IP=192.168.0.10
# 替換 k8s.master 為 您想要的 dnsName
export APISERVER_NAME=k8s.master
# Kubernetes 容器組所在的網段，該網段安裝完成后，由 kubernetes 創建，事先並不存在於物理網絡中
export POD_SUBNET=172.18.0.1/16
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

2.初始化Master節點

在test10服務器上創建init_master.sh腳本文件，文件內容如下所示。

#!/bin/bash
# 腳本出錯時終止執行
set -e

if [ ${#POD_SUBNET} -eq 0 ] || [ ${#APISERVER_NAME} -eq 0 ]; then
  echo -e "\033[31;1m請確保您已經設置了環境變量 POD_SUBNET 和 APISERVER_NAME \033[0m"
  echo 當前POD_SUBNET=$POD_SUBNET
  echo 當前APISERVER_NAME=$APISERVER_NAME
  exit 1
fi


# 查看完整配置選項 https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
rm -f ./kubeadm-config.yaml
cat <<EOF > ./kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.18.2
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
controlPlaneEndpoint: "${APISERVER_NAME}:6443"
networking:
  serviceSubnet: "10.96.0.0/16"
  podSubnet: "${POD_SUBNET}"
  dnsDomain: "cluster.local"
EOF

# kubeadm init
# 初始化kebeadm
kubeadm init --config=kubeadm-config.yaml --upload-certs

# 配置 kubectl
rm -rf /root/.kube/
mkdir /root/.kube/
cp -i /etc/kubernetes/admin.conf /root/.kube/config

# 安裝 calico 網絡插件
# 參考文檔 https://docs.projectcalico.org/v3.13/getting-started/kubernetes/self-managed-onprem/onpremises
echo "安裝calico-3.13.1"
rm -f calico-3.13.1.yaml
wget https://kuboard.cn/install-script/calico/calico-3.13.1.yaml
kubectl apply -f calico-3.13.1.yaml

賦予init_master.sh腳本文件可執行權限並執行腳本。

# 賦予init_master.sh文件可執行權限
chmod a+x ./init_master.sh
# 運行init_master.sh腳本
./init_master.sh

3.查看Master節點的初始化結果

（1）確保所有容器組處於Running狀態

# 執行如下命令，等待 3-10 分鐘，直到所有的容器組處於 Running 狀態
watch kubectl get pod -n kube-system -o wide

具體執行如下所示。

[root@test10 ~]# watch kubectl get pod -n kube-system -o wide
Every 2.0s: kubectl get pod -n kube-system -o wide                                                                                                                          test10: Sun May 10 11:01:32 2020

NAME                                       READY   STATUS    RESTARTS   AGE    IP                NODE        NOMINATED NODE   READINESS GATES          
calico-kube-controllers-5b8b769fcd-5dtlp   1/1     Running   0          118s   172.18.203.66     test10   <none>           <none>          
calico-node-fnv8g                          1/1     Running   0          118s   192.168.0.10   test10   <none>           <none>          
coredns-546565776c-27t7h                   1/1     Running   0          2m1s   172.18.203.67     test10   <none>           <none>          
coredns-546565776c-hjb8z                   1/1     Running   0          2m1s   172.18.203.65     test10   <none>           <none>          
etcd-test10                             1/1     Running   0          2m7s   192.168.0.10   test10   <none>           <none>          
kube-apiserver-test10                   1/1     Running   0          2m7s   192.168.0.10   test10   <none>           <none>          
kube-controller-manager-test10          1/1     Running   0          2m7s   192.168.0.10   test10   <none>           <none>          
kube-proxy-dvgsr                           1/1     Running   0          2m1s   192.168.0.10   test10   <none>           <none>          
kube-scheduler-test10                   1/1     Running   0          2m7s   192.168.0.10   test10   <none>           <none>

（2）查看 Master 節點初始化結果

# 查看Master節點的初始化結果
kubectl get nodes -o wide

具體執行如下所示。

[root@test10 ~]# kubectl get nodes -o wide
NAME        STATUS   ROLES    AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION         CONTAINER-RUNTIME
test10   Ready    master   3m28s   v1.18.2   192.168.0.10   <none>        CentOS Linux 8 (Core)   4.18.0-80.el8.x86_64   docker://19.3.8

初始化Worker節點

1.獲取join命令參數

在Master節點（test10服務器）上執行如下命令獲取join命令參數。

kubeadm token create --print-join-command

具體執行如下所示。

[root@test10 ~]# kubeadm token create --print-join-command
W0510 11:04:34.828126   56132 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

其中，有如下一行輸出。

kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

這行代碼就是獲取到的join命令。

注意：join命令中的token的有效時間為 2 個小時，2小時內，可以使用此 token 初始化任意數量的 worker 節點。

2.初始化Worker節點

針對所有的 worker 節點執行，在這裏，就是在test11服務器和test12服務器上執行。

在命令分別手動執行如下命令。

# 只在 worker 節點執行
# 192.168.0.10 為 master 節點的內網 IP
export MASTER_IP=192.168.0.10
# 替換 k8s.master 為初始化 master 節點時所使用的 APISERVER_NAME
export APISERVER_NAME=k8s.master
echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts

# 替換為 master 節點上 kubeadm token create 命令輸出的join
kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d

具體執行如下所示。

[root@test11 ~]# export MASTER_IP=192.168.0.10
[root@test11 ~]# export APISERVER_NAME=k8s.master
[root@test11 ~]# echo "${MASTER_IP}    ${APISERVER_NAME}" >> /etc/hosts
[root@test11 ~]# kubeadm join k8s.master:6443 --token 8nblts.62xytoqufwsqzko2     --discovery-token-ca-cert-hash sha256:1717cc3e34f6a56b642b5751796530e367aa73f4113d09994ac3455e33047c0d 
W0510 11:08:27.709263   42795 join.go:346] [preflight] WARNING: JoinControlPane.controlPlane settings will be ignored when control-plane flag is not set.
[preflight] Running pre-flight checks
        [WARNING FileExisting-tc]: tc not found in system path
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

根據輸出結果可以看出，Worker節點加入了K8S集群。

注意：kubeadm join…就是master 節點上 kubeadm token create 命令輸出的join。

3.查看初始化結果

在Master節點（test10服務器）執行如下命令查看初始化結果。

kubectl get nodes -o wide

具體執行如下所示。

[root@test10 ~]# kubectl get nodes
NAME        STATUS   ROLES    AGE     VERSION
test10   Ready    master   20m     v1.18.2
test11   Ready    <none>   2m46s   v1.18.2
test12   Ready    <none>   2m46s   v1.18.2

注意：kubectl get nodes命令後面加上-o wide參數可以輸出更多的信息。

重啟K8S集群引起的問題

1.Worker節點故障不能啟動

Master 節點的 IP 地址發生變化，導致 worker 節點不能啟動。需要重新安裝K8S集群，並確保所有節點都有固定的內網 IP 地址。

2.Pod崩潰或不能正常訪問

重啟服務器后使用如下命令查看Pod的運行狀態。

#查看所有pod的運行情況
kubectl get pods --all-namespaces

發現很多 Pod 不在 Running 狀態，此時，需要使用如下命令刪除運行不正常的Pod。

kubectl delete pod <pod-name> -n <pod-namespece>

注意：如果Pod 是使用 Deployment、StatefulSet 等控制器創建的，K8S 將創建新的 Pod 作為替代，重新啟動的 Pod 通常能夠正常工作。

其中，pod-name表示運行在K8S中的pod的名稱，pod-namespece表示命名空間。例如，需要刪除pod名稱為pod-test，命名空間為pod-test-namespace的pod，可以使用下面的命令。

kubectl delete pod pod-test -n pod-test-namespace

K8S安裝ingress-nginx

作為反向代理將外部流量導入集群內部，將 Kubernetes 內部的 Service 暴露給外部，在 Ingress 對象中通過域名匹配 Service，這樣就可以直接通過域名訪問到集群內部的服務了。相對於 traefik 來說，nginx-ingress 性能更加優秀。

注意：在Master節點（test10服務器上執行）

1.創建ingress-nginx命名空間

創建ingress-nginx-namespace.yaml文件，主要的作用是創建ingress-nginx命名空間，文件內容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    name: ingress-nginx

執行如下命令創建ingress-nginx命名空間。

kubectl apply -f ingress-nginx-namespace.yaml

2.安裝ingress controller

創建ingress-nginx-mandatory.yaml文件，主要的作用是安裝ingress-nginx。文件內容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default-http-backend
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
  namespace: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: default-http-backend
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: default-http-backend
        app.kubernetes.io/part-of: ingress-nginx
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: default-http-backend
          # Any image is permissible as long as:
          # 1. It serves a 404 page at /
          # 2. It serves 200 on a /healthz endpoint
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/defaultbackend-amd64:1.5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: 10m
              memory: 20Mi
            requests:
              cpu: 10m
              memory: 20Mi

---
apiVersion: v1
kind: Service
metadata:
  name: default-http-backend
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx
spec:
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app.kubernetes.io/name: default-http-backend
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
    resources:
      - ingresses/status
    verbs:
      - update

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: registry.cn-qingdao.aliyuncs.com/kubernetes_xingej/nginx-ingress-controller:0.20.0
          args:
            - /nginx-ingress-controller
            - --default-backend-service=$(POD_NAMESPACE)/default-http-backend
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
          securityContext:
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

---

執行如下命令安裝ingress controller。

kubectl apply -f ingress-nginx-mandatory.yaml

3.安裝K8S SVC：ingress-nginx

主要是用來用於暴露pod：nginx-ingress-controller。

創建service-nodeport.yaml文件，文件內容如下所示。

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
      nodePort: 30080
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP
      nodePort: 30443
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

執行如下命令安裝。

kubectl apply -f service-nodeport.yaml

4.訪問K8S SVC：ingress-nginx

查看ingress-nginx命名空間的部署情況，如下所示。

[root@test10 k8s]# kubectl get pod -n ingress-nginx
NAME                                        READY   STATUS    RESTARTS   AGE
default-http-backend-796ddcd9b-vfmgn        1/1     Running   1          10h
nginx-ingress-controller-58985cc996-87754   1/1     Running   2          10h

在命令行服務器命令行輸入如下命令查看ingress-nginx的端口映射情況。

kubectl get svc -n ingress-nginx

具體如下所示。

[root@test10 k8s]# kubectl get svc -n ingress-nginx 
NAME                   TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                      AGE
default-http-backend   ClusterIP   10.96.247.2   <none>        80/TCP                       7m3s
ingress-nginx          NodePort    10.96.40.6    <none>        80:30080/TCP,443:30443/TCP   4m35s

所以，可以通過Master節點（test10服務器）的IP地址和30080端口號來訪問ingress-nginx，如下所示。

[root@test10 k8s]# curl 192.168.0.10:30080       
default backend - 404

也可以在瀏覽器打開http://192.168.0.10:30080 來訪問ingress-nginx，如下所示。

K8S安裝gitlab代碼倉庫

GitLab是由GitLabInc.開發，使用MIT許可證的基於網絡的Git倉庫管理工具，且具有Wiki和issue跟蹤功能。使用Git作為代碼管理工具，並在此基礎上搭建起來的web服務。

注意：在Master節點（test10服務器上執行）

1.創建k8s-ops命名空間

創建k8s-ops-namespace.yaml文件，主要作用是創建k8s-ops命名空間。文件內容如下所示。

apiVersion: v1
kind: Namespace
metadata:
  name: k8s-ops
  labels:
    name: k8s-ops

執行如下命令創建命名空間。

kubectl apply -f k8s-ops-namespace.yaml

2.安裝gitlab-redis

創建gitlab-redis.yaml文件，文件的內容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: k8s-ops
  labels:
    name: redis
spec:
  selector:
    matchLabels:
      name: redis
  template:
    metadata:
      name: redis
      labels:
        name: redis
    spec:
      containers:
      - name: redis
        image: sameersbn/redis
        imagePullPolicy: IfNotPresent
        ports:
        - name: redis
          containerPort: 6379
        volumeMounts:
        - mountPath: /var/lib/redis
          name: data
        livenessProbe:
          exec:
            command:
            - redis-cli
            - ping
          initialDelaySeconds: 30
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - redis-cli
            - ping
          initialDelaySeconds: 10
          timeoutSeconds: 5
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/redis

---
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: k8s-ops
  labels:
    name: redis
spec:
  ports:
    - name: redis
      port: 6379
      targetPort: redis
  selector:
    name: redis

首先，在命令行執行如下命令創建/data1/docker/xinsrv/redis目錄。

mkdir -p /data1/docker/xinsrv/redis

執行如下命令安裝gitlab-redis。

kubectl apply -f gitlab-redis.yaml

3.安裝gitlab-postgresql

創建gitlab-postgresql.yaml，文件內容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgresql
  namespace: k8s-ops
  labels:
    name: postgresql
spec:
  selector:
    matchLabels:
      name: postgresql
  template:
    metadata:
      name: postgresql
      labels:
        name: postgresql
    spec:
      containers:
      - name: postgresql
        image: sameersbn/postgresql
        imagePullPolicy: IfNotPresent
        env:
        - name: DB_USER
          value: gitlab
        - name: DB_PASS
          value: passw0rd
        - name: DB_NAME
          value: gitlab_production
        - name: DB_EXTENSION
          value: pg_trgm
        ports:
        - name: postgres
          containerPort: 5432
        volumeMounts:
        - mountPath: /var/lib/postgresql
          name: data
        livenessProbe:
          exec:
            command:
            - pg_isready
            - -h
            - localhost
            - -U
            - postgres
          initialDelaySeconds: 30
          timeoutSeconds: 5
        readinessProbe:
          exec:
            command:
            - pg_isready
            - -h
            - localhost
            - -U
            - postgres
          initialDelaySeconds: 5
          timeoutSeconds: 1
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/postgresql
---
apiVersion: v1
kind: Service
metadata:
  name: postgresql
  namespace: k8s-ops
  labels:
    name: postgresql
spec:
  ports:
    - name: postgres
      port: 5432
      targetPort: postgres
  selector:
    name: postgresql

首先，執行如下命令創建/data1/docker/xinsrv/postgresql目錄。

mkdir -p /data1/docker/xinsrv/postgresql

接下來，安裝gitlab-postgresql，如下所示。

kubectl apply -f gitlab-postgresql.yaml

4.安裝gitlab

（1）配置用戶名和密碼

首先，在命令行使用base64編碼為用戶名和密碼進行轉碼，本示例中，使用的用戶名為admin，密碼為admin.1231

轉碼情況如下所示。

[root@test10 k8s]# echo -n 'admin' | base64 
YWRtaW4=
[root@test10 k8s]# echo -n 'admin.1231' | base64 
YWRtaW4uMTIzMQ==

轉碼后的用戶名為：YWRtaW4= 密碼為：YWRtaW4uMTIzMQ==

也可以對base64編碼后的字符串解碼，例如，對密碼字符串解碼，如下所示。

[root@test10 k8s]# echo 'YWRtaW4uMTIzMQ==' | base64 --decode 
admin.1231

接下來，創建secret-gitlab.yaml文件，主要是用戶來配置GitLab的用戶名和密碼，文件內容如下所示。

apiVersion: v1
kind: Secret
metadata:
  namespace: k8s-ops
  name: git-user-pass
type: Opaque
data:
  username: YWRtaW4=
  password: YWRtaW4uMTIzMQ==

執行配置文件的內容，如下所示。

kubectl create -f ./secret-gitlab.yaml

（2）安裝GitLab

創建gitlab.yaml文件，文件的內容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab
  namespace: k8s-ops
  labels:
    name: gitlab
spec:
  selector:
    matchLabels:
      name: gitlab
  template:
    metadata:
      name: gitlab
      labels:
        name: gitlab
    spec:
      containers:
      - name: gitlab
        image: sameersbn/gitlab:12.1.6
        imagePullPolicy: IfNotPresent
        env:
        - name: TZ
          value: Asia/Shanghai
        - name: GITLAB_TIMEZONE
          value: Beijing
        - name: GITLAB_SECRETS_DB_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_SECRETS_SECRET_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_SECRETS_OTP_KEY_BASE
          value: long-and-random-alpha-numeric-string
        - name: GITLAB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: git-user-pass
              key: password
        - name: GITLAB_ROOT_EMAIL
          value: 12345678@qq.com
        - name: GITLAB_HOST
          value: gitlab.binghe.com
        - name: GITLAB_PORT
          value: "80"
        - name: GITLAB_SSH_PORT
          value: "30022"
        - name: GITLAB_NOTIFY_ON_BROKEN_BUILDS
          value: "true"
        - name: GITLAB_NOTIFY_PUSHER
          value: "false"
        - name: GITLAB_BACKUP_SCHEDULE
          value: daily
        - name: GITLAB_BACKUP_TIME
          value: 01:00
        - name: DB_TYPE
          value: postgres
        - name: DB_HOST
          value: postgresql
        - name: DB_PORT
          value: "5432"
        - name: DB_USER
          value: gitlab
        - name: DB_PASS
          value: passw0rd
        - name: DB_NAME
          value: gitlab_production
        - name: REDIS_HOST
          value: redis
        - name: REDIS_PORT
          value: "6379"
        ports:
        - name: http
          containerPort: 80
        - name: ssh
          containerPort: 22
        volumeMounts:
        - mountPath: /home/git/data
          name: data
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 180
          timeoutSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          timeoutSeconds: 1
      volumes:
      - name: data
        hostPath:
          path: /data1/docker/xinsrv/gitlab
---
apiVersion: v1
kind: Service
metadata:
  name: gitlab
  namespace: k8s-ops
  labels:
    name: gitlab
spec:
  ports:
    - name: http
      port: 80
      nodePort: 30088
    - name: ssh
      port: 22
      targetPort: ssh
      nodePort: 30022
  type: NodePort
  selector:
    name: gitlab

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gitlab
  namespace: k8s-ops
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: gitlab.binghe.com
    http:
      paths:
      - backend:
          serviceName: gitlab
          servicePort: http

注意：在配置GitLab時，監聽主機時，不能使用IP地址，需要使用主機名或者域名，上述配置中，我使用的是gitlab.binghe.com主機名。

在命令行執行如下命令創建/data1/docker/xinsrv/gitlab目錄。

mkdir -p /data1/docker/xinsrv/gitlab

安裝GitLab，如下所示。

kubectl apply -f gitlab.yaml

5.安裝完成

查看k8s-ops命名空間部署情況，如下所示。

[root@test10 k8s]# kubectl get pod -n k8s-ops
NAME                          READY   STATUS    RESTARTS   AGE
gitlab-7b459db47c-5vk6t       0/1     Running   0          11s
postgresql-79567459d7-x52vx   1/1     Running   0          30m
redis-67f4cdc96c-h5ckz        1/1     Running   1          10h

也可以使用如下命令查看。

[root@test10 k8s]# kubectl get pod --namespace=k8s-ops
NAME                          READY   STATUS    RESTARTS   AGE
gitlab-7b459db47c-5vk6t       0/1     Running   0          36s
postgresql-79567459d7-x52vx   1/1     Running   0          30m
redis-67f4cdc96c-h5ckz        1/1     Running   1          10h

二者效果一樣。

接下來，查看GitLab的端口映射，如下所示。

[root@test10 k8s]# kubectl get svc -n k8s-ops
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                     AGE
gitlab       NodePort    10.96.153.100   <none>        80:30088/TCP,22:30022/TCP   2m42s
postgresql   ClusterIP   10.96.203.119   <none>        5432/TCP                    32m
redis        ClusterIP   10.96.107.150   <none>        6379/TCP                    10h

此時，可以看到，可以通過Master節點（test10）的主機名gitlab.binghe.com和端口30088就能夠訪問GitLab。由於我這裏使用的是虛擬機來搭建相關的環境，在本機訪問虛擬機映射的gitlab.binghe.com時，需要配置本機的hosts文件，在本機的hosts文件中加入如下配置項。

192.168.0.10 gitlab.binghe.com

注意：在Windows操作系統中，hosts文件所在的目錄如下。

C:\Windows\System32\drivers\etc

接下來，就可以在瀏覽器中通過鏈接：http://gitlab.binghe.com:30088 來訪問GitLab了，如下所示。

此時，可以通過用戶名root和密碼admin.1231來登錄GitLab了。

注意：這裏的用戶名是root而不是admin，因為root是GitLab默認的超級用戶。

到此，K8S安裝gitlab完成。

安裝Harbor私有倉庫

Habor是由VMWare公司開源的容器鏡像倉庫。事實上，Habor是在Docker Registry上進行了相應的企業級擴展，從而獲得了更加廣泛的應用，這些新的企業級特性包括：管理用戶界面，基於角色的訪問控制，AD/LDAP集成以及審計日誌等，足以滿足基本企業需求。

注意：這裏將Harbor私有倉庫安裝在Master節點（test10服務器）上，實際生產環境中建議安裝在其他服務器。

1.下載Harbor的離線安裝版本

wget https://github.com/goharbor/harbor/releases/download/v1.10.2/harbor-offline-installer-v1.10.2.tgz

2.解壓Harbor的安裝包

tar -zxvf harbor-offline-installer-v1.10.2.tgz

解壓成功后，會在服務器當前目錄生成一個harbor目錄。

3.配置Harbor

注意：這裏，我將Harbor的端口修改成了1180，如果不修改Harbor的端口，默認的端口是80。

（1）修改harbor.yml文件

cd harbor
vim harbor.yml

修改的配置項如下所示。

hostname: 192.168.0.10
http:
  port: 1180
harbor_admin_password: binghe123
###並把https註釋掉，不然在安裝的時候會報錯：ERROR:root:Error: The protocol is https but attribute ssl_cert is not set
#https:
  #port: 443
  #certificate: /your/certificate/path
  #private_key: /your/private/key/path

（2）修改daemon.json文件

修改/etc/docker/daemon.json文件，沒有的話就創建，在/etc/docker/daemon.json文件中添加如下內容。

[root@binghe~]# cat /etc/docker/daemon.json
{
  "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"],
  "insecure-registries":["192.168.0.10:1180"]
}

也可以在服務器上使用 ip addr 命令查看本機所有的IP地址段，將其配置到/etc/docker/daemon.json文件中。這裏，我配置后的文件內容如下所示。

{
    "registry-mirrors": ["https://zz3sblpi.mirror.aliyuncs.com"],
    "insecure-registries":["192.168.175.0/16","172.17.0.0/16", "172.18.0.0/16", "172.16.29.0/16", "192.168.0.10:1180"]
}

4.安裝並啟動harbor

配置完成后，輸入如下命令即可安裝並啟動Harbor

[root@binghe harbor]# ./install.sh

5.登錄Harbor並添加賬戶

安裝成功后，在瀏覽器地址欄輸入http://192.168.0.10:1180打開鏈接，輸入用戶名admin和密碼binghe123，登錄系統。

接下來，我們選擇用戶管理，添加一個管理員賬戶，為後續打包Docker鏡像和上傳Docker鏡像做準備。

密碼為Binghe123。點擊確，此時，賬戶binghe還不是管理員，此時選中binghe賬戶，點擊“設置為管理員”。

此時，binghe賬戶就被設置為管理員了。到此，Harbor的安裝就完成了。

6.修改Harbor端口

如果安裝Harbor后，大家需要修改Harbor的端口，可以按照如下步驟修改Harbor的端口，這裏，我以將80端口修改為1180端口為例

（1）修改harbor.yml文件

cd harbor
vim harbor.yml

修改的配置項如下所示。

hostname: 192.168.0.10
http:
  port: 1180
harbor_admin_password: binghe123
###並把https註釋掉，不然在安裝的時候會報錯：ERROR:root:Error: The protocol is https but attribute ssl_cert is not set
#https:
  #port: 443
  #certificate: /your/certificate/path
  #private_key: /your/private/key/path

（2）修改docker-compose.yml文件

vim docker-compose.yml

修改的配置項如下所示。

ports:
      - 1180:80

（3）修改config.yml文件

cd common/config/registry
vim config.yml

修改的配置項如下所示。

realm: http://192.168.0.10:1180/service/token

（4）重啟Docker

systemctl daemon-reload
systemctl restart docker.service

（5）重啟Harbor

[root@binghe harbor]# docker-compose down
Stopping harbor-log ... done
Removing nginx             ... done
Removing harbor-portal     ... done
Removing harbor-jobservice ... done
Removing harbor-core       ... done
Removing redis             ... done
Removing registry          ... done
Removing registryctl       ... done
Removing harbor-db         ... done
Removing harbor-log        ... done
Removing network harbor_harbor
 
[root@binghe harbor]# ./prepare
prepare base dir is set to /mnt/harbor
Clearing the configuration file: /config/log/logrotate.conf
Clearing the configuration file: /config/nginx/nginx.conf
Clearing the configuration file: /config/core/env
Clearing the configuration file: /config/core/app.conf
Clearing the configuration file: /config/registry/root.crt
Clearing the configuration file: /config/registry/config.yml
Clearing the configuration file: /config/registryctl/env
Clearing the configuration file: /config/registryctl/config.yml
Clearing the configuration file: /config/db/env
Clearing the configuration file: /config/jobservice/env
Clearing the configuration file: /config/jobservice/config.yml
Generated configuration file: /config/log/logrotate.conf
Generated configuration file: /config/nginx/nginx.conf
Generated configuration file: /config/core/env
Generated configuration file: /config/core/app.conf
Generated configuration file: /config/registry/config.yml
Generated configuration file: /config/registryctl/env
Generated configuration file: /config/db/env
Generated configuration file: /config/jobservice/env
Generated configuration file: /config/jobservice/config.yml
loaded secret from file: /secret/keys/secretkey
Generated configuration file: /compose_location/docker-compose.yml
Clean up the input dir
 
[root@binghe harbor]# docker-compose up -d
Creating network "harbor_harbor" with the default driver
Creating harbor-log ... done
Creating harbor-db   ... done
Creating redis       ... done
Creating registry    ... done
Creating registryctl ... done
Creating harbor-core ... done
Creating harbor-jobservice ... done
Creating harbor-portal     ... done
Creating nginx             ... done
 
[root@binghe harbor]# docker ps -a
CONTAINER ID        IMAGE                                               COMMAND                  CREATED             STATUS                             PORTS

安裝Jenkins（一般的做法）

Jenkins是一個開源的、提供友好操作界面的持續集成(CI)工具，起源於Hudson（Hudson是商用的），主要用於持續、自動的構建/測試軟件項目、監控外部任務的運行（這個比較抽象，暫且寫上，不做解釋）。Jenkins用Java語言編寫，可在Tomcat等流行的servlet容器中運行，也可獨立運行。通常與版本管理工具(SCM)、構建工具結合使用。常用的版本控制工具有SVN、GIT，構建工具有Maven、Ant、Gradle。

1.安裝nfs（之前安裝過的話，可以省略此步）

使用 nfs 最大的問題就是寫權限，可以使用 kubernetes 的 securityContext/runAsUser 指定 jenkins 容器中運行 jenkins 的用戶 uid，以此來指定 nfs 目錄的權限，讓 jenkins 容器可寫；也可以不限制，讓所有用戶都可以寫。這裏為了簡單，就讓所有用戶可寫了。

如果之前已經安裝過nfs，則這一步可以省略。找一台主機，安裝 nfs，這裏，我以在Master節點（test10服務器）上安裝nfs為例。

在命令行輸入如下命令安裝並啟動nfs。

yum install nfs-utils -y
systemctl start nfs-server
systemctl enable nfs-server

2.創建nfs共享目錄

在Master節點（test10服務器）上創建 /opt/nfs/jenkins-data目錄作為nfs的共享目錄，如下所示。

mkdir -p /opt/nfs/jenkins-data

接下來，編輯/etc/exports文件，如下所示。

vim /etc/exports

在/etc/exports文件文件中添加如下一行配置。

/opt/nfs/jenkins-data 192.168.175.0/24(rw,all_squash)

這裏的 ip 使用 kubernetes node 節點的 ip 範圍，後面的 all_squash 選項會將所有訪問的用戶都映射成 nfsnobody 用戶，不管你是什麼用戶訪問，最終都會壓縮成 nfsnobody，所以只要將 /opt/nfs/jenkins-data 的屬主改為 nfsnobody，那麼無論什麼用戶來訪問都具有寫權限。

這個選項在很多機器上由於用戶 uid 不規範導致啟動進程的用戶不同，但是同時要對一個共享目錄具有寫權限時很有效。

接下來，為 /opt/nfs/jenkins-data目錄授權，並重新加載nfs，如下所示。

#為/opt/nfs/jenkins-data/目錄授權
chown -R 1000 /opt/nfs/jenkins-data/
#重新加載nfs-server
systemctl reload nfs-server

在K8S集群中任意一個節點上使用如下命令進行驗證：

#查看nfs系統的目錄權限
showmount -e NFS_IP

如果能夠看到 /opt/nfs/jenkins-data 就表示 ok 了。

具體如下所示。

[root@test10 ~]# showmount -e 192.168.0.10
Export list for 192.168.0.10:
/opt/nfs/jenkins-data 192.168.175.0/24

[root@test11 ~]# showmount -e 192.168.0.10
Export list for 192.168.0.10:
/opt/nfs/jenkins-data 192.168.175.0/24

3.創建PV

Jenkins 其實只要加載對應的目錄就可以讀取之前的數據，但是由於 deployment 無法定義存儲卷，因此我們只能使用 StatefulSet。

首先創建 pv，pv 是給 StatefulSet 使用的，每次 StatefulSet 啟動都會通過 volumeClaimTemplates 這個模板去創建 pvc，因此必須得有 pv，才能供 pvc 綁定。

創建jenkins-pv.yaml文件，文件內容如下所示。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins
spec:
  nfs:
    path: /opt/nfs/jenkins-data
    server: 192.168.0.10
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 1Ti

我這裏給了 1T存儲空間，可以根據實際配置。

執行如下命令創建pv。

kubectl apply -f jenkins-pv.yaml

4.創建serviceAccount

創建service account，因為 jenkins 後面需要能夠動態創建 slave，因此它必須具備一些權限。

創建jenkins-service-account.yaml文件，文件內容如下所示。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: jenkins
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: jenkins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: jenkins
subjects:
  - kind: ServiceAccount
    name: jenkins

上述配置中，創建了一個 RoleBinding 和一個 ServiceAccount，並且將 RoleBinding 的權限綁定到這個用戶上。所以，jenkins 容器必須使用這個 ServiceAccount 運行才行，不然 RoleBinding 的權限它將不具備。

RoleBinding 的權限很容易就看懂了，因為 jenkins 需要創建和刪除 slave，所以才需要上面這些權限。至於 secrets 權限，則是 https 證書。

執行如下命令創建serviceAccount。

kubectl apply -f jenkins-service-account.yaml

5.安裝Jenkins

創建jenkins-statefulset.yaml文件，文件內容如下所示。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: jenkins
  labels:
    name: jenkins
spec:
  selector:
    matchLabels:
      name: jenkins
  serviceName: jenkins
  replicas: 1
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      name: jenkins
      labels:
        name: jenkins
    spec:
      terminationGracePeriodSeconds: 10
      serviceAccountName: jenkins
      containers:
        - name: jenkins
          image: docker.io/jenkins/jenkins:lts
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
            - containerPort: 32100
          resources:
            limits:
              cpu: 4
              memory: 4Gi
            requests:
              cpu: 4
              memory: 4Gi
          env:
            - name: LIMITS_MEMORY
              valueFrom:
                resourceFieldRef:
                  resource: limits.memory
                  divisor: 1Mi
            - name: JAVA_OPTS
              # value: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=1 -XshowSettings:vm -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85
              value: -Xmx$(LIMITS_MEMORY)m -XshowSettings:vm -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85
          volumeMounts:
            - name: jenkins-home
              mountPath: /var/jenkins_home
          livenessProbe:
            httpGet:
              path: /login
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 5
            failureThreshold: 12 # ~2 minutes
          readinessProbe:
            httpGet:
              path: /login
              port: 8080
            initialDelaySeconds: 60
            timeoutSeconds: 5
            failureThreshold: 12 # ~2 minutes
  # pvc 模板，對應之前的 pv
  volumeClaimTemplates:
    - metadata:
        name: jenkins-home
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Ti

jenkins 部署時需要注意它的副本數，你的副本數有多少就要有多少個 pv，同樣，存儲會有多倍消耗。這裏我只使用了一個副本，因此前面也只創建了一個 pv。

使用如下命令安裝Jenkins。

kubectl apply -f jenkins-statefulset.yaml

6.創建Service

創建jenkins-service.yaml文件，主要用於後台運行Jenkins，文件內容如下所示。

apiVersion: v1
kind: Service
metadata:
  name: jenkins
spec:
  # type: LoadBalancer
  selector:
    name: jenkins
  # ensure the client ip is propagated to avoid the invalid crumb issue when using LoadBalancer (k8s >=1.7)
  #externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
      nodePort: 31888
      targetPort: 8080
      protocol: TCP
    - name: jenkins-agent
      port: 32100
      nodePort: 32100
      targetPort: 32100
      protocol: TCP
  type: NodePort

使用如下命令安裝Service。

kubectl apply -f jenkins-service.yaml

7.安裝 ingress

jenkins 的 web 界面需要從集群外訪問，這裏我們選擇的是使用 ingress。創建jenkins-ingress.yaml文件，文件內容如下所示。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins
spec:
  rules:
    - http:
        paths:
          - path: /
            backend:
              serviceName: jenkins
              servicePort: 31888
      host: jekins.binghe.com

這裏，需要注意的是host必須配置為域名或者主機名，否則會報錯，如下所示。

The Ingress "jenkins" is invalid: spec.rules[0].host: Invalid value: "192.168.0.10": must be a DNS name, not an IP address

使用如下命令安裝ingress。

kubectl apply -f jenkins-ingress.yaml

最後，由於我這裏使用的是虛擬機來搭建相關的環境，在本機訪問虛擬機映射的jekins.binghe.com時，需要配置本機的hosts文件，在本機的hosts文件中加入如下配置項。

192.168.0.10 jekins.binghe.com

注意：在Windows操作系統中，hosts文件所在的目錄如下。

C:\Windows\System32\drivers\etc

接下來，就可以在瀏覽器中通過鏈接：http://jekins.binghe.com:31888 來訪問Jekins了。

物理機安裝SVN

Apache Subversion 通常被縮寫成 SVN，是一個開放源代碼的版本控制系統，Subversion 在 2000 年由 CollabNet Inc 開發，現在發展成為 Apache 軟件基金會的一個項目，同樣是一個豐富的開發者和用戶社區的一部分。

SVN相對於的RCS、CVS，採用了分支管理系統，它的設計目標就是取代CVS。互聯網上免費的版本控制服務多基於Subversion。

這裏，以在Master節點（binghe101服務器）上安裝SVN為例。

1.使用yum安裝SVN

在命令行執行如下命令安裝SVN。

yum -y install subversion

2.創建SVN庫

依次執行如下命令。

#創建/data/svn
mkdir -p /data/svn 
#初始化svn
svnserve -d -r /data/svn
#創建代碼倉庫
svnadmin create /data/svn/test

3.配置SVN

mkdir /data/svn/conf
cp /data/svn/test/conf/* /data/svn/conf/
cd /data/svn/conf/
[root@binghe101 conf]# ll
總用量 20
-rw-r--r-- 1 root root 1080 5月  12 02:17 authz
-rw-r--r-- 1 root root  885 5月  12 02:17 hooks-env.tmpl
-rw-r--r-- 1 root root  309 5月  12 02:17 passwd
-rw-r--r-- 1 root root 4375 5月  12 02:17 svnserve.conf

配置authz文件，

vim authz

配置后的內容如下所示。

[aliases]
# joe = /C=XZ/ST=Dessert/L=Snake City/O=Snake Oil, Ltd./OU=Research Institute/CN=Joe Average

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
SuperAdmin = admin
binghe = admin,binghe

# [/foo/bar]
# harry = rw
# &joe = r
# * =

# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r

[test:/]
@SuperAdmin=rw
@binghe=rw

配置passwd文件

vim passwd

配置后的內容如下所示。

[users]
# harry = harryssecret
# sally = sallyssecret
admin = admin123
binghe = binghe123

配置 svnserve.conf

vim svnserve.conf

配置后的文件如下所示。

### This file controls the configuration of the svnserve daemon, if you
### use it to allow access to this repository.  (If you only allow
### access through http: and/or file: URLs, then this file is
### irrelevant.)

### Visit http://subversion.apache.org/ for more information.

[general]
### The anon-access and auth-access options control access to the
### repository for unauthenticated (a.k.a. anonymous) users and
### authenticated users, respectively.
### Valid values are "write", "read", and "none".
### Setting the value to "none" prohibits both reading and writing;
### "read" allows read-only access, and "write" allows complete 
### read/write access to the repository.
### The sample settings below are the defaults and specify that anonymous
### users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
anon-access = none
auth-access = write
### The password-db option controls the location of the password
### database file.  Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
password-db = /data/svn/conf/passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control.  Unless you specify a path
### starting with a /, the file's location is relative to the
### directory containing this file.  The specified path may be a
### repository relative URL (^/) or an absolute file:// URL to a text
### file in a Subversion repository.  If you don't specify an authz-db,
### no path-based access control is done.
### Uncomment the line below to use the default authorization file.
authz-db = /data/svn/conf/authz
### The groups-db option controls the location of the file with the
### group definitions and allows maintaining groups separately from the
### authorization rules.  The groups-db file is of the same format as the
### authz-db file and should contain a single [groups] section with the
### group definitions.  If the option is enabled, the authz-db file cannot
### contain a [groups] section.  Unless you specify a path starting with
### a /, the file's location is relative to the directory containing this
### file.  The specified path may be a repository relative URL (^/) or an
### absolute file:// URL to a text file in a Subversion repository.
### This option is not being used by default.
# groups-db = groups
### This option specifies the authentication realm of the repository.
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa.  The default realm
### is repository's uuid.
realm = svn
### The force-username-case option causes svnserve to case-normalize
### usernames before comparing them against the authorization rules in the
### authz-db file configured above.  Valid values are "upper" (to upper-
### case the usernames), "lower" (to lowercase the usernames), and
### "none" (to compare usernames as-is without case conversion, which
### is the default behavior).
# force-username-case = none
### The hooks-env options specifies a path to the hook script environment 
### configuration file. This option overrides the per-repository default
### and can be used to configure the hook script environment for multiple 
### repositories in a single file, if an absolute path is specified.
### Unless you specify an absolute path, the file's location is relative
### to the directory containing this file.
# hooks-env = hooks-env

[sasl]
### This option specifies whether you want to use the Cyrus SASL
### library for authentication. Default is false.
### Enabling this option requires svnserve to have been built with Cyrus
### SASL support; to check, run 'svnserve --version' and look for a line
### reading 'Cyrus SASL authentication is available.'
# use-sasl = true
### These options specify the desired strength of the security layer
### that you want SASL to provide. 0 means no encryption, 1 means
### integrity-checking only, values larger than 1 are correlated
### to the effective key length for encryption (e.g. 128 means 128-bit
### encryption). The values below are the defaults.
# min-encryption = 0
# max-encryption = 256

接下來，將/data/svn/conf目錄下的svnserve.conf文件複製到/data/svn/test/conf/目錄下。如下所示。

[root@binghe101 conf]# cp /data/svn/conf/svnserve.conf /data/svn/test/conf/
cp：是否覆蓋'/data/svn/test/conf/svnserve.conf'？ y

4.啟動SVN服務

（1）創建svnserve.service服務

創建svnserve.service文件

vim /usr/lib/systemd/system/svnserve.service

文件的內容如下所示。

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target
Documentation=man:svnserve(8)

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/svnserve
#ExecStart=/usr/bin/svnserve --daemon --pid-file=/run/svnserve/svnserve.pid $OPTIONS
ExecStart=/usr/bin/svnserve --daemon $OPTIONS
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

接下來執行如下命令使配置生效。

systemctl daemon-reload

命令執行成功后，修改 /etc/sysconfig/svnserve 文件。

vim /etc/sysconfig/svnserve

修改后的文件內容如下所示。

# OPTIONS is used to pass command-line arguments to svnserve.
# 
# Specify the repository location in -r parameter:
OPTIONS="-r /data/svn"

（2）啟動SVN

首先查看SVN狀態，如下所示。

[root@test10 conf]# systemctl status svnserve.service
● svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:svnserve(8)

可以看到，此時SVN並沒有啟動，接下來，需要啟動SVN。

systemctl start svnserve.service

設置SVN服務開機自啟動。

systemctl enable svnserve.service

接下來，就可以下載安裝TortoiseSVN，輸入鏈接svn://192.168.0.10/test 並輸入用戶名binghe，密碼binghe123來連接SVN了。

Docker安裝SVN

拉取SVN鏡像

docker pull docker.io/elleflorio/svn-server

啟動SVN容器

docker run -v /usr/local/svn:/home/svn -v /usr/local/svn/passwd:/etc/subversion/passwd -v /usr/local/apache2:/run/apache2 --name svn_server -p 3380:80 -p 3690:3960 -e SVN_REPONAME=repos -d docker.io/elleflorio/svn-server

進入SVN容器內部

docker exec -it svn_server bash

進入容器后，可以參照物理機安裝SVN的方式配置SVN倉庫。

物理機安裝Jenkins

注意：安裝Jenkins之前需要安裝JDK和Maven，我這裏同樣將Jenkins安裝在Master節點（binghe101服務器）。

1.啟用Jenkins庫

運行以下命令以下載repo文件並導入GPG密鑰：

wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

2.安裝Jenkins

執行如下命令安裝Jenkis。

yum install jenkins

接下來，修改Jenkins默認端口，如下所示。

vim /etc/sysconfig/jenkins

修改后的兩項配置如下所示。

JENKINS_JAVA_CMD="/usr/local/jdk1.8.0_212/bin/java"
JENKINS_PORT="18080"

此時，已經將Jenkins的端口由8080修改為18080

3.啟動Jenkins

在命令行輸入如下命令啟動Jenkins。

systemctl start jenkins

配置Jenkins開機自啟動。

systemctl enable jenkins

查看Jenkins的運行狀態。

[root@test10 ~]# systemctl status jenkins
● jenkins.service - LSB: Jenkins Automation Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins; generated)
   Active: active (running) since Tue 2020-05-12 04:33:40 EDT; 28s ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 71 (limit: 26213)
   Memory: 550.8M

說明，Jenkins啟動成功。

配置Jenkins運行環境

1.登錄Jenkins

首次安裝后，需要配置Jenkins的運行環境。首先，在瀏覽器地址欄訪問鏈接http://192.168.0.10:18080，打開Jenkins界面。

根據提示使用如下命令到服務器上找密碼值，如下所示。

[root@binghe101 ~]# cat /var/lib/jenkins/secrets/initialAdminPassword
71af861c2ab948a1b6efc9f7dde90776

將密碼71af861c2ab948a1b6efc9f7dde90776複製到文本框，點擊繼續。會跳轉到自定義Jenkins頁面，如下所示。

這裏，可以直接選擇“安裝推薦的插件”。之後會跳轉到一個安裝插件的頁面，如下所示。

此步驟可能有下載失敗的情況，可直接忽略。

2.安裝插件

需要安裝的插件

Kubernetes Cli Plugin：該插件可直接在Jenkins中使用kubernetes命令行進行操作。
Kubernetes plugin：使用kubernetes則需要安裝該插件
Kubernetes Continuous Deploy Plugin：kubernetes部署插件，可根據需要使用

還有更多的插件可供選擇，可點擊系統管理->管理插件進行管理和添加，安裝相應的Docker插件、SSH插件、Maven插件。其他的插件可以根據需要進行安裝。如下圖所示。

3.配置Jenkins

（1）配置JDK和Maven

在Global Tool Configuration中配置JDK和Maven，如下所示，打開Global Tool Configuration界面。

接下來就開始配置JDK和Maven了。

由於我在服務器上將Maven安裝在/usr/local/maven-3.6.3目錄下，所以，需要在“Maven 配置”中進行配置，如下圖所示。

接下來，配置JDK，如下所示。

注意：不要勾選“Install automatically”

接下來，配置Maven，如下所示。

注意：不要勾選“Install automatically”

（2）配置SSH

進入Jenkins的Configure System界面配置SSH，如下所示。

找到 SSH remote hosts 進行配置。

配置完成后，點擊Check connection按鈕，會显示 Successfull connection。如下所示。

至此，Jenkins的基本配置就完成了。

Jenkins發布Docker項目到K8s集群

1.調整SpringBoot項目的配置

實現，SpringBoot項目中啟動類所在的模塊的pom.xml需要引入打包成Docker鏡像的配置，如下所示。

  <properties>
  	 	<docker.repostory>192.168.0.10:1180</docker.repostory>
        <docker.registry.name>test</docker.registry.name>
        <docker.image.tag>1.0.0</docker.image.tag>
        <docker.maven.plugin.version>1.4.10</docker.maven.plugin.version>
  </properties>

<build>
  		<finalName>test-starter</finalName>
		<plugins>
            <plugin>
			    <groupId>org.springframework.boot</groupId>
			    <artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
			
			<!-- docker的maven插件，官網：https://github.com/spotify/docker‐maven‐plugin -->
			<!-- Dockerfile maven plugin -->
			<plugin>
			    <groupId>com.spotify</groupId>
			    <artifactId>dockerfile-maven-plugin</artifactId>
			    <version>${docker.maven.plugin.version}</version>
			    <executions>
			        <execution>
			        <id>default</id>
			        <goals>
			            <!--如果package時不想用docker打包,就註釋掉這個goal-->
			            <goal>build</goal>
			            <goal>push</goal>
			        </goals>
			        </execution>
			    </executions>
			    <configuration>
			    	<contextDirectory>${project.basedir}</contextDirectory>
			        <!-- harbor 倉庫用戶名及密碼-->
			        <useMavenSettingsForAuth>useMavenSettingsForAuth>true</useMavenSettingsForAuth>
			        <repository>${docker.repostory}/${docker.registry.name}/${project.artifactId}</repository>
			        <tag>${docker.image.tag}</tag>
			        <buildArgs>
			            <JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
			        </buildArgs>
			    </configuration>
			</plugin>

        </plugins>
        
		<resources>
			<!-- 指定 src/main/resources下所有文件及文件夾為資源文件 -->
			<resource>
				<directory>src/main/resources</directory>
				<targetPath>${project.build.directory}/classes</targetPath>
				<includes>
					<include>**/*</include>
				</includes>
				<filtering>true</filtering>
			</resource>
		</resources>
	</build>

接下來，在SpringBoot啟動類所在模塊的根目錄創建Dockerfile，內容示例如下所示。

#添加依賴環境，前提是將Java8的Docker鏡像從官方鏡像倉庫pull下來，然後上傳到自己的Harbor私有倉庫中
FROM 192.168.0.10:1180/library/java:8
#指定鏡像製作作者
MAINTAINER binghe
#運行目錄
VOLUME /tmp
#將本地的文件拷貝到容器
ADD target/*jar app.jar
#啟動容器后自動執行的命令
ENTRYPOINT [ "java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/app.jar" ]

根據實際情況，自行修改。

注意：FROM 192.168.0.10:1180/library/java:8的前提是執行如下命令。

docker pull java:8
docker tag java:8 192.168.0.10:1180/library/java:8
docker login 192.168.0.10:1180
docker push 192.168.0.10:1180/library/java:8

在SpringBoot啟動類所在模塊的根目錄創建yaml文件，錄入叫做test.yaml文件，內容如下所示。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-starter
  labels:
    app: test-starter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-starter
  template:
    metadata:
      labels:
        app: test-starter
    spec:
      containers:
      - name: test-starter
        image: 192.168.0.10:1180/test/test-starter:1.0.0
        ports:
        - containerPort: 8088
      nodeSelector:
        clustertype: node12

---
apiVersion: v1
kind: Service
metadata:
  name: test-starter
  labels:
    app: test-starter
spec:
  ports:
    - name: http
      port: 8088
      nodePort: 30001
  type: NodePort
  selector:
    app: test-starter

2.Jenkins配置發布項目

將項目上傳到SVN代碼庫，例如地址為svn://192.168.0.10/test

接下來，在Jenkins中配置自動發布。步驟如下所示。

點擊新建Item。

在描述文本框中輸入描述信息，如下所示。

接下來，配置SVN信息。

注意：配置GitLab的步驟與SVN相同，不再贅述。

定位到Jenkins的“構建模塊”，使用Execute Shell來構建發布項目到K8S集群。

執行的命令依次如下所示。

#刪除本地原有的鏡像,不會影響Harbor倉庫中的鏡像
docker rmi 192.168.0.10:1180/test/test-starter:1.0.0
#使用Maven編譯、構建Docker鏡像，執行完成后本地Docker容器中會重新構建鏡像文件
/usr/local/maven-3.6.3/bin/mvn -f ./pom.xml clean install -Dmaven.test.skip=true
#登錄 Harbor倉庫
docker login 192.168.0.10:1180 -u binghe -p Binghe123
#上傳鏡像到Harbor倉庫
docker push 192.168.0.10:1180/test/test-starter:1.0.0
#停止並刪除K8S集群中運行的
/usr/bin/kubectl delete -f test.yaml
#將Docker鏡像重新發布到K8S集群
/usr/bin/kubectl apply -f test.yaml

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

信息泄漏時代，如何讓自己的密碼更安全？

發佈日期: 2020-12-14 作者: admin

密碼的重要性，相信大家都不言而喻。而密碼泄漏或信息泄漏，經常是層出不窮地出現，令人防不勝防。所以，一個強大而複雜的密碼是保證自己賬戶安全的第一步。

為了防止信息泄漏，我們可以做些什麼呢？

密碼足夠複雜；
每個平台密碼都不一樣，比如QQ，微信，郵箱等；
定期更換密碼。

那怎樣的密碼才算是比較可靠的密碼？一般而言，一個密碼至少12位字符，包含数字，包含大小寫，包含特殊符號，不使用現有單詞，即是一個比較複雜的密碼。

那你自認為比較安全的密碼，是否真正的安全呢？這裏良許介紹兩個工具可以用來評估你的密碼的安全性—— cracklib 和 pwscore 。

cracklib介紹

1. cracklib 的安裝

cracklib 可以用來檢測你的密碼是否可靠，在大部分發行版里都可以直接安裝這個工具。

對於 Fedora 系的發行版，可以使用 dnf 命令安裝 cracklib：

$ sudo dnf install cracklib

對於 Debian/Ubuntu 系的發行版，可以使用 apt-get 命令安裝：

$ sudo apt install libcrack2

對於 Arch 系統的發行版，可以使用 pacman 命令安裝：

$ sudo pacman -S cracklib

對於 RHEL/CentOS 系的發行版，可以使用 yum 命令安裝：

$ sudo yum install cracklib

對於 openSUSE 系的發行版，可以使用 zypper 命令安裝：

$ sudo zypper install cracklib

2. cracklib 的使用

我們直接來看幾個實例。

如果你的密碼里包含了人名、地名，或者我們常用的單詞，那麼會被提示 it is based on a dictionary word ：

$ echo "password" | cracklib-check
password: it is based on a dictionary word

Linux 下默認的密碼長度是 7 個字符，如果你的密碼長度小於 7 個字符，會被提示 it is WAY too short ：

$ echo "123" | cracklib-check 
123: it is WAY too short

如果你的密碼比較強壯，則會提示 OK ：

$ echo "ME$2w!@fgty6723" | cracklib-check
ME!@fgty6723: OK

pwscore 介紹

我們使用 cracklib 工具只能判斷一個密碼是否安全，但具體也不知道它有多安全。而 pwscore 工具就能告訴你，你的密碼強度可以打幾分。

1. pwscore 的安裝

同樣地，對於大部分 Linux 發行版，可以直接安裝 pwscore 工具。安裝過程與 cracklib 類似，只需將 cracklib 改成 pwscore 即可。這裏介紹 Debian/Ubuntu 系發行版的安裝，其餘的類似：

$ sudo apt install libpwquality

2. pwscore 的使用

同樣直接來看幾個實例。

與 cracklib 類似，如果你的密碼里包含了人名、地名，或者我們常用的單詞，那麼會被提示 it is based on a dictionary word ；如果密碼長度短於 7 個字符，會被提示 it is WAY too short 。

$ echo "password" | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word

$ echo "123" | pwscore
Password quality check failed:
 The password is shorter than 8 characters

如果你的密碼合乎規範，那麼它就會給你打相應的分數：

$ echo "ME!@fgty6723" | pwscore
90

小結

雖然黑客有一萬種竊取你的私人數據的方法，但一個強壯的密碼是你保護你敏感數據的第一步。網絡環境本身就不是 100% 安全，如果你再使用一個很容易玫破的密碼，那下一個艷照門可能很快就會再次出現……

公眾號：良許Linux

有收穫？希望老鐵們來個三連擊，給更多的人看到這篇文章

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

解Bug之路-記一次存儲故障的排查過程

Bug現場

偶發性錯誤

開始排查是否網絡問題

又發生了兩次

開始排查日誌

進一步進行排查

只能靠日誌分析了

為什麼之前的模擬宕機測試發現不了這一點

為什麼commit會變慢?

緊急修復方案

一身冷汗

中間件修復

總結

公眾號

1. Netty 中的數據容器分類

2. Netty 中的內存分配

Before

Round 1

Round 2

Reference

docker registry 鏡像同步

Intro

實現思路

Docker-Registry API

獲取所有鏡像

獲取鏡像的 tag

操作示例

獲取鏡像列表：

獲取鏡像的 tag 列表

PowerShell 腳本

More

Reference

前置

template

script

style

最後

前言

日誌處理

結果封裝

參數校驗

異常處理

環境搭建概述

1.K8S是什麼？

2.為什麼要用K8S?

3.使用K8S有哪些好處？

4.環境構成

服務器規劃

安裝環境版本

安裝Docker環境

安裝docker-compose

1.下載docker-compose文件

2.為docker-compose文件賦予可執行權限

3.查看docker-compose版本

安裝K8S集群環境

安裝K8S基礎環境

初始化Master節點

初始化Worker節點

重啟K8S集群引起的問題

1.Worker節點故障不能啟動

2.Pod崩潰或不能正常訪問

K8S安裝ingress-nginx

1.創建ingress-nginx命名空間

2.安裝ingress controller

3.安裝K8S SVC：ingress-nginx

4.訪問K8S SVC：ingress-nginx

K8S安裝gitlab代碼倉庫

1.創建k8s-ops命名空間

2.安裝gitlab-redis

3.安裝gitlab-postgresql

4.安裝gitlab

5.安裝完成

安裝Harbor私有倉庫

1.下載Harbor的離線安裝版本

2.解壓Harbor的安裝包

3.配置Harbor

4.安裝並啟動harbor

5.登錄Harbor並添加賬戶

6.修改Harbor端口