CNCF 會重蹈 OpenStack 的覆轍嗎？｜航海日誌 Vol.25

時間  2019-11-17
標籤 cncf 重蹈 openstack 覆轍 航海 日誌 vol.25 vol 简体版
原文   原文鏈接


➤ CNCF 會重蹈 OpenStack 的覆轍嗎？


CNCF（Cloud Native Computing Foundation），即雲原生計算基金會，於 2015 年 7 月成立，隸屬於 Linux 基金會，初衷圍繞「雲原生」服務雲計算，致力於維護和集成開源技術，支持編排容器化微服務架構應用。html


因爲最近大佬級別的雲提供商的加入,雲原生計算基金會（CNCF）很快就站在了開源容器世界的中心。在過去的幾個星期裏, CNCF 吸引了微軟和亞馬遜的 Web 服務 （AWS）的加入。他們的加入對於這個原本就隸屬於 Linux 基金會的組織來講，無疑是如虎添翼。web

而伴隨着 Kubernetes 的成功，和市場對於容器技術的需求逐漸擴大，CNCF 的聲勢也日漸浩大。微軟和 AWS 相繼加入 CNCF，對於 CNCF、開源和 Kubernetes 來講, 也是一個巨大的勝利。docker


儘管這些會給 CNCF 帶來規模和潛在的影響，但組織仍然面臨挑戰。數據庫


CNCF 執行董事 Dan Kohn 表示：npm


CNCF 一直很是專一於確保全部成員在迅速擴張的組織中都有各自的表明性。CNCF 的最大優點是他們足夠新興，因此他們可以向前人學習，其的願景是隻犯新的錯誤, 而不是照搬過去的錯誤。因此推斷 CNCF 會重蹈 OpenStack 的覆轍，這樣的論斷是錯誤的。api


而對 OpenStack 來講，許多運營商早期的時候使用 OpenStack 來實現他們的 SDN 計劃，而如今供應商社區則沒法提供所需的解決方案。同時，OpenStack 存在的一些問題還歸咎於它沒法處理一些較大成員的不一樣需求。安全


而爲了規避這樣的問題，CNCF 留出了在供應商之上添加更多產品的餘地，讓社區來決定其有用性。這樣他們的生存和死亡由自身的優點決定，但 OpenStack 社區人爲地支撐着將死的平臺。bash


同時，Dan Kohn 也認可 Kubernetes 一直處於爆炸性增加的狀態。若是能管理這一增加，則能實現組織目前最大的成就。網絡

➤ Kubernetes 1.7.4 版本發佈


8 月 17 日， Kubernetes 1.7.4 版本發佈，相比 1.7.3 版本共有 17 處明顯變化，例如：架構


  • 修復建立或更新 ELB 會修改全局定義的 Security Group Bug

  • 修復 kubefed 在不一樣版本 RBAC 建立問題

  • 修復 API Server Watch Cache 中一個 Bug

  • Azure：容許 VNet 在一個單獨的資源組中

  • Cluster Autoscaler -修復了與 taints 相關的問題，並更新了 kube – proxy cpu請求

  • 以 Stackdriver 模式收集來自 Heapster 的 Metrics

  • GCE：Bump GLBC 版本更新到 0.9.6

  • 更新 Heapster 版本 1.4.1


➤ Docker Tips：將容器的文件重定向到您的 Docker 主機


每隔一段時間，我都須要將容器的文件轉存到個人 Docker 主機上。在這裏向你們提供一種簡單的方法。

有時爲了調試，您可能想將容器內部的配置文件的內容複製到 Docker 主機，以便您在本身喜歡的代碼編輯器中打開它，或將其發送給別人。這對於已經運行的 Docker 容器來講很是方便，而且您不但願用 volume 從新啓動它，由於你想要馬上就獲取這個文件。

完成如下兩點你就能夠達成目的:

# 重寫那個鏡像的 Dockerfile 的 CMD, 來cat到你想要的文件
docker run --rm alpine cat /etc/hosts複製代碼

以上步驟將打印出容器的 /etc/hosts 文件的內容

# 修改命令將該輸出重定向到 Docker 主機上的新文件。
docker run --rm alpine cat /etc/hosts > /tmp/alpinehosts複製代碼

