Skip to content

zh

面對規模化敏捷團隊的挑戰

我曾在一個使用了Nexus框架和規模化Scrum的項目上工作。一個Nexus被視為規模化Scrum中的開發單位,形成人與人之間的關聯或聯繫。軟件開發本身就是一個困難的任務,當多個團隊正在開發同一產品,並且有許多相依性時,這項任務變得更加困難。除了要面對各種角色,文物和事件,我在日常工作中遇到了三大挑戰:

  1. 唯一產品擁有者和Nexus衝刺規劃 - 根據Scrum指南,最終的決策權屬於一個單一的產品擁有者。多個團隊在Nexus衝刺規劃後進行自己的衝刺規劃。這使得產品擁有者在每個團隊的規劃中參與,如果他們同時進行,會面臨挑戰。產品擁有者不能在同一時間回答關於領域知識的問題,或為多個團隊做優先決定。如果會議時間不同步,產品擁有者就會浪費很多時間。此外,像Scrum Master,資深架構師或設計師等資源可能需要在不同的團隊之間共享。有些組織甚至設計一組產品擁有者,使決策變得複雜,因為沒有人對規模化產品具有絕對權威。

  2. 將產品待辦事項清單精煉可視化的挑戰 - 可能出現新的依賴性,需要識別並盡量減少。不幸的是,像JIRA和Trello這樣的工具並未提供簡單的方式以視覺化這些依賴性的進度或解決方法。Scrum Master可能無法充分理解複雜的技術含義,因此難以有效管理依賴性。

  3. 通過速度的角度審核Nexus Sprint - 整合工作是不可避免的,可能會影響團隊的速度。由於每個團隊都有自己的估計基準和議程,因此不清楚誰應該對重疊的工作負責。像設定伺服器、自動化測試和解決git代碼合併問題等耗時的整合任務都至關重要,但可能會拖慢團隊的進展。這些任務可能不在故事點數中完全列入,並可能在高級管理層看到速度下降時產生誤解。此外,即使每個團隊根據完成定義完成他們的故事,但在實證世界中的後期整合可能會引入新的問題,需要進行額外的跨團隊討論。

Nexus整合團隊的思維模式是答案 - 管理軟體開發的複雜性和不可預測性的最重要因素是具有正確的思維模式。會議、工具和共享工作只是更基本挑戰的症狀:讓團隊中的每一個人,包括組織領導者,理解並擁抱敏捷性。

你以前是否在規模化Scrum環境中工作過,比如SAFe或LeSS?歡迎你的評論,並期待從你的經驗中學習。

網際網路邊界閘道協定(BGP)

本文章探討網際網路邊界閘道協定(BGP),這是一種標準化的外部閘道協定,設計用於在互聯網上的不同自治系統(ASes)或網際網路服務提供商(ISP)之間交換路由和可達性資訊。以下,我們詳細介紹了與此協定相關的重要性、能力、挑戰和解決方案。

1. 邊界閘道協定及其功能

1989年1月,在第12次網際網路工程任務組(IETF)會議上,Len Bosack、Kirk Lougheed和Yakov Rekhter創造了BGP,其設計目標是開發一種能夠提供政策控制、迴路檢測以及通過地址聚合技術支持數十萬個網路的協定。

BGP作為一種自治系統間的路由協定,便利了ISPs之間的連接。例如,和記黃埔和中國移動交換網路層可達性資訊(NLRI)。在互聯網缺乏集中控制的環境中,這些實體必須交換NLRI以整合他們的自治網路。每一個都控制自己的設備並使用不同的自治系統內部路由協定;他們需要合作來交換與他們的客戶相關的IP地址資訊。

一個使用 BGP 的系統的主要功能已演變為解決這個工程和研究問題:使自治網路之間能交換資訊,而無需集中式控制。發送到服務提供商的數據包需要進行查找才能決定下一個目的地,可能是中國另一邊的完全不同的網絡。BGP是全球 TCP/IP 網路的基本架構。

