Home » Posts tagged "docker"

Amazon DynamoDB 提供 Docker Image 讓開發者可以在本地端測試

AWS 推出了 Amazon DynamoDB 的相容 Docker Image,讓開發者可以在本地端測試 DynamoDB 的 API:「Use Amazon DynamoDB Local More Easily with the New Docker Image」,在 amazon/dynamodb-local 這邊可以拉到,裡面其實是包 Java:

DynamoDB local is now available to download as a self-contained Docker image or a .jar file that can run on Microsoft Windows, Linux, macOS, and other platforms that support Java.

這樣在 Continuous Integration (CI) 的過程裡面也可以拉起 service 測試...

Google 推出 gVisor 強化 Container 的安全性

Google 發表了 gVisor,針對 Linux 所使用的 container 技術強化安全的部份:「Open-sourcing gVisor, a sandboxed container runtime」。

依照 Google 的說法,一般 container 的架構是這樣:

而具有強隔離性的 VM 技術則是這樣:

在 VM 的 overhead 偏重,但一般的 container 安全性又不夠。而 gVisor 則是這樣:

對於目前最常見的 Docker 系統上,在安裝 gVisor 後只需要指定 --runtime=runsc 就可以使用 (預設是 --runtime=runc),像是這樣:

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

其中 runsc 的意思是「run Sandboxed Container」。

另外而因為 gVisor 卡在中間,不認識的 syscall 都會被擋下來,所以目前並不是所有的應用程式都可以跑,但開發團隊已經測了不少應用程式可以在上面運作,算是堪用的程度:

gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.

值得一提的是,雖然是處理 syscall,但是是用 Go 開發的,而不是 C 或是 C++,這點頗特殊的...

透過 Docker 跑 Command Line 程式時,螢幕大小改變時程式不會變更的問題...

其實是我拿 DockerrTorrent 遇到的問題... (在 gslin/rtorrent-docker 這包裡面)

因為平常都是用 tmux 掛著,有時候是使用桌機接起來,有時候是使用 Mac 接起來,就會遇到 resize 的問題了 :o

GitHub 上其實有討論這個問題:「SIGWINCH attached processes · Issue #5736 · moby/moby」(Docker 改名叫 Moby 了,如果你看到網址不是很確定的話,提醒一下... XD)。

在 resize 的機制上是透過 SIGWINCH 這個 signal 傳進去,所以就一層一層檢查... 然後發現是 su 不會把 SIGWINCH 傳下去,改用 sudo 就解決了,這樣就不用每次切換時還要重跑 rTorrent...

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.

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

Amazon ECS 可以跑 cron job 了...

Amazon ECS 上面固定時間跑某些東西,以前得自己用 AWS Lambda 帶 (或是自己架,不過這樣就要自己考慮 High Availability 架構了),現在則是直接支援:「Amazon ECS Now Supports Time and Event-Based Task Scheduling」。

Previously, you could start and stop Amazon ECS tasks manually, but running tasks on a schedule required writing and integrating an external scheduler with the Amazon ECS API.

Now you can schedule tasks through the Amazon ECS console on fixed time intervals (e.g.: number of minutes, hours, or days). Additionally, you can now set Amazon ECS as a CloudWatch Events target, allowing you to launch tasks by using CloudWatch Events.

對於是否要用 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 裡面有些想法有點走火入魔,但對於大多數情況,裡面寫的其實不錯。

Archives