Amazon EKS 與 AWS Fargate

在今年的 AWS re:Invent 2017 上宣佈 Amazon ECS 也支援 Kubernetes,也就是 Amazon EKS:「Amazon Elastic Container Service for Kubernetes」,一個用的人夠多就支援的概念...

目前這個服務還在 Preview,所以要申請才能用:

Amazon EKS is available in Preview. We look forward to hearing your feedback.

另外一個在 AWS re:Invent 2017 上宣佈的是 AWS Fargate,讓你連 Amazon ECS 或是 Amazon EKS 都不用管的服務,直接按照 container 的大小收費:「Introducing AWS Fargate – Run Containers without Managing Infrastructure」、「AWS Fargate: A Product Overview」。

第一個有疑慮的點是,是否會跟其他人共用相同的 host,也就是 isolation 的程度。這點在 AWS 的人在 Hacker News 上的這邊有回覆,在不同的 cluster 上不會使用同樣的底層:

NathanKP 4 days ago [-]
Fargate isolation is at the cluster level. Apps running in the same cluster may share the underlying infrastructure, apps running in different clusters won't.

另外也提到每個 cluster 都是使用者自己產生的:

NathanKP 3 days ago [-]
A customer creates a cluster on their account. You as a customer can create one or more Fargate clusters on your account to launch your containers in.

不是很正面的回覆,而且不是在官方的 forum 回的,安全性就要大家自己判斷了...

另外也有有提到與 Amazon EC2 相比,價錢當然會比較貴,但可以預期會降低 engineer 的時間成本:

NathanKP 4 days ago [-]
AWS employee here. Just want to say that we actually had a typo in the per second pricing on launch. The actual pricing is:
$0.0506 per CPU per hour
$0.0127 per GB of memory per hour
Fargate is definitely more expensive than running and operating an EC2 instance yourself, but for many companies the amount that is saved by needing to spend less engineer time on devops will make it worth it right now, and as we iterate I expect this balance to continue to tip. AWS has dropped prices more than 60 times since we started out.

目前只能接 Amazon ECS,預定 2018 可以接 Amazon EKS:

I will tell you that we plan to support launching containers on Fargate using Amazon EKS in 2018.

而目前這個版本 (可以接 Amazon ECS 的版本) 在 us-east-1 已經開放了:

Fargate is available today in the US East (Northern Virginia) region.

AWS 推出 Cloud Native Networking,在每個 Container 內都有自己獨立的網路卡

AWSAmazon ECS 變得更好用了:「Introducing Cloud Native Networking for Amazon ECS Containers」。

Today, AWS announced task networking for Amazon ECS. This feature brings Amazon EC2 networking capabilities to tasks using elastic network interfaces.

awsvpc 模式下會給每個 container 一個獨立的網路卡 (Elastic Network Interface,ENI):

這樣有兩個好處。第一個是 port 就不需要拆開,所有 container 如果都是跑 nginx,都可以跑在同一個 port (80 或是 443),這對於前端應用程式會簡單一些。第二個整合了 AWS 的 security group,這對在 AWS 上本來就會使用 security group 的大多數人來說就可以輕鬆整合了。

Google 推出比較兩個 Docker Image 的 container-diff

Google 放出來的工具,可以比較兩個 Docker Image 的內容:「Introducing container-diff, a tool for quickly comparing container images」,GitHub 的連結在「GoogleCloudPlatform/container-diff」這邊。

不是單純的 binary diff,而是分析裡面的內容。像是安裝套件的差異,或是 pipnpm 的差異:

主要是開發者會用到,可以觀察不同 container 之間的差異。

AWS Batch 在東京區可以用了

AWS Batch 支援東京區了:「AWS Batch is Now Available in Tokyo」。

總算是在東京出現了... 在 FAQ 裡面有提到:

AWS Batch uses Amazon ECS to execute containerized jobs and therefore requires the ECS Agent to be installed on compute resources within your AWS Batch Compute Environments. The ECS Agent is pre-installed in Managed Compute Environments.

開起來測一些東西看看...

對於是否要用 Container (Docker) 的檢查表