BGP的另一個重要角色是管理商業問題。例如,中國移動可能不希望和記黃埔發送過量的流量,因為這將增加額外的成本。這些自治網絡內部運行著不同的協定,「最佳路徑」可能會根據合同和政策而有所不同。BGP提供了靈活性,可以定義對不同方來說什麼是最佳路徑。

2. BGP的運作

BGP的當前版本是版本4,於2006年以RFC 4271的形式出版。BGP使用一種路徑向量算法,而不是純粹的距向量或連接狀態算法。它使用存儲在AS_PATH屬性中的路徑資訊來避免傳統路由問題。路由表被遍歷以到達目標網絡,從而提供迴路避免。BGP還支持地址聚合,從而大大減少了核心互聯網路由表的大小。

當一條互聯網路徑失效時,BGP提供了網路穩定性,使路由器能夠快速適應和重新路由數據包。每個BGP路由器都維護一個標準路由表,該表與路由資訊庫(RIB)一起使用,並在變化發生時不斷更新。

BGP只在變化發生時更新路由表資訊。它缺少自動發現機制,這意味著必須手動建立對等連接。該協定使用一種增量更新策略,以節省帶寬和處理能力,依賴TCP來提供可靠的傳輸。

3. 舉例說明ASes如何了解網際網路的可達性

可以假設我們有五個由唯一的32位自治系統號(ASN)標識的ASes,如下所示:

BGP允許這些ASes內的路由器通過內部和外部的BGP說明者來學習多條路徑。它選擇最佳路徑並將其安裝在RIB中。當AS104網絡中的一個客戶希望將數據發送到AS100網絡時,BGP幫助AS104內的路由器決定哪條路徑走,並相應地更新可達性資訊。

BGP還提供了對不同服務提供商之間的信任和不信任的管理,並且在RFC 4271中進行了描述。它允許具有共同路由政策的網絡能夠被唯一的標識,並且被廣泛地用在互聯網的骨幹網絡上。

BGP確定最佳路徑的決策依賴於當前的可達性、跳數和其他路徑屬性。它可以被配置為告知一個組織的路由偏好,並且有一個定義任意標簽(即社區)的機制,以控制經過對等體之間的共同協議的路由廣告行為。

4. BGP包格式和欄位函數

BGP消息通過TCP連接進行傳輸。只有在消息完全接收後才進行處理。消息的最大尺寸為4096字節,而最小允許的消息由一個19字節的頭部組成,而沒有任何數據。以下我們突出了一些欄位的功能:

4.1 消息頭部格式

標記:這是一個16字節的欄位,用於相容性,必須設置為全1。

長度:這是一個2字節的無符號整數,表示消息中包括頭部在內的總長度,以字節為單位。它有助於在TCP流中找到下一條消息的標記欄位。欄位值必須始終大於19並小於4096。消息後面不能填充額外的數據,因此該欄位必須包含最小的必需值。

類型:這是一個1字節的無符號整數,指定消息的類型代碼。類型代碼有:1-Open、2-Update、3-Notification、4-Keepalive。

4.2 Open消息格式

建立TCP連接後,雙方首先發送的消息是Open消息。如果Open消息是可以接受的,則回發送一個確認Open的Keepalive消息。

版本:這是一個1字節的無符號整數,表示消息的協定版本號。

我的自治系統:這是一個2字節的無符號整數,指定發件者的AS號碼。

保持時間:這是一個2字節的無符號整數,表明在秒中的保持計時器的值。在收到一條Open消息後,BGP講話者透過取其配置的保持時間和收到的保持時間中的較小者來計算保持計時器。此時間必須為0 或 至少為3秒。可能會根據此時間值拒絕連接。

BGP標識符:這是一個4字節的無符號整數,標識發件人的BGP標識符。該值在啟動時確定,並在所有本地接口與BGP對等方保持一致。

