靜態網頁服務的選擇

Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇,除了文章連結外,留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務,或是透過 Netlify,需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後,其他人把真正有用的工具整理了出來...

Elasticsearch 提供免費版本的安全功能

Elasticsearch 決定將基本的安全功能從付費功能轉為免費釋出,很明顯的是受到 Open Distro for Elasticsearch 的壓力而做出的改變:「Security for Elasticsearch is now free」。

要注意的是這不是 open source 版本,只是將這些功能放到 basic tier 裡讓使用者免費使用:

Previously, these core security features required a paid Gold subscription. Now they are free as a part of the Basic tier. Note that our advanced security features — from single sign-on and Active Directory/LDAP authentication to field- and document-level security — remain paid features.

這代表 Open Distro for Elasticsearch 提供的還是比較多:

With Open Distro for Elasticsearch, you can leverage your existing authentication infrastructure such as LDAP/Active Directory, SAML, Kerberos, JSON web tokens, TLS certificates, and Proxy authentication/SSO for user authentication. An internal user repository with support for basic HTTP authentication is also avaliable for easy setup and evaluation.

Granular, role-based access control enables you to control the actions a user can perform on your Elasticsearch cluster. Roles control cluster operations, access to indices, and even the fields and documents users can access. Open Distro for Elasticsearch also supports multi-tenant environments, allowing multiple teams to share the same cluster while only being able to access their team's data and dashboards.

目前看起來還是可以朝 Open Distro for Elasticsearch 靠過去...

用 Google Docs 惡搞的方式...

看到「UDS : Unlimited Drive Storage」這個專案,利用 Google Docs 存放資料。主要的原因是因為 Google Docs 不計入 Google Drive 所使用的空間:

Google Docs take up 0 bytes of quota in your Google Drive

用這個方法可以存放不少大檔案 (像是各種 ISO image),讓人想起當年 Love Machine 的玩法 (不知道的人可以參考「愛的機器 Love machine」這篇),切割檔案後傳到某些空間以提供下載?只是這邊是用 base64 放到 Google Docs 上...

base64 的資料會比原始資料大 33%,而 Google Docs 單篇的上限大約是 710KB:

Size of the encoded file is always larger than the original. Base64 encodes binary data to a ratio of about 4:3.

A single google doc can store about a million characters. This is around 710KB of base64 encoded data.

方法不是太新鮮,但是讓人頗懷念的... XD

改 Open Distro for Elasticsearch 預設密碼的方式

AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」),應該是目前新架設 Elasticsearch 的首選。

不過裝好後預設有五個帳號,但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (adminkibanaserver),要修改密碼發現得花不少功夫,不知道為什麼要這樣設計 :/

這邊講的是透過 RPM (以及 deb) 的方式的修改方式,如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章:「Change your Admin Passwords in Open Distro for Elasticsearch」。

首先先透過 hash.sh 產生 bcrypt 的 hash,像是這樣 (輸入 password 當密碼):

bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
WARNING: JAVA_HOME not set, will use /usr/bin/java
[Password:]
$2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG

然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值,順便改掉 readonly 的部分。

接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西,所以偷懶用 root 跑:

sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem

做完後可能要重跑 Elasticsearch 與 Kibana:

sudo service elasticsearch restart
sudo service kibana restart

或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後,就是用新的帳號密碼連到 Kibana。

上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。

官方的說明文件則是在寫這篇文章時才找到的,平常搜尋時不太會出現:「Apply configuration changes」。

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫,經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」,裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30,被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style:

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊,但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來?

Amazon S3 要拿掉 Path-style 存取方式

Hacker News 上翻的時候翻到的公告:「Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020」。

現有的兩種方法,一種是把 bucket name 放在 path (V1),另外一種是把 bucket name 放在 hostname (V2):

Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key).

這次要淘汰的是 V1 的方式,預定在 2020 年十月停止服務 (服務到九月底):

Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.

DynamoDB 也有固定的 IP address 區段了

AWS 宣佈 DynamoDB 也有固定的 IP address 區段了:「AWS specifies the IP address ranges for Amazon DynamoDB endpoints」,對於使用 IP firewall 的人可以多一些控制權。

資料可以在 https://ip-ranges.amazonaws.com/ip-ranges.json 這邊抓到,裡面 serviceDYNAMODB 的就是了。

因為沒看到 IPv6 的位置,才發現 DynamoDB 目前沒有提供 IPv6 Endpoint...

AWS 推出使用 AMD CPU 的 t3a.*

AWS 推出了 t3a.* 的 EC2 instance:「Now Available – AMD EPYC-Powered Amazon EC2 T3a Instances」。

目前開放的區域有限,但算是個開始:

You can launch T3a instances today in seven sizes in the US East (N. Virginia), US West (Oregon), Europe (Ireland), US East (Ohio), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance form.

價錢大約再低個 10% 左右:

Pricing is 10% lower than the equivalent existing T3 instances; see the On-Demand, Spot, and Reserved Instance pricing pages for more info.

有些超小的機器可以考慮重開的時候就順便換過去...

AWS 香港區開放

Twitter 上看到 AWS 公開了香港區的消息:「Announcing the AWS Asia Pacific (Hong Kong) Region」,他們總算是想起來有這區了:

有三個 AZ:

The AWS Asia Pacific (Hong Kong) Region consists of three Availability Zones and with this launch, the AWS Global Infrastructure now offers 64 Availability Zones worldwide, serving customers in over 190 countries.

不過在 Region Table 裡面還沒出現,雖然上面已經標「Last updated: April 24, 2019」了... 從「AWS Regions and Endpoints」可以看到區域代碼是 ap-east-1,然後可以看到 S3 的部分是這樣寫:

You must enable this Region before you can use it.

加上之前的一些傳言,可以猜測一些事情?

Anyway,本來是說 2018 年的時候要開 (參考 2017 年的「AWS 香港區 2018 開台」這篇),總算在 2019 年開了...

CloudFront 開始提供中國大陸的服務

Amazon CloudFront 開始提供中國大陸上的節點:「Amazon CloudFront is now Available in Mainland China」。看起來是綁在 AWS China 上面,而且需要 ICP 才能使用:

To start using CloudFront in China, customers must setup a CloudFront distribution using the AWS Management Console or API in China and also obtain a valid ICP (Internet Content Provider) recordal.

不過第一波提供的節點不多,只有北京、上海與寧夏:

Amazon CloudFront announces the launch of CloudFront in China with three new Edge locations (POPs) located in Beijing, Shanghai, and Zhongwei, operated by Ningxia Western Cloud Data Co. Ltd. (NWCD).

後續不知道還有機會展到哪些地區...