黑皮考町

前言 當我們開發完一個WEB專案之後, 接下來要做的就是測試跟部屬, 通常在部屬的時候, 往往都是找一台機器開始灌OS, 切partition, ...OS灌完之後還要再安裝Application Server, 像Tomcat, IIS 等等 然後設定環境, 如網路,憑證,備份,,等等 最後才開始部屬WEB application, 可是到這個時候, 差不多也浪費掉了一兩天的時間 Elastic Beanstalk(簡稱EBS)是Amazon提供的PAAS服務, 開發人員不需要考慮如何配置以及維護環境, 甚至也不需要煩惱scaling的問題, 只要專心寫程式, 然後上傳到EBS上, 所有跟環境有關的工作EBS都會幫你完成 EBS會幫我們做Heath check, 程式有問題時馬上就會知道, 如果流量增加, EBS也可以幫我們做load balancing, 除此之外, 版本管控的功能也可以讓我們隨時方便的做Roll back Deployment policy EBS 提供四種部屬方式 All at once 直接部屬到所有的instance上, 在部屬期間服務會被停止, 部屬失敗的話需要額外再做Roll back Rolling 選擇這個方式, EBS會一個接著一個將程式部屬到每個instance上, 對外服務不會被停止但整體的performance會下降, 對於很吃performance的WEB APP來說並不適用, 部屬失敗時也需要額外的動作去做Roll back Rolling with additional batch policy 會額外再多建立新的instance去做部屬, 然後再一個接一個部屬下去, 好處是部屬時不會造成performance下降, 部屬失敗時也需要額外的動作去做Roll back Immutable 所有的instance會先部屬在分身上面, 當部屬成功後分身會取代本尊成為服務的提供者, 而先前的instance會被刪除(非常適合Missions critical production), 部屬失敗時影響最小, 只要砍掉分身就好 Config EBS允許我們使用特定的config檔案去客製化EBS上的環境, 例如安裝那些套件, 建立那些特定的

API Gateway API Gateway有點像是水龍頭的概念, 每個水龍頭後面可能各自連接著不同的水源, 用的人不需要知道後面管線怎麼牽的, 如果想要山泉水就去轉開山泉水的水龍頭, 如果想要自來水就去轉開自來水的水龍頭 我們可以在API Gateway上定義RESTful API, 被後再介接Lambda或是其他的web service, 使API Gateway 成為這些網路資源統一對外的出口 Cache 如果想要增加Performance, 我們可以額外付費去啟用快取的功能, 對於相同的請求, 就可以從塊取拿答案直接回覆 (步驟 Stages > Your_stage > Settings ) Throttle 我們可以限制API的呼叫次數, 以避免被有心人士惡意攻擊 (步驟Stages > Your_Stage > Settings) Cross Origin Resource Sharing(CORS) 在Same-origin Policy的機制下, 為了避免Cross-site Script(XSS)攻擊, 大部分的瀏覽器只允許存取與頁面相同Domain下的資源 CORS 可以讓瀏覽器放寬這個限制執行跨域請求

Lambda Lambda 是一種 serverless 的服務, 也就是不需要考慮實體 server 的配置以及相關的維運, 因此開發人員可以專注於商業邏輯的開發, Scaling Out 當同一時間內的請求數量增加的很快時, Lambda 會自己做 Scaling out, 也就是複製另一個容器去處理這些突然增加的請求, 因此對開發人員來說, 就不需要去考慮負載平衡的問題 Version Control 如果沒有特別建立版本, Lambda只會替我們保留最後一版($Latest) 這是個非常好用的功能, 因為實務上同一個 Lambda Function 我們可能會需要同時存在多個版本, 正式版, 測試版,等等, 在 Lambda 上只要幾個步驟, 我們就能發布一個版本 Action > Publish new version (每次修改 Lambda 都允許我們對此發布"一個"版本, 但發布出來的版本無法再被修改) 每個版本都有它自己的 ARN, 搭配建立 Alias Name 我們可以讓 API Gateway去串接特定名稱的Lambda ARN, 而去呼叫某特定版本的 Lambda Function 當有新版本出現時, 我們也測試過一切都沒問題後, 只要將原本 Alias 名稱指到最新版, API Gateway 就能夠呼叫到最新版 Qualified ARN  Qualified ARN 就是ARN後面會再帶一個版本 ARN - arn:aws:lambda:us-east-1:5234234220:function:ProcessVideo: 2 Alias Lambda 允許我們替每個版本建立Alias名稱(如上所述) 除此之外, 我們也可以在建立Alias的時候設定分流 在  Addition Version 這邊, 我們可以指定將部分的流量轉到特定的版本上 (可以用在做A&B Testing) 也就是說, 假設我呼叫底下ARN的Lambda時 arn:aws:lambda:us-east-1:5234234220:function:ProcessVideo:proc 實際上, 會有30%的請求