Opt Param Len:這是一個1字節的無符號整數,顯示可選引數欄位的總長度,以字節為單位。零值表示沒有提供可選引數。

可選參數(變量):此欄位包含一個參數列表,每個參數分別編碼如下:

  • 參數類型:1字節欄位用於識別個別參數。
  • 參數長度:1字節欄位指定參數值欄位的長度,以字節為單位。
  • 參數值(變量):根據參數類型欄位的值來詮釋。

Open消息的最小長度(包括頭部)為29個字節。

4.3 Update消息格式

此格式用於在BGP對等體之間交換路由資訊,有助於構建表示各種自治系統(AS)之間關係的圖。它通過識別並消除路由迴路和其他的自治系統間路由異常。

Update消息可以用來廣告具有共同路徑屬性的可行路徑,或撤銷多條不可行的路徑。它可以在同時廣告一條可行路徑和撤銷多條不可行路徑。

撤銷的路徑長度(2個字節):指示撤銷路徑欄位的總長度;值為0表示沒有路徑被撤銷。

撤銷的路徑(變量):包含被撤銷路徑的IP地址前綴的列表。

長度(1個字節):以位為單位指定IP地址前綴的長度;值為0與所有IP地址的匹配。

前綴(變量):包含一個IP地址前綴,以及為在字節邊界上對齊欄位結尾需要的最少尾隨位數。

總路徑屬性長度(2個字節):指示以字節為單位的路徑屬性欄位的總長度。值為0表示沒有 NLRI 或 path 屬性欄位存在。

路經屬性(可變):由<屬性類型,屬性長度,屬性值>組成的 3 元組。 屬性類型是一個 2 字節的欄位,其中包括:

  • 屬性標誌:各種位用於不同的目的,如選擇位、轉移位、部分位和擴展長度位。
  • 屬性類型代碼:如原始碼、AS_PATH、NEXT_HOP、MULTI_EXIT_DISC、LOCAL_PREF、原子聚合和聚合器指定了不同類型的路徑屬性。

網路層可達性資訊(變量):包含一個 IP 地址前綴的列表。其長度並不直接編碼,但可以使用以下式子計算:

( \text{更新消息長度} - 23 - \text{路徑屬性長度總計} - \text{撤銷路徑長度} )

  • 「更新消息長度」是固定大小的BGP首部中編碼的值。
  • 「路徑屬性長度總計」和「撤銷路徑長度」是更新消息的變動部分。
  • 23是固定大小的BGP頭部、路徑屬性長度和撤銷路徑長度的總和。

達性資訊是以一個或多個2元組編碼,每個都有:

長度(1個字節):以位為單位指出 IP 地址前綴的長度。值為0與所有 IP 地址的匹配,自身前綴包含零個字節。

4. 在BGP中的包格式及突出一些欄位的功能

BGP消息通過TCP連線發送。僅在接收到整個消息後才進行處理。消息的最大尺寸為4096個八位組,而最小合理的消息由19個八位組的標頭組成,不含任何數據。以下,我們突出了某些欄位的功能:

4.1 消息標頭格式
  • 標記:這是一個16個八位組的欄位,為了與過去的協議版本相容,必須設定為全為一。

  • 長度:這是一個2個八位組的無號整數,表示包含標頭在內的消息的總長度,單位為八位組。須以此欄位的值間接找出TCP資料流中下一個消息的標記欄位。欄位值必須永遠大於19且小於4096。禁止在消息後面填充額外的數據,因此這個欄位的值必須只含最小所需的值。

  • 類型:這是一個單個八位組無號整數,指定了消息的類型碼。類型碼為:1-Open、2-Update、3-Notification、4-Keepalive。

4.2 Open消息格式

