AWS 推出 Amazon Elastic Container Registry Public (公開版的 ECR)

算是延伸產品線,把 Amazon ECR 變成可以公開使用:「Amazon Elastic Container Registry Public: A New Public Container Registry」。

這篇稍微有趣的地方是,文章裡面的上面這張圖有把 path 模糊化,但下面那張沒有遮,後面的文字也直接有提到 path (這是要給使用者玩的...):

ECR Public 會自動同步到兩個 region,但設定的頁面上好像沒寫會怎麼挑... 另外前面會放 CloudFront 加速。

ECR Public automatically replicates container images across two AWS Regions to reduce download times and improve availability. Therefore, using public images directly from ECR Public may simplify your build process if you were previously creating and managing local copies. ECR Public caches image layers in Amazon CloudFront, to improve pull performance for a global audience, especially for popular images.

費用的部份,意外的有提供一些免費的空間與頻寬可以用,算是在推廣嗎?

Canonical 與 Docker 合作,推出了一系列 LTS Docker Image

CanonicalDocker 合作,推出了一系列 LTS Docker Image:「Canonical publishes LTS Docker Image Portfolio on Docker Hub」。

這邊的 LTS 是十年:

Ten year maintenance commitment on app images provides secure cloud software supply chain

另外有提到這些 LTS Docker Image 將不受 per-user rate limit 限制:

Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.

發佈的 image 可以在 https://hub.docker.com/u/ubuntu 上面翻到,主要就是常見的 server 軟體,算是多一個選擇...

Amazon Lightsail 推出 Container 版本

看到 Amazon Lightsail 推出了 Container 版本的消息:「Announcing Amazon Lightsail Containers, an easy way to run containerized applications on the cloud」,另外在「Lightsail Containers: An Easy Way to Run your Containers in the Cloud」這邊也有介紹。

從官方 blog 上的圖可以看到機器規格與價位,比 Lightsail 貴一些:

另外有提到如果之後要轉到 Amazon ECS 或是 Amazon EKS 的話也都可以直接轉,不過我印象中 ELB 的部份還是要設一下,這點看起來 Lightsail 簡化了不少:

If you plan to later deploy your container to Amazon ECS or Amazon Elastic Kubernetes Service, no changes are required. You can pull the container image from your repository, just like you do with Amazon Lightsail.

不過後面實際上是用什麼架構跑啊?如果考慮到安全性的話應該是直接拿 t3.* 的主機直接 1:1 對應,只是包裝成吃 Docker,而不會共用主機?

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,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...

在 x86-64 上跑 Raspberry Pi 的 OS

看到「dockerpi」這個專案,讓你可以在 x86-64 上模擬 Raspberry Pi 環境跑 Raspbian

然後整包是先透過 Docker 產出一個獨立環境,然後裡面跑 QEMU 模擬 ARM 的環境,接下來再跑 Raspbian:

A full ARM environment is created by using Docker to bootstrap a QEMU virtual machine. The Docker QEMU process virtualises a machine with a single core ARM11 CPU and 256MB RAM, just like the Raspberry Pi. The official Raspbian image is mounted and booted along with a modified QEMU compatible kernel.

這馬上讓人想到 Inception 啊 XDDD

Anyway,這個方法對於想玩玩的人可以省不少功夫,是個有趣的專案就是了...

把 Docker Image 轉成 VM Image

看到「ottomatica/slim」這個專案:

slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM.

This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable unikernels for running services, or build tiny and embedded development environments.

從 screenshot 可以看到會產生 ISO Image:

產生的 ISO Image 可以透過 HyperKit (在 macOS 時) 或是 VirtualBox 跑起來。

實際用途不知道多大,算是一種嘗試?

GitHub 推出 Package Registry

GitHub 推出了「GitHub Package Registry」,可以代管自己開發的軟體。

目前支援 npm (Node.js)、DockerMaven (Java)、NuGet (.NET)、RubyGems (Ruby) 五個平台,

隔壁 GitLab 說我們早就有了而氣噗噗中:「Packaging now standard, dependency proxy next?」。

Anyway,省下一些事情,以前會透過 CI/CD 丟到像是 packagecloud.io 這樣的服務上讓內部使用,現在看起來 GitHub 上面可以解決一些簡單的情境...

用 Dive 看 Docker Image 裡面每一層的內容

看到 wagoodman/dive 這個工具,只要給 Docker 的 image 與 tag 資訊,就可以看每一層裡面的內容:

安裝上也有提供各平台的套件包 (deb、rpm 之類的)。操作的熱鍵在首頁的下方也有提供,用起來很方便。

Travis CI 將轉移到 VM-based 環境

Travis CI 宣佈了將目前 container-based 的環境轉移到 VM-based 的時程:「Upcoming Required Linux Infrastructure Migration」,裡面有提到十月初的時候的文章「Combining The Linux Infrastructures」。

看起來是因為安全性的考慮,container-based 的環境必須在指定 sudo: false 的情境下才能使用。如果需要 root 權限一定會丟到 VM-based 的環境跑。現在看起來 Travis CI 不打算維護 container-based 環境了,所以整個轉移到 VM-based 的環境...

另外一個方向應該是 Google 之前提出來的 gVisor 專案 (參考「Google 推出 gVisor 強化 Container 的安全性」),不過看起來相容性又是個問題...

Travis CI 居然記得要支援 16.04 了...

看到 Travis CI 的「Ubuntu Xenial 16.04 is available!」這篇讓人痛哭流涕啊... 五年的支援期偷已經過了兩年半,總算想起來要推出了 16.04 的 image 了?還是是因為 14.04 剩不到半年?不然好像很有可能繼續撐...

下一次要出 18.04 又是兩年後了嗎...