你能夠運行命令ls -la /tmp | grep alpinehosts來進行驗證。

固然，若是您在 Docker 主機上運行 Windows 而不是 MacOS 或 Linux，則你的命令須要進行一些小的調整。例如，在 Windows 上不起做用。若是您使用 PowerShell 等，您將須要 Google 一下如何將輸出重定向到文件。

另外，在這兩種狀況下，您都須要將Cat指令安裝在 Docker 鏡像中，但全部主要的 Linux 版本都已經默認安裝了(包括 Alpine)。


➤ 從環境變量到 Docker secrets

12 Factor app

12 Factor app 中的第三項告訴咱們要將配置存儲在環境中。

它還提供瞭如下內容的示例：

  • 資源處理數據庫，Memcached 和其餘後臺服務

  • 對外部服務的認證，如 Amazon S3 或 Twitter

  • 部署的規範主機名

咱們想知道現在是否仍然推薦這種方法，而且使用它的風險程度。在這篇文章中，咱們將一個簡單的應用程序爲例，看看如何修改它以更安全的方式來處理這些敏感的信息。

在 Docker 世界運行的應用

在過去的幾年中，咱們看到了許多應用在開發和部署方面都產生了變化。這主要是由於Docker 平臺的流行。應用程序如今主要採用微服務體系結構：它們由多個隔離式服務組成。使用 Docker Compose 文件格式定義微服務應用程序如今很是廣泛。此格式定義了服務及其使用的組件（網絡，卷，...）。如下是用於定義由如下組成的 Web 應用程序的 Docker Compose 文件（其默認名稱爲 docker-compose.yml）的簡單示例：

version: "3.3"
services:
  db:
    image: mongo:3.4
    network:
      - backend
    volumes:
      — mongo-data:/data/db
    deploy:
      restart_policy:
        condition: on-failure
  api:
    image: lucj/api:1.0
    networks:
      - backend    
    deploy:
      restart_policy:
        condition: on-failure
  web:
    image: lucj/web:1.0
    networks:
      - frontend
      - backend    
    deploy:
      restart_policy:
        condition: on-failure    
volumes:
  mongo-data:
networks:
  frontend:  
  backend:複製代碼

使用環境變量處理 AWS 憑據

當咱們深刻了解 api 服務，假設這須要 AWS S3 的一些憑據。api 服務是在 Node.js 中編寫的。使用 aws-sdk npm 模塊鏈接到 Amazon API 的代碼相似於如下內容。

// Middleware handling user's profile images const AWS = require('aws-sdk'), config = require(‘../config’), aws_config = config.amazon; // Configure AWS SDK AWS.config.update(aws_config.credentials); // Define S3 bucket var s3Bucket = new AWS.S3( { params: {Bucket: aws_config.bucket} } ) ... // Upload image object s3Bucket.putObject(obj, function(err){ if (err) { log.error(err); return next(err); } else { return next(); } }複製代碼

以上代碼中所需的配置模塊在一些其餘配置內容中定義了 AWS 憑據。咱們在這裏看到，每一個元素從一個環境變量獲取它的值。

// config.js
module.exports = {
...
  "amazon":{
    "credentials": {
      "accessKeyID": process.env.AWS_ACCESS_KEY_ID,
      "secretAccessKey": process.env.AWS_SECRET_ACCESS_KEY,
    },
    "bucketName": process.env.AWS_BUCKET_NAME
  }
};複製代碼

而後，當經過 Docker Compose 運行應用程序時，咱們經過環境鍵指定這些環境變量。

api:
 image: lucj/api:1.0
networks:
      - backend    
    deploy:
      restart_policy:
        condition: on-failure
 environment:
   — AWS_BUCKET_NAME=BucketName
   — AWS_ACCESS_KEY_ID=AccessKeyID
   — AWS_SECRET_ACCESS_KEY=SecretAccessKey複製代碼

這的確是處理這個問題的一個方式，可是，將這些敏感信息以純文本格式化是很是危險的。

處理具備 Docker secrets 的 AWS 憑據

有幾種方式能夠以安全的方式處理這些信息。使用 Docker secrets 就是其中之一。

咱們再也不在環境變量中以純文本定義憑據信息，而是從中建立 docker secrets。