在建立TCP連線後,每一方首先發送的消息是一條open消息。如果收到的open消息可以被接受,就會回應一條確認接收open消息的keepalive消息。

  • 版本:這是一個單個八位組無號整數,顯示了消息的協議版本號。

  • 我的自治系統:這是一個2個八位組無號整數,表明了發送者的AS編號。

  • 保持時間:這是一個2個八位組無號整數,表示了保持計時器的值建議,單位為秒。在收到open消息時,一個BGP有聲人應當通過取配置的保持時間和已接收到的保持時間中的最小值來計算保持計時器。此時間必

偽Scrum - 瀑布式和敏捷的混合體

我有些事情要告訴你:你並非真正的敏捷。你可能已經完成了所有的 Scrum 儀式,如站立會議、示範和檢討。你甚至可能有所有必要的工具,如JIRA、使用者故事和Scrum看板。然而,如果心態不正確,那麼某些基本的東西仍然缺失。以下是原因:

你有一個詳細的計劃

你正在堅持嚴格的一年期限。Scrum團隊根據在衝刺計劃期間做出的估算來計算速度。那麼,你怎麼能期待Scrum團隊與高層管理的最佳猜測相符呢?當路線圖是固定的,範圍不變,並且發布計劃不切實際時,你實際上正在遵循瀑布模型。

真正的Scrum Master缺席

你的組織圖上可能有一個Scrum Master,但他們的實際角色是什麼?通常,這個人不是全職的Scrum Master,而是一個項目經理、產品擁有者或者資深開發者,他們並未全心投入這個角色。當Scrum Master兼顧多項責任時,事情就開始出軌。即使你有一個專門的Scrum Master,他們可能也無法解決由於技術複雜性或超出他們工作職責的限制所帶來的實際障礙。

沒有指定的產品擁有者

需要有人負責產品,但通常這個人會被其他優先事項所佔據。如果沒有明確的視野和產品所有權,特性開發可能會出錯。當要求由外部高級主管指導時,這一點尤其正確,導致開發努力被浪費。雖然產品擁有者應該做出這些決定,但很少有人願意冒這些風險,許多人對他們實際想要什麼並不確定。

缺乏預算策略

故事點並不能替代預算。當你操縱估算來獲得更多的資金和時間,或者為了符合預算限制而向下談判,你就會對團隊的真實速度失去了視覺。傳統的會計方法也與敏捷開發不兼容。在預算上吝嗇往往會導致團隊燒休息,而不達到預期的結果。

我對敏捷宣言的看法

以下是我用自己的話來解釋敏捷宣言:把對變化的反應性放在遵循高級管理層設定的嚴格路線圖之上。尊重個人和互動超過辦公室政治。強調工作軟體超過無休止,毫無意義的會議。偏愛客戶合作超過預算談判。實現這一點並非易事,但對於官僚機構來說,這是在數位時代適應和繁榮的唯一途徑。

將 Koa.js 應用程式部署至 AWS EC2 Ubuntu 實例

我正在使用 Koa.js 開發一個應用程式,這是一個由 Express 團隊創建的新網頁框架。在這個逐步教學中,我將指導您如何在 Amazon Web Services (AWS) Ubuntu 伺服器上部署 Koa.js 應用程式。

在 AWS 上啟動 Ubuntu 實例

首先,在 AWS 上啟動一個 Ubuntu 實例。您需要修改安全組設定。

Security Group Settings

如果您沒有進行這些更改,試圖在瀏覽器中訪問公共域將導致“連接”狀態,直到超時,導致無法訪問網站。

Site Unreachable

默認情況下,啟動嚮導僅啟用 SSH。

SSH Only

點擊“編輯”按鈕以添加適用於 HTTP 端口 80 和 HTTPS 端口 443 的入站規則。

Edit Inbound Rules

安裝 Node.js

通過 SSH 登入您的實例並根據官方文檔安裝 Node.js:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

設置 Nginx 作為反向代理伺服器

接下來,安裝 Nginx:

sudo apt-get update
sudo apt-get install nginx

打開配置文件並進行以下編輯。別忘了分號:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/yourApp;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

