Home » Posts tagged "docker"

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

把 rTorrent 跑到 Docker 裡

花了些時間研究如何把 rTorrent 丟進 Docker 裡跑,對應的設定都放在 GitHub 上的「gslin/rtorrent-docker」這邊。

使用的方式是傳入使用者的 uid 與 gid (-e USER_GID-e USER_UID),以及預期的 port (有兩個地方,一個是 -e PORT,另外一個是 -p 開 port forwarding,不然外面沒辦法直接連進來),然後把 TERM 變數丟進確保 console 的操作。剩下來把對應的目錄掛進 container 讓他可以寫入 (-v 的部份):

docker run \
    -e PORT=6991 -e TERM=${TERM} \
    -e USER_GID=`id -g` -e USER_UID=`id -u` \
    -i -p 6991:6991 -t -v "`pwd`:/srv/rtorrent" \
    gslin/rtorrent:latest

自己用這樣應該是夠用了... 把這串命令放到 shell 的 alias 裡面用就好了。

Archives