Home » Posts tagged "user" (Page 2)

CodeDeploy 的權限設定...

這陣子在弄 AWS CodeDeploy,調整了半天才把權限壓低到合理的範圍 (AWS 給的預設值還是有點大),記錄下來之後會比較好找...

在權限部份,AWS CodeDeploy 應該有三個權限要設定:

  • IAM user:給 CI 跑完後丟上 Amazon S3 並且呼叫 AWS CodeDeploy 佈署用的,像是 Travis CI 或是之類的服務。但如果是手動到 web console 觸發的話,這個部份就不需要了。
  • Service Role:給 AWS CodeDeploy 的服務本身用的。
  • EC2 Role:給跑在機器上 AWS CodeDeploy Agent 用的。

如同前面講的,IAM user 的部份有兩個要處理,一個是讓 CI 服務把檔案傳上 Amazon S3,另外一個是讓他有權限可以呼叫 AWS CodeDeploy 佈署新版本。

後者比較簡單,直接拉 AWSCodeDeployDeployerAccess 就可以了,前者比較麻煩一點,需要透過 Policy Generator 建出對應的權限:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1486156178000",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::codedeploy-testbucket/*"
            ]
        }
    ]
}

第二個的 Service Role 是最簡單的,直接拉 AWSCodeDeployRole 就可以了。

第三個的 EC2 Role 只需要給存取 Amazon S3 的權限。照 AWS 的建議用 AmazonEC2RoleforAWSCodeDeploy 是會動啦,但權限給太大了,整個帳號可以存取的 S3 bucket 他都可以拉到:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListObjects"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

改成自己用 Policy Generator 生,限制在 codedeploy-testbucket 上會比較好:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1486165995000",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::codedeploy-testbucket/*"
            ]
        }
    ]
}

這樣權限的部份就差不多了...

Jenkins 的 Blue Ocean 計畫,改善使用者操作的友善度...

JenkinsBlue Ocean 計畫打算改善讓人頭痛很久的操作體驗了:

Blue Ocean is a new project that rethinks the user experience of Jenkins.

Jenkins 讓人頭痛有兩個面向,一個是界面很難讀,另外一個是操作流程很沒有規則,所謂「熟悉 Jenkins」其中一個很艱難的任務就是要背下一堆功能「蔵在哪邊」。而這次 Blue Ocean 想改善的事情看起來主力放在界面,對於流程修的比較少... 即使如此,這還是可以讓使用的人減少一些痛苦就是了...

成功與爆炸的表現:

在專案頁面的後面有提到 Blue Ocean 用的技術:

Blue Ocean is built as a collection of Jenkins plugins itself. There is one key difference, however. It provides both its own endpoint for http requests and delivers up html/javascript via a different path, without the existing Jenkins UI markup/scripts. React.js and ES6 are used to deliver the javascript components of Blue Ocean. Inspired by this excellent open source project (react-plugins) an <ExtensionPoint>pattern was established, that allows extensions to come from any Jenkins plugin (only with Javascript) and should they fail to load, have failures isolated.

又是個不需要用 SPA 呈現的東西跑去用 React 了...

Netflix 對 sendfile() 在 TLS 情況下的加速

Netflix 對於寫了一篇關於隱私保護的技術細節:「Protecting Netflix Viewing Privacy at Scale」。

其中講到 2012 年的 Netflix Open Connect 中的 Open Connect Appliance (OCA,放伺服器到 ISP 機房的計畫) 只有單台伺服器 8Gbps,到現在 2016 可以達到 90Gbps:

As we mentioned in a recent company blog post, since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016.

早期的 Netflix 走 sendfile() 將影片丟出去,這在 kernel space 處理,所以很有效率:

當影片本身改走 HTTPS (TLS) 時,其中一個遇到的效能問題是導致 sendfile() 無法使用,而必須在 userland space 加密後改走回傳統的 write() 架構,這對於效能影響很大:

所以他們就讓 kernel 支援 AES 系列加密 (包括 AES-GCM 與 AES-CBC),效能的提昇大約是 30%:

Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version.

文章開頭也有提到選 AES-GCM 與 AES-CBC 的一些來龍去脈,主要是 AES-GCM 的安全強度比較好,另外考慮到舊的 client 不支援 AES-GCM 時會使用 AES-CBC:

