CNCF 會重蹈 OpenStack 的覆轍嗎？
CNCF(Cloud Native Computing Foundation)，即云原生計算基金會，于 2015 年 7 月成立，隸屬于 Linux 基金會，初衷圍繞“云原生”服務云計算，致力于維護和集成開源技術，支持編排容器化微服務架構應用。
由于最近大佬級別的云提供商的加入,云原生計算基金會(CNCF)很快就站在了開源容器世界的中心。在過去的幾個星期里, CNCF 吸引了微軟和亞馬遜的 Web 服務 (AWS)的加入。他們的加入對于這個本來就隸屬于 Linux 基金會的組織來說，無疑是如虎添翼。
而伴隨著 Kubernetes 的成功，和市場對于容器技術的需求逐漸擴大，CNCF 的聲勢也日漸浩大。微軟和 AWS 相繼加入 CNCF，對于 CNCF、開源和 Kubernetes 來說, 也是一個巨大的勝利。
盡管這些會給 CNCF 帶來規模和潛在的影響，但組織仍然面臨挑戰。
CNCF 執行董事 Dan Kohn 表示：
CNCF 一直非常專注于確保所有成員在迅速擴張的組織中都有各自的代表性。CNCF 的最大優勢是他們足夠新興，所以他們能夠向前人學習，其的愿景是只犯新的錯誤, 而不是照搬過去的錯誤。所以推斷 CNCF 會重蹈 OpenStack 的覆轍，這樣的論斷是錯誤的。
而對 OpenStack 來說，許多運營商早期的時候使用 OpenStack 來實現他們的 SDN 計劃，而現在供應商社區則無法提供所需的解決方案。同時，OpenStack 存在的一些問題還歸咎于它無法處理一些較大成員的不同需求。
而為了規避這樣的問題，CNCF 留出了在供應商之上添加更多產品的余地，讓社區來決定其有用性。這樣他們的生存和死亡由自身的優勢決定，但 OpenStack 社區人為地支撐著將死的平臺。
同時，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
1. 12 Factor app
12 Factor app 中的第三項告訴我們要將配置存儲在環境中。
它還提供了以下內容的示例：
- 資源處理數據庫，Memcached 和其他后臺服務
- 對外部服務的認證，如 Amazon S3 或 Twitter
- 部署的規范主機名
我們想知道如今是否仍然推薦這種方法，并且使用它的風險程度。在這篇文章中，我們將一個簡單的應用程序為例，看看如何修改它以更安全的方式來處理這些敏感的信息。
2. 在 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:
3. 使用環境變量處理 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
這的確是處理這個問題的一個方式，但是，將這些敏感信息以純文本格式化是非常危險的。
4. 處理具有 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
但他們的內容無法被檢索。例如，如果我們檢查與關鍵字 AWSACCESSKEY_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 存在。如果沒有的話，我們仍然使用環境變量。
【本文是51CTO專欄機構“道客船長”的原創文章，轉載請通過微信公眾號(daocloudpublic)聯系原作者】