保存文件並重新啟動 Nginx 服務:

sudo systemctl restart nginx

部署您的應用程式

將您的 Git 存儲庫克隆到 /var/www/yourApp 目錄。您可能會遇到“Permission Denied”錯誤,所以更改文件夾的所有權:

sudo chown -R ubuntu /var/www

創建一個簡單的 app.js 來運行您的伺服器:

var koa = require("koa")
var app = koa()

// logger
app.use(function* (next) {
  var start = new Date()
  yield next
  var ms = new Date() - start
  console.log("%s %s - %s", this.method, this.url, ms)
})

// response
app.use(function* () {
  this.body = "Hello World"
})

app.listen(3000)

啟動伺服器:

node app.js

打開您的瀏覽器並導航到您的公共域。您應該看到您的 Koa.js 應用程式正在運行。

App Running

完成!如果您有任何問題,請隨時在下面留言。:)

從物聯網項目中吸取的教訓

去年,我參與了一個專注於藍牙智能裝置的物聯網(IoT)項目。這個經驗與純軟體開發在幾個方面有顯著的不同:

首先,集成帶來了挑戰,因為項目的機械設計、固件、手機應用程式和設計組件被分包給多個供應商。這些供應商有地理上分散的團隊和不同的工作文化。當開發人員在他們的領域專門化到組織成獨立的群體時,Scrum模型不太可能有效運行。

其次,硬體迭代的時長遠超過軟體迭代,使其難以適應變化。與軟體不同,軟體可以輕易被模塊化,許多硬體組件如晶片和主機板卻是相互關聯。這種情況推動了開發過程向著更像瀑布模型的方向。你只能收到整個原型或者一無所有;沒有傳遞一個用於消費者測試的最小可行產品(MVP)的中間地帶。早期用戶反饋的缺乏進一步阻礙了特性優先級的確定過程。

第三,當事情出錯時,診斷問題尤其具有挑戰性。很難確定問題是出在機械設計、固件還是手機應用程式的開發。此外,隨著介面的演變,端到端的測試變得更加複雜。在沒有全面的硬體自動化的情況下進行測試也很耗時。為了緩解這一點,有必要明確並可驗證的接受準則,確保“完成”的嚴格定義。

對任何IT項目的成功而言,有效的溝通至關重要,特別是當各個方面沒有按計劃進展時。指責和防衛可以嚴重損害部門之間的關係。有效的溝通需要同理心;嘗試從他人的角度理解問題,而不是情緒化或判斷式地反應。

客戶根據他們從產品中獲得的價值來評估性能。採取同理心和解決問題的思維方式可以減少浪費的時間和精力,從而提高整體性能。我期待著產品的發佈和最終用戶的積極反饋。

如何修復 iOS 10 權限崩潰錯誤

我一直在開發一款需要訪問用戶麥克風的應用程序。

該應用在 iOS 9 上運行正常,但在升級到 iOS 10 之後,它開始崩潰。終端顯示的錯誤消息如下:

> 此應用程序已崩潰,因為它試圖訪問隱私敏感數據而未提供使用說明。應用程序的 Info.plist 必須包含一個 NSMicrophoneUsageDescription 鍵,並提供一個字符串值解釋應用程序如何使用這些數據。
> (lldb)

要解決此問題,按源碼編輯 Info.plist 文件並添加以下行:

    <key>NSMicrophoneUsageDescription</key>
    <string>提供一個說明,解釋您的應用為何需要訪問麥克風。</string>

此外,如果您的應用需要訪問用戶的相機,請添加以下內容:

    <key>NSCameraUsageDescription</key>
    <string>提供一個說明,解釋您的應用為何需要訪問相機。</string>

如果您的應用需要訪問用戶的聯繫人,請添加以下內容:

    <key>NSContactsUsageDescription</key>
    <string>此應用需要訪問您的聯繫人。</string>

祝你編碼愉快!