這篇積的有點久,但很不錯的一篇文章 (以條列出來的東西來看):「Instead of containerization, give me strong config & deployment primitives」。

作者遇到了現在很多團隊「因為潮/因為好像可以解決問題,而想要用 Docker」,在沒有想清楚的情況跳下去用,發現沒解決本來的問題,反而製造了一堆問題。

如果你已經在用 AWS,那麼 Docker 相較於 AWS 大致上只有一個優點,也就是開啟速度很快 (因為是 container 的特性)。Docker 的另外幾個優點在 AWS 上是不存在的,包括了 immutable 以及隔離性。

在 AWS 上使用 Docker 反而有不少麻煩,像是要處理 AutoScaling + Service Discovery 時整合的問題,以及 storage 問題。這些都需要另外花力氣處理。

另外一個常聽到的是「讓開發環境與線上環境一致」的議題常常是假議題,對於有照 The Twelve-Factor App 避免寫出有 bad smell code 的程式,開發環境用 Docker,正式環境用標準的 EC2 其實不會有太大問題。

PS:雖然我覺得 The Twelve-Factor App 裡面有些想法有點走火入魔,但對於大多數情況,裡面寫的其實不錯。

Docker 的權限控制

Red Hat Enterprise Linux Blog 上整理了一篇關於 Docker 目前支援的權限控制:「Secure Your Containers with this One Weird Trick」,目前有 38 個權限可以控制:

Originally the kernel allocated a 32-bit bitmask to define these capabilities. A few years ago it was expanded to 64. There are currently around 38 capabilities defined.

這對於跑一些應用來說還頗不錯的,像是之前提到的「用 Docker 跑 Skype 講電話」,可以再縮限一些權限 :o

用 Docker 跑 Skype 講電話

Update:中文的部份是有問題的。之前以為是跑 Docker 版本時,實際上跑到很久前裝的 skype... 移除後發現 voice 沒問題,但沒有中文字型...

因為 Skype 裡面不知道跑了什麼東西,所以想要用 Docker 包起來放在 container 裡面跑,但之前測起來不穩定,而且中文字型的問題一直沒解決,所以就先一直丟著。

而剛剛測了一下 sameersbn/docker-skype 這邊的版本,發現之前遇到沒辦法看中文的問題也解決了。

安裝的方法非常簡單,先拉下來,然後執行他:

$ docker pull sameersbn/skype:latest
$ docker run -it --rm --volume /usr/local/bin:/target sameersbn/skype:latest install

這樣就會產生 /usr/local/bin/skype,直接跑他就好了,登入後再拿自家電話撥號,測了一下沒什麼問題。另外中文輸入法也是吃 host 的,所以也很順,弄得頗不錯的...

試玩 LXD

LXDCanonical (Ubuntu 的那家公司) 推的 container 系統,在「Super Fast Local Workloads With LXD, ZFS, and Juju」這篇文章裡雖然是提 ZFS + Juju 這兩個東西,但 LXD 的部份還是給了些可以直接拿來用的資訊。

首先先安裝 LXD,我是裝 ppa:ubuntu-lxc/stable 這個版本,裝完 lxd 後就照著先執行:

$ newgrp lxd
$ lxd init

由於沒有裝 zfs,就用 dir 模式跑就好了。網路的部份就先選 no 混過去,反正 NAT 會通... 接著就拉 image 回來:

$ lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty

拉完後就可以跑起來了:

$ lxc launch ubuntu-trust test
$ lxc exec test /bin/bash

直接打 lxc 也可以看到一些說明,用過 Docker 的人應該是沒什麼問題,還蠻簡單的。

超小的 Docker Image

Hacker News Daily 上看到「Super small Docker image based on Alpine Linux」這個專案,看了一下是 BusyBox 類的專案,不過套件支援度比起其他 BusyBox 專案多不少。

基於 Alpine Linux 的系統:

Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.

musl libc 與 BusyBox:

Alpine Linux is built around musl libc and busybox. This makes it smaller and more resource efficient than traditional GNU/Linux distributions. A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository.

可以拿來玩看看,不過一般狀態下應該還是會拿 UbuntuDebian 的系統來用吧,環境標準多了。(不需要自己花時間找問題)