標籤: 南投搬家費用

在這之前已經把編輯個人的所有信息的功能已經完成了

之後先對首頁的列表搞動態的，之前都是寫死的靜態

1、之前都是把好友寫死的，現在就在js裏面定義一個數組，用循環來動態的綁定

在onReady中定義，取真實的數據給定義的列表數組list　　

通過調用  db.collection(‘users’).get()  這裏沒有加其他的限制，得到的就是所有的數據了，拿到全部的數據之後就會觸發then方法了

用then返回的res中有一個data的列表集合，有一個注意的點就是，這樣子讀取是吧數據庫中的數據的全部字段，但是我們需要用的只是

用戶的頭像和點贊數、用戶昵稱，其他的數據其實是不需要的

可以加一個field方法，可以要求返回的字段是哪些的

 

可以看到是只有一個用戶，我們為了模擬的話，就可以多賬號進行調試，

 

 1、創立多賬號

　　　　①首先這個多賬號的一定要是測試號，所以先進入微信的管理後台 https://mp.weixin.qq.com/

　　　　②進入 【成員管理】添加項目成員

　　　　③回到微信開發者工具中-》工具-》多賬號調試-》可以通過添加虛擬測試號來進行測試的，不用真實的微信號都可以

 

之後就是對點贊的功能進行設計了（就可以在index.wxml中給點贊的小心上加一個點擊事件即可了

（小細節在小程序中規定，在客戶端中讀取用戶列表的時候，一般不會把整個數據庫的用戶都讀取出來的，是有一個限制的

一般都是把前二十條數據給讀取出來的，如果數據一多的話，一般都是進行分頁處理了–一般都是用數據庫中的collection.skip和collection.limit,這兩個東西一起配合的話就可以做下拉加載的功能了）

由於這個點贊是要對找到用戶的id地址的，所以在wxml中給點贊這個圖標加上一個id自定義屬性的掛載

 

data-id="{{ item._id}}"

這個東西的用處就是，在點擊這個心心的時候就可以拿到這個自定義的屬性id了　　

通過把handleLinks（ev）函數中把ev打印出來發現，這個自定義屬性id 的位置在

 ev.target.dataset.id

console.log就是用來測試的，如果沒效果的話，一般都是直接在點擊事件後面通過promise 的then把res打印出來看看情況是怎麼樣的

***有時候這些點擊事件無法觸發的話，就可以在檢查一下樣式，可能這個區域在前端显示是在這裏，但是實際上是在其他的地方，

 

 

 也就是布局引起的問題了

 

 

 

 可以看到這裏就是碰到的是點贊的這個圖標，但是這個樣式是在左上角進行了渲染的

這個時候為了演示把，就把自定義屬性，和點擊事件放在點贊圖標還有點贊數包含的這個text裏面了

<text bindtap="handleLinks" data-id="{{ item._id}}" >
          <!-- 點贊圖標 -->
              <text class="iconfont icondianzan"
              ></text>
          <!-- 點贊數 -->
              <text>{{ item.links }}</text>
          </text>

改完之後，再點擊心心或者是數量，就可以正常的進行點贊了

　　但是發現只有給自己點贊的時候才可以改變點贊的數量，而改其他人點贊的時候就改不了

比如：

 

 

 這就是一個權限的問題了也就是只能改自己的數據（點贊數）改不了別人的數據l

 

 

因為在小程序端中，由於用戶可以直接對數據庫進行操作，所以會有一定的風險，所以就通過這個訪問權限來進行了限制

那？

怎麼修改別人的數據呢？—這個操作就要在服務端來進行操作了！　　也就是在雲函數中去完成一個雲函數的操作了

 

下面就是講解 如何在 服務端來對数字字段來進行更改！

 

二、點贊功能實現與update雲函數

 由於要在服務端來做的話，就可以把這一塊的部分代碼刪掉了

  handleLinks(ev){
    let id = ev.target.dataset.id;
    db.collection('users').doc(id).update({
      data : {
        links : 5
      }
    }).then((res)=>{
      console.log(res)
    }); 
  }

需要新創一個雲函數（新建一個node.js雲函數

 

這些默認的結構都是可以刪掉的了

 

 之後就是參考 微信開放文檔 雲開發-》SDK文檔->數據庫-》collection->update-》示例代碼demo

其中：這個就是指定了數據庫的環境

cloud.init({
  env: cloud.DYNAMIC_CURRENT_ENV
})

然後就是在服務端拿到數據庫db

const db = cloud.database()

然後可以在示例代碼中看到async這個異步的操作

直接複製 try catch

try {
    return await db.collection('todos').where({
      done: false
    })
    .update({
      data: {
        progress: _.inc(10)
      },
    })
  } catch(e) {
    console.error(e)
  }

return就是返回一個異步的數據，而catch就是返回錯誤信息

主要修改的就是 db.collecion()中要反問那個數據庫表單，這裏不能寫死為users，因為可能其他的地方也是要用到更新的這個功能的

所以最好就是把update這個雲函數寫成一個通用的方式

其中雲函數入口函數 