How to create Google DialogFlow chatbot in10 minutes 前言 隨著Machine Learning的技術越來越成熟, 越來越多的雲端大廠也開始提供自家的AI solution給大眾使用, 如  Google DialogFlow, MS Luis, FB Wit, Amazon Alexa... DialogFlow 是Google 提供的自然語言處理服務, 能夠將文字轉換成電腦看得懂的結構性資料, 再傳遞給後端介接的Web Service處理, 現在的聊天機器人大多都是使用這種架構 DialogFlow response 的簡單範例, { "queryResult" : { "queryText" : "find some hotel in taipei" , "parameters" : { "geo-city" : "Taipei" }, "intent" : { "displayName" : "FindHotel" }, "intentDetectionConfidence" : 1 , "languageCode" : "en" } } intentName 就是使用者意圖, chatbot 可以根據意圖去執行對應的商用邏輯 parameter 則是語句當中的關鍵字, chatbot可以用這些關鍵字當成查詢資料庫的條件, 最後再將答案反饋給使用者  Integration 作為輸入的來源, DialogFlow 目前支援自家的Google Assistant, 還有其他頻道像是 Line, Skype, Facebook ..., 也就是說使用DialogFlow開發的機器人, 不一定只能用在Google Assistant上, 還可以串到Skype, 臉書,,,等等 以下教學, 如何快速建

Lambda Function 如何呼叫另一個 Lambda Function? 實務上有些情況我們會需要從某個Lambda function去呼叫另一個Lambda function起來做事 例如, 處理客戶訂單的OrderLambdaFunction 處理完客戶訂購的請求後, 需要喚起處理付款的PaymentLambdaFunction 要達到這個目的有兩個方法 Lambda Invoke 這個方法最簡單, 使用aws-sdk就能呼叫另一個Lambda Function, 但我們需要添加合適的Policy到OrderLambdaFunction使用的Role中 { "Sid": "Stmt1234567890", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "*" } 步驟1: IAM > Policies > Create Policy > JSON(建立Customized Policy) 步驟2: IAM > Roles > Your_Lambda_Role > Attach Policy OrderLambdaFunction exports.handler = (event, context, callback) => { // TODO implement lambda.invoke({ FunctionName: 'PaymentLambdaFunction', Payload: JSON.stringify({}, null, 2) // pass params }, function(error, data) { if (error) { console.log(

前言 當我們在操作Linux系統時, 有時不免需要輸入一大串指令, 而且某些指令當中的字串, 還有可能重複出現在另一個指令中 列如: docker build -t mydockerpool.io/sample/myRestApi:latest . docker run -it RestAPI  mydockerpool.io/sample/myRestApi:latest 為了能夠偷懶一點 我們替mydockerpool.io/sample設定成環境變數 export ORIGIN= mydockerpool.io/sample 之後指令就變簡單的 docker build -t ${ORIGIN}/myRestApi:latest . docker run -it RestAPI  ${ORIGIN} /myRestApi:latest 問題是, 每次重新連到終端機時, 這些變數又要再重新設定, 非常的不方便 永久生效 如果要讓變數永久生效, 我們可以試著編輯 .bashrc vim  .bashrc 然後在最底下加入變數 , # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). ... ORIGIN = 'dockerpool.azurecr.io/samples' export ORIGIN

I got this information when I tried to train my model. Misaligned entity annotation in sentence The problem is my utterance. for example It was supposed to be "whats the warranty" not "whats thewarranty" It results in Rasa is not able to use start value and end value to extract the entities.

前言 DynamoDb 是Amazon提供的一種同時支援Key Value和Document 儲存方式的No SQL資料庫服務, 開發人員無需考慮環境的建置, 而是把資料庫當成服務來使用, 對於開發人員來說可以省去不少時間 此外, No SQL的形式, 也方便開發者不需要花費多餘的心思去設計Table Schema Primary Key 我們在DynamoDb上建立的每一筆資料都需要指定Patition Key 當作區分資料的主鍵 Partition Key 顧名思義, 跟儲存資料的實體位置有關 我們也可以再多定義一個Sort Key跟Partition Key組合成複合型的Primary Key 擁有複合型主鍵的資料在儲存時, 相同Partition Key的資料會被儲存在相同的Partition內, 當我們在撈資料時, Dynamodb 會根據Sort Key將資料排序 Consistency Model 目前DynamoDb 支援兩種Consistency Model: Eventually Consistency Read(Default) 這是預設選項, 當資料寫入成功後, 不保證能馬上讀取到新資料, 也就是說想要在寫完後立即讀取的話, 有可能會讀到舊值 Strong Consistency Read 則是保證在寫完後可以立即讀取到新的值, 但Performance 會比較差 若我們儲存的資料不像金融資料那樣需要立即性的話, 建議還是使用Eventually Consistency Read, 成本會比較低 查詢 若只要查詢單筆資料, 基本上可以使用GetItem API, 它的用途主要是用在想要取得某一明確的資料的時候, aws dynamodb get-item \ --table-name UserOrdersTable \ --key '{ "Username": {"S": "alexdebrie"}, "OrderId": {"S":"20160630-12928"} }' 所以必須要以