We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-CGM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method.

另外 OCA 機器本身也都夠新,支援 AES-NI 指令集,效能上不是太大的問題:

All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L).

不過在「Netflix Open Connect Appliance Deployment Guide」(26 July 2016 版) 這份文件裡看起來還是用多條 10Gbps 透過 LACP 接上去:

You must be able to provision 2-4 x 10 Gbps ethernet ports in a LACP LAG per OCA. The exact quantity depends on the OCA type.

可能是下一版準備要上 40Gbps 或 100Gbps 的準備...?

Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西:

維基百科的 User Agent 公開資料

Nuzzel 上看到的東西...

維基百科不掛 Google Analytics 之類的第三方服務,而是透過 Piwik 蒐集後自己分析:「Dashboards and Data Downloads for Wikimedia Projects」。

主要有兩個資料可以看,一個是「Browser Statistics」,另外一個是「Readers: Pageviews and Unique Devices」。

不過翻了一下,Piwik 好像還是沒有寫到 NoSQL 之類的方案,出自「How do I use another database like Postgresql, SQLite, Oracle? Will you support Nosql databases like Hadoop, Mongodb?」:

Piwik only works on Mysql, where all the development and testing is done. Supporting multiple databases is a long term objective for Piwik, but not our current focus.

不知道維基百科是怎麼 scale 的...

AWS Certificate Manager (ACM) 開放全區

剛剛在辦公室裡跟 Gaod & Rianol 抱怨 AWS Certificate Manager (AWS ACM) 只有 us-east-1 與 CloudFront 可以用,結果 Gaod 說已經開放全區了... (然後我跟 Rianol 一臉茫然)

AWS Certificate Manager FAQs 這邊這樣寫:

Q: In what Regions is ACM available?

Please visit the AWS Global Infrastructure pages to see the current Region availability for AWS services. Certificates provisioned in the US East (Northern Virginia) Region, and associated with an Amazon CloudFront distribution, are distributed to the geographic locations configured for your distribution.

在官方的 FAQ 上面寫只有 us-east-1 以及 CloudFront。但在 User Guide「Supported Regions - AWS Certificate Manager」這邊則是寫上個禮拜的 2016/05/16 開放:

大概是負責的人跑去休假了,所以 User Guide 改完後還沒把 FAQ 改好請 Jeff Barr 發文章公告宣佈吧,感覺是個資安上可以宣傳的事情?

這樣之後在 AWS 上就不用自己搞 SSL certificate 再 import 進去了,ELB 可以直接吃 ACM 產生的 SSL certificate。

Update:其實官方有發稿,在「AWS Certificate Manager now available in more regions」這邊,不過 FAQ 還是舊的 XD

GitHub 大幅調漲企業方案

GitHub 推出以 user 數量計費的方案:「Introducing unlimited private repositories」。舊的方案可以參考在「web.archive.org」這邊記錄下來的內容。

這個方案下的個人帳號會大幅受益:原先最低消費的 USD$7/month 是 5 private repositories,現在變成 unlimited private repositories。

而企業方案將會大幅調漲,雖然現有的 Plan 還是存在,但有種開始殺雞的味道了。

以前 USD$200/month 可以買到 125 個 repository,現在只能給 22 個人用。同時因為 GitHub 對 deploy key 的限制,跨 repository 時無法重複使用同一把 key,就需要用到真正的 user account,這點就變成額外的成本了。

看了一下內部的數字,不是多一倍兩倍的費用,而是多一個數量級...

Homebrew 會將安裝資訊送到 Google Analytics 上

Hacker News Daily 上看到 Homebrew 會將安裝資訊送到 Google Analytics 上面:「Homebrew's Anonymous Aggregate User Behaviour Analytics」。

opt-out 的方法有兩個,一個是環境變數,另外一個是透過 git 設定:

If after everything you've read you still wish to opt-out of Homebrew's analytics you may set HOMEBREW_NO_ANALYTICS=1 in your environment or run git config --file="$(brew --repository)/.git/config" --replace-all homebrew.analyticsdisabled true which will prevent analytics from ever being sent when either of them have been set.

Archives