exports.main = async (event, context) => {  這個裡面的event就是前端傳參過來的對象了 就訪問 event.colletion,然後不用where而是用doc 再把event的doc也傳進來，這 ***小知識點：ES6的擴展運算符 。。。 (三個點）

更新成功了之後，就可以返回結果到前台了

這個就是update雲函數中js文件的代碼（傳進去的doc實際上是用戶的_id

 // 雲函數入口文件
const cloud = require('wx-server-sdk')

cloud.init({
  env: cloud.DYNAMIC_CURRENT_ENV
})
const db = cloud.database()
// 雲函數入口函數
exports.main = async (event, context) => {
  try {
    return await db.collection(event.collection).doc(event.doc)
      .update({
        data: {
         ...event.data 
        },
      })
  } catch (e) {
    console.error(e)
  }
}

View Code

把雲函數寫好之後，這個時候雲函數還是在本地，要把這個雲函數傳到雲開發平台上

 

上傳了之後一定要去雲平台-》雲函數中去檢查一下

 

之後就可以調用這個雲函數了

再回到index.js 點贊的方法 handleLinkes方法中進行設置即可；

 

 如果雲函數沒問題，可能是雲函數裏面定義的env出了問題，就可以寫死了，傳入自己的那個環境，就不用默認的那個環境了

【注意】修改了雲函數記得要重新上傳到雲平台才行

 

 

 

 （因為在服務端是不會受到數據庫權限的限制的）

後面要優化的就是（上面的點贊是寫死給多少links的，並且不能點完之後立馬更新

可以把數據庫的links讀出來，+1之後再寫入，但是這樣的話就多了一個數據庫的操縱了　　，但是數據庫本身就提供了累加或者累減等運算的操作的

（這樣的話就只需要一次的數據庫讀取即可了）

在開放文檔 db.command裏面就有很多的方法

https://developers.weixin.qq.com/miniprogram/dev/wxcloud/reference-sdk-api/database/command/Command.inc.html

示例代碼
將一個 todo 的進度自增 10：

const _ = db.command
db.collection('todos').doc('todo-id').update({
  data: {
    progress: _.inc(10)
  }
})

為了在服務端不把運算給寫死了，一般都是把運算直接通過前端來傳入的

由於前端不認識下劃線這種操作，因為前端要先解析，之後再把東西傳到服務端的，所以就可以在前端給服務端傳一個字符串的話

然後再在服務端解析即可

 data : "{links : _.inc(1)}"

在前端把這個字符串傳入到服務端中，之後就可以在服務端那邊對這個字符串進行解析了

所以在update雲函數中 就要對event.data這個傳過來的數據進行判斷，判斷它的類型，是普通的還是字符串類型的，如果是字符串類型的話就要進行解析

用js裏面的eval方法，它是把字符串轉成 js 語句的

 if(typeof event.data == 'string'){
      event.data =  eval('(' + event.data + ')')
    }

即可了（點一下心心就可以讓點贊數+1）

後面有空的話，可以繼續進行優化，也就是對一次的點贊數進行限制，或者是點一下加+1，再點一下就是取消了就-1了

後面就是要把點贊了之後，實時的把點贊數進行更新

 

可以看到給服務端那邊上傳之後，對數據庫進行了更新之後，then返回的結果res，中有一個是updated==1，就可以進行if判斷了

再用for循環對列表中的每一個元素判斷，是不是現在被點擊點贊的這個id

let updated = res.result.stats.updated;
    if(updated){
      // 先用擴展運算符 克隆一份數組
      let cloneListData = [...this.data.listData];
      for(let i = 0;i < cloneListData.length ; i++){
        if( cloneListData[i]._id == id){ 
          cloneListData[i].links++;
        }
      }
      this.setData({
        listData : cloneListData
      });
    }

點贊數增加 就是通過_inc 但是在服務端中的update函數中是用全局的，不能寫死，所以運算的規則就通過前端傳過去

為了以後其他的頁面也有更新功能的話做準備了

 

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

美國電動車廠特斯拉（Tesla）公佈首季獲利不如預期，但好消息是眾所矚目的Model 3平價電動車，有望如期量產。

特斯拉當季營收27億美元，為去年同期營收11.5億美元的兩倍多，亦優於分析師預估的26.2億美元。（路透社）

儘管如此，特斯拉當季每股虧1.33美元，遠超過分析師預估每股虧0.81美元。特斯拉去年同期每股虧1.45美元。

特斯拉說Model 3開發進度順利，將可在今年7月導入量產。不過從虧損超出預期可知，這應該是特斯拉燒錢換來的成果。

另外，特斯拉執行長Elon Musk還憂心客戶對定價只有35,000美元的Model 3期待太高，而忘了Model 3是平價車種，性能與續航力均不能與售價70,000美元的Model S相提並論。

特斯拉首季共交車25,051部，較去年同期成長64%、較去年第四季成長13%，上半年47,000-50,000部的交車目標也有望達陣。

（本文內容由授權使用。圖片出處：Tesla）  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

特斯拉（Tesla）懷著超級工廠大夢，準備在電池領域一統江湖，歐洲強國也不甘示弱，德國總理梅克爾（Angela Merkel）參加德國戴姆勒汽車（Daimler）斥資5 億歐元興建的鋰電池工廠的動土典禮，這項歐洲大陸的超級電池工廠計畫，將挑戰Tesla 在綠色電力領域的領導地位。

彭博報導，德國電池工廠位於柏林南部130 公里處，突顯主要汽車製造商和電力公司進入儲能的行動，這項技術對推動下一代綠色車輛，以及在需要時儲存風力與太陽能電力上至關重要。報導認為，隨著汽車製造商與電力公司同步發展，電池成本可能會迅速下滑。

彭博分析師認為，電池成本下降與能源密度增加，預計2030 年就可以看到電動車比燃料汽車更便宜的情況。根據彭博新能源財經（BNEF）數據，全球電池製造產能將在2021 年翻倍，達到2.78 億度，現在約1.03 億度，屆時歐洲市場佔比將從現在的2.5% 提高一倍。

瑞典、匈牙利和波蘭計劃中的大型工廠，以及戴姆勒在德國的電池組裝廠，預計會為福斯與雷諾等汽車製造商提供需求，屆時鋰離子電池成本將降低43%，使電動汽車成為主流。

對於公用事業而言，便宜的電池可以降低儲存單元的成本，儲存單元可將變動型再生能源如風能與太陽能的電力傳送至電網。義大利國家電力公司Enel SpA 將電池與風力發電場配套使用，電網管理人員對電力輸出的預測準度因此提高30%。

1990 年代初期消費類電子產品如電腦和手機使用的鋰離子電池，已經跨界應用於運輸和電力行業，但礙於成本，鋰電池在電網和汽車上的應用才剛剛開始，電池的興起對於電動汽車的消費者來說最為明顯，大多數主要汽車製造商將充電式電動車訂為未來10 年的中期計劃。

目前電池業務仍由亞洲電子製造商所主導。根據BNEF，韓國LG 和三星SDI 是頂級供應商，亞洲有望繼續保持領先地位，中國另有8 個工廠正在興建。

汽車製造商採取行動確保電池供應源，戴姆勒的工廠將是歐洲最大的工廠，供應旗下汽車與梅賽德斯賓士，並與屋頂太陽能安裝商Vivint Solar 合資生產家庭能源儲存系統。

2017 年1 月Tesla 的工廠完成三分之一，完工後每年產能可達35 千兆瓦，足以支持每年生產50 萬輛電動車，這將使Tesla 成為繼LG 化學之後的第2 大供應商，特斯拉也在計畫興建更多超級工廠。

戴姆勒的投資規模較小，且尚未披露產能目標。福斯正在與電池廠商討論投資項目，並計劃在德國興建原型組裝廠以開發自己的技術。位於斯德哥爾摩的創業公司NorthVolt AB 宣布計劃在2023 年在瑞典設立一家40 億歐元的電池廠。鋰電池產量大增可望降低所有應用的電池成本，讓家庭和電網的儲存更加實惠。

未來10 年電動汽車價格可望能與汽油或柴油車競爭，由於電池組是充電電動車中最昂貴的部分，佔總成本的三分之一，預計到2021 年，鋰離子電池將便宜43%，從目前的每千瓦273 美元降至156 美元。

鋰電池普及是可以預見的事，但問題是儲存對消費者或大型公用事業而言是否有利可圖仍然是一個懸而未決的問題。即使如此，電動汽車廠商也正在尋找未來，根據BNEF，2030 年前充電式電動車可能佔新車銷售的五分之一，即2,100 萬台。梅克爾訪問戴姆勒工廠展現了德國政府計劃2030 年讓600 萬輛電動汽車上路的決心。

（合作媒體：。圖片出處：Tesla）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

　　前文我聊到了docker machine的簡單使用和基本原理的說明，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/13160915.html；今天我們來聊一聊docker集群管理工具docker swarm；docker swarm是docker 官方的集群管理工具，它可以讓跨主機節點來創建，管理docker 集群；它的主要作用就是可以把多個節點主機的docker環境整合成一個大的docker資源池；docker swarm面向的就是這個大的docker 資源池在上面管理容器；在前面我們都只是在單台主機上的創建，管理容器，但是在生產環境中通常一台物理機上的容器實在是不能夠滿足當前業務的需求，所以docker swarm提供了一種集群解決方案，方便在多個節點上創建，管理容器；接下來我們來看看docker swarm集群的搭建過程吧；

　　docker swarm 在我們安裝好docker時就已經安裝好了，我們可以使用docker info來查看

[root@node1 ~]# docker info
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 19.03.11
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-693.el7.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.686GiB
 Name: docker-node01
 ID: 4HXP:YJ5W:4SM5:NAPM:NXPZ:QFIU:ARVJ:BYDG:KVWU:5AAJ:77GC:X7GQ
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
  provider=generic
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[root@node1 ~]# 

　　提示：從上面的信息可以看到，swarm是處於非活躍狀態，這是因為我們還沒有初始化集群，所以對應的swarm選項的值是處於inactive狀態；

　　初始化集群

[root@docker-node01 ~]# docker swarm init --advertise-addr 192.168.0.41
Swarm initialized: current node (ynz304mbltxx10v3i15ldkmj1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

[root@docker-node01 ~]# 

　　提示：從上面反饋的信息可以看到，集群初始化成功，並且告訴我們當前節點為管理節點，如果想要其他節點加入到該集群，可以在對應節點上運行docker swarm join –token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377 這個命令，就把對應節點當作work節點加入到該集群，如果想要以管理節點身份加入到集群，我們需要在當前終端運行docker swarm join-token manager命令

[root@docker-node01 ~]# docker swarm join-token manager
To add a manager to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-dqjeh8hp6cp99bksjc03b8yu3 192.168.0.41:2377

[root@docker-node01 ~]# 

　　提示：我們執行docker swarm join-token manager命令，它返回了一個命令，並告訴我們添加一個管理節點，在對應節點上執行docker swarm join –token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-dqjeh8hp6cp99bksjc03b8yu3 192.168.0.41:2377命令即可；

　　到此docker swarm集群就初始化完畢，接下來我們把其他節點加入到該集群

　　把docker-node02以work節點身份加入集群

[root@node2 ~]# docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377
This node joined a swarm as a worker.
[root@node2 ~]# 

　　提示：沒有報錯就表示加入集群成功；我們可以使用docker info來查看當前的docker 環境詳細信息

　　提示：從上面的信息可以看到，在docker-node02這台主機上docker swarm 已經激活，並且可以看到管理節點的地址；除了以上方式可以確定docker-node02以及加入到集群；我們還可以在管理節點上運行docker node ls 查看集群節點信息；

　　查看集群節點信息

　　提示：在管理節點上運行docker node ls 就可以列出當前集群里有多少節點已經成功加入進來；

　　把docker-node03以管理節點身份加入到集群

　　提示：可以看到docker-node03已經是集群的管理節點，所以可以在docker-node03這個節點執行docker node ls 命令；到此docker swarm集群就搭建好了；接下來我們來說一說docker swarm集群的常用管理

　　有關節點相關管理命令

　　docker node ls ：列出當前集群上的所有節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# 

　　提示：該命令只能在管理節點上執行；

　　docker node inspect ：查看指定節點的詳細信息；

[root@docker-node01 ~]# docker node inspect docker-node01
[
    {
        "ID": "ynz304mbltxx10v3i15ldkmj1",
        "Version": {
            "Index": 9
        },
        "CreatedAt": "2020-06-20T05:57:17.57684293Z",
        "UpdatedAt": "2020-06-20T05:57:18.18575648Z",
        "Spec": {
            "Labels": {},
            "Role": "manager",
            "Availability": "active"
        },
        "Description": {
            "Hostname": "docker-node01",
            "Platform": {
                "Architecture": "x86_64",
                "OS": "linux"
            },
            "Resources": {
                "NanoCPUs": 4000000000,
                "MemoryBytes": 3958075392
            },
            "Engine": {
                "EngineVersion": "19.03.11",
                "Labels": {
                    "provider": "generic"
                },
                "Plugins": [
                    {
                        "Type": "Log",
                        "Name": "awslogs"
                    },
                    {
                        "Type": "Log",
                        "Name": "fluentd"
                    },
                    {
                        "Type": "Log",
                        "Name": "gcplogs"
                    },
                    {
                        "Type": "Log",
                        "Name": "gelf"
                    },
                    {
                        "Type": "Log",
                        "Name": "journald"
                    },
                    {
                        "Type": "Log",
                        "Name": "json-file"
                    },
                    {
                        "Type": "Log",
                        "Name": "local"
                    },
                    {
                        "Type": "Log",
                        "Name": "logentries"
                    },
                    {
                        "Type": "Log",
                        "Name": "splunk"
                    },
                    {
                        "Type": "Log",
                        "Name": "syslog"
                    },
                    {
                        "Type": "Network",
                        "Name": "bridge"
                    },
                    {
                        "Type": "Network",
                        "Name": "host"
                    },
                    {
                        "Type": "Network",
                        "Name": "ipvlan"
                    },
                    {
                        "Type": "Network",
                        "Name": "macvlan"
                    },
                    {
                        "Type": "Network",
                        "Name": "null"
                    },
                    {
                        "Type": "Network",
                        "Name": "overlay"
                    },
                    {
                        "Type": "Volume",
                        "Name": "local"
                    }
                ]
            },
            "TLSInfo": {
                "TrustRoot": "-----BEGIN CERTIFICATE-----\nMIIBaTCCARCgAwIBAgIUeBd/eSZ7WaiyLby9o1yWpjps3gwwCgYIKoZIzj0EAwIw\nEzERMA8GA1UEAxMIc3dhcm0tY2EwHhcNMjAwNjIwMDU1MjAwWhcNNDAwNjE1MDU1\nMjAwWjATMREwDwYDVQQDEwhzd2FybS1jYTBZMBMGByqGSM49AgEGCCqGSM49AwEH\nA0IABMsYxnGoPbM4gqb23E1TvOeQcLcY56XysLuF8tYKm56GuKpeD/SqXrUCYqKZ\nHV+WSqcM0fD1g+mgZwlUwFzNxhajQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB\nAf8EBTADAQH/MB0GA1UdDgQWBBTV64kbvS83eRHyI6hdJeEIv3GmrTAKBggqhkjO\nPQQDAgNHADBEAiBBB4hLn0ijybJWH5j5rtMdAoj8l/6M3PXERnRSlhbcawIgLoby\newMHCnm8IIrUGe7s4CZ07iHG477punuPMKDgqJ0=\n-----END CERTIFICATE-----\n",
                "CertIssuerSubject": "MBMxETAPBgNVBAMTCHN3YXJtLWNh",
                "CertIssuerPublicKey": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyxjGcag9sziCpvbcTVO855BwtxjnpfKwu4Xy1gqbnoa4ql4P9KpetQJiopkdX5ZKpwzR8PWD6aBnCVTAXM3GFg=="
            }
        },
        "Status": {
            "State": "ready",
            "Addr": "192.168.0.41"
        },
        "ManagerStatus": {
            "Leader": true,
            "Reachability": "reachable",
            "Addr": "192.168.0.41:2377"
        }
    }
]
[root@docker-node01 ~]#

　　docker node ps ：列出指定節點上運行容器的清單

[root@docker-node01 ~]# docker node ps 
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE       ERROR               PORTS
[root@docker-node01 ~]# docker node ps docker-node01
ID                  NAME                IMAGE               NODE                DESIRED STATE       CURRENT STATE       ERROR               PORTS
[root@docker-node01 ~]# 

　　提示：類似docker ps 命令，我上面沒有運行容器，所以看不到對應信息；默認不指定節點名稱表示查看當前節點上的運行容器清單；

　　docker node rm ：刪除指定節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# docker node rm docker-node03
Error response from daemon: rpc error: code = FailedPrecondition desc = node aeo8j7zit9qkoeeft3j0q1h0z is a cluster manager and is a member of the raft cluster. It must be demoted to worker before removal
[root@docker-node01 ~]# docker node rm docker-node02
Error response from daemon: rpc error: code = FailedPrecondition desc = node tzkm0ymzjdmc1r8d54snievf1 is not down and can't be removed
[root@docker-node01 ~]# 

　　提示：刪除節點前必須滿足，被刪除的節點不是管理節點，其次就是要刪除的節點必須是down狀態；

　　docker swarm leave：離開當前集群

[root@docker-node03 ~]# docker ps 
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
e7958ffa16cd        nginx               "/docker-entrypoint.…"   28 seconds ago      Up 26 seconds       80/tcp              n1
[root@docker-node03 ~]# docker swarm leave 
Error response from daemon: You are attempting to leave the swarm on a node that is participating as a manager. Removing this node leaves 1 managers out of 2. Without a Raft quorum your swarm will be inaccessible. The only way to restore a swarm that has lost consensus is to reinitialize it with `--force-new-cluster`. Use `--force` to suppress this message.
[root@docker-node03 ~]# docker swarm leave -f
Node left the swarm.
[root@docker-node03 ~]# 

　　提示：管理節點默認是不允許離開集群的，如果強制使用-f選項離開集群，會導致在其他管理節點無法正常管理集群；

[root@docker-node01 ~]# docker node ls
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
[root@docker-node01 ~]#

　　提示：我們在docker-node01上現在就不能使用docker node ls 來查看集群節點列表了；解決辦法重新初始化集群；

[root@docker-node01 ~]# docker node ls 
Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.
[root@docker-node01 ~]# docker swarm init --advertise-addr 192.168.0.41
Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.
[root@docker-node01 ~]# docker swarm init --force-new-cluster 
Swarm initialized: current node (ynz304mbltxx10v3i15ldkmj1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-6difxlq3wc8emlwxzuw95gp8rmvbz2oq62kux3as0e4rbyqhk3-2m9x12n102ca4qlyjpseobzik 192.168.0.41:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Unknown             Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Down                Active                                  19.03.11
rm3j7cjvmoa35yy8ckuzoay46     docker-node03       Unknown             Active                                  19.03.11
[root@docker-node01 ~]# 

　　提示：重新初始化集群不能使用docker swarm init –advertise-addr 192.168.0.41這種方式初始化，必須使用docker swarm init –force-new-cluster，該命令表示使用從當前狀態強制創建一個集群；現在我們就可以使用docker node rm 把down狀態的節點從集群刪除；

　　刪除down狀態的節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
aeo8j7zit9qkoeeft3j0q1h0z     docker-node03       Down                Active                                  19.03.11
rm3j7cjvmoa35yy8ckuzoay46     docker-node03       Down                Active                                  19.03.11
[root@docker-node01 ~]# docker node rm aeo8j7zit9qkoeeft3j0q1h0z rm3j7cjvmoa35yy8ckuzoay46
aeo8j7zit9qkoeeft3j0q1h0z
rm3j7cjvmoa35yy8ckuzoay46
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

　　docker node promote：把指定節點提升為管理節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# docker node promote docker-node02
Node docker-node02 promoted to a manager in the swarm.
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# 

　　docker node demote：把指定節點降級為work節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active              Reachable           19.03.11
[root@docker-node01 ~]# docker node demote docker-node02
Manager docker-node02 demoted in the swarm.
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

　　docker node update：更新指定節點

[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Active              Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# docker node update docker-node01 --availability drain 
docker-node01
[root@docker-node01 ~]# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
ynz304mbltxx10v3i15ldkmj1 *   docker-node01       Ready               Drain               Leader              19.03.11
tzkm0ymzjdmc1r8d54snievf1     docker-node02       Ready               Active                                  19.03.11
[root@docker-node01 ~]# 

　　提示：以上命令把docker-node01的availability屬性更改為drain，這樣更改后docker-node01的資源就不會被調度到用來運行容器；

　　為docker swarm集群添加圖形界面

[root@docker-node01 docker]# docker run --name v1 -d -p 8888:8080 -e HOST=192.168.0.41 -e PORT=8080 -v /var/run/docker.sock:/var/run/docker.sock docker-registry.io/test/visualizer
Unable to find image 'docker-registry.io/test/visualizer:latest' locally
latest: Pulling from test/visualizer
cd784148e348: Pull complete 
f6268ae5d1d7: Pull complete 
97eb9028b14b: Pull complete 
9975a7a2a3d1: Pull complete 
ba903e5e6801: Pull complete 
7f034edb1086: Pull complete 
cd5dbf77b483: Pull complete 
5e7311667ddb: Pull complete 
687c1072bfcb: Pull complete 
aa18e5d3472c: Pull complete 
a3da1957bd6b: Pull complete 
e42dbf1c67c4: Pull complete 
5a18b01011d2: Pull complete 
Digest: sha256:54d65cbcbff52ee7d789cd285fbe68f07a46e3419c8fcded437af4c616915c85
Status: Downloaded newer image for docker-registry.io/test/visualizer:latest
3c15b186ff51848130393944e09a427bd40d2504c54614f93e28477a4961f8b6
[root@docker-node01 docker]# docker ps 
CONTAINER ID        IMAGE                                COMMAND             CREATED             STATUS                            PORTS                    NAMES
3c15b186ff51        docker-registry.io/test/visualizer   "npm start"         6 seconds ago       Up 5 seconds (health: starting)   0.0.0.0:8888->8080/tcp   v1
[root@docker-node01 docker]# 

　　提示：我上面的命令是從私有倉庫中下載的鏡像，原因是互聯網下載太慢了，所以我提前下載好，放在私有倉庫中；有關私有倉庫的搭建使用，請參考https://www.cnblogs.com/qiuhom-1874/p/13061984.html或者https://www.cnblogs.com/qiuhom-1874/p/13058338.html；在管理節點上運行visualizer容器后，我們就可以直接訪問該管理節點地址的8888端口，就可以看到當前容器的情況；如下圖

　　提示：從上面的信息可以看到當前集群有一個管理節點和兩個work節點；現目前集群里沒有運行任何容器；

　　在docker swarm運行服務

[root@docker-node01 ~]# docker service create --name myweb docker-registry.io/test/nginx:latest
i0j6wvvtfe1360ibj04jxulmd
overall progress: 1 out of 1 tasks 
1/1: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service ps myweb
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
99y8towew77e        myweb.1             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 1 minutes ago                       
[root@docker-node01 ~]#

　　提示：docker service create 表示在當前swarm集群環境中創建一個服務；以上命令表示在swarm集群上創建一個名為myweb的服務，用docker-registry.io/test/nginx:latest鏡像；默認情況下只啟動一個副本；

　　提示：可以看到當前集群中運行了一個myweb的容器，並且運行在docker-node03這台主機上；

　　在swarm 集群上創建多個副本服務

[root@docker-node01 ~]# docker service create --replicas 3 --name web docker-registry.io/test/nginx:latest
mbiap412jyugfpi4a38mb5i1k
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          3/3                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]#docker service ps web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 28 seconds ago                       
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 28 seconds ago                       
l9jtbswl2x22        web.3               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 32 seconds ago                       
[root@docker-node01 ~]# 

　　提示:–replicas選項用來指定期望運行的副本數量,該選項會在集群上創建我們指定數量的副本,即便我們集群中有節點宕機,它始終會創建我們指定數量的容器在集群上運行着;

　　測試:把docker-node03關機,看看我們運行的服務是否會遷移到節點2上呢?

　　docker-node03關機前

　　docker-node03關機后

　　提示:從上面的截圖可以看到,當節點3宕機后,節點3上跑的所有容器,會全部遷移到節點2上來;這就是創建容器時用–replicas選項的作用;總結一點,創建服務使用副本模式,該服務所在節點故障,它會把對應節點上的服務遷移到其他節點上;這裏需要提醒一點的是,只要集群上的服務副本滿足我們指定的replicas的數量,即便故障的節點恢復了,它是不會把服務遷移回來的;

[root@docker-node01 ~]# docker service ps web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE             ERROR               PORTS
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 15 minutes ago                        
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 15 minutes ago                        
t3gjvsgtpuql        web.3               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 6 minutes ago                         
l9jtbswl2x22         \_ web.3           docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 23 seconds ago                       
[root@docker-node01 ~]# 

　　提示:我們在管理節點查看服務列表,可以看到它遷移服務就是把對應節點上的副本停掉,然後在其他節點創建一個新的副本;

　　服務伸縮

[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          1/1                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          3/3                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service scale myweb=3 web=5
myweb scaled to 3
web scaled to 5
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
overall progress: 5 out of 5 tasks 
1/5: running   [==================================================>] 
2/5: running   [==================================================>] 
3/5: running   [==================================================>] 
4/5: running   [==================================================>] 
5/5: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          3/3                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          5/5                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service ps myweb web
ID                  NAME                IMAGE                                  NODE                DESIRED STATE       CURRENT STATE            ERROR               PORTS
j7w490h2lons        myweb.1             docker-registry.io/test/nginx:latest   docker-node02       Running             Running 12 minutes ago                       
1rt0e7u4senz        web.1               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 21 minutes ago                       
99y8towew77e        myweb.1             docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 5 minutes ago                       
en5rk0jf09wu        myweb.2             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
31ll0zu7udld        web.2               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 21 minutes ago                       
h1hze7h819ca        myweb.3             docker-registry.io/test/nginx:latest   docker-node03       Running             Running 30 seconds ago                       
t3gjvsgtpuql        web.3               docker-registry.io/test/nginx:latest   docker-node02       Running             Running 12 minutes ago                       
l9jtbswl2x22         \_ web.3           docker-registry.io/test/nginx:latest   docker-node03       Shutdown            Shutdown 5 minutes ago                       
od3ti2ixpsgc        web.4               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
n1vur8wbmkgz        web.5               docker-registry.io/test/nginx:latest   docker-node03       Running             Running 31 seconds ago                       
[root@docker-node01 ~]# 

　　提示:docker service scale 命令用來指定服務的副本數量,從而實現動態伸縮;

　　服務暴露

[root@docker-node01 ~]# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                                  PORTS
i0j6wvvtfe13        myweb               replicated          3/3                 docker-registry.io/test/nginx:latest   
mbiap412jyug        web                 replicated          5/5                 docker-registry.io/test/nginx:latest   
[root@docker-node01 ~]# docker service update  --publish-add 80:80 myweb 
myweb
overall progress: 3 out of 3 tasks 
1/3: running   [==================================================>] 
2/3: running   [==================================================>] 
3/3: running   [==================================================>] 
verify: Service converged 
[root@docker-node01 ~]#

　　提示：docker swarm集群中的服務暴露和docker裏面的端口暴露原理是一樣的，都是通過iptables 規則表或LVS規則實現的；

　　提示：我們可以在管理節點上看到對應80端口已經處於監聽狀態，並且在iptables規則表中多了一項訪問本機80端口都DNAT到172.18.0.2的80上了；其實不光是在管理節點，在work節點上相應的iptables規則也都發生了變化；如下

　　提示：從上面的規則來看，我們訪問節點地址的80端口，都會DNAT到172.18.0.2的80；

　　提示：從上面是显示結果看，我們不難得知在docker-node02運行myweb容器的內部地址是10.0.0.7，那為什麼我們訪問172.18.0.2是能夠訪問到容器內部的服務呢？

　　測試：我們在docker-node02追蹤查看nginx容器的訪問日誌，看看到容器的IP地址是那個？

[root@docker-node02 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
2134e1b2c689        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   24 minutes ago      Up 24 minutes       80/tcp              nginx.1.ych7y3ugxp6o592pbz5k2i412
[root@docker-node02 ~]# docker logs -f nginx.1.ych7y3ugxp6o592pbz5k2i412 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
10.0.0.3 - - [21/Jun/2020:02:37:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
172.18.0.1 - - [21/Jun/2020:02:38:35 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.0.0.2 - - [21/Jun/2020:02:53:32 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
10.0.0.2 - - [21/Jun/2020:02:53:58 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"
^C
[root@docker-node02 ~]# 

　　提示：我們在管理節點上訪問172.18.0.2在node2節點上看到的日誌是10.0.0.2的ip訪問到nginx服務；這是為什麼呢？其實原因就是在每個節點上都有一個ingress-sbox容器，該容器的地址就10.0.0.2；不同節點上的ingress-sbox的地址都不同，所以我們訪問不同節點地址，在nginx上看到地址也就不同；如下圖所示

　　提示：訪問不同的節點地址，在nginx日誌上記錄的IP各不相同

　　提示：從上面的截圖可以了解到每個節點的ingress-sbox容器的地址各不相同，但他們都把網關指向10.0.0.1，這意味着各個節點容器通信就可以基於這個網關來進行，從而實現了swarm集群上的容器間通信能夠基於ingress網絡進行；現在還有一個問題就是172.18.0.0/18的網絡是怎麼和10.0.0.0/24的網絡通信的？

　　提示：從上面的截圖可以看到，在管理節點上有兩個網絡名稱空間，一個id為0，而id為0的網絡名稱空間中有veth0和vxlan0這兩個網卡；而veth0和vxlan0都是橋接到br0上的，br0的地址就是10.0.0.1/24；vxlan的vlan id為4096；結合上面nginx的日誌，不難想到

我們訪問管理節點上的80，通過iptables規則把流量轉發給docker-gwbridge網絡上；現在我們還不清楚docker-gwbridge網絡上那個名稱空間的網絡，但是我們清楚知道在容器內部有兩張網卡，一張是eth0，一張是eth1,而eth1就是橋接到docker-gwbridge網絡上，這也就意味着容docker-gwbridge網絡的名稱空間和容器內部的eth1網絡名稱空間相同；

　　提示：從上面的截圖看，1-u5mwgfq7rb這個名稱的網絡名稱空間有三張網卡，分別是eth0,eth1和vxlan0，它們都是橋接在br0這個網卡上；而上面管理節點也在1-u5mwgfq7rb這個網絡名稱空間，並且它們中的vxlan0的vlan id都是4096，這意味着管理節點上的vxlan0可以同node2上的vxlan0直接通信（相同網絡名稱空間中的相同VLAN id是可以直接通信的），而vxlan0又是直接橋接到br0這塊網卡，所以我們在nginx日誌中能夠看到ingress-sbox容器的地址在訪問nginx；這其中的原因是ingress-sbox的網關就是br0；其實node3也是相同邏輯，不同節點上的容器間通信都是走vxlan0，與外部通信走eth1—->然後通過SNAT走docker-gwbridge—->物理網卡出去；

　　提示：一個容器上有兩個網絡，一個是eth0 ingress網絡，一個是eth1屬於docker-gwbridge網絡，兩者都屬於同一容器中的網絡名稱空間，所以我們訪問172.18.0.2就會通過ingress-sbox容器把源地址更改為docker-gwbridge上的ingress-sbox的地址，從而我們在看nginx日誌，就會看到10.0.0.2的地址；ingress-sbox容器作用我們可以理解為做SNAT的作用；

　　測試：訪問管理節點的80服務看看是否能夠訪問到nginx提供的頁面呢？

[root@docker-node02 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
b829991d6966        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   About an hour ago   Up About an hour    80/tcp              myweb.1.ilhkslrlnreyo6xx5j2h9isjb
8c2965fbdc27        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.2.pthe8da2n45i06oee4n7h4krd
b019d663e48e        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.3.w26gqpoyysgplm7qwhjbgisiv
a7c1afd76f1f        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.1.ho0d7u3wensl0kah0ioz1lpk5
[root@docker-node02 ~]# docker exec -it myweb.1.ilhkslrlnreyo6xx5j2h9isjb  bash
root@b829991d6966:/# cd /usr/share/nginx/html/
root@b829991d6966:/usr/share/nginx/html# ls
50x.html  index.html
root@b829991d6966:/usr/share/nginx/html# echo "this is docker-node02 index page" >index.html
root@b829991d6966:/usr/share/nginx/html# cat index.html
this is docker-node02 index page
root@b829991d6966:/usr/share/nginx/html# 

　　提示：以上是在docker-node02節點上對運行的nginx容器的主頁進行了修改，接下我們訪問管理節點的80端口，看看是否能夠訪問得到work節點上的容器，它們會有什麼效果？是輪詢？還是一直訪問一個容器？

　　提示：可以看到我們訪問管理節點的80端口，會輪詢的訪問到work節點上的容器；用瀏覽器測試可能存在緩存的問題，我們可以用curl命令測試比較準確；如下

[root@docker-node03 ~]# docker ps
CONTAINER ID        IMAGE                                  COMMAND                  CREATED             STATUS              PORTS               NAMES
f43fdb9ec7fc        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              myweb.3.pgdjutofb5thlk02aj7387oj0
4470785f3d00        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              myweb.2.uwxbe182qzq00qgfc7odcmx87
7493dcac95ba        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.4.rix50fhlmg6m9txw9urk66gvw
118880d300f4        docker-registry.io/test/nginx:latest   "/docker-entrypoint.…"   2 hours ago         Up 2 hours          80/tcp              web.5.vo7c7vjgpf92b0ryelb7eque0
[root@docker-node03 ~]# docker exec -it myweb.2.uwxbe182qzq00qgfc7odcmx87 bash
root@4470785f3d00:/# cd /usr/share/nginx/html/
root@4470785f3d00:/usr/share/nginx/html# echo "this is myweb.2 index page" > index.html 
root@4470785f3d00:/usr/share/nginx/html# cat index.html
this is myweb.2 index page
root@4470785f3d00:/usr/share/nginx/html# exit
exit
[root@docker-node03 ~]# docker exec -it myweb.3.pgdjutofb5thlk02aj7387oj0 bash
root@f43fdb9ec7fc:/# cd /usr/share/nginx/html/
root@f43fdb9ec7fc:/usr/share/nginx/html# echo "this is myweb.3 index page" >index.html 
root@f43fdb9ec7fc:/usr/share/nginx/html# cat index.html
this is myweb.3 index page
root@f43fdb9ec7fc:/usr/share/nginx/html# exit
exit
[root@docker-node03 ~]# 

　　提示：為了訪問方便看得出效果，我們把myweb.2和myweb.3的主頁都更改了內容

[root@docker-node01 ~]# for i in {1..10} ; do curl 192.168.0.41; done
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
this is docker-node02 index page
this is myweb.2 index page
this is myweb.3 index page
[root@docker-node01 ~]# 

　　提示：通過上面的測試，我們在使用–publish-add 暴露服務時，就相當於在管理節點創建了一個load balance；

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

這裏介紹的垃圾回收相關算法，主要解決的問題：

判斷哪些內存是垃圾（需要回收的）？

常用的兩種算法：

• 引用計數
• 可達性分析（GC Root）

首先介紹算法前，得定義：

如何判斷一個對象的死亡？

我們一般這樣定義：當一個對象不再被任何存活的對象繼續引用的時候，這個對象就死亡了。

引用計數

引用計數算法，是給每一個對象添加一個計數器，當有對象引用它的時候，計數器+1，當有對象取消對它的引用時，計數就會-1。

當計數器的值為 0 時，即說明沒有對象引用它，也就是這個對象死亡了。

這種算法很簡單，但是有個重大缺陷，那就是無法解決循環引用的問題。

什麼是循環引用問題呢？

比如對象A 引用 對象B，對象B 引用 對象A，那麼 對象A 和 對象B 的計數器都為1。但是如果後續的運行環境再也用不到對象A 和 對象B，那麼就造成了內存泄漏。

上圖就是循環引用的例子。對象引用 Obj1 和 Obj2 在棧中，然後分別指向在堆中的具體實例。然後兩個相互實例中的成員互相引用。那麼對於堆中的對象而言，就有2個引用。一個是來自Obj1，一個來自堆對象的另一方。

如果，現在將 Obj1 指向 nu l l，那麼就如下圖：

這個時候，引用已經不可用了，但是堆中的對象仍然相互引用，他們的計數器不為0，所以無法死亡。

但是，Java 沒有使用這種算法，而是使用了我們後面說的可達性算法，所以接下來的演示，GC 會將這種情況的內存給其清理。

package GC;

public class ReferenceCountGC {
    public Object instance = null;

    private static final int _1MB = 1024 * 1024;
    // 每個對象中包含2M的成員，方便觀察
    private byte[] bigSize = new byte[2 * _1MB];
    public static void main(String[] args) {
        ReferenceCountGC objA = new ReferenceCountGC();
        ReferenceCountGC objB = new ReferenceCountGC();
        objA.instance = objB.instance;
        objB.instance = objA.instance;

        //取消對對象的引用
        objA = null;
        objB = null;
      // 是否進行垃圾回收
        System.gc();
    }
}

這段代碼實現的就是上面圖片所描述的情況。

首先，我們將 System.gc() 註釋掉，也就是我們在默認情況下，不去觸發垃圾回收。並在運行的時候，添加參數 -XX:+PrintGCDetails。我們觀察輸出結果

可以看到，這個時候，佔用的空間為8M左右。

如果我們取消註釋，也就是主動去調用垃圾回收器，那麼運行結果為：

佔用空間為2M左右。

可以看出來，Java 的垃圾回收，並非採用我們上面介紹的引用計數方式。

可達性分析

可達性算法，還有一系列的別名：根搜索算法，追蹤性垃圾收集，GC Root。

之後，看到原理，其實這些別名都是描述原理的。

首先，我們選取一些對象，這些對象是存活的，也被稱為 GC Roots，然後根據這些對象的引用關係，凡是直接或者間接跟 GC Roots 相關聯的對象，都是存活的。就像圖中的連通性判斷一樣。

這個算法的想法不難。難的是，如何確定 GC Roots。

我們考慮，我們什麼時候需要用到對象？（我們需要對象的時候，肯定需要這個對象是存活的）

• 棧中保存着，我們當前或者之後需要運行的方法及相關參數，所以，棧上所引用的堆中對象肯定是存活的。
• 類中的一些屬性，比如，靜態屬性，因為它不依賴於具體的類
• 一些常用的對象，以免清理后，又要重複加載，比如常用的異常對象，基本數據類型對應的 Class 對象。

除此之外，還有很多零零碎碎的。

在堆結構周圍的一些結構，其中引用的對象可以作為GC Roots

具體 GC Roots 可以概括為：

• 虛擬機棧上（確切的說，是棧幀上的本地變量表）所引用的對象

• 本地方法棧引用的對象

• 方法區中的靜態屬性，常量引用

• Java 虛擬機的內部引用，常用數據類型的 Class 對象，常駐的異常對象，系統類加載器

• 所有被同步鎖持有的對象

除此之外，還有一些臨時的 GC Roots 可以加入進來。這裏涉及到新生代老年代。

比如老年代中的對象一般都存活時間比較久，也就是大概率是活着的對象，也可臨時作為 GC Roots。

可達性算法的一些細節

前面說了可達性算法，我們根據 GC Roots 來進行標記對象的死活。

但是，被判定為不可達的對象，並不立刻死亡。它仍然有次機會進行自救。

這個自救的機會，是需要重寫 finalize（）進行自救。

也就是可達性算法的邏輯大致是這樣的：

• 第一次進行標記，凡是不可達 GC Roots 的對象，都暫時判定為死亡，只是暫時
• 檢查暫時被判定為死亡對象，檢查是否有重寫 finalize（）方法，如果有，則觸發，對象可以在裏面完成自救。

如果沒有自救成功 或者 沒有重寫 finalize（）方法，則宣告這個對象的死亡。

除此之外，這個對象中的 finalize（）方法，只能被調用一次，一生只有一次自救機會。

這個方法，官方並不推薦，所以不必細究。

接下來，演示下上面的兩次標記過程以及自救過程。

（個人認為，《深入理解 Java 虛擬機》中的此章節代碼，略有點不夠完善，故略微改動）

package GC;

import javax.swing.tree.VariableHeightLayoutCache;

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    private byte[] bigSize = new byte[5*1024*1024];

    public void isAlive(){
        System.out.println("Yes, i am alive");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("Finalize method executed");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if(SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
            System.gc();
        }else {
            System.out.println("Dead");
            System.gc();
        }
    }
}

在這個程序中，我們給這個類，添加名為 bigSize 的屬性，其佔用 4M 大小的空間。

大致分析下代碼邏輯：

• 創建了一個對象，其中有成員佔用 4M 的空間
• 取消對這個對象的引用
• 調用垃圾回收（第一次標記）
• 調用 finalize 方法進行自救
• 之後再次調用垃圾回收（第二次標記）

所以演示的時候，分為兩種情況：

• FinalizeEscapeGC.SAVE_HOOK = this; 未註釋，完成自救

運行時，參數仍然設置為 +XX:PrintGCDetails，可以看到輸出結果：

第一次調用垃圾回收，仍然佔用 5M，說明此時即便失去引用，但是仍然未被清理。

在 finalize（）中完成自救后，第二次調用垃圾回收的時候，仍然佔用 5M 的內存大小。說明自救成功。

• FinalizeEscapeGC.SAVE_HOOK = this; 註釋，無法完成自救

第一次垃圾回收，佔用 5M，保留了對象。無法完成自救，然後第二次被清理掉。

所以我發現以下錶述也許更為確切：

• 當對象重寫了 finalize（）方法的時候，第一次垃圾回收的時候，如果為不可達對象，對其進行暫緩，並不清理。
• 當對象沒有重寫 finalize（）方法的時候，且為不可達對象的時候，直接判定死亡。

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案