中部空污嚴重，台中火力電廠屢屢成為眾矢之的，根據最新空污排放清冊統計，台中市PM2.5排放來源，中火佔11.2%，柴油大貨車緊追在後，貢獻10.1%，但若從全國尺度來看，中火佔整體1.3%，而柴油大貨車高達10.17%。
中興大學環工系教授莊秉潔指出，一月初出現嚴重空污，當時中火已減排七成，空品仍不佳，PM2.5來到每立方公尺41微克，其中14微克來自柴油貨車。莊秉潔教授指出，台灣訂下2050年要減碳50%，光汰換老舊柴油大貨車還不夠，應推出更優惠的補助，鼓勵業者使用電動大貨車，成效才會明顯。
【其他文章推薦】
※空壓機這裡買最划算!
※貨梯使用安全與保養
※如何知道自已的電腦cpu支不支持AVX指令集?
※臭氧機推薦
※高效率洗滌塔活性碳設備有哪些?
內飾Q50L的內飾風格顯得有些個性，並不如外觀給人感覺那麼的運動，更偏向一台家用車，但由於豪華品牌的定位，用料做工層面還是非常厚道細膩的類型。由於也是前置后驅，後排同樣存在這中間地台較高的特點。動力Q50L搭載的2。
說到30-40萬的豪華品牌車型，不少人第一主觀就會聯想到德系三強BBA，儘管BBA品牌雄踞豪華車市場銷量榜前列多年，但是路面曝光率過高的事實也不免顯得稍微喪失了一些個性，其實在豪華車市場，還有不少新晉的車型。
捷豹XFL
推薦車型：2.0T 200pS風華版
指導價格：38.80萬
捷豹XFL是捷豹品牌在中國首款國產的車型，對標車型是奔馳E級，寶馬5系這類豪華品牌中大型車，但是從定價來看，XFL的入門定價顯得頗為“謙虛”，38.80萬的入門車型配置已經非常不錯。
外觀
XFL的外觀設計呈現的車身姿態比較低矮，真的就宛如一隻卧身伏擊的豹子，囂張的前臉更凸顯了它品牌血統里就富有的攻擊氣質。
車尾設計優雅沉穩，並沒有太多視覺上覺得突兀的地方，或許這也是英國車的一種特點吧；XFL車身修長，超過5米，但並不顯得生拉硬拽，整車比例相當協調，線條勾勒手法流暢柔和，表明了它同樣是一台尺寸傲人的豪華轎車。
內飾
作為最低配的風華版，車內裝飾並沒有使用高配車型上所使用的撞色設計，但根據市場反饋，似乎消費者對於全黑內飾並不會抗拒。
XFL內飾秉承了捷豹家族式的風格，採用了整體環抱式的設計理念，讓前排人員駕乘時的包裹感更加強烈。
由於是前置后驅的驅動形式，後排地板因為傳動軸的原因導致地台較高，乘坐三人稍微有些不便利。
動力
200pS 風華版搭載了一台2.0T渦輪增壓發動機，最大馬力200匹，峰值扭矩320牛米，動力參數上領先於同級別主流的豪華品牌車型。與之匹配的是一台8擋手自一體變速箱，日常行駛動力儲備相當充沛，變速箱的平順性也非常出色。
英菲尼迪Q50L
推薦車型：2016款 2.0T悅享版
指導價格：30.98萬
英菲尼迪是誕生於北美地區的日產豪華品牌，旗下的Q50L是一款性價比較高的中型三廂車，對錶車型是奧迪A4L、寶馬3系這一級別的豪華品牌車型。作為豪華品牌車型，27.98萬的起售門檻還算不錯。
外觀
Q50L同樣也是作為東風英菲尼迪在華國產的首款車型，相較於進口Q50，Q50L的軸距加長了48mm，車身加長50mm，更大尺寸的車身和更長的軸距也讓Q50L更向“豪華”層面靠攏一分。
英菲尼迪Q50L採用了“長車頭短車尾”的造型設計，視覺效果保持一個上揚的態勢，營造出了一種較為兇狠的感覺，車尾緊湊飽滿，外露的雙邊排氣管凸顯了轎跑車型的運動范兒，Q50L偏運動風格的造型也是年輕人更喜歡的類型。
內飾
Q50L的內飾風格顯得有些個性，並不如外觀給人感覺那麼的運動，更偏向一台家用車，但由於豪華品牌的定位，用料做工層面還是非常厚道細膩的類型；由於也是前置后驅，後排同樣存在這中間地台較高的特點。
動力
Q50L搭載的2.0T發動機，最大馬力211匹，峰值扭矩350牛米，匹配的是7速手自一體變速箱，整體調校稍微有些激進，配合上略顯沉重但是十分精準的轉向，Q50L是一台極其富有駕駛樂趣的三廂車。
林肯MKZ
推薦車型：2017款 2.0T尊享版
指導價格：30.48萬
林肯和凱迪拉克一樣，都曾經作為美國總統用車的品牌，只是凱迪拉克在中國市場耕耘已久，而林肯則更多的是作為後起之秀意圖在國內立足。林肯MKZ是目前林肯旗下定位相對親民的一款三廂轎車，起步售價28.48萬，這個價位也引起了不少目標車型在ATS-L、寶馬3系這類車型潛在買家的關注。
外觀：
2017款的MKZ外觀借鑒了林肯自家旗艦車型Continental（大陸）的設計，未來這種尺寸更大，風格更沉穩的進氣格柵設計很有可能成為林肯最新的家族風格。MKZ整體外觀並不激進，圓潤大氣的設計理念讓它彰顯出一種行政級的嚴肅氣質。車尾標誌性的貫穿式尾燈永遠是林肯品牌的辨別武器，就目前來說，一台林肯MKZ還是非常小眾的存在。
內飾：
作為福特旗下的豪華品牌，MKZ的內飾風格看上去高檔感還是相對出色，中間按鍵式的換擋機構對於眾多消費者來說一時間可能難以適應，不過操作便利程度還是很高。由於MKZ是前驅車型，後排地台相對平整，在乘坐空間上的的捨棄程度沒前兩款那麼高，後排空間相對充裕。
動力：
林肯MKZ搭載的是2.0T渦輪增壓發動機，最大馬力203匹，峰值扭矩381牛米，匹配的是6速手自一體變速箱，調校風格也是偏向“福特”的類型，油門輕快，動力輸出很直接。
全文總結：現如今很多80後人群買車的預算區間已經上升到30萬的層級，但是多數人的選擇依舊停留在BBA，不是說BBA不好，而是在崇尚個性化的當下，選擇一款不一樣的，也正是符合年輕人個性化訴求的選擇。
以上三款車型，捷豹接近40萬的售價或許對於大多數人來說還是高了，所以推薦在Q50L和MKZ之間做抉擇；而喜歡駕駛樂趣和操控感的可以考慮Q50L，后驅布局，動力不俗；
偏向沉穩舒適訴求的朋友則可以考慮林肯MKZ，畢竟定位就是一款偏向舒適的中型車。亦個性亦豪華，三十萬級別這兩款都是不錯的選擇。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※想知道最厲害的網頁設計公司"嚨底家"!
※別再煩惱如何寫文案,掌握八大原則!
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※回頭車貨運收費標準
※台中搬家公司費用怎麼算?
本文是我在閱讀 Koa 源碼后，並實現迷你版 Koa 的過程。如果你使用過 Koa 但不知道內部的原理，我想這篇文章應該能夠幫助到你，實現一個迷你版的 Koa 不會很難。
本文會循序漸進的解析內部原理，包括：
application.js: 入口文件，裡面包括我們常用的 use 方法、listen 方法以及對 ctx.body 做輸出處理context.js: 主要是做屬性和方法的代理，讓用戶能夠更簡便的訪問到request和response的屬性和方法request.js: 對原生的 req 屬性做處理，擴展更多可用的屬性和方法，比如：query 屬性、get 方法response.js: 對原生的 res 屬性做處理，擴展更多可用的屬性和方法，比如：status 屬性、set 方法用法：
const Coa = require('./coa/application')
const app = new Coa()
// 應用中間件
app.use((ctx) => {
ctx.body = '<h1>Hello</h1>'
})
app.listen(3000, '127.0.0.1')
application.js:
const http = require('http')
module.exports = class Coa {
use(fn) {
this.fn = fn
}
// listen 只是語法糖 本身還是使用 http.createServer
listen(...args) {
const server = http.createServer(this.callback())
server.listen(...args)
}
callback() {
const handleRequest = (req, res) => {
// 創建上下文
const ctx = this.createContext(req, res)
// 調用中間件
this.fn(ctx)
// 輸出內容
res.end(ctx.body)
}
return handleRequest
}
createContext(req, res) {
let ctx = {}
ctx.req = req
ctx.res = res
return ctx
}
}
基礎版本的實現很簡單，調用 use 將函數存儲起來，在啟動服務器時再執行這個函數，並輸出 ctx.body 的內容。
但是這樣是沒有靈魂的。接下來，實現 context 和中間件原理，Koa 才算完整。
ctx 為我們擴展了很多好用的屬性和方法，比如 ctx.query、ctx.set()。但它們並不是 context 封裝的，而是在訪問 ctx 上的屬性時，它內部通過屬性劫持將 request 和 response 內封裝的屬性返回。就像你訪問 ctx.query，實際上訪問的是 ctx.request.query。
說到劫持你可能會想到 Object.defineProperty，在 Kao 內部使用的是 ES6 提供的對象的 setter 和 getter，效果也是一樣的。所以要實現 ctx，我們首先要實現 request 和 response。
在此之前，需要修改下 createContext 方法：
// 這三個都是對象
const context = require('./context')
const request = require('./request')
const response = require('./response')
module.exports = class Coa {
constructor() {
this.context = context
this.request = request
this.response = response
}
createContext(req, res) {
const ctx = Object.create(this.context)
// 將擴展的 request、response 掛載到 ctx 上
// 使用 Object.create 創建以傳入參數為原型的對象，避免添加屬性時因為衝突影響到原對象
const request = ctx.request = Object.create(this.request)
const response = ctx.response = Object.create(this.response)
ctx.app = request.app = response.app = this;
// 掛載原生屬性
ctx.req = request.req = response.req = req
ctx.res = request.res = response.res = res
request.ctx = response.ctx = ctx;
request.response = response;
response.request = request;
return ctx
}
}
上面一堆花里胡哨的賦值，是為了能通過多種途徑獲取屬性。比如獲取 query 屬性，可以有 ctx.query、ctx.request.query、ctx.app.query 等等的方式。
如果你覺得看起來有點冗餘，也可以主要理解這幾行，因為我們實現源碼時也就用到下面這些：
const request = ctx.request = Object.create(this.request)
const response = ctx.response = Object.create(this.response)
ctx.req = request.req = response.req = req
ctx.res = request.res = response.res = res
request.js：
const url = require('url')
module.exports = {
/* 查看這兩步操作
* const request = ctx.request = Object.create(this.request)
* ctx.req = request.req = response.req = req
*
* 此時的 this 是指向 ctx，所以這裏的 this.req 訪問的是原生屬性 req
* 同樣，也可以通過 this.request.req 來訪問
*/
// 請求的 query 參數
get query() {
return url.parse(this.req.url).query
},
// 請求的路徑
get path() {
return url.parse(this.req.url).pathname
},
// 請求的方法
get method() {
return this.req.method.toLowerCase()
}
}
response.js：
module.exports = {
// 這裏的 this.res 也和上面同理
// 返回的狀態碼
get status() {
return this.res.statusCode
},
set status(val) {
return this.res.statusCode = val
},
// 返回的輸出內容
get body() {
return this._body
},
set body(val) {
return this._body = val
},
// 設置頭部
set(filed, val) {
if (typeof filed === 'string') {
this.res.setHeader(filed, val)
}
if (toString.call(filed) === '[object Object]') {
for (const key in filed) {
this.set(key, filed[key])
}
}
}
}
通過上面的實現，我們可以使用 ctx.request.query 來訪問到擴展的屬性。但是在實際應用中，更常用的是 ctx.query。不過 query 是在 request 的屬性，通過 ctx.query 是無法訪問的。
這時只需稍微做個代理，在訪問 ctx.query 時，將 ctx.request.query 返回就可以實現上面的效果。
context.js:
module.exports = {
get query() {
return this.request.query
}
}
實際的代碼中會有很多擴展的屬性，總不可能一個一個去寫吧。為了優雅的代理屬性，Koa 使用 delegates 包實現。這裏我就直接簡單封裝下代理函數，代理函數主要用到__defineGetter__ 和 __defineSetter__ 兩個方法。
在對象上都會帶有 __defineGetter__ 和 __defineSetter__，它們可以將一個函數綁定在當前對象的指定屬性上，當屬性被獲取或賦值時，綁定的函數就會被調用。就像這樣：
let obj = {}
let obj1 = {
name: 'JoJo'
}
obj.__defineGetter__('name', function(){
return obj1.name
})
此時訪問 obj.name，獲取到的是 obj1.name 的值。
了解這個兩個方法的用處后，接下來開始修改 context.js：
const proto = module.exports = {
}
// getter代理
function delegateGetter(prop, name){
proto.__defineGetter__(name, function(){
return this[prop][name]
})
}
// setter代理
function delegateSetter(prop, name){
proto.__defineSetter__(name, function(val){
return this[prop][name] = val
})
}
// 方法代理
function delegateMethod(prop, name){
proto[name] = function() {
return this[prop][name].apply(this[prop], arguments)
}
}
delegateGetter('request', 'query')
delegateGetter('request', 'path')
delegateGetter('request', 'method')
delegateGetter('response', 'status')
delegateSetter('response', 'status')
delegateGetter('response', 'body')
delegateSetter('response', 'body')
delegateMethod('response', 'set')
中間件思想是 Koa 最精髓的地方，為擴展功能提供很大的幫助。這也是它雖然小，卻很強大的原因。還有一個優點，中間件使功能模塊的職責更加分明，一個功能就是一个中間件，多个中間件組合起來成為一個完整的應用。
下面是著名的“洋蔥模型”。這幅圖很形象的表達了中間件思想的作用，它就像一個流水線一樣，上游加工后的東西傳遞給下游，下游可以繼續接着加工，最終輸出加工結果。
在調用 use 註冊中間件的時候，內部會將每个中間件存儲到數組中，執行中間件時，為其提供 next 參數。調用 next 即執行下一个中間件，以此類推。當數組中的中間件執行完畢后，再原路返回。就像這樣:
app.use((ctx, next) => {
console.log('1 start')
next()
console.log('1 end')
})
app.use((ctx, next) => {
console.log('2 start')
next()
console.log('2 end')
})
app.use((ctx, next) => {
console.log('3 start')
next()
console.log('3 end')
})
輸出結果如下：
1 start
2 start
3 start
3 end
2 end
1 end
有點數據結構知識的同學，很快就想到這是一個“棧”結構，執行的順序符合“先入后出”。
下面我將內部中間件實現原理進行簡化，模擬中間件執行：
function next1() {
console.log('1 start')
next2()
console.log('1 end')
}
function next2() {
console.log('2 start')
next3()
console.log('2 end')
}
function next3() {
console.log('3 start')
console.log('3 end')
}
next1()
執行過程：
next1，將其入棧執行，輸出 1 startnext2 函數，將其入棧執行，輸出 2 startnext3 函數，將其入棧執行，輸出 3 start3 end，函數執行完畢，next3 彈出棧2 end，函數執行完畢，next2 彈出棧1 end，函數執行完畢，next1 彈出棧相信通過這個簡單的例子，都大概明白中間件的執行過程了吧。
中間件原理實現的關鍵點主要是 ctx 和 next 的傳遞。
function compose(middleware) {
return function(ctx) {
return dispatch(0)
function dispatch(i){
// 取出中間件
let fn = middleware[i]
if (!fn) {
return
}
// dispatch.bind(null, i + 1) 為應用中間件接受到的 next
// next 即下一個應用中間件
fn(ctx, dispatch.bind(null, i + 1))
}
}
}
可以看到，實現過程本質是函數的遞歸調用。在內部實現時，其實 next 沒有做什麼神奇的操作，它就是下一个中間件調用的函數，作為參數傳入供使用者調用。
下面我們來單獨測試 compose，你可以將它粘貼到控制台上運行：
function next1(ctx, next) {
console.log('1 start')
next()
console.log('1 end')
}
function next2(ctx, next) {
console.log('2 start')
next()
console.log('2 end')
}
function next3(ctx, next) {
console.log('3 start')
next()
console.log('3 end')
}
let ctx = {}
let fn = compose([next1, next2, next3])
fn(ctx)
最後，因為 Koa 中間件是可以使用 async/await 異步執行的，所以還需要修改下 compose 返回 Promise：
function compose(middleware) {
return function(ctx) {
return dispatch(0)
function dispatch(i){
// 取出中間件
let fn = middleware[i]
if (!fn) {
return Promise.resolve()
}
// dispatch.bind(null, i + 1) 為應用中間件接受到的 next
// next 即下一個應用中間件
try {
return Promise.resolve( fn(ctx, dispatch.bind(null, i + 1)) )
} catch (error) {
return Promise.reject(error)
}
}
}
}
實現完成中間件的邏輯后，將它應用到迷你版Koa中，原來的代碼邏輯要做一些修改(部分代碼忽略)
application.js:
module.exports = class Coa {
constructor() {
// 存儲中間件的數組
this.middleware = []
}
use(fn) {
if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');
// 將中間件加入數組
this.middleware.push(fn)
return this
}
listen(...args) {
const server = http.createServer(this.callback())
server.listen(...args)
}
callback() {
const handleRequest = (req, res) => {
// 創建上下文
const ctx = this.createContext(req, res)
// fn 為第一個應用中間件
const fn = this.compose(this.middleware)
// 在所有中間件執行完畢后 respond 函數用於處理 ctx.body 輸出
return fn(ctx).then(() => respond(ctx)).catch(console.error)
}
return handleRequest
}
compose(middleware) {
return function(ctx) {
return dispatch(0)
function dispatch(i){
let fn = middleware[i]
if (!fn) {
return Promise.resolve()
}
// dispatch.bind(null, i + 1) 為應用中間件接受到的 next
try {
return Promise.resolve(fn(ctx, dispatch.bind(null, i + 1)))
} catch (error) {
return Promise.reject(error)
}
}
}
}
}
function respond(ctx) {
let res = ctx.res
let body = ctx.body
if (typeof body === 'string') {
return res.end(body)
}
if (typeof body === 'object') {
return res.end(JSON.stringify(body))
}
}
application.js:
const http = require('http')
const context = require('./context')
const request = require('./request')
const response = require('./response')
module.exports = class Coa {
constructor() {
this.middleware = []
this.context = context
this.request = request
this.response = response
}
use(fn) {
if (typeof fn !== 'function') throw new TypeError('middleware must be a function!');
this.middleware.push(fn)
return this
}
listen(...args) {
const server = http.createServer(this.callback())
server.listen(...args)
}
callback() {
const handleRequest = (req, res) => {
// 創建上下文
const ctx = this.createContext(req, res)
// fn 為第一個應用中間件
const fn = this.compose(this.middleware)
return fn(ctx).then(() => respond(ctx)).catch(console.error)
}
return handleRequest
}
// 創建上下文
createContext(req, res) {
const ctx = Object.create(this.context)
// 處理過的屬性
const request = ctx.request = Object.create(this.request)
const response = ctx.response = Object.create(this.response)
// 原生屬性
ctx.app = request.app = response.app = this;
ctx.req = request.req = response.req = req
ctx.res = request.res = response.res = res
request.ctx = response.ctx = ctx;
request.response = response;
response.request = request;
return ctx
}
// 中間件處理邏輯實現
compose(middleware) {
return function(ctx) {
return dispatch(0)
function dispatch(i){
let fn = middleware[i]
if (!fn) {
return Promise.resolve()
}
// dispatch.bind(null, i + 1) 為應用中間件接受到的 next
// next 即下一個應用中間件
try {
return Promise.resolve(fn(ctx, dispatch.bind(null, i + 1)))
} catch (error) {
return Promise.reject(error)
}
}
}
}
}
// 處理 body 不同類型輸出
function respond(ctx) {
let res = ctx.res
let body = ctx.body
if (typeof body === 'string') {
return res.end(body)
}
if (typeof body === 'object') {
return res.end(JSON.stringify(body))
}
}
本文的簡單實現了 Koa 主要的功能。有興趣最好還是自己去看源碼，實現自己的迷你版 Koa。其實 Koa 的源碼不算多，總共4個文件，全部代碼包括註釋也就 1800 行左右。而且邏輯不會很難，很推薦閱讀，尤其適合源碼入門級別的同學觀看。
最後附上完整實現的代碼：github
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※別再煩惱如何寫文案,掌握八大原則!
※教你寫出一流的銷售文案?
※超省錢租車方案
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※回頭車貨運收費標準
原文鏈接：https://fuckcloudnative.io/posts/openshift4.4-install-offline-static-1-requirement/
本系列文章描述了離線環境下以 UPI (User Provisioned Infrastructure) 模式安裝 Openshift Container Platform (OCP) 4.4.5 的步驟，我的環境是 VMware ESXI 虛擬化，也適用於其他方式提供的虛擬機或物理主機。離線資源包括安裝鏡像、所有樣例 Image Stream 和 OperatorHub 中的所有 RedHat Operators。
本系列採用靜態 IP 的方式安裝 OCP 集群，如果你可以隨意分配網絡，建議採用 DHCP 的方式。
單獨準備一台節點用來執行安裝任務和離線資源準備，這台節點最好具備魔法上網的能力，以便可以同時訪問內外網，我們稱這台節點為基礎節點。
除此之外還需要部署一個私有鏡像倉庫，以供 OCP 安裝和運行時使用，要求支持 version 2 schema 2 (manifest list)，我這裏選擇的是 Quay 3.3。鏡像倉庫需要部署在另外一台節點，因為需要用到 443 端口，與後面的負載均衡端口衝突。
很多人誤以為必須聯繫 Red Hat 銷售，簽單之後才能使用 OCP4，其實不然，註冊一個開發者賬號后就可以獲得
quay.io和registry.redhat.io的拉取密鑰了。
目前最新的 OCP 版本是 4.4.5，可以從這裏下載客戶端：
解壓出來的二進制文件放到基礎節點的 $PATH 下，看下版本信息：
→ oc adm release info quay.io/openshift-release-dev/ocp-release:4.4.5-x86_64
Name: 4.4.5
Digest: sha256:4a461dc23a9d323c8bd7a8631bed078a9e5eec690ce073f78b645c83fb4cdf74
Created: 2020-05-21T16:03:01Z
OS/Arch: linux/amd64
Manifests: 412
Pull From: quay.io/openshift-release-dev/ocp-release@sha256:4a461dc23a9d323c8bd7a8631bed078a9e5eec690ce073f78b645c83fb4cdf74
Release Metadata:
Version: 4.4.5
Upgrades: 4.3.18, 4.3.19, 4.3.21, 4.3.22, 4.4.2, 4.4.3, 4.4.4
Metadata:
description:
Metadata:
url: https://access.redhat.com/errata/RHBA-2020:2180
Component Versions:
kubernetes 1.17.1
machine-os 44.81.202005180831-0 Red Hat Enterprise Linux CoreOS
Images:
NAME DIGEST
aws-machine-controllers sha256:7817d9e707bb51bc1e5110ef66bb67947df42dcf3c9b782a8f12f60b8f229dca
azure-machine-controllers sha256:5e2320f92b7308a4f1ec4aca151c752f69265e8c5b705d78e2f2ee70d717711a
baremetal-installer sha256:4c8c6d2895e065711cfcbffe7e8679d9890480a4975cad683b643d8502375fe3
baremetal-machine-controllers sha256:5f1b312ac47b7f9e91950463e9a4ce5af7094a3a8b0bc064c9b4dcfc9c725ad5
baremetal-operator sha256:a77ff02f349d96567da8e06018ad0dfbfb5fef6600a9a216ade15fadc574f4b4
baremetal-runtimecfg sha256:715bc48eda04afc06827189883451958d8940ed8ab6dd491f602611fe98a6fba
cli sha256:43159f5486cc113d64d5ba04d781c16a084d18745a911a5ae7200bb895778a72
cli-artifacts sha256:ce7130db82f5a3bb2c806d7080f356e4c68c0405bf3956d3e290bc2078a8bf32
cloud-credential-operator sha256:244ab9d0fcf7315eb5c399bd3fa7c2e662cf23f87f625757b13f415d484621c3
cluster-authentication-operator sha256:3145e4fbd62dde385fd0e33d220c42ec3d00ac1dab72288e584cc502b4b8b6db
cluster-autoscaler sha256:66e47de69f685f2dd063fbce9f4e5a00264a5572140d255f2db4c367cb00bad9
cluster-autoscaler-operator sha256:6a32eafdbea3d12c0681a1a1660c7a424f7082a1c42e22d1b301ab0ab6da191b
cluster-bootstrap sha256:fbde2b1a3df7172ce5dbc5e8818bfe631718399eda8058b301a1ef059f549e95
cluster-config-operator sha256:5437794d2309ebe65ca08d1bdeb9fcd665732207b3287df8a7c56e5a2813eccb
cluster-csi-snapshot-controller-operator sha256:bc4d8ad97b473316518dbd8906dd900feba383425671eb7d4d73ed1d705c105e
cluster-dns-operator sha256:1a7469258e351d2d56a98a5ef4a3dfa0326b4677fdc1dd11279b6a193ccdbad1
cluster-etcd-operator sha256:9f7a02df3a5d91326d95e444e2e249f8205632ae986d6dccc7f007ec65c8af77
cluster-image-registry-operator sha256:0aaa817389487d266faf89cecbfd3197405d87172ee2dcda169dfa90e2e9ca18
cluster-ingress-operator sha256:4887544363e052e656aa1fd44d2844226ee2e4617e08b88ba0211a93bb3101fa
cluster-kube-apiserver-operator sha256:718ca346d5499cccb4de98c1f858c9a9a13bbf429624226f466c3ee2c14ebf40
cluster-kube-controller-manager-operator sha256:0aa16b4ff32fbb9bc7b32aa1bf6441a19a1deb775fb203f21bb8792ff1a26c2e
cluster-kube-scheduler-operator sha256:887eda5ce495f1a33c5adbba8772064d3a8b78192162e4c75bd84763c5a1fb01
cluster-kube-storage-version-migrator-operator sha256:0fd3e25304a6e23e9699172a84dc134b9b5b81dd89496322a9f46f4cd82ecf71
cluster-machine-approver sha256:c35b382d426ff03cfe07719f19e871ec3bd4189fa27452b3e2eb2fb4ab085afc
cluster-monitoring-operator sha256:d7d5f3b6094c88cb1aa9d5bf1b29c574f13db7142e0a9fba03c6681fe4b592a5
cluster-network-operator sha256:563018341e5b37e5cf370ee0a112aa85dd5e17a658b303714252cc59ddfadea5
cluster-node-tuned sha256:0d1a3f66cd7cfc889ddf17cbdb4cb2e4b9188c341b165de1c9c1df578fb53212
cluster-node-tuning-operator sha256:8e00331fd6b725b1d44687bafa2186920e2864fd4d04869ad4e9f5ba56d663ca
cluster-openshift-apiserver-operator sha256:087dd3801b15ca614be0998615a0d827383e9c9ab39e64107324074bddccfff8
cluster-openshift-controller-manager-operator sha256:a25afbcb148f3535372784e82c66a6cc2843fe9e7119b9198a39422edb95c2ae
cluster-policy-controller sha256:6294d4af2061d23f52a2a439d20272280aa6e5fcff7a5559b4797fb8e6536790
cluster-samples-operator sha256:7040633af70ceb19147687d948a389d392945cb57236165409e66e5101c0d0c0
cluster-storage-operator sha256:bcfeab624513563c9e26629be2914770436c49318c321bd99028a7d1ffab30cf
cluster-svcat-apiserver-operator sha256:21a562f26c967ad6d83e1f4219fad858154c3df9854f1462331b244906c6ca9c
cluster-svcat-controller-manager-operator sha256:b635529e5843996a51ace6a2aea4854e46256669ef1773c7371e4f0407dbf843
cluster-update-keys sha256:828e11d8132caf5533e18b8e5d292d56ccf52b08e4fe4c53d7825404b05b2844
cluster-version-operator sha256:7a2a210bc07fead80b3f4276cf14692c39a70640a124326ee919d415f0dc5b2c
configmap-reloader sha256:07d46699cb9810e3f629b5142a571db83106aa1190d5177a9944272080cd053d
console sha256:69f14151fe8681e5fa48912f8f4df753a0dcc3d616ad7991c463402517d1eab4
console-operator sha256:85c9a48c9b1896f36cf061bd4890e7f85e0dc383148f2a1dc498e668dee961df
container-networking-plugins sha256:1a2ecb28b80800c327ad79fb4c8fb6cc9f0b434fc42a4de5b663b907852ee9fb
coredns sha256:b25b8b2219e8c247c088af93e833c9ac390bc63459955e131d89b77c485d144d
csi-snapshot-controller sha256:33f89dbd081d119aac8d7c56abcb060906b23d31bc801091b789dea14190493f
deployer sha256:b24cd515360ae4eba89d4d92afe2689a84043106f7defe34df28acf252cd45b4
docker-builder sha256:d3cf4e3ad3c3ce4bef52d9543c87a1c555861b726ac9cae0cc57486be1095f8a
docker-registry sha256:8b6ab4a0c14118020fa56b70cab440883045003a8d9304c96691a0401ad7117c
etcd sha256:aba3c59eb6d088d61b268f83b034230b3396ce67da4f6f6d49201e55efebc6b2
gcp-machine-controllers sha256:1c67b5186bbbdc6f424d611eeff83f11e1985847f4a98f82642dcd0938757b0e
grafana sha256:aa5c9d3d828b04418d17a4bc3a37043413bdd7c036a75c41cd5f57d8db8aa25a
haproxy-router sha256:7064737dd9d0a43de7a87a094487ab4d7b9e666675c53cf4806d1c9279bd6c2e
hyperkube sha256:187b9d29fea1bde9f1785584b4a7bbf9a0b9f93e1323d92d138e61c861b6286c
insights-operator sha256:51dc869dc1a105165543d12eeee8229916fc15387210edc6702dbc944f7cedd7
installer sha256:a0f23a3292a23257a16189bdae75f7b5413364799e67a480dfad086737e248e0
installer-artifacts sha256:afe926af218d506a7f64ef3df0d949aa6653a311a320bc833398512d1f000645
ironic sha256:80087bd97c28c69fc08cd291f6115b0e12698abf2e87a3d2bbe0e64f600bae93
ironic-hardware-inventory-recorder sha256:2336af8eb4949ec283dc22865637e3fec80a4f6b1d3b78178d58ea05afbd49c2
ironic-inspector sha256:1f48cc344aab15c107e2fb381f9825613f586e116c218cdaf18d1e67b13e2252
ironic-ipa-downloader sha256:a417b910e06ad030b480988d6864367c604027d6476e02e0c3d5dcd6f6ab4ccb
ironic-machine-os-downloader sha256:10b751d8e4ba2975dabc256c7ac4dcf94f4de99be35242505bf8db922e968403
ironic-static-ip-manager sha256:0c122317e3a6407a56a16067d518c18ce08f883883745b2e11a5a39ff695d3d0
jenkins sha256:d4ab77a119479a95a33beac0d94980a7a0a87cf792f5850b30dff4f1f90a9c4d
jenkins-agent-maven sha256:10559ec206191a9931b1044260007fe8dcedacb8b171be737dfb1ccca9bbf0f5
jenkins-agent-nodejs sha256:ad9e83ea1ea3f338af4dbc9461f8b243bd817df722909293fde33b4f9cbab2bc
k8s-prometheus-adapter sha256:be548d31a65e56234e4b98d6541a14936bc0135875ec61e068578f7014aac31e
keepalived-ipfailover sha256:a882a11b55b2fc41b538b59bf5db8e4cfc47c537890e4906fe6bf22f9da75575
kube-client-agent sha256:8eb481214103d8e0b5fe982ffd682f838b969c8ff7d4f3ed4f83d4a444fb841b
kube-etcd-signer-server sha256:8468b1c575906ed41aa7c3ac3b0a440bf3bc254d2975ecc5e23f84aa54395c81
kube-proxy sha256:886ae5bd5777773c7ef2fc76f1100cc8f592653ce46f73b816de80a20a113769
kube-rbac-proxy sha256:f6351c3aa750fea93050673f66c5ddaaf9e1db241c7ebe31f555e011b20d8c30
kube-state-metrics sha256:ca47160369e67e1d502e93175f6360645ae02933cceddadedabe53cd874f0f89
kube-storage-version-migrator sha256:319e88c22ea618e7b013166eace41c52eb70c8ad950868205f52385f09e96023
kuryr-cni sha256:3eecf00fdfca50e90ba2d659bd765eb04b5c446579e121656badcfd41da87663
kuryr-controller sha256:7d70c92699a69a589a3c2e1045a16855ba02af39ce09d6a6df9b1dbabacff4f5
libvirt-machine-controllers sha256:cc3c7778de8d9e8e4ed543655392f942d871317f4b3b7ed31208312b4cc2e61f
local-storage-static-provisioner sha256:a7ff3ec289d426c7aaee35a459ef8c862b744d709099dedcd98a4579136f7d47
machine-api-operator sha256:4ca2f1b93ad00364c053592aea0992bbb3cb4b2ea2f7d1d1af286c26659c11d3
machine-config-operator sha256:31dfdca3584982ed5a82d3017322b7d65a491ab25080c427f3f07d9ce93c52e2
machine-os-content sha256:b397960b7cc14c2e2603111b7385c6e8e4b0f683f9873cd9252a789175e5c4e1
mdns-publisher sha256:dea1fcb456eae4aabdf5d2d5c537a968a2dafc3da52fe20e8d99a176fccaabce
multus-admission-controller sha256:377ed5566c062bd2a677ddc0c962924c81796f8d45346b2eefedf5350d7de6b3
multus-cni sha256:bc58468a736e75083e0771d88095229bdd6c1e58db8aa33ef60b326e0bfaf271
multus-route-override-cni sha256:e078599fde3b974832c06312973fae7ed93334ea30247b11b9f1861e2b0da7d6
multus-whereabouts-ipam-cni sha256:89c386f5c3940d88d9bc2520f422a2983514f928585a51ae376c43f19e5a6cad
must-gather sha256:a295d2568410a45f1ab403173ee84d7012bb3ec010c24aa0a17925d08d726e20
oauth-proxy sha256:619bdb128e410b52451dbf79c9efb089e138127812da19a1f69907117480827f
oauth-server sha256:58545567c899686cae51d2de4e53a5d49323183a7a3065c0b96ad674686acbe8
openshift-apiserver sha256:8fd79797e6e0e9337fc9689863c3817540a003685a6dfc2a55ecb77059967cef
openshift-controller-manager sha256:4485d6eb7625becf581473690858a01ab83244ecb03bb0319bf849068e98a86a
openshift-state-metrics sha256:6de02ce03089b715e9f767142de33f006809226f037fe21544e1f79755ade920
openstack-machine-controllers sha256:d61e611416196650c81174967e5f11cbdc051d696e38ba341de169375d985709
operator-lifecycle-manager sha256:6e1bca545c35fb7ae4d0f57006acce9a9fabce792c4026944da68d7ddfdec244
operator-marketplace sha256:f0750960873a7cc96f7106e20ea260dd41c09b8a30ce714092d3dcd8a7ec396d
operator-registry sha256:7914f42c9274d263c6ba8623db8e6af4940753dcb4160deb291a9cbc61487414
ovirt-machine-controllers sha256:44f9e65ccd39858bf3d7aa2929f5feac634407e36f912ca88585b445d161506c
ovn-kubernetes sha256:d80899ed1a6a9f99eb8c64856cd4e576f6534b7390777f3180afb8a634743d62
pod sha256:d7862a735f492a18cb127742b5c2252281aa8f3bd92189176dd46ae9620ee68a
prom-label-proxy sha256:1cf614e8acbe3bcca3978a07489cd47627f3a3bd132a5c2fe0072d9e3e797210
prometheus sha256:5eea86e59ffb32fca37cacff22ad00838ea6b947272138f8a56062f68ec40c28
prometheus-alertmanager sha256:bb710e91873ad50ac10c2821b2a28c29e5b89b5da7740a920235ecc33fb063f5
prometheus-config-reloader sha256:7cadb408d7c78440ddacf2770028ee0389b6840651c753f4b24032548f56b7aa
prometheus-node-exporter sha256:7d4e76fea0786f4025e37b5ad0fb30498db5586183fc560554626e91066f60f3
prometheus-operator sha256:6e599a9a8691cce0b40bf1ac5373ddb8009113a2115b5617b2d3a3996174c8f7
sdn sha256:08c256b7b07c57f195faa33ea4273694dd3504d4a85a10dbf7616b91eaa8e661
service-ca-operator sha256:8c9a3071040f956cce15d1e6da70f6f47dc55b609e4f19fe469ce581cd42bfe5
service-catalog sha256:d9a5fbf60e3bbf1c9811e1707ce9bd04e8263552ba3a6bea8f8c7b604808fdf9
telemeter sha256:19cfc3e37e12d9dd4e4dd9307781368bbeb07929b6ab788e99aa5543badee3c9
tests sha256:fc56c9805e2e4a8416c1c5433d7974148f0bad88be4a62feeedcd5d9db4b6ad6
thanos sha256:a4ea116aec2f972991f5a22f39aa1dbc567dddc3429ddca873601714d003a51c
內部鏡像倉庫用於存放部署 OCP 集群所需的鏡像，倉庫本身使用 Quay 部署。Quay 包含了幾個核心組件：
首先修改鏡像倉庫節點的主機名：
$ hostnamectl set-hostname registry.openshift4.example.com
所有節點主機名都要採用三級域名格式，如
master1.aa.bb.com。
接着安裝 podman：
$ yum install -y podman
先創建一個 Pod，用來共享 Network Namespace：
→ podman pod create --name quay -p 443:8443
安裝 Mysql 數據庫：
$ mkdir -p /data/quay/lib/mysql
$ chmod 777 /data/quay/lib/mysql
$ export MYSQL_CONTAINER_NAME=quay-mysql
$ export MYSQL_DATABASE=enterpriseregistrydb
$ export MYSQL_PASSWORD=<PASSWD>
$ export MYSQL_USER=quayuser
$ export MYSQL_ROOT_PASSWORD=<PASSWD>
$ podman run \
--detach \
--restart=always \
--env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} \
--env MYSQL_USER=${MYSQL_USER} \
--env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
--env MYSQL_DATABASE=${MYSQL_DATABASE} \
--name ${MYSQL_CONTAINER_NAME} \
--privileged=true \
--pod quay \
-v /data/quay/lib/mysql:/var/lib/mysql/data:Z \
registry.access.redhat.com/rhscl/mysql-57-rhel7
安裝 Redis：
$ mkdir -p /data/quay/lib/redis
$ chmod 777 /data/quay/lib/redis
$ podman run -d --restart=always \
--pod quay \
--privileged=true \
--name quay-redis \
-v /data/quay/lib/redis:/var/lib/redis/data:Z \
registry.access.redhat.com/rhscl/redis-32-rhel7
獲取 Red Hat Quay v3 鏡像的訪問權：
$ podman login -u="redhat+quay" -p="O81WSHRSJR14UAZBK54GQHJS0P1V4CLWAJV1X2C4SD7KO59CQ9N3RE12612XU1HR" quay.io
參考：https://access.redhat.com/solutions/3533201
配置 Quay：
$ podman run --privileged=true \
--name quay-config \
--pod quay \
--add-host mysql:127.0.0.1 \
--add-host redis:127.0.0.1 \
--add-host clair:127.0.0.1 \
-d quay.io/redhat/quay:v3.3.0 config fuckcloudnative.io
這一步會啟動一個配置 Quay 的進程，打開瀏覽器訪問：https://registry.openshift4.example.com，用戶名/密碼為：quayconfig/fuckcloudnative.io：
選擇新建配置，然後設置數據庫：
設置超級管理員：
下一個界面要設置兩個地方，一個是 Server configuration 的 Server Hostname，另一個是 Redis Hostname，SSL 不用設置，後面直接通過命令行配置：
配置檢查通過後，就可以保存下載下來：
最後會導出一個 quay-config.tar.gz，將其上傳到 Quay 所在的服務器，解壓到配置文件目錄：
$ mkdir -p /data/quay/config
$ mkdir -p /data/quay/storage
$ cp quay-config.tar.gz /data/quay/config/
$ cd /data/quay/config/
$ tar zxvf quay-config.tar.gz
生成自簽名證書：
# 生成私鑰
$ openssl genrsa -out ssl.key 1024
根據私鑰生成證書申請文件 csr：
$ openssl req -new -key ssl.key -out ssl.csr
這裏根據命令行嚮導來進行信息輸入：
Common Name 可以輸入：*.yourdomain.com，這種方式可以生成通配符域名證書。
使用私鑰對證書申請進行簽名從而生成證書：
$ openssl x509 -req -in ssl.csr -out ssl.cert -signkey ssl.key -days 3650
這樣就生成了有效期為 10 年的證書文件，對於自己內網服務使用足夠。
或者你也可以一步到位：
$ openssl req \
-newkey rsa:2048 -nodes -keyout ssl.key \
-x509 -days 3650 -out ssl.cert -subj \
"/C=CN/ST=Shanghai/L=Shanghai/O=IBM/OU=IBM/CN=*.openshift4.example.com"
證書搞定了之後，還需要修改 config.yaml，將協議修改為 https：
PREFERRED_URL_SCHEME: https
然後停止 quay-config：
$ podman stop quay-config
最後一步才是部署 Quay：
$ podman run --restart=always \
--sysctl net.core.somaxconn=4096 \
--privileged=true \
--name quay-master \
--pod quay \
--add-host mysql:127.0.0.1 \
--add-host redis:127.0.0.1 \
--add-host clair:127.0.0.1 \
-v /data/quay/config:/conf/stack:Z \
-v /data/quay/storage:/datastorage:Z \
-d quay.io/redhat/quay:v3.3.0
安裝成功后，將自簽名的證書複製到默認信任證書路徑：
$ cp ssl.cert /etc/pki/ca-trust/source/anchors/ssl.crt
$ update-ca-trust extract
現在可以通過 podman login 命令來測試倉庫的連通性，看到如下字樣即表示安裝成功（也可以通過瀏覽器訪問 Web UI）：
→ podman login registry.openshift4.example.com
Username: admin
Password: ********
Login Succeeded
如果使用 Docker 登錄，需要將證書複製到 docker 的信任證書路徑：
$ mkdir -p /etc/docker/certs.d/registry.openshift4.example.com
$ cp ssl.cert /etc/docker/certs.d/registry.openshift4.example.com/ssl.crt
$ systemctl restart docker
準備拉取鏡像權限認證文件。 從 Red Hat OpenShift Cluster Manager 站點的 Pull Secret 頁面下載 registry.redhat.io 的 pull secret。
# 把下載的 txt 文件轉出 json 格式，如果沒有 jq 命令，通過 epel 源安裝
$ cat ./pull-secret.txt | jq . > pull-secret.json
$ yum install epel-release
$ yum install jq
JSON 內容如下：
{
"auths": {
"cloud.openshift.com": {
"auth": "b3BlbnNo...",
"email": "you@example.com"
},
"quay.io": {
"auth": "b3BlbnNo...",
"email": "you@example.com"
},
"registry.connect.redhat.com": {
"auth": "NTE3Njg5Nj...",
"email": "you@example.com"
},
"registry.redhat.io": {
"auth": "NTE3Njg5Nj...",
"email": "you@example.com"
}
}
}
把本地倉庫的用戶密碼轉換成 base64 編碼：
$ echo -n 'admin:password' | base64 -w0
cm9vdDpwYXNzd29yZA==
然後在 pull-secret.json 裏面加一段本地倉庫的權限。第一行倉庫域名和端口，第二行是上面的 base64，第三行隨便填個郵箱：
"auths": {
...
"registry.openshift4.example.com": {
"auth": "cm9vdDpwYXNzd29yZA==",
"email": "you@example.com"
},
...
設置環境變量：
$ export OCP_RELEASE="4.4.5-x86_64"
$ export LOCAL_REGISTRY='registry.openshift4.example.com'
$ export LOCAL_REPOSITORY='ocp4/openshift4'
$ export PRODUCT_REPO='openshift-release-dev'
$ export LOCAL_SECRET_JSON='/root/pull-secret.json'
$ export RELEASE_NAME="ocp-release"
oc adm 時會提示 image does not exist。ocp4/openshift4。PRODUCT_REPO 和 RELEASE_NAME 都不需要改，這些都是一些版本特徵，保持不變即可。pull-secret.json 的存放路徑。在 Quay 中創建一個組織（Organization）ocp4 用來存放同步過來的鏡像。
最後一步就是同步鏡像，這一步的動作就是把 quay 官方倉庫中的鏡像同步到本地倉庫，如果失敗了可以重新執行命令，整體內容大概 5G。
$ oc adm -a ${LOCAL_SECRET_JSON} release mirror \
--from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE} \
--to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} \
--to-release-image=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}
oc adm release mirror 命令執行完成後會輸出下面類似的信息，保存下來，將來會用在 install-config.yaml 文件中：
imageContentSources:
- mirrors:
- registry.openshift4.example.com/ocp4/openshift4
source: quay.io/openshift-release-dev/ocp-release
- mirrors:
- registry.openshift4.example.com/ocp4/openshift4
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
本地鏡像倉庫緩存好鏡像之後，通過 tag/list 接口查看所有 tag，如果能列出來一堆就說明是正常的：
$ curl -s -X GET -H "Authorization: Bearer <token>" https://registry.openshift4.example.com/api/v1/repository/ocp4/openshift4/tag/|jq .
{
"has_additional": true,
"page": 1,
"tags": [
{
"name": "4.4.5-cluster-kube-scheduler-operator",
"reversion": false,
"start_ts": 1590821178,
"image_id": "a778898a93d4fc5413abea38aa604d14d7efbd99ee1ea75d2d1bea3c27a05859",
"last_modified": "Sat, 30 May 2020 06:46:18 -0000",
"manifest_digest": "sha256:887eda5ce495f1a33c5adbba8772064d3a8b78192162e4c75bd84763c5a1fb01",
"docker_image_id": "a778898a93d4fc5413abea38aa604d14d7efbd99ee1ea75d2d1bea3c27a05859",
"is_manifest_list": false,
"size": 103582366
},
{
"name": "4.4.5-kube-rbac-proxy",
"reversion": false,
"start_ts": 1590821178,
"image_id": "f1714cda6028bd7998fbba1eb79348f33b9ed9ccb0a69388da2eb0aefc222f85",
"last_modified": "Sat, 30 May 2020 06:46:18 -0000",
"manifest_digest": "sha256:f6351c3aa750fea93050673f66c5ddaaf9e1db241c7ebe31f555e011b20d8c30",
"docker_image_id": "f1714cda6028bd7998fbba1eb79348f33b9ed9ccb0a69388da2eb0aefc222f85",
"is_manifest_list": false,
"size": 102366055
},
{
"name": "4.4.5-cluster-kube-controller-manager-operator",
"reversion": false,
"start_ts": 1590821178,
"image_id": "bc7e19d35ec08c1a93058db1705998da2f8bbe5cdbb7f3f5974e6176e2f79eb6",
"last_modified": "Sat, 30 May 2020 06:46:18 -0000",
"manifest_digest": "sha256:0aa16b4ff32fbb9bc7b32aa1bf6441a19a1deb775fb203f21bb8792ff1a26c2e",
"docker_image_id": "bc7e19d35ec08c1a93058db1705998da2f8bbe5cdbb7f3f5974e6176e2f79eb6",
"is_manifest_list": false,
"size": 104264263
},
{
"name": "4.4.5-baremetal-operator",
"reversion": false,
"start_ts": 1590821178,
"image_id": "6ec90c0fb53125801d41b37f8f28c4679e49ce19427f7848803a2bc397e4c23b",
"last_modified": "Sat, 30 May 2020 06:46:18 -0000",
"manifest_digest": "sha256:a77ff02f349d96567da8e06018ad0dfbfb5fef6600a9a216ade15fadc574f4b4",
"docker_image_id": "6ec90c0fb53125801d41b37f8f28c4679e49ce19427f7848803a2bc397e4c23b",
"is_manifest_list": false,
"size": 110117444
},
{
"name": "4.4.5-cluster-etcd-operator",
"reversion": false,
"start_ts": 1590821178,
"image_id": "d0cf3539496e075954e53fce5ed56445ae87f9f32cfb41e9352a23af4aa04d69",
"last_modified": "Sat, 30 May 2020 06:46:18 -0000",
"manifest_digest": "sha256:9f7a02df3a5d91326d95e444e2e249f8205632ae986d6dccc7f007ec65c8af77",
"docker_image_id": "d0cf3539496e075954e53fce5ed56445ae87f9f32cfb41e9352a23af4aa04d69",
"is_manifest_list": false,
"size": 103890103
},
{
"name": "4.4.5-openshift-apiserver",
"reversion": false,
"start_ts": 1590821177,
"image_id": "eba5a051dcbab534228728c7295d31edc0323c7930fa44b40059cf8d22948363",
"last_modified": "Sat, 30 May 2020 06:46:17 -0000",
"manifest_digest": "sha256:8fd79797e6e0e9337fc9689863c3817540a003685a6dfc2a55ecb77059967cef",
"docker_image_id": "eba5a051dcbab534228728c7295d31edc0323c7930fa44b40059cf8d22948363",
"is_manifest_list": false,
"size": 109243025
},
{
"name": "4.4.5-kube-client-agent",
"reversion": false,
"start_ts": 1590821177,
"image_id": "fc1fdfb96e9cd250024094b15efa79344c955c7d0c93253df312ffdae02b5524",
"last_modified": "Sat, 30 May 2020 06:46:17 -0000",
"manifest_digest": "sha256:8eb481214103d8e0b5fe982ffd682f838b969c8ff7d4f3ed4f83d4a444fb841b",
"docker_image_id": "fc1fdfb96e9cd250024094b15efa79344c955c7d0c93253df312ffdae02b5524",
"is_manifest_list": false,
"size": 99721802
},
{
"name": "4.4.5-kube-proxy",
"reversion": false,
"start_ts": 1590821177,
"image_id": "d2577f4816cb81444ef3b441bf9769904c602cd6626982c2fd8ebba162fd0c08",
"last_modified": "Sat, 30 May 2020 06:46:17 -0000",
"manifest_digest": "sha256:886ae5bd5777773c7ef2fc76f1100cc8f592653ce46f73b816de80a20a113769",
"docker_image_id": "d2577f4816cb81444ef3b441bf9769904c602cd6626982c2fd8ebba162fd0c08",
"is_manifest_list": false,
"size": 103473573
},
...
}
這裏需要創建一個 OAuth access token 來訪問 Quay 的 API，創建過程如下：
Organization），例如 ocp4。Applications 圖標。Create New Application，輸入 Application 的名字然後回車。Generate Token。Generate Access Token。Authorize Application。Quay 的 API 文檔可以參考這裏：Appendix A: Red Hat Quay Application Programming Interface (API)。
Quay 中也能看到所有的鏡像：
為了保證安裝版本一致性，需要從鏡像庫中提取 openshift-install 二進制文件，不能直接從 https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.4.5 下載，不然後面會有 sha256 匹配不上的問題。
# 這一步需要用到上面的 export 變量
$ oc adm release extract \
-a ${LOCAL_SECRET_JSON} \
--command=openshift-install \
"${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}"
如果提示 error: image dose not exist，說明拉取的鏡像不全，或者版本不對。
把文件移動到 $PATH 並確認版本：
$ chmod +x openshift-install
$ mv openshift-install /usr/local/bin/
$ openshift-install version
openshift-install 4.4.5
built from commit 15eac3785998a5bc250c9f72101a4a9cb767e494
release image registry.openshift4.example.com/ocp4/openshift4@sha256:4a461dc23a9d323c8bd7a8631bed078a9e5eec690ce073f78b645c83fb4cdf74
準備一個鏡像列表，然後使用 oc image mirror 將鏡像同步到私有倉庫中：
cat sample-images.txt | while read line; do
target=$(echo $line | sed 's/registry.redhat.io/registry.openshift4.example.com/')
oc image mirror -a ${LOCAL_SECRET_JSON} $line $target
done
如果之前裝過 OCP 4.4.5，把 openshift-cluster-samples-operator 項目下 cluster-samples-operator Pod 的 /opt/openshift 目錄同步出來，簡單 grep 一下就都有了完整的鏡像列表。
完整列表參考這裏。
同步過程中如果遇到報錯，可根據報錯信息到 Quay 中創建相應的 Organization，不用中斷任務。這裏給出一個參考，需要創建以下的 Organization：
rhscl
jboss-datavirt-6
3scale-amp21
3scale-amp22
3scale-amp23
3scale-amp24
3scale-amp25
3scale-amp26
jboss-eap-6
devtools
openshift3
rhpam-7
rhdm-7
jboss-amq-6
jboss-datagrid-7
jboss-datagrid-6
jboss-webserver-3
amq-broker-7
jboss-webserver-5
redhat-sso-7
openjdk
redhat-openjdk-18
fuse7
dotnet
首先在 Quay 中創建一個 devinfra 項目，然後構建 RedHat Operators 的 catalog image, 保存為 registry.openshift4.example.com/devinfra/redhat-operators:v1。
$ oc adm catalog build \
-a ${LOCAL_SECRET_JSON} \
--appregistry-endpoint https://quay.io/cnr \
--from=registry.redhat.io/openshift4/ose-operator-registry:v4.4 \
--appregistry-org redhat-operators \
--to=registry.openshift4.example.com/devinfra/redhat-operators:v1
這個 catalog image 相當於 RedHat Operators 的一個目錄，通過 catalog image 可以找到 RedHat Operators 的所有鏡像。而且 catalog image 使用 sha256 digest 來引用鏡像，能夠確保應用有穩定可重複的部署。
然後使用 catalog image 同步 RedHat Operators 的所有鏡像到私有倉庫：
$ oc adm catalog mirror \
-a ${LOCAL_SECRET_JSON} \
registry.openshift4.example.com/devinfra/redhat-operators:v1 \
registry.openshift4.example.com
如果執行過程中遇到 project not found 之類的錯誤，可根據報錯信息到 Quay 中創建相應的項目，不用中斷任務。
這裏還會遇到一個 bug，執行到最後會有如下的報錯信息：
...
I0409 08:04:48.342110 11331 mirror.go:231] wrote database to /tmp/db-225652515/bundles.db
W0409 08:04:48.347417 11331 mirror.go:258] errors during mirroring. the full contents of the catalog may not have been mirrored: couldn't parse image for mirroring (), skipping mirror: invalid reference format
I0409 08:04:48.385816 11331 mirror.go:329] wrote mirroring manifests to redhat-operators-manifests
先來看看有哪些 Operators：
$ sqlite3 /tmp/db-225652515/bundles.db 'select * from related_image'|grep '^|'
隨便挑一個 Operator，查看其 ClusterServiceVersion 的 spec.relatedImages 字段內容：
$ cat /tmp/cache-943388495/manifests-698804708/3scale-operator/3scale-operator-9re7jpyl/0.5.0/3scale-operator.v0.5.0.clusterserviceversion.yaml
...
spec:
replaces: 3scale-operator.v0.4.2
relatedImages:
- name: apicast-gateway-rhel8
image: registry.redhat.io/3scale-amp2/apicast-gateway-rhel8@sha256:21be62a6557846337dc0cf764be63442718fab03b95c198a301363886a9e74f9
- name: backend-rhel7
image: registry.redhat.io/3scale-amp2/backend-rhel7@sha256:ea8a31345d3c2a56b02998b019db2e17f61eeaa26790a07962d5e3b66032d8e5
- name: system-rhel7
image: registry.redhat.io/3scale-amp2/system-rhel7@sha256:93819c324831353bb8f7cb6e9910694b88609c3a20d4c1b9a22d9c2bbfbad16f
- name: zync-rhel7
image: registry.redhat.io/3scale-amp2/zync-rhel7@sha256:f4d5c1fdebe306f4e891ddfc4d3045a622d2f01db21ecfc9397cab25c9baa91a
- name: memcached-rhel7
image: registry.redhat.io/3scale-amp2/memcached-rhel7@sha256:ff5f3d2d131631d5db8985a5855ff4607e91f0aa86d07dafdcec4f7da13c9e05
- name: redis-32-rhel7
value: registry.redhat.io/rhscl/redis-32-rhel7@sha256:a9bdf52384a222635efc0284db47d12fbde8c3d0fcb66517ba8eefad1d4e9dc9
- name: mysql-57-rhel7
value: registry.redhat.io/rhscl/mysql-57-rhel7@sha256:9a781abe7581cc141e14a7e404ec34125b3e89c008b14f4e7b41e094fd3049fe
- name: postgresql-10-rhel7
value: registry.redhat.io/rhscl/postgresql-10-rhel7@sha256:de3ab628b403dc5eed986a7f392c34687bddafee7bdfccfd65cecf137ade3dfd
...
可以看到 relatedImages 列表中有些條目的鍵是 value 而不是 image，這就是問題所在！ 那些沒有 image 的條目在反序列化時會將 image 的值當成空字符串 ""：
$ sqlite3 /tmp/db-225652515/bundles.db 'select * from related_image where operatorbundle_name="3scale-operator.v0.5.0"'
registry.redhat.io/3scale-amp2/zync-rhel7@sha256:f4d5c1fdebe306f4e891ddfc4d3045a622d2f01db21ecfc9397cab25c9baa91a|3scale-operator.v0.5.0
registry.redhat.io/3scale-amp2/memcached-rhel7@sha256:ff5f3d2d131631d5db8985a5855ff4607e91f0aa86d07dafdcec4f7da13c9e05|3scale-operator.v0.5.0
|3scale-operator.v0.5.0
registry.redhat.io/3scale-amp2/apicast-gateway-rhel8@sha256:21be62a6557846337dc0cf764be63442718fab03b95c198a301363886a9e74f9|3scale-operator.v0.5.0
registry.redhat.io/3scale-amp2/backend-rhel7@sha256:ea8a31345d3c2a56b02998b019db2e17f61eeaa26790a07962d5e3b66032d8e5|3scale-operator.v0.5.0
registry.redhat.io/3scale-amp2/3scale-rhel7-operator@sha256:2ba16314ee046b3c3814fe4e356b728da6853743bd72f8651e1a338e8bbf4f81|3scale-operator.v0.5.0
registry.redhat.io/3scale-amp2/system-rhel7@sha256:93819c324831353bb8f7cb6e9910694b88609c3a20d4c1b9a22d9c2bbfbad16f|3scale-operator.v0.5.0
從上面的輸出可以看到鍵為 value 的那幾個條目都反序列化失敗了，具體的討論參考：bundle validate should validate that there are no empty relatedImages。
這裏給出一個臨時解決方案，先打開另外一個窗口，然後回到原來的窗口執行命令：
$ oc adm catalog mirror \
-a ${LOCAL_SECRET_JSON} \
registry.openshift4.example.com/devinfra/redhat-operators:v1 \
registry.openshift4.example.com
然後迅速切到下一個窗口，查找最新的 manifest 緩存目錄：
$ ls -l /tmp/cache-*/
根據日期判斷最新的緩存目錄，假設是 /tmp/cache-320634009，然後將所有的 value 替換為 image：
$ sed -i "s/value: registry/image: registry/g" $(egrep -rl "value: registry" /tmp/cache-320634009/)
同步完成後會產生 redhat-operators-manifests 目錄，下面有兩個文件:
ImageContentSourcePolicy 對象，該對象可以配置節點將其對官方 Operator manifests 中鏡像的引用改為對本地鏡像倉庫中鏡像的引用。oc image mirror 命令可以引用該文件進一步修改鏡像配置。然而目前這麼做還是有問題 1800674: 同步出來的鏡像 manifest digest 不對，導致後面離線安裝 Operator 時會報鏡像無法獲取的錯誤。
暫時可以使用上面 bugzilla 鏈接里給出的臨時解決方案，先安裝 skopeo：
$ yum install -y golang gpgme-devel libassuan-devel btrfs-progs-devel device-mapper-devel
$ git clone https://github.com/containers/skopeo
$ cd skopeo
$ make binary-local
$ mv skopeo /usr/local/bin/
從 pull-secret.json 中解碼 quay.io、registry.redhat.io 和 registry.access.redhat.com 的用戶名密碼，然後通過下面的命令認證：
$ skopeo login -u <quay.io_user> -p <quay.io_psw> quay.io
$ skopeo login -u <registry.redhat.io_user> -p <registry.redhat.io_psw> registry.redhat.io
$ skopeo login -u <registry.access.redhat.com_user> -p <registry.access.redhat.com_psw> registry.access.redhat.com
最後同步鏡像的 manifest digest：
cat redhat-operators-manifests/mapping.txt | while read line; do
origin=$(echo $line | cut -d= -f1)
target=$(echo $line | cut -d= -f2)
if [[ "$origin" =~ "sha256" ]]; then
tag=$(echo $origin | cut -d: -f2 | cut -c -8)
skopeo copy --all docker://$origin docker://$target:$tag
else
skopeo copy --all docker://$origin docker://$target
fi
done
不得不說，OCP 的安裝真是個浩大的工程，這洋洋洒洒的一大篇也只是準備了離線資源，這隻是安裝的一小步，還有很長的步驟要寫，心理素質不過關的同學切勿隨意模仿。
Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包發布地址http://store.lameleg.com ，歡迎體驗。 使用了最新的sealos v3.3.6版本。 作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs加載問題， 修復lvscare社區netlink與3.10內核不兼容問題,sealos生成百年證書等特性。更多特性 https://github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群 ，釘釘群已經集成sealos的機器人實時可以看到sealos的動態。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※別再煩惱如何寫文案,掌握八大原則!
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※超省錢租車方案
※教你寫出一流的銷售文案?
※網頁設計最專業,超強功能平台可客製化
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!
1.導讀
駕車導航是数字地圖的核心用戶場景，用戶在進行導航規劃時，高德地圖會提供給用戶3條路線選擇，由用戶根據自身情況來決定按照哪條路線行駛。
同時各路線的ETA（estimated time of arrival，預估到達時間）會直接显示給用戶，這是用戶關心的核心點之一。用戶給定起點和終點后，我們的任務是預測起終點的ETA，ETA的準確率越高，給用戶帶來的出行體驗越好。
2.基於深度學習模型的探索和實踐
2.1模型選擇
傳統機器學習模型在ETA中，比較常用的有線性回歸、RF（隨機森林）、GBDT（梯度提升決策樹）等回歸預測類模型。線性模型表達能力較差，需要大量特徵工程預先分析出有效的特徵；RF通過樣本隨機和特徵隨機的方式引入更多的隨機性，解決了決策樹泛化能力弱的問題；GBDT是通過採用加法模型（即基函數的線性組合），以及不斷減小訓練過程產生的殘差來達到回歸的算法。
傳統機器學習模型相對簡單易懂，也能達到不錯的效果，但存在兩個問題：
第一個問題很好理解，深度學習模型能很好地彌補這方面。針對第二個問題，以歷史速度信息選取存在的不確定性為例來說明一下，歷史速度信息是一個區分周一到周日七個工作日、10分鐘間隔的歷史平均時間，可以根據該路段的預計進入時間所在10分鐘區間來選定。如下圖（歷史平均速度）從0:00-24:00的變化曲線，可以看到一天中特別是早晚高峰，速度值存在較大波動。
而在選取歷史平均時間時，依賴的是預計進入時間，這個時間依賴於上游路段的預計通行時間，因此其選取存在不確定性，進而導致ETA計算不準確。
考慮到以上問題的存在，我們選擇利用RNN的時間序列思想將路線中上下游路段串聯起來進行路段ETA的預測。
另外考慮到RNN存在的長依賴問題，且結合實際業務情況，我們選擇使用LSTM模型來進行建模，LSTM的門結構具有的選擇性還能讓模型自行學習選擇保留哪些上游的特徵信息進行預測。
2.2網絡架構
上圖為整個模型的框架圖，主要分為兩部分，使用LSTM模塊對路線中的路段ETA的預測和最終使用N層全連接模塊對累計路段ETA及路線各特徵進行完整路線的ETA預測。
2.3路段ETA預測
上圖為各路段ETA預測使用的LSTM結構圖，Xt為路線中第t個路段的特徵信息，主要包含對應的實時路況信息、歷史路況信息、路段的靜態特徵等。
LSTM本是輸入時間序列數據的模型，我們利用該思想，將路線中各路段序列依次輸入模型。
2.4完整路線ETA預測
在LSTM模塊得到累計路線ETA預測值后，結合該路線的靜態屬性，使用全連接模塊將其整合成最終輸出的完整路線ETA預測值。
路線的屬性特徵主要指一些人工提取的特徵，如該路線的長度、導航規劃發起特徵日、是否早晚高峰時段等，用以加強模型在不同場景下的表達能力。
損失函數選用線性回歸常用的平方形式：MSE，公式如下：
其中，N是路線數量，ETA路線j為路線ETA，即預測值；用戶實走j為用戶在該路線的實走時間，即真值。
3.模型效果
衡量模型效果，即路線上ETA的預測值時，主要考慮的是準確率。一般情況下，用戶對ETA偏長和偏短的容忍度不同，對偏長容忍度更高。比如用戶要去機場，ETA給的時間偏短10分鐘比偏長10分鐘對用戶的損害更大。因此準確度的指標設計傾向於ETA偏長，定義為滿足用戶一定容忍範圍的請求比例，即準確率作為主要衡量指標。
在北京市上的實驗結果显示，ETA準確率得到提升，MSE loss下降比例28.2%，效果有了明顯的提升。
4.小結
本文介紹了引入深度學習模型，幫助建模導航規劃的預估到達時間預測，成功解決了線性模型的不足，也為後續引入更多特徵、進行更多探索打開了空間，如歷史速度信息的不確定度、時效性、周期性、突發事件、路網結構等。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※教你寫出一流的銷售文案?
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※回頭車貨運收費標準
※別再煩惱如何寫文案,掌握八大原則!
※超省錢租車方案
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※推薦台中搬家公司優質服務,可到府估價
我們開發的系統，一般可以不用考慮語言國際化的問題，大多數系統一般是給本國人使用的，而且直接使用中文開發界面會更加迅速 一些，不過框架最好能夠支持國際化的處理，以便在需要的時候，可以花點時間來實現多語言切換的處理，使系統具有更廣泛的受眾用戶。VUE+Element 前端應用實現國際化的處理還是非常方便的，一般在Main.js函數裏面引入語言文件，然後在界面上進行一定的處理，把對應的鍵值轉換為對應語言的語義即可。本篇隨筆介紹在VUE+Element 前端應用中如何實現在界面快速的支持多語言國際化的處理邏輯代碼。
Element 組件內部默認使用中文，若希望使用其他語言，則需要進行多語言設置。以英文為例，在 main.js 中：
// 完整引入 Element import Vue from 'vue' import ElementUI from 'element-ui' import locale from 'element-ui/lib/locale/lang/en' Vue.use(ElementUI, { locale })
由於我們現在是需要處理多語言的切換，那麼，我們在src下面的一個目錄裏面創建一個lang目錄，在其中裏面編輯zh.js和en.js分別代表中英文語言對照信息，index.js文件則為引入這兩個文件的處理關係。
在index.js裏面，需要設置一個函數，用來獲取Cookie裏面存儲的語言，如果沒有找到，以瀏覽器國際化語言為準，如下代碼所示。
export function getLanguage() { const chooseLanguage = Cookies.get('language') if (chooseLanguage) return chooseLanguage // 如果沒有選擇語言，那麼使用瀏覽器語言 const language = (navigator.language || navigator.browserLanguage).toLowerCase() const locales = Object.keys(messages) for (const locale of locales) { if (language.indexOf(locale) > -1) { return locale } } return 'en' }
其中代碼行
const locales = Object.keys(messages)
是獲取message對象裏面的鍵，如下所示。
import Vue from 'vue' import VueI18n from 'vue-i18n' import Cookies from 'js-cookie' import elementEnLocale from 'element-ui/lib/locale/lang/en' // element-ui lang import elementZhLocale from 'element-ui/lib/locale/lang/zh-CN'// element-ui lang import enLocale from './en' import zhLocale from './zh' Vue.use(VueI18n) // 定義對應語言鍵，展開對應的鍵值對應表 const messages = { en: { ...enLocale, ...elementEnLocale }, zh: { ...zhLocale, ...elementZhLocale } }
其中message就是一個兩個語言（en/zh）字典下的對照表，包含各自對應鍵值下的內容。
然後整個index.js文件就是公布對應的多語言處理接口和屬性。
const i18n = new VueI18n({ locale: getLanguage(), messages }) export default i18n
然後在main.js函數裏面處理國際化的處理即可
Vue.use(ElementUI, { size: Cookies.get('size') || 'medium', // set element-ui default size i18n: (key, value) => i18n.t(key, value) }) new Vue({ el: '#app', router, store, i18n, render: h => h(App) })
有了這些準備，那麼我們在界面上就可以調用對應的鍵來獲取對應語言的語義了，
首先，我們編輯一下對應國際化的鍵值內容，例如中文參照如下所示。
例如對應登錄界面上，界面效果如下所示。
或者
其中裏面的文本內容，我們都是以國際化處理內容。
如登陸表單裏面的代碼如下所示。
<el-form ref="loginForm" :model="loginForm" :rules="rules" class="loginForm"> <el-form-item prop="username" class="login-item"> <el-input v-model="loginForm.username" class="area" type="text" :placeholder="$t('login.username')" prefix-icon="el-icon-user-solid" @keyup.enter.native="submitForm('loginForm')" /> </el-form-item> <el-form-item prop="password" class="login-item"> <el-input v-model="loginForm.password" class="area" type="password" :placeholder="$t('login.password')" prefix-icon="el-icon-lock" @keyup.enter.native="submitForm('loginForm')" /> </el-form-item> <el-form-item> <el-button :loading="loading" type="primary" class="submit_btn" @click="submitForm('loginForm')">{{ $t('login.logIn') }}</el-button> </el-form-item> <div class="tiparea"> <span style="margin-right:20px;">{{ $t('login.username') }} : admin</span> <span> {{ $t('login.password') }} : {{ $t('login.any') }}</span> </div> </el-form>
我們多處採用了類似 $t(‘login.username’) 的函數處理方式來動態獲取對應語言的內容即可，其中$t(）函數裏面就是對應的語義解析的鍵參數，對應我們lang/zh.js裏面或者lang/en.js裏面的內容即可。
其中多語言切換的時候，單擊圖標就可以切換為其他語言內容了。
切換英文後界面如下所示
同樣，其他地方，如果需要切換多語言的國際化處理，也可以使用$t的轉義方式，在頂部導航欄裏面，我們可以設置得到多語言支持的界面。
中文界面提示如下所示。
這部分的實現代碼是在組件模塊裏面，一樣可以實現國際化的處理的。
<template v-if="device!=='mobile'"> <search id="header-search" class="right-menu-item" /> <error-log class="errLog-container right-menu-item hover-effect" /> <el-tooltip :content="$t('navbar.fullscreen')" effect="dark" placement="bottom"> <screenfull id="screenfull" class="right-menu-item hover-effect" /> </el-tooltip> <el-tooltip :content="$t('navbar.size')" effect="dark" placement="bottom"> <size-select id="size-select" class="right-menu-item hover-effect" /> </el-tooltip> <el-tooltip :content="$t('navbar.language')" effect="dark" placement="bottom"> <lang-select class="right-menu-item hover-effect" /> </el-tooltip> </template>
列出以下前面幾篇隨筆的連接，供參考：
循序漸進VUE+Element 前端應用開發(1）— 開發環境的準備工作
循序漸進VUE+Element 前端應用開發(2）— Vuex中的API、Store和View的使用
循序漸進VUE+Element 前端應用開發(3）— 動態菜單和路由的關聯處理
循序漸進VUE+Element 前端應用開發(4）— 獲取後端數據及產品信息頁面的處理
循序漸進VUE+Element 前端應用開發(5）— 表格列表頁面的查詢，列表展示和字段轉義處理
循序漸進VUE+Element 前端應用開發(6）— 常規Element 界面組件的使用
循序漸進VUE+Element 前端應用開發(7）— 介紹一些常規的JS處理函數
循序漸進VUE+Element 前端應用開發(8）— 樹列表組件的使用
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※超省錢租車方案
※別再煩惱如何寫文案,掌握八大原則!
※回頭車貨運收費標準
※教你寫出一流的銷售文案?
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※網頁設計最專業,超強功能平台可客製化
起源
許多年前，一個剛結婚的名叫 Shay Banon 的失業開發者，跟着他的妻子去了倫敦，他的妻子在那裡學習廚師。 在尋找一個賺錢的工作的時候，為了給他的妻子做一個食譜搜索引擎，他開始使用 Lucene 的一個早期版本。
直接使用 Lucene 是很難的，因此 Shay 開始做一個抽象層，Java 開發者使用它可以很簡單的給他們的程序添加搜索功能。 他發布了他的第一個開源項目 Compass。
後來 Shay 獲得了一份工作，主要是高性能，分佈式環境下的內存數據網格。這個對於高性能，實時，分佈式搜索引擎的需求尤為突出， 他決定重寫 Compass，把它變為一個獨立的服務並取名 Elasticsearch。
第一個公開版本在2010年2月發布，從此以後，Elasticsearch 已經成為了 Github 上最活躍的項目之一，他擁有超過300名 contributors(目前736名 contributors )。 一家公司已經開始圍繞 Elasticsearch 提供商業服務，並開發新的特性，但是，Elasticsearch 將永遠開源並對所有人可用。
據說，Shay 的妻子還在等着她的食譜搜索引擎…
有3台機器
2台做elasticsearch的主副節點
1台做kibana和elasticsearch_head 由於機器匱乏我還在這台機器上部署了logstash和nginx服務（雖然下面的架構中都提到了redis等緩存，但是暫時沒有加該服務，後期會研究添加上的）
先說目的：將nginx的日誌通過logstash收集后發送到ela，然後kibana進行展示
環境如下
elasticsearch master 10.5.2.175:9200
elasticsearch salve 10.5.2.176:9200
logstash 172.17.211.153 啟動命令: nohup /usr/local/logstash/bin/logstash -f /usr/local/logstash/config/agent.conf -w 10 -l /usr/local/logstash/logs/logstash-plain.log &
nginx
es-head: 172.16.211.143:9100
kibana: 172.16.211.143:5601
架構如下：
加redis/kafa的原因：
在生產環境中，我們的日誌可能會有瞬時高峰，而這個時候如果直接存入es，可能會導致es承受不住，從而影響日誌的收集和查詢。 一般情況下，我們會將日誌存直接放到kafka或者redis這種讀寫性能非常高的應用中，作為一個緩存，然後通過下游組件（例如logstash）進行消費、過濾后存入ES，然後通過可視化界面查看。
Elasticsearch 是一個開源的搜索引擎，建立在一個全文搜索引擎庫 Apache Lucene™ 基礎之上。 Lucene 可以說是當下最先進、高性能、全功能的搜索引擎庫—無論是開源還是私有。
中文文檔https://www.elastic.co/guide/cn/elasticsearch/guide/current/intro.html#intro
具體安裝可以參考https://www.cnblogs.com/yanjieli/p/11187430.html這個教程，這裏直說下配置和思路，首先懂思路，安裝看教程就行。
需要有jdk環境
vim /etc/elasticsearch/jvm.options
2g
2g
1.vim /etc/elasticsearch/elasticsearch.yml
http.port: 9200
discovery.zen.ping.unicast.hosts: ["10.5.2.175","10.5.2.176"]
network.host: 10.5.2.175
2.vim /etc/systemd/system.conf
DefaultLimitNOFILE=65536
DefaultLimitNPROC=32000
DefaultLimitMEMLOCK=infinity
3.vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 32000
* hard nproc 32000
* hard memlock unlimited
* soft memlock unlimited
4.vim /etc/sysconfig/elasticsearch
JAVA_HOME=/usr/java/jdk1.8.0_151
5.vim /usr/lib/systemd/system/elasticsearch.service
[Service]
LimitMEMLOCK=infinity
啟動elasticsearch失敗，報找不到JAVA環境，可明明系統是有的 解決方法如下：
vim /etc/sysconfig/elasticsearch
JAVA_HOME=/usr/java/jdk1.8.0_151
index 索引 相當於數據庫里的“數據庫” 他是我們存儲和索引關聯數據的地方
type 類數據 將一類的數據放到一起 相當於數據庫中的“表”
id 相當於數據庫表中的一行
Elastic 本質上是一個分佈式數據庫，允許多台服務器協同工作，每台服務器可以運行多個 Elastic 實例。單個 Elastic 實例稱為一個節點（node）。一組節點構成一個集群（cluster）。
Elastic 會索引所有字段，經過處理后寫入一個反向索引（Inverted Index）。查找數據的時候，直接查找該索引。
倒排索引（反向索引）
原始文檔
創建倒排索引列表
倒排索引創建索引的流程：
1） 首先把所有的原始數據進行編號，形成文檔列表
2） 把文檔數據進行分詞，得到很多的詞條，以詞條為索引。保存包含這些詞條的文檔的編號信息。
搜索的過程：
當用戶輸入任意的詞條時，首先對用戶輸入的數據進行分詞，得到用戶要搜索的所有詞條，然後拿着這些詞條去倒排索引列表中進行匹配。找到這些詞條就能找到包含這些詞條的所有文檔的編號。
然後根據這些編號去文檔列表中找到文檔
所以，Elastic 數據管理的頂層單位就叫做 Index（索引）。它是單個數據庫的同義詞。每個 Index （即數據庫）的名字必須是小寫。
下面的命令可以查看當前節點的所有 Index。
$ curl -X GET 'http://localhost:9200/_cat/indices?v
index 索引 相當於數據庫里的“數據庫” 他是我們存儲和索引關聯數據的地方
type 類數據 將一類的數據放到一起 相當於數據庫中的“表”
id 相當於數據庫表中的一行
pertty 在網頁中格式化輸出響應內容
官方教程在這裏，我覺得這個更加實用官方教程 https://www.cnblogs.com/chuyuan/p/11380744.html
增
# 增加
http://10.5.103.176:9200/database1/table1
{
"name": "doudou",
"age": 4.5,
"weight": 20,
}
# 查詢
# 以上方法是正確的
但是再增加一個table2的是否發生如下報錯
http://10.5.103.176:9200/database1/table2
{
"name": "dianche1",
"weight": 1000
}
原因是elastic search在6.x版本調整了， 一個index只能存儲一種type。
查
GET /atguigu/_mapping
1. 檢索文檔
Mysql : select * from user where id = 1
ES : GET /atguigu/doc/1
響應結果
{
"_index" : "megacorp",
"_type" : "employee",
"_id" : "1",
"_version" : 1,
"found" : true,
"_source" : {
"first_name" : "John",
"last_name" : "Smith",
"age" : 25,
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
}
2.簡單檢索
Mysql : select * from user
ES : GET /megacorp/employee/_search
3.全文檢索
ES : GET /megacorp/employee/_search?q=haha
查詢出所有文檔字段值為haha的文檔
4.搜索（模糊查詢）
ES : GET /megacorp/employee/_search?q=hello
查詢出所有文檔字段值分詞后包含hello的文檔
5.聚合
PUT atguigu/_mapping/doc
{
"properties": {
"interests": {
"type": "text",
"fielddata": true
}
}
}
ealsticsearch只是後端提供各種api，那麼怎麼直觀的使用它呢？elasticsearch-head將是一款專門針對於elasticsearch的客戶端工具，是es的集群管理工具、數據可視化、增刪改查工具。相關詳細的教程在這裏
1 https://www.sojson.com/blog/85.html
2 https://www.cnblogs.com/xuwenjin/p/8792919.html
3 https://blog.csdn.net/huwei2003/article/details/40581143
一、下載head插件
https://github.com/mobz/elasticsearch-head
二、解壓到任意目錄
注意：為避免找不到，一定要和elasticsearch的安裝目錄區分開
三、安裝Node.js
因為head是一個Node.js項目。所以，如果沒有安裝nodejs需要先安裝Node.js
32位安裝包下載地址： https://nodejs.org/dist/v4.4.3/node-v4.4.3-x86.tar.gz
64位安裝包下載地址： https://nodejs.org/dist/v4.4.3/node-v4.4.3-x64.tar.gz
檢測PATH環境變量是否配置了Node.js，打開命令行輸入命令"which npm"，輸出如下結果：
/usr/bin/npm
wget https://nodejs.org/dist/latest-v8.x/node-v8.16.0.tar.gz
tar xf node-v8.16.0.tar.gz
cd node-v8.16.0
./configure --prefix=/usr/local/node-v8.16
make -j 8 && make install
添加環境變量
vim /etc/profile
################nodejs###############
export NODE_HOME=/usr/local/node-v8.16
export PATH=$PATH:$NODE_HOME/bin
source /etc/profile
node -v
v8.16.0
npm -v
6.4.1
四、安裝npm
yum install npm -y
五、es-head安裝：
解壓源碼包：elasticsearch-head.tar.gz
啟動：cd /usr/local/src/elasticsearch-head
npm run start &
訪問地址是http://{你的ip地址}:9200/_plugin/head/
在瀏覽器中輸入：這台機器的ip+端口
http://10.5.2.220:9100/
問題解決：
在elasticsearch中沒有當天的索引
頭一天使用過的bj日誌第二天無法收集到，原因是昨天logstash已經收集過一遍，就被打過了標籤，今天再使用的話，如果這個日誌是不再增加的就不會被收集，因為日誌中沒有新的內容進來，解決方法如下：
在logstash的config文件下的agent.conf加入以下配置
start_position =>"beginning"#檢查時間戳
vim config/kibana.yml
i18n.locale: "en" 或者zh-CN中文
systemctl restart kibana重啟即可
重新加載systemctl配置，這個是針對centos7以上使用systemctl kibana restart命令的
systemctl daemon-reload
這裏由於是二進制的安裝方法，所以要設置一個systemctl start kibana.service的啟動方法
1. vim /usr/lib/systemd/system/kibana.service
添加以下內容
[Unit]
Description=Kibana
After=network.target
[Service]
ExecStart=/usr/local/kibana/bin/kibana
Type=simple
PIDFile=/usr/local/kibana/kibana.pid
Restart=always
#User=es 這裏我直接使用root用戶進行啟動
#Group=es
[Install]
WantedBy=default.target
2. 重新加載一下配置文件
systemctl daemon-reload
3. 啟動
systemctl start kibana.service
4. 訪問測試
http://10.5.2.220:5601
參考地址1 參考地址2 參考地址3https://blog.csdn.net/u013958257/article/details/88567581
kibana查詢語法基於Lucene
Lucene是apache軟件基金會4 jakarta項目組的一個子項目，是一個開放源代碼的全文檢索引擎工具包，但它不是一個完整的全文檢索引擎，而是一個全文檢索引擎的架構，提供了完整的查詢引擎和索引引擎，部分文本分析引擎（英文與德文兩種西方語言）。Lucene的目的是為軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者是以此為基礎建立起完整的全文檢索引擎。Lucene是一套用於全文檢索和搜尋的開源程式庫，由Apache軟件基金會支持和提供。Lucene提供了一個簡單卻強大的應用程式接口，能夠做全文索引和搜尋。在Java開發環境里Lucene是一個成熟的免費開源工具。就其本身而言，Lucene是當前以及最近幾年最受歡迎的免費Java信息檢索程序庫。人們經常提到信息檢索程序庫，雖然與搜索引擎有關，但不應該將信息檢索程序庫與搜索引擎相混淆。
Lucene最初是由Doug Cutting開發的，在SourceForge的網站上提供下載。在2001年9月作為高質量的開源Java產品加入到Apache軟件基金會的 Jakarta家族中
kibana在ELK陣營中用來查詢展示數據
elasticsearch構建在Lucene之上，過濾器語法和Lucene相同
1. 根據某個字段查詢
精確匹配： agent:"Mozilla/5.0"
如果不帶雙引號，只要包含指定值就可以搜索到 agent:Mozilla/5.0
如果是數值類型沒有以上區別
2. 數組範圍查詢
[7758794 TO 7758794] 表示等於，原意思是一個區間範圍
指定區間： response:[100 TO 200]
大於等於指定數值的： response:[201 TO *]
小於等於指定數值的： response:[* TO 200]
3. 從指定時間到現在/或者查詢指定時間前數據
2015-05-20T09:20:41.943Z之後的數據： @timestamp:{2015-05-20T09:20:41.943Z TO *}
2015-05-20T09:20:41.943Z之前的數據： @timestamp:{* TO 2015-05-20T09:20:41.943Z }
指定時間範圍： @timestamp:{2015-05-20T09:20:41.943Z TO 015-05-22T09:20:41.943Z}
備註：09:20:41事實上是17:20:41，存在8個小時差
4. 正則匹配
包含指定值： request:/uploads*/
不包含指定值： !request:/uploads*/
5. 邏輯查詢
AND（與關係數據庫一樣） request:/uploads*/ AND response:404
OR（與關係數據庫一樣） request:/uploads*/ OR response:200
組合查詢: (uid OR token) AND version
6. 存在/不存在
存在host字段但不存在url字段： _exists_:host AND _missing_:url
特殊轉義字符
+ – && || ! () {} [] ^” ~ * ? : \
https://blog.csdn.net/weixin_34727238/article/details/81540692
當在els中有了當天的索引，就可以到kibana中取創建索引模式了，只是這裏提供了一手動創建的方式，無法自動進行，需要本地定義腳本的方式進行自動索引的創建。
等所有索引都創建完畢后，在下面就能看到了
然後在下面這個裡面就能看到我們的索引裏面的數據情況了，前提是你的logstash成功將切割后的日誌發送到了els中
否則就是以下這種的
由於logstash客戶端運行的問題，只要有當天日誌產生，就會將該日誌發送給elasticsearch，然後會在elasticsearch裏面產生一個新的索引
方法如下：
在kibana節點上寫一個腳本，然後設置定時任務執行kibana中索引與elasticsearch的關聯
vim /usr/local/scripts/kibana_create_index.sh
#!/bin/bash
today=`date +%Y-%m-%d`
index_name="nginx-log-${today}.log"
curl -X POST -H "kbn-xsrf:reporting" -H "Content-Type: application/json" -d '{"attributes":{"title":"'$log_name'"}}' 'http://172.16.211.143:5601/api/saved_objects/index-pattern'
這裏遇到一個問題，json中調用變量的問題，一直調用不到，後來各種查詢原來是格式不對
json數據里變量要用''括起來
<font color=gray size=72>color=gray</font>
json數據里變量要用”括起來https://www.cnblogs.com/landhu/p/7048255.html
第一點：KB、ES版本不一致（網上大部分都是這麼說的）
解決方法：把KB和ES版本調整為統一版本
第二點：kibana.yml中配置有問題（通過查看日誌，發現了Error: No Living connections的問題）
解決方法：將配置文件kibana.yml中的elasticsearch.url改為正確的鏈接，默認為: http://elasticsearch:9200
改為http://自己的IP地址:9200
第三點：瀏覽器沒有緩過來
解決方法：刷新幾次瀏覽器。
終極解決方法:在elasticsearch中刪除kibana的相關索引，只是再打開kibana看不到其他了之前創建的圖形什麼的了
分析的必要性：頂級
更多圖形看這裏https://www.cnblogs.com/hanyifeng/p/5860731.html
比較牛逼一點的教程看這裏https://www.bilibili.com/video/BV1TE411A77i?p=6
Filebeat是收集日誌的另外一種方式，二者區別在於以下
Filebeat用於日誌收集和傳輸，相比Logstash更加輕量級和易部署，對系統資源開銷更小，日誌流架構的話，Filebeat適合部署在收集的最前端，Logstash相比Filebeat功能更強，可以在Filebeat收集之後，由Logstash進一步做日誌的解析，至於kafka也可以考慮添加，然後收集的數據都存放在elasticsearch中。
https://blog.csdn.net/m0_38120325/article/details/79072921
在logstash客戶端的配置文件中會有這麼一個配置文件
就是會將日誌發送到當天日期的索引匯總，沒有的話自動創建索引,我們只需要做的就是每日刪除舊的索引。
电子書教程推薦：http://doc.yonyoucloud.com/doc/logstash-best-practice-cn/get_start/introduction.html
啟動方法 基於最基礎的 nohup 方式
nohup /usr/local/logstash/bin/logstash -f /usr/local/logstash/conf/agent.conf &> /dev/null
也可以用daemontools來進行管理
安裝
yum -y install supervisord --enablerepo=epel
在 /etc/supervisord.conf 配置文件里添加內容，定義你要啟動的程序：
[program:elkpro_1]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro1.conf --pluginpath /opt/logstash/plugins/ -w 10 -l /var/log/logstash/pro1.log
[program:elkpro_2]
environment=LS_HEAP_SIZE=5000m
directory=/opt/logstash
command=/opt/logstash/bin/logstash -f /etc/logstash/pro2.conf --pluginpath /opt/logstash/plugins/ -w 10 -l /var/log/logstash/pro2.log
然後啟動 service supervisord start 即可。
logstash 會以 supervisord 子進程的身份運行，你還可以使用 supervisorctl 命令，單獨控制一系列 logstash 子進程中某一個進程的啟停操作：
supervisorctl stop elkpro_2
官方給定的語法
https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
https://github.com/elastic/logstash/tree/v1.4.2/patterns
如果你使用的正則語言可以將nginx日誌進行匹配，就可以成功對日誌進行切割，效果看下圖：
調試的過程中可以使用這個網站來進行正則語法的測試：http://grokdebug.herokuapp.com/
1. 線上配置的信息格式192.168.70.94 跟權威指南中的一樣
SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:
以下這個是Logstash默認自帶了Apache標準日誌的grok正則表達式：
COMMONAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest
})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)
COMBINEDAPACHELOG %{COMMONAPACHELOG} %{QS:referrer} %{QS:agent}
2. 我的nginx日誌切割格式
NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{HTTPDATE:tiem_local}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_referer}\" \"%{DATA:http_user_agent}\"
MAINNGINXLOG %{COMBINEDAPACHELOG} %{QS:x_forwarded_for}
COMBINEDAPACHELOG 合併的apache日誌 logstash客戶端用的是這種方式
COMMONAPACHELOG 普通的apache日誌
當grok匹配失敗的時候，插件會為這個事件打個tag，默認是_grokparsefailure。LogStash允許你把這些處理失敗的事件路由到其他地方做後續的處理
input { # ... }
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} \[%{IPV4:ip};%{WORD:environment}\] %{LOGLEVEL:log_level} %{GREEDYDATA:message}" }
}
}
output {
if "_grokparsefailure" in [tags] {
# write events that didn't match to a file
file { "path" => "/tmp/grok_failures.txt" }
} else {
elasticsearch { }
}
}
看下面紅色的地方，表示grok匹配失敗，才會將tags的標籤定義成_grokparsefailure這個默認的
解決說是要設置錨點 目前不懂什麼意思 先放到這裏
https://www.jianshu.com/p/86133dd66ca4
另外一種說法，暫時不會用，先放着
1.
if "_grokparsefailure" in [tags] { drop { } }
2.match語句跟第一個一樣的 沒啥要點，看着官網例子搞就行了
3.盡量用grok吧 ，grep功能以後要去掉的。
當時想的另外一種解決方法就是改nginx的日誌格式成json形式的，但是我不想用這種方法。
log_format json '{"@timestamp":"$time_iso8601",'
'"host":"$server_addr",'
'"clientip":"$remote_addr",'
'"request":"$request",'
'"status":"$status",'
'"request_method": "$request_method",'
'"size":"$body_bytes_sent",'
'"request_time":"$request_time",'
'"upstreamtime":"$upstream_response_time",'
'"upstreamhost":"$upstream_addr",'
'"http_host":"$host",'
'"url":"$uri",'
'"http_forward":"$http_x_forwarded_for",'
'"referer":"$http_referer",'
'"agent":"$http_user_agent"}';
access_log /var/log/nginx/access.log json ;
以下是兩種日誌方式：
log_format main '$remote_addr - $remote_user [$time_iso8601] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$host" "$request_time"';
log_format format2 '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$host" "$request_time"';
在logstash中進行切割的時候調用的時間變量是不同的，靈感來自如下：
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:time}" }
}
date{
match => ["time", "yyyy-MM-dd HH:mm:ss", "ISO8601"]
target => "@timestamp"
}
mutate{
remove_field => ["time"]
}
定義：
HTTPDATE %{MONTHDAY}/%{MONTH}/%{YEAR}:%{TIME} %{INT}
TIMESTAMP_ISO8601 %{YEAR}-%{MONTHNUM}-%{MONTHDAY}[T ]%{HOUR}:?%{MINUTE}(?::?%{SECOND})?%{ISO8601_TIMEZONE}?
#NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{HTTPDATE:time_iso8601}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_referer}\" \"%
{DATA:http_user_agent}\"
{DATA:http_user_agent}\"
NGINX_ACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{TIMESTAMP_ISO8601:time_iso8601}\] \"%{DATA:request}\" %{INT:status} %{NUMBER:bytes_sent} \"%{DATA:http_refere
r}\" \"%{DATA:http_user_agent}\"
SYSLOGBASE %{SYSLOGTIMESTAMP:timestamp} (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:
COMMONAPACHELOG %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "(?:%{WORD:verb} %{NOTSPACE:request}(?: HTTP/%{NUMBER:httpversion})?|%{DATA:rawrequest
})" %{NUMBER:response} (?:%{NUMBER:bytes}|-)
COMBINEDAPACHELOG %{COMMONAPACHELOG} %{QS:referrer} %{QS:agent}
Nginx中時間格式1：$time_local 對應logstash中\[%{HTTPDATE:timestamp}\]
Nginx中時間格式2：$time_iso8601 對應logstash中\[%{TIMESTAMP_ISO8601:timestamp}\]
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※回頭車貨運收費標準
※推薦評價好的iphone維修中心
※超省錢租車方案
※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!
※推薦台中搬家公司優質服務,可到府估價
什麼是http緩存呢，當我們使用chrome瀏覽器，按F12打開控制台，在網絡請求中有時候看到狀態碼是200，有時候狀態碼是304，當我們去看這種請求的時候，我們會發現狀態碼為304的狀態結果是：Status Code: 304 Not Modified，而狀態碼為200的時候一般會有四種情況，一種是直接返回200，沒有任何其他的標誌，另一種是Status Code: 200 OK (from memory cache)，還有一種是Status Code: 200 (from disk cache)。最後一種不是太常見，Status Code: 200 (from Service Worker).後面這三種狀態碼看到的效果是灰色的，其實從給出的信息也能看出來是從緩存中獲取上數據。下面我們來詳細介紹一下他們都分別是什麼時候出現的。
其實我們可以按狀態碼來區分其為兩大類，分別是協商緩存–304和強制緩存–200
這種方式使用到了headers請求頭裡的兩個字段，Last-Modified & If-Modified-Since 。服務器通過響應頭Last-Modified告知瀏覽器，資源最後被修改的時間：
Last-Modified: Thu, 20 Jun 2019 15:58:05 GMT 當再次請求該資源時，瀏覽器需要再次向服務器確認，資源是否過期，其中的憑證就是請求頭If-Modified-Since字段，值為上次請求中響應頭Last-Modified字段的值：
If-Modified-Since: Thu, 20 Jun 2019 15:58:05 GMT 瀏覽器在發送請求的時候服務器會檢查請求頭request header裏面的If-modified-Since，如果最後修改時間相同則返回304，否則給返回頭(response header)添加last-Modified並且返回數據(response body)。
另外，瀏覽器在發送請求的時候服務器會檢查請求頭(request header)裏面的if-none-match的值與當前文件的內容通過hash算法（例如 nodejs: cryto.createHash(‘sha1’)）生成的內容摘要字符對比，相同則直接返回304，否則給返回頭(response header)添加etag屬性為當前的內容摘要字符，並且返回內容。
綜上總結為：
這裏我們使用到了Cache-Control和Expires這兩個字段來進行控制，Cache-Control裏面可以有多個屬性，可以組合設置，其屬性有如下幾種：
比如我們設置
Catch-Control:public,max-age=360000 我們在之前說了強制緩存有三種情況，上面說返回200有四種，第一種其實是不緩存，正常服務器返迴響應。
這個東西其實本質上時服務器和客戶端之間的代理服務器，一般我們在使用react開發的時候，會發現在根目錄出現了一個server-worker.js文件，這個東西就是和service Worker緩存相關的，他會根據網絡的狀態做出不同的緩存策略，有時候斷網了，之前訪問過的接口有可能依然會返回數據，其數據來源就是從其緩存中讀取。
這個是將資源緩存在了內存中。事實上，所有的網絡請求都會被瀏覽器緩存到內存中，當然，內存容量有限，緩存不能無限存放在內存中，因此，註定是個短期緩存。而其控制權在於瀏覽器。
與內存緩存相對的，這個是將資源緩存在硬盤中。雖然相比於內存，硬盤的讀取速度要慢很多，但總比沒有強。硬盤緩存的控制權在後端，通過什麼控制呢？通過HTTP響應頭控制，也就是我們在上面說到的catche-control和expires
Expires設置的過期時間是一個絕對的GMT時間，例如：Expires：Thu，20 Jun 2019 20：00：00 GMT; 他告訴瀏覽器緩存有效性持續到2019年6月20日為止，一直都使用緩存來處理。
Expires有一個非常大的缺陷，它使用一個固定的時間，要求服務器與客戶端的時鐘保持嚴格的同步，並且這一天到來后，服務器還得重新設定新的時間。
HTTP1.1引入了Cathe-Control，它使用max-age指定組件被緩存多久，從請求開始在max-age時間內瀏覽器使用緩存，之外的使用請求，這樣就可以消除Expires的限制，
如果對瀏覽器兼容性要求很高的話，可以兩個都使用。
其實在上面說到的Last-Modified對比最後修改時間與Expires一樣是有缺陷的，如果，資源的變化的時間間隔小於秒級，比如說是毫秒級的，或者說資源直接是動態生成的，那根據Last-Modified判斷，資源就是每時每刻都最新的，即被修改過！
所以，Etag & If-Node-Match 就是來解決這個問題的。
Etag字段的值為文件的特殊標識，一般都是hash生成的，服務器存儲着資源的Etag值。接下來的流程都與Lst-Modified & If-Modified-Since一致，只不過，比較的值從最後修改時間變成了Etag值。
Etag的優點在於，對於動態資源或者現在流行的Restful API返回的JSON數據，這些是沒有修改時間這一說法的，但是Http標準並沒有規定Etag值如何生成，因此我們通過代碼自己生成Etag值。當然，計算Etag值會消耗服務器性能。
因為http1.1>http1.0，所以Cache-Control>Expires，ETag>Last-Modified。依照就近原則，先找本地緩存，沒有再向服務器發請求，所以Expires>Last-Modified,Cache-Control>ETag，
如果瀏覽器只支持http1.0，那麼瀏覽器只會攜帶Last-Modified發送給後台，
如果服務器只支持http1.0，那麼服務器會以Last-Modified為標準。
如果瀏覽器支持http1.1，那麼瀏覽器會攜帶Cache-Control+Last-Modified+ETag發送給後台，
如果服務器支持http1.1，那麼服務器會以Cache-Control+ETag為標準。
在沒有設置Cache-Contral的情況下，設置Last-Modified和ETag緩存，會出現200（from cache）和304 交替出現的情況。
設置Cache-Contral的情況下，過期刷新會出現304(如果有更新內容，則是200)，之後再過期之前刷新都是200（from cache）。如果要確保要向服務端確認，可以將Cache-Contral的max-age設置為0。
通過下圖我們可以清晰的明白200和304
https://www.oecom.cn/http-header-control/
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※回頭車貨運收費標準
※產品缺大量曝光嗎?你需要的是一流包裝設計!
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※推薦評價好的iphone維修中心
※教你寫出一流的銷售文案?
※台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!
※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!