OpenVZ 裡的 Docker

前幾天在公司弄 GitLabGitLab CI,前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體,動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變,不過最少丟個 1GB 差不多...

公司用的機器當然是還好,先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體,然後另外一台 t3a.small (2GB) 跑 CI 的 Runner,真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題,畢竟也只有自己一個人用,如果在 Vultr 上面租類似的機器就要 USD$30/month,其他的 KVM VPS 也都差不多價錢。

OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少,但有不少限制。其中一個限制就是沒辦法跑 Docker,這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑,但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker),發現 OpenVZ 7 已經支援 Docker 了,而且在官方文件上面也都已經有說明了:「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下,發現市場上也已經有 OpenVZ 7 的 VPS,而且會宣傳支援 Docker,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...

便宜 VPS 主機的找法...

因為手上 side project 很多,有時候想要長期測一些東西,就需要租用性價比比較好的 VPS。

其中 VPS 的基準點應該是以 LinodeDigitalOcean 以及 Vultr 這幾家為主,而目前這幾家的基準點都是 RAM 的部份,目前是 1GB RAM VPS 約 $5/month。

如果你不想花太多時間在研究,選這幾家應該沒什麼問題,Linode 與 Vultr 都算是很不錯的方案。另外雖然 DigitalOcean 的 CPU 比較差,但可以看出他在非 IaaS 的服務上花了不少力氣,想要朝類似 AWS 的方向在走,如果你想要用到他們的服務,但又不想要用純正的 cloud service 的話 (通常是價位考量),可以考慮看看他們家的服務。

另外一方面,因為我自己喜歡設定底層系統,所以會朝「便宜」的方向找 VPS (能設定的東西比起 Web Hosting 多很多),然後因為機器數量愈來愈多,所以在我自己的 wiki 上整理了「Hosting」這個條目,之後就有些朋友看到價錢就會問怎麼找的... (像是 1.5GB RAM + 20GB Disk 一年只要 USD$14 這種價錢)

我主要是透過 Low End Box - Cheap VPS Hosting Providers Listing & Reviews 這邊找的,這邊常常會有各家 VPS 提供促銷,這時候可以朝幾個方向看:

  • 公司成立時間:透過 whois 資料可以看到一些,另外文章上面通常會直接對 vps 下 tag,可以看看之前是不是有跟 Low End Box 合作過。
  • 以往的評價:透過 tag 找到之前的促銷,然後看看 comment 的評價。先記住這種便宜的 VPS 不會有完美的狀態,如果負評可以接受的話就可以考慮。

另外要注意的是,這類 VPS 我通常都是先假設「資料掉了不會痛」的想法在用,然後主要是以 PayPal 為付款方式,避免主機商跑路後沒辦法拿到退款 (yeah 我遇過 XD)。

這類 VPS 主機有兩種形式:

  • 最常見的是 OpenVZ 類的,通常這類會很便宜,但限制是 RAM 與 Swap 的數量一開始就決定了,也就是你沒有辦法透過 file swap 增加可以用的記憶體。另外因為是 OpenVZ 的關係,上面不能跑 Docker 之類的 container。
  • 另外一種是虛擬機類的,通常會比 OpenVZ 類貴一些,像是 KVM 或是 Xen,這類因為技術上是全虛擬化,通常都可以跑 Docker 這類 container 技術。

接下來就是踩地雷了... XD

AWS 的 Firecracker 技術 (安全的 Container?)

AWS 放出來的 open source 專案 Firecracker,也就是在 AWS 內打造安裝的 container 環境所使用的技術:「Firecracker – Lightweight Virtualization for Serverless Computing」。

依照說明,看起來是利用 crosvm (KVM-based) 但讓他更輕,啟動 image 的時間更快,達到跟 container 類似的效果:

High Performance – You can launch a microVM in as little as 125 ms today (and even faster in 2019), making it ideal for many types of workloads, including those that are transient or short-lived.

Low Overhead – Firecracker consumes about 5 MiB of memory per microVM. You can run thousands of secure VMs with widely varying vCPU and memory configurations on the same instance.

看起來有機會在自己機器上跑看看 (i.e. 非虛擬環境)?跑之前要注意目前只支援 Intel 的硬體:

Firecracker currently supports Intel CPUs, with planned AMD and Arm support. Firecracker will also be integrated with popular container runtimes.

Amazon EC2 各種虛擬化技術的效能

Brendan Gregg 整理了 Amazon EC2 的各種虛擬化技術以及效能的比較:「AWS EC2 Virtualization 2017」,從他做的這張圖可以看到最新的兩個技術 (編號 7 與 8) 的效能相當好:

主要分成三種虛擬化技術:

  • Virtualized in Software: While this can support an unmodified guest OS, many operations are emulated and slow. Apps may run 2x to 10x slower, or worse.
  • Paravirtualization: The hypervisor provides efficient hypercalls, and the guest OS uses drivers and kernel modifications to call these hypercalls. It's using software and coordination between the hypervisor and guest to improve performance. I'd expect measurable overhead of 10% to 50% (depending on the PV type and workload).
  • Virtualized in Hardware: Hardware support for virtualization, and near bare-metal speeds. I'd expect between 0.1% and 1.5% overhead.

用硬體虛擬化的過程... 然後最後也推出 bare metal 的機器 XD

Amazon EC2 的 C5 改跑 KVM

前幾天提到的「Amazon EC2 的 C5 家族...」講到 Amazon EC2 推出 C5 系列帶來的效能與價錢的提昇,後來在 The Register 上看到「AWS adopts home-brewed KVM as new hypervisor」這邊提到更多東西,而且有些還頗有趣的...