香港金融科技的未來

我經常被我的老師告知,香港是一個國際金融中心。確實,在我們競爭激烈的企業環境中,我們每天都享受著經濟的成功。然而,香港目前在金融科技的革命中落後了。新加坡已經抓住了這個機會,並積極地前進。新加坡政府在吸引金融科技公司方面起著至關重要的作用,他們提供了激勵措施和明確的規章制度。此外,中國內地金融科技公司可用的廣大客戶基礎使得他們能夠以香港公司無法實現的方式蓬勃發展。

挑戰十分明顯:香港過於保守的心態正在減緩金融科技行業的進步。作為一名 IT 顧問,我聽到許多銀行業的人對像區塊鏈、比特幣和移動支付等創新科技表示擔憂。他們擔心這些技術可能會破壞他們的業務,威脅工作,並導致大公司無法適應。

然而,這裡有一線希望:香港擁有大量的創新和創造力的個體。我們的社區擁有多樣化的思考者,建設者,和領導者。我們有可能組建優秀的團隊來啟發並為創造世界上最好的金融科技生態系統做出貢獻。現在是提高我們的意識,重新想象當金融科技作為正向產業轉型的助推器時,可能會發生什麼。

依我看,這是我們期望的結果:我們正引導全球的金融科技變得更以人為本。我們目前的法律沙盒政策允許公司在市場上測試他們的創新想法。這些金融科技有可能對全球人民的生活產生積極的影響。讓我們一起利用金融科技的語言和工具,將香港重新建立為金融科技商業的區域中心。

什麼是區塊鏈,以及它如何被使用?

很多朋友都在問我關於區塊鏈革命的出現。根據最近的新聞,世界四大銀行已經聯手開發一種新形式的數位現金。這種數位現金旨在成為清算和結算金融交易的區塊鏈技術的行業標準。同時,Ripple已經在B輪融資中籌得5500萬美元。在我看來,無疑區塊鏈有潛力顛覆傳統銀行。

何謂區塊鏈?

區塊鏈是一種數據結構,用作交易的數字記錄簿。這個記錄簿在數以百萬計的分散式網絡的電腦之間共享。利用最先進的密碼學,該技術安全地管理記錄簿。區塊鏈依賴共識模型運作:每個節點都同意每一筆交易,從而消除了傳統結算過程中需要中央交易對手(CCP)的需要。

如何使用?

區塊鏈通過使其更高效,對跨貨幣支付有廣泛的影響。它消除了時間延遲並降低了後勤成本。為了回應客戶對更快、更低成本的全球支付的日益增長的需求,區塊鏈允許直接的銀行對銀行的結算。這種技術的一些應用包括零售客戶的匯款服務,國際交易,企業支付和跨國銀行間的貨幣轉帳。

何種創新?

這項技術提供了交易可以在不需要知道對方是誰的情況下進行的機會。其最創新的特點是分散化數據庫的理念,其中信任是通過大規模協作建立的,而不是通過一個負責認證和結算的中心化機構建立的。

可解決哪些問題?

區塊鏈的潛在應用擴展到了金融市場之外。這種技術可能提供一個對於多種用途可以信賴的不可變更的記錄。當前的身份識別基礎設施很容易被破壞;然而,在區塊鏈中,一旦數據塊被記錄,修改起來就變得非常困難。因此,它可以用於真正的隱私保護。每當有人試圖向區塊鏈添加數據時,所有現有的副本都運行算法來驗證交易。試圖欺詐系統的惡意嘗試被拒絕,而預期的交易在大多數節點通過鏈交易歷史驗證其有效性時獲得批准。因此,區塊鏈可以作為基於web的身份驗證的開放協議的基礎,創建一個'信任網絡',並以加密格式儲存數據。

