AWS 推出 CloudShell

AWS 推出了 CloudShell,讓使用者可以繼承 IAM 的權限,在瀏覽器裡面用 command line 操作 AWS 資源:「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單,在 web console 上方的 icon 點下去就可以用了,只是第一次使用的時候會看到需要建立環境的訊息,會等比較久:

連進去後測了一下,看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來,/dev/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器,以這個資訊來查,看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通,但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些,之後應該會陸陸續續再開放:

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份,官方是說不需要另外的費用,只需要付出用到的 AWS 資源,但這邊沒給範例啊,到底是怎麼算的... 看了一圈 EC2ECSEKS 都沒有機器,應該是不會算到這邊?

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是,對於已經習慣跳板機的人來說好像還好,尤其是 command line 已經用熟了,太習慣用 Ctrl-W 刪字串,而在瀏覽器裡面按下去就會直接出事的情況,還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限,所以在 awscli 下的權限是一樣的,另外對於有些 web console 沒支援的操作可以用這個方法補強,而不需要自己弄機器出來跑。

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

Sony 放出 PS5 拆解影片...

Hacker News Daily 上看到 PS5 的拆解影片:「PS5 Teardown: An up-close and personal look at the console hardware」。

本來想說這種東西為什麼會上 Hacker News Daily,是有拆出什麼有趣的東西嗎... 後來看到一半才注意到這是 Sony 官方丟出來的影片,不是第三方拆機開箱影片 XDDD

然後回頭看發現這是 Sony 家的 VP 出來拍的:

基本上是個官方拆機指南,雖然影片開頭有警告自行拆機會有風險以及保固問題 XD

讓 Python 輸出變豐富的 Rich

Hacker News 上看到的 Python 專案,讓 terminal 輸出變得更好看:「Rich is a Python library for rich text and beautiful formatting in the terminal.」。

看到當下吸引我的地方在於表格:

from rich.console import Console
from rich.table import Column, Table

console = Console()

table = Table(show_header=True, header_style="bold magenta")
table.add_column("Date", style="dim", width=12)
table.add_column("Title")
table.add_column("Production Budget", justify="right")
table.add_column("Box Office", justify="right")
table.add_row(
    "Dev 20, 2019", "Star Wars: The Rise of Skywalker", "$275,000,000", "$375,126,118"
)
table.add_row(
    "May 25, 2018",
    "[red]Solo[/red]: A Star Wars Story",
    "$275,000,000",
    "$393,151,347",
)
table.add_row(
    "Dec 15, 2017",
    "Star Wars Ep. VIII: The Last Jedi",
    "$262,000,000",
    "[bold]$1,332,539,889[/bold]",
)

console.print(table)

輸出長這樣:

另外還有不少功能也不錯,會讓畫面豐富不少。

寫了一個可以用 '/' 在 AWS 上快速切換服務的小工具

AWS Management Console 上切換服務需要用到滑鼠,而這個 Userscript 工具提供了 / 快速鍵可以直接拉出服務選單,另外也可以用 Esc 鍵關閉服務選單:「AWS Web Console Service Shortkeys」。

這個套件應該是支援多個瀏覽器,但是需要先安裝 Tampermonkey 這類可以跑 Userscript 的套件。

主要是常常在切的時候發現需要拿滑鼠,寫了這個 script 後多了一個方式可以用,而不需要把手移開鍵盤,會順手一些...

不過還是希望這個功能直接變成內建的 :o

各種對 AWS Managemenet Console 的抱怨...

Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文,差不多是兩個月前開始累積的:「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主,而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發,然後呼叫 API),而且的確是常常中 bug,所以會有這樣的抱怨其實不太意外...

然後就有人放火了:

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了:

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念),而 AWS Managemenet Console 當作是輔助,因為目前的雲端服務在設計上的確是希望你多用 API...

Chrome 72+ (目前在 Beta 的版本) 對延伸套件的影響

我的桌機平常都是跑 beta channel 的 Chrome,所以前陣子已經升級到 72,然後發現兩個問題:

從 dev console 可以看到問題都是 Referer 沒被送出,導致有檢查 Referer 的網站拒絕存取,後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則,裡面提到了:

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

Accept-Language
Accept-Encoding
Referer
Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

不確定這個設計的目的是什麼,但反正已經中獎了,總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一?)。

所以就先去 Tampermonkey 開 ticket,也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版):「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。

另外跟 Referer Control 的開發者回報這個問題,也修正出新版上架了,更新就生效了:「refererControlDisqus.html」。

目前看起來還有「Spoofs Lang」得修,不過這個軟體好久沒更新了,不知道有沒有機會...

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機,不想弄在日本 (latency),所以就想到 Google Cloud Platform (GCP) 在台灣有機房,而 Compute Enginef1-micro,類似 AWSEC2 提供的 t2.nano 的機器。而這兩天玩了玩,大概有些事情值得記錄起來。

CPU 相關的部份:

  • EC2 的 t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少,GCE 沒找到在哪邊可以看。
  • EC2 的 t2 系列在 CPU credit 用完後是變慢運行,除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選,相當於一定要開 T2 Unlimited。
  • GCE 的 f1-micro 是 0.2 vCPU,但我在上面跑 Ubuntu 18.04,平常沒事就已經是 15% 左右。這數字比預期的高不少,還在找是什麼原因...

網路相關的部份:

  • 因為要用台灣的機房,網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有),也就是會先走 Google 佈建的網路再出去,所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
  • 但 Premium 等級實測品質真的很不一樣,到香港居然在 15ms 以下,以前在固網機房內沒看過這個數字...

其他的部份:

  • 硬碟空間方面,Standard provisioned space 比 EBSgp2 便宜不少,而且還包括了 i/o 費用 (AWS 會另外收費)
  • 連續使用就會有 discount 了,也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了:「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫:

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉:

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...