首先是 Amazon EC2 FAQs 裡面就有提到的,C5 跑的是 KVM,而不像以前是以 Xen 為底:

Q. What is the underlying hypervisor on C5 instances?
C5 instances use a new EC2 hypervisor that is based on core KVM technology.

另外一點比較有疑慮,是 The Register 提到 IntelAmazon 都發出新聞稿,說明 C5 是使用客製化版本的 Intel 處理器,不過看完後讀不出這個感覺...:「Intel Xeon Scalable Processors Supercharge Amazon Web Services’ Most Powerful Compute-Optimized Instances」、「AWS Announces Availability of C5 Instances for Amazon EC2」。

不過先不管這個... 本來 AWS 都一直圍繞在 Xen 上,這次切去 KVM 是個很值得關注的決策,可以找機會問問看為什麼要這樣換。

Linode 將全面使用 KVM

Linode 宣佈從五月開始全面使用 KVM,新的機器將無法選擇 Xen:「KVM Update」。

原有的 Xen 機器還是會繼續跑,但將會集中起來:

Existing Xen-based Linodes will be fine. However, in the near future we will begin to consolidate Xen Linodes onto fewer physical servers, which will mean scheduled migrations with periods of downtime. Don’t worry – if you will be affected, we’ll provide plenty of advance notice when those migrations are planned.

Linode 的 KVM 的確快不少,我猜也跟硬體升級有關吧,畢竟就其他單位看到的數據應該是沒有這麼高的幅度。

Linode 提供 KVM-based hosting 服務

Linode 前幾天宣佈開始提供 KVM-based hosting:「Linode turns 12! Here’s some KVM!」。

使用 KVM 最大的進展是可以跑 Windows 了:(這對產品面來說很重要)

However, we also now support fully virtualized guests – which means you can run alternative operating systems like FreeBSD, BSD, Plan 9, or even Windows – using emulated hardware (PIIX IDE and e1000).

同時圖形化界面的 console 也會釋出:

We’re also working on a graphical console (GISH?) which should be out in the next few weeks.

而現有 Xen 換到 KVM 也包裝得很簡單:

On a Xen Linode’s dashboard, you will see an “Upgrade to KVM” link on the right sidebar. It’s a one-click migration to upgrade your Linode to KVM from there. Essentially, our KVM upgrade means you get a much faster Linode just by clicking a button.

而且打算逐步淘汰掉 Xen:

New customers and new Linodes will, by default, still get Xen. Xen will cease being the default in the next few weeks. Eventually we will transition all Xen Linodes over to KVM, however this is likely to take quite a while. Don’t sweat it.

不過 Linode 還是沒支援更好的網路環境 (i.e. Private LAN),對於要架大型服務的人來說還是有技術障礙 :o

Ubuntu Core 與 Snappy Transactional Updates

OSNews 上看到「Announcing Ubuntu Core, with snappy transactional updates」,原文出自 Ubuntu 老大 Mark Shuttleworth 的文章「Announcing Ubuntu Core, with snappy transactional updates!」。

依照官方說明:

Ubuntu Core is a minimal server image with the same libraries as today’s Ubuntu, but applications are provided through a simpler mechanism.

希望提供比較穩定的套件環境,並且讓 app 之間不受干擾執行。系統裡分成 release、framework、app 三種角色,release 就是 Ubuntu Core,而 framework 可以是 Docker,最後的 app 就是自己的應用程式,而 snappy 就是管理這三個的軟體。

Snappy Ubuntu Core 是個 readonly image (裡面大多數的地方都不能寫,只有部份目錄以及用 tmpfs 掛起來的部份可以寫入)。

除了可以在雲端平台上面測試外,還可以用 QEMU 掛起來跑,不過實際測試的時候發現 precise (12.04) 的 QEMU 因為是 1.0 版所以不能跑,要 trusty (14.04) 附的版本才夠新 (2.0 版,需要 1.1+)。

找到 trusty 的機器跑的時候因為是遠端的機器,要多加上 -nographic -curses 的參數:

sudo kvm -m 512 -nographic -curses -redir :8090::80 -redir :8022::22 ubuntu-core-alpha-01.img

然後就可以依照官方文件裡提到的方法連進去了:

ssh -p 8022 ubuntu@localhost

然後就可以照著官方的文件操作一次,我自己沒遇到什麼問題。

看起來是 Ubuntu 自己在推動的一套標準,不知道市場接受度如何 :p

做 Ubuntu 14.04.1 的 VMware Template

公司有買 VMware license,但一直沒研究要如何做一份 VM template 出來,所以花了點時間研究到底怎麼做才會比較好。

這邊提供的方法是為了之後的通用性 (像是之後有可能用 KVM 堆虛擬機),所以不使用 VMware 獨規的設計,因此有些設定需要手動調整。

首先是先生出一台 Ubuntu 14.04.1 的 VM,在裝完基本系統後有些要先處理的:

  • 可以考慮用 DHCP 或是不開啟網路設定,反正不要設固定 IP address,以免同時裝多台機器時發生狀況。
  • 因為是 VMware 裡面,安裝 open-vm-tools 可以省下一些 puppet 安裝的時間。
  • 砍掉 /etc/ssh/ssh_host_*,每台機器的 host key 應該要不一樣。

做好 VM 後轉成 Template,之後每次在 deploy 完、開起來後,還要做這些事情:

  • /etc/hostname/etc/hosts 裡的機器名稱。
  • /etc/network/interfaces 裡的網路設定。
  • dpkg-reconfigure openssh-server 重新產生 SSH host key。

有些參考資料:

過程其實還蠻簡單的,只是有一些眉眉角角的東西要注意...