$ echo "BucketName"| docker secret create AWS_BUCKET_NAME -
vjp5zh8hwb9dqkvohtyvtifl1
$ echo "AccessKeyID" | docker secret create AWS_ACCESS_KEY_ID -
5txxg3fslf9g5z1o4i19vvmcr
$echo "SecretAccessKey"|docker secret create AWS_SECRET_ACCESS_KEY -
v8g65iwcx1eb6uuwsjzknyi7g複製代碼

secrets 建立成功。使用docker secret ls。

$ docker secret ls
ID NAME CREATED UPDATED
5x..vm AWS_ACCESS_KEY_ID About a minute ago About a minute ago
v8..7g AWS_SECRET_ACCESS_KEY About a minute ago About a minute ago
vj..l1 AWS_BUCKET_NAME About a minute ago About a minute ago複製代碼

但他們的內容沒法被檢索。例如，若是咱們檢查與關鍵字 AWS

ACCESS
KEY_ID 相關聯的 secret，咱們只會獲取元數據，而不是其實際內容。 

$ docker secret inspect 5txxg3fslf9g5z1o4i19vvmcr
[
  {
    "ID": "5txxg3fslf9g5z1o4i19vvmcr",
    "Version": {
      "Index": 12
    },
    "CreatedAt": "2017–08–13T12:58:50.54021338Z",
    "UpdatedAt": "2017–08–13T12:58:50.54021338Z",
    "Spec": {
      "Name": "AWS_ACCESS_KEY_ID",
      "Labels": {}
    }
  }
]複製代碼

建立了 secret 之後，咱們就能夠在 Docker Compose 文件中引用它們。

secrets:
  AWS_BUCKET_NAME:
    external: true
  AWS_ACCESS_KEY_ID:
    external: true
  AWS_SECRET_ACCESS_KEY:
    external: true 
 
複製代碼

在 Docker Compose 文件中，咱們還須要修改 api 服務的描述，以便使用這些 secrets。

api:
 image: lucj/api:2.0
 secrets:
   — AWS_BUCKET_NAME
   — AWS_ACCESS_KEY_ID
   — AWS_SECRET_ACCESS_KEY
 networks:
   — backend
 deploy:
   restart_policy:
     condition: on-failure複製代碼

當一個服務須要訪問一個 secret 時，默認狀況下，它被安裝在該服務的每一個容器中的臨時文件系統中。


因爲咱們的應用程序僅在此階段檢查環境變量，所以須要進行更新。


這能夠用一個簡單的模塊來實現，只須要從`/run/secrets`中讀取一個 secret。這在如下代碼中說明。

// secrets.js
const fs = require("fs"),
      util = require("util");
module.exports = {
  // Get a secret from its name
  get(secret){
    try{
      // Swarm secret are accessible within tmpfs /run/secrets dir
      return fs.readFileSync(util.format(「/run/secrets/%s」, secret), "utf8").trim();
     }
     catch(e){
       return false;
     }
  }
};複製代碼

而後，咱們能夠修改配置文件，以便它使用 secrets.js 模塊的 get 函數：

...
"amazon":{
  "credentials": {
    "accessKeyId": secrets.get(「AWS_ACCESS_KEY_ID」) || process.env.AWS_ACCESS_KEY_ID,
    "secretAccessKey": secrets.get(「AWS_SECRET_ACCESS_KEY」) || process.env.AWS_SECRET_ACCESS_KEY,
  },
 "bucket": secrets.get("AWS_BUCKET_NAME") || process.env.AWS_BUCKET_NAME
 }複製代碼

對於每一個 key，咱們首先檢查它是否做爲 secret 存在。若是沒有的話，咱們仍然使用環境變量。

這一期的『航海日誌』就到這裏，下期再浪～


參考連接


做者介紹

莫非 Beck：DaoCloud 微服務攻城獅，吃飽了就困的一流段子手。

劉璽元 Boring：DaoCloud 市場部門（僞）程序猿。


Discussion | 你對今天的哪條新聞最感興趣？

  • 你對今天的哪條新聞最感興趣？你有什麼獨到的看法？

  • 本週你還有什麼更具爆炸性的容器圈新聞嗎？歡迎在留言區爆料！


▼ 點這兒，回顧一下船長的過去

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程