CNCF 會(huì)重蹈 OpenStack 的覆轍嗎？
CNCF(Cloud Native Computing Foundation)，即云原生計(jì)算基金會(huì)，于 2015 年 7 月成立，隸屬于 Linux 基金會(huì)，初衷圍繞“云原生”服務(wù)云計(jì)算，致力于維護(hù)和集成開源技術(shù)，支持編排容器化微服務(wù)架構(gòu)應(yīng)用。
由于最近大佬級(jí)別的云提供商的加入,云原生計(jì)算基金會(huì)(CNCF)很快就站在了開源容器世界的中心。在過(guò)去的幾個(gè)星期里, CNCF 吸引了微軟和亞馬遜的 Web 服務(wù) (AWS)的加入。他們的加入對(duì)于這個(gè)本來(lái)就隸屬于 Linux 基金會(huì)的組織來(lái)說(shuō)，無(wú)疑是如虎添翼。
而伴隨著 Kubernetes 的成功，和市場(chǎng)對(duì)于容器技術(shù)的需求逐漸擴(kuò)大，CNCF 的聲勢(shì)也日漸浩大。微軟和 AWS 相繼加入 CNCF，對(duì)于 CNCF、開源和 Kubernetes 來(lái)說(shuō), 也是一個(gè)巨大的勝利。
盡管這些會(huì)給 CNCF 帶來(lái)規(guī)模和潛在的影響，但組織仍然面臨挑戰(zhàn)。
CNCF 執(zhí)行董事 Dan Kohn 表示：
CNCF 一直非常專注于確保所有成員在迅速擴(kuò)張的組織中都有各自的代表性。CNCF 的最大優(yōu)勢(shì)是他們足夠新興，所以他們能夠向前人學(xué)習(xí)，其的愿景是只犯新的錯(cuò)誤, 而不是照搬過(guò)去的錯(cuò)誤。所以推斷 CNCF 會(huì)重蹈 OpenStack 的覆轍，這樣的論斷是錯(cuò)誤的。
而對(duì) OpenStack 來(lái)說(shuō)，許多運(yùn)營(yíng)商早期的時(shí)候使用 OpenStack 來(lái)實(shí)現(xiàn)他們的 SDN 計(jì)劃，而現(xiàn)在供應(yīng)商社區(qū)則無(wú)法提供所需的解決方案。同時(shí)，OpenStack 存在的一些問(wèn)題還歸咎于它無(wú)法處理一些較大成員的不同需求。
而為了規(guī)避這樣的問(wèn)題，CNCF 留出了在供應(yīng)商之上添加更多產(chǎn)品的余地，讓社區(qū)來(lái)決定其有用性。這樣他們的生存和死亡由自身的優(yōu)勢(shì)決定，但 OpenStack 社區(qū)人為地支撐著將死的平臺(tái)。
同時(shí)，Dan Kohn 也承認(rèn) Kubernetes 一直處于爆炸性增長(zhǎng)的狀態(tài)。如果能管理這一增長(zhǎng)，則能實(shí)現(xiàn)組織目前最大的成就。
Kubernetes 1.7.4 版本發(fā)布
8 月 17 日， Kubernetes 1.7.4 版本發(fā)布，相比 1.7.3 版本共有 17 處明顯變化，例如：
- 修復(fù)創(chuàng)建或更新 ELB 會(huì)修改全局定義的 Security Group Bug
- 修復(fù) kubefed 在不同版本 RBAC 創(chuàng)建問(wèn)題
- 修復(fù) API Server Watch Cache 中一個(gè) Bug
- Azure：允許 VNet 在一個(gè)單獨(dú)的資源組中
- Cluster Autoscaler -修復(fù)了與 taints 相關(guān)的問(wèn)題，并更新了 kube – proxy cpu請(qǐng)求
- 以 Stackdriver 模式收集來(lái)自 Heapster 的 Metrics
- GCE：Bump GLBC 版本更新到 0.9.6
- 更新 Heapster 版本 1.4.1
Docker Tips：將容器的文件重定向到您的 Docker 主機(jī)
每隔一段時(shí)間，我都需要將容器的文件轉(zhuǎn)存到我的 Docker 主機(jī)上。在這里向大家提供一種簡(jiǎn)單的方法。
有時(shí)為了調(diào)試，您可能想將容器內(nèi)部的配置文件的內(nèi)容復(fù)制到 Docker 主機(jī)，以便您在自己喜歡的代碼編輯器中打開它，或?qū)⑵浒l(fā)送給別人。這對(duì)于已經(jīng)運(yùn)行的 Docker 容器來(lái)說(shuō)非常方便，并且您不希望用 volume 重新啟動(dòng)它，因?yàn)槟阆胍⒖叹瞳@取這個(gè)文件。
完成以下兩點(diǎn)你就可以達(dá)成目的：
- # 重寫那個(gè)鏡像的 Dockerfile 的 CMD, 來(lái)cat到你想要的文件
- docker run --rm alpine cat /etc/hosts
以上步驟將打印出容器的 /etc/hosts 文件的內(nèi)容
- # 修改命令將該輸出重定向到 Docker 主機(jī)上的新文件。
- docker run --rm alpine cat /etc/hosts > /tmp/alpinehosts
你可以運(yùn)行命令ls -la /tmp | grep alpinehosts來(lái)進(jìn)行驗(yàn)證。
當(dāng)然，如果您在 Docker 主機(jī)上運(yùn)行 Windows 而不是 MacOS 或 Linux，則你的命令需要進(jìn)行一些小的調(diào)整。例如，在 Windows 上不起作用。如果您使用 PowerShell 等，您將需要 Google 一下如何將輸出重定向到文件。
另外，在這兩種情況下，您都需要將Cat指令安裝在 Docker 鏡像中，但所有主要的 Linux 版本都已經(jīng)默認(rèn)安裝了(包括 Alpine)。
從環(huán)境變量到 Docker secrets
1. 12 Factor app
12 Factor app 中的第三項(xiàng)告訴我們要將配置存儲(chǔ)在環(huán)境中。
它還提供了以下內(nèi)容的示例：
- 資源處理數(shù)據(jù)庫(kù)，Memcached 和其他后臺(tái)服務(wù)
- 對(duì)外部服務(wù)的認(rèn)證，如 Amazon S3 或 Twitter
- 部署的規(guī)范主機(jī)名
我們想知道如今是否仍然推薦這種方法，并且使用它的風(fēng)險(xiǎn)程度。在這篇文章中，我們將一個(gè)簡(jiǎn)單的應(yīng)用程序?yàn)槔?，看看如何修改它以更安全的方式?lái)處理這些敏感的信息。
2. 在 Docker 世界運(yùn)行的應(yīng)用
在過(guò)去的幾年中，我們看到了許多應(yīng)用在開發(fā)和部署方面都產(chǎn)生了變化。這主要是因?yàn)镈ocker 平臺(tái)的流行。應(yīng)用程序現(xiàn)在主要采用微服務(wù)體系結(jié)構(gòu)：它們由多個(gè)隔離式服務(wù)組成。使用 Docker Compose 文件格式定義微服務(wù)應(yīng)用程序現(xiàn)在非常普遍。此格式定義了服務(wù)及其使用的組件(網(wǎng)絡(luò)，卷，...)。以下是用于定義由以下組成的 Web 應(yīng)用程序的 Docker Compose 文件(其默認(rèn)名稱為 docker-compose.yml)的簡(jiǎn)單示例：
- 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. 使用環(huán)境變量處理 AWS 憑據(jù)
當(dāng)我們深入了解 api 服務(wù)，假設(shè)這需要 AWS S3 的一些憑據(jù)。api 服務(wù)是在 Node.js 中編寫的。使用 aws-sdk npm 模塊連接到 Amazon API 的代碼類似于以下內(nèi)容。
- // 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();
- }
- }
以上代碼中所需的配置模塊在一些其他配置內(nèi)容中定義了 AWS 憑據(jù)。我們?cè)谶@里看到，每個(gè)元素從一個(gè)環(huán)境變量獲取它的值。
- // 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
- }
- };
然后，當(dāng)通過(guò) Docker Compose 運(yùn)行應(yīng)用程序時(shí)，我們通過(guò)環(huán)境鍵指定這些環(huán)境變量。
- 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
這的確是處理這個(gè)問(wèn)題的一個(gè)方式，但是，將這些敏感信息以純文本格式化是非常危險(xiǎn)的。
4. 處理具有 Docker secrets 的 AWS 憑據(jù)
有幾種方式可以以安全的方式處理這些信息。使用 Docker secrets 就是其中之一。
我們不再在環(huán)境變量中以純文本定義憑據(jù)信息，而是從中創(chuàng)建 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 創(chuàng)建成功。使用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
但他們的內(nèi)容無(wú)法被檢索。例如，如果我們檢查與關(guān)鍵字 AWSACCESSKEY_ID 相關(guān)聯(lián)的 secret，我們只會(huì)獲取元數(shù)據(jù)，而不是其實(shí)際內(nèi)容。
- $ 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": {}
- }
- }
- ]
創(chuàng)建了 secret 以后，我們就可以在 Docker Compose 文件中引用它們。
- secrets:
- AWS_BUCKET_NAME:
- external: true
- AWS_ACCESS_KEY_ID:
- external: true
- AWS_SECRET_ACCESS_KEY:
- external: true
在 Docker Compose 文件中，我們還需要修改 api 服務(wù)的描述，以便使用這些 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
當(dāng)一個(gè)服務(wù)需要訪問(wèn)一個(gè) secret 時(shí)，默認(rèn)情況下，它被安裝在該服務(wù)的每個(gè)容器中的臨時(shí)文件系統(tǒng)中。
由于我們的應(yīng)用程序僅在此階段檢查環(huán)境變量，因此需要進(jìn)行更新。
這可以用一個(gè)簡(jiǎn)單的模塊來(lái)實(shí)現(xiàn)，只需要從`/run/secrets`中讀取一個(gè) secret。這在以下代碼中說(shuō)明。
- // 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 函數(shù)：
- ...
- "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
- }
對(duì)于每個(gè) key，我們首先檢查它是否作為 secret 存在。如果沒(méi)有的話，我們?nèi)匀皇褂铆h(huán)境變量。
【本文是51CTO專欄機(jī)構(gòu)“道客船長(zhǎng)”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)(daocloudpublic)聯(lián)系原作者】