參考文獻
  1. Martin Arnold, "Big banks plan to coin new digital currency," Financial Times, August 24, 2016, Financial Times Article
  2. Alyssa Jarrett, "Ripple Raises $55 Million in Series B Funding," Ripple official website, September 15, 2016, Ripple Article
  3. Don Tapscott, Alex, and Rik Kirkland, "How Blockchains Could Change the World," McKinsey & Co, May 8, 2016, ValueWalk Article

在 macOS 上安裝 Jupyter Notebook

我正在使用 Anaconda 發行版安裝 Jupyter Notebook。

步驟 1:下載 Anaconda

首先,訪問 Anaconda 網站以下載安裝程式:https://www.anaconda.com/products/distribution

步驟 2:安裝 Anaconda

運行下載的安裝程式並按照圖形提示進行 Anaconda 的安裝。

步驟 3:嘗試運行 Jupyter Notebook

安裝完成後,嘗試執行 Jupyter Notebook:

jupyter notebook

你可能會遇到以下錯誤:

> zsh: command not found: jupyter

這是因為 conda 命令也找不到:

> zsh: command not found: conda

步驟 4:更新 Shell 配置

為了解決此問題,使用你偏好的文本編輯器打開你的 .zshrc 文件:

vim ~/.zshrc

在文件底部添加以下行:

export PATH="$HOME/anaconda3/bin:$PATH"

步驟 5:重新啓動 Shell 並運行 Jupyter Notebook

保存文件並重新啓動你的 shell。嘗試再次運行 Jupyter Notebook。現在應該可以在 http://localhost:8888/ 上訪問。

在AWS EC2上啟動RancherOS

RancherOS是一種為運行Docker容器而設計的Linux發行版。雖然AWS Marketplace已經有可用的AMI(Amazon Machine Image),但設置安全組和其他配置可能會有些棘手。這份指南就是缺少的使用手冊。

1. 使用Rancher AMI啟動一個實例

假設你已經有一個 .pem密鑰,啟動一個實例並選擇Rancher AMI。

2. 連接到您的實例

打開終端並連接到您的實例。請注意,您應該使用rancher作為用戶,而不是root:

ssh -i "XXX.pem" rancher@ec2-XX-XXX-XX-XX.ap-southeast-1.compute.amazonaws.com
3. 驗證Rancher服務器

Rancher服務器應該已經在運行。你可以通過執行以下命令進行檢查:

docker ps

如果它沒有運行,可以使用Docker下載並啟動服務器:

docker run -d -p 8080:8080 rancher/server
4. 配置安全組

在AWS控制台中,轉到Security Group選項卡並創建一個包含入站規則的新組:

規則應包括:

  • 端口22、2376和8080/tcp 供Docker機器分配主機
  • 端口500和4500/udp 供Rancher網絡使用
  • 端口9345和9346/tcp 用於UI界面
  • 端口80/tcp 用於您部署的站點
5. 分配新的安全組

選擇實例,然後導航到Actions > Networking > Change Security Group。檢查新的安全組ID並將其分配給您的實例。

6. 訪問Rancher UI

打開一個瀏覽器並轉到公共DNS的8080端口,如 http://ec2-XX-XXX-XX-XX.ap-southeast-1.compute.amazonaws.com:8080

您應該會看到Rancher UI:

7. 使用AWS憑證添加主機

要使用Amazon EC2添加一個主機,您需要Access Key和Secret Key。如果您沒有它們,請前往AWS Console > IAM (Identity and Access Management) > Create New Users。下載credentials.csv文件。

接下來,前往Groups選項卡 > Group Actions > Add Users to Group。通過搜索"AmazonEC2FullAccess"來附加策略,選中方框,並應用更改。

8. 在Rancher UI中輸入AWS憑證

返回到Rancher UI,並從credentials.csv文件中輸入新生成的Access Key和Secret Key。

最後,填寫所需的信息,您將看到您的主機正在運行。

附言

要管理Docker的秘密API鑰匙、證書文件和生產配置,您可以根據您的具體需求嘗試使用beta版的Vault集成。