一般我們在實作 Nginx 的 Reverse Proxy with Cache 時, 可以參考這篇:
https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachingexample/
不過若是 proxy_pass 的 upstream 是 https://example.com/ 時, 會發生以下錯誤:
SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while SSL handshaking to upstream
從 log 來看, 其實原因很單純, 因為預設往 upstream 的 web request 會使用 ip 的方式連接, 而導致錯誤 (前端收到為 502 bad gateway), 解決方式只需要新增一個值:
proxy_ssl_server_name on;
如此即可, 請參閱:
之前介紹過 1.1.1.1, 8.8.8.8, 9.9.9.9 (https://diary.tw/archives/185), 現在有個台灣的 101.101.101.101, 雖然長, 不過也十分好記, 因為台灣有個 101高樓啊.
官方網站說明: http://101.101.101.101/
這個 DNS 的重點在官網上說明的:
隱私優先
我們絕不會出售您的資料，或是用來定位廣告。
我們絕不會記錄您的 IP 位址 。
而且我們委由 PwC Taiwan 每年審核我們的系統，確保我們說到做到。
這樣真的很棒呢, 而且也有提供 ipv6 版本的: 2001:de4::101 / 2001:de4::102 呢.
101.102.103.104 是他的備份 DNS 是不是也十分好記呢?
另外參考看看 mobile01 上的網友測試:
https://www.mobile01.com/topicdetail.php?f=507&t=5496792
繼續閱讀:
https://free.com.tw/quad101/
今天在解一個已停用 TLS 1.0 加密通訊協定問題時, 發現舊的 web server 上的 php curl 無法正常連線, 在 command line 下使用 curl https://xxx.xxx 時, 也會出現:
curl: (35) TCP connection reset by peer
研判為 curl 的原因造成, 由於需要使用 php 中的 curl_xxxx 系列指令與其他 server 的 api 溝通, 所以必須更新對應的模組來解決, 指令如下:
yum update nss curl openssl
更新完成後, 重起 apache 即完成正常呼叫其他 server api 停用 TLS1.0 的加密通訊協議問題.
參考資料:
https://stackoverflow.com/questions/30145089/tls-1-2-not-working-in-curl
使用 play with docker: https://play-with-docker.com 可以快速建立 docker container 環境, 每次可以使用 4個小時, 供測試驗證應用.
進入 play with docker 後, 使用以下指令進行 mongodb 的建立:
docker run --name some-mongo -d mongo
當然因為沒有 mongo 的 image, 所以會進行 pull, 並發起一個 container 執行 mongodb.
接下來可以使用 docker ps 來檢查是否已正常執行.
若要進入該 instance 裡, 可以使用以下指令:
docker exec -it some-mongo /bin/bash
就可以進行該 mongo instance 中的 bash 中, 進入 db 的 shell , 可以再下指令: mongo, 即可正常進入該 mongodb 的 shell 中, 接下來就可以使用大家熟悉的 mongo 指令, 如:
use [db_name]
db.createCollection(“[collection_name]”)
db.[collection_name].insert({xxx})
等指令.
在設置家用 WIFI AP時, 有時會有收訊好, 但品質不好的問題, 若有線沒有問題的狀況下, 即使 WIFI AP 收訊格數不錯, 也沒有好的品質時, 可以將 wifi 的 channel 和附近訊號較強的 wifi ap 分開, 以達成不會互相干擾導致的寬頻不良狀況.
可以使用工具如下(免費):
Android: Wifi Scanner: https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer
iOS: AirPort 工具程式: https://itunes.apple.com/tw/app/airport-%E5%B7%A5%E5%85%B7%E7%A8%8B%E5%BC%8F/id427276530?mt=8
Windows: Wireless netview: http://www.nirsoft.net/utils/wireless_network_view.html
利用這些工具可以查找 wifi ap 使用的 channel, 參考訊號較強的 ap channel, 必須分開不互相在同一頻道上, 可減少 wifi ap 互相干擾的狀況, wifi ap channel 的設定, 一般出廠值都會設定在 auto, 也就是自動選擇, 若要進行手動調整, 建議是在訊號不錯的狀況下, 但頻寬表現不良時使用, 沒有必要也不需要手動進行調整.
其中以 wifi scanner 來看:
集中在 1, 11 上, 就可以將自己的 ap 設定在 4, 6, 7 上以分離不同頻道來進行 wifi ap 的傳輸優化.
另外 iOS 的 AirPort 工具程式, 要到設定裡, AirPort 中的 Wi-Fi 掃描器打開(預設為關閉), 就可以在不用 JB 的狀況下掃描 wifi ap 的頻道.
參考資料:
https://www.accessagility.com/blog/free-wifi-scanner-for-iphone-and-ipad-without-jailbreak
https://www.technonutty.com/2016/04/wifi-analyzer-channel-scanner.html
厲害, 雲端資源原來遊戲規則要調整了, 以小時計費計價的基礎將要進行調整, 改為以秒計費, 真的來到了用多少付多少的計價方式.
參考這篇資料:
https://aws.amazon.com/tw/blogs/aws/new-per-second-billing-for-ec2-instances-and-ebs-volumes/
其中提到:
Effective October 2nd, usage of Linux instances that are launched in On-Demand, Reserved, and Spot form will be billed in one-second increments. Similarly, provisioned storage for EBS volumes will be billed in one-second increments.
也就是從 2017/10/2 起, EC2, EBS 都會以”秒”計費, 真的太棒了.
繼續閱讀:
https://www.bnext.com.tw/article/46219/amazon-aws-per-second-billing
[2017/9/28 9:34]
結果 Google Cloud Platform 也來加入混戰了, 以秒計費, 即刻開始:
https://www.bnext.com.tw/article/46330/following-aws-google-compute-engine-also-moves-to-per-second-billing
Docker的便利性相信大家都清楚了. 不過建立一個開發或測試環境, 尚需要一些時間, 有沒有更快的方式來建立 docker 的環境呢? 有個超級好用的工具, play-with-docker:
這個工具可以讓你快速地有個環境, 並且已經裝好了 docker , 可以快速地建立測試、開發環境, 並且進行測試與驗證, 這個工具真的有效地解決了自行建立安裝 docker 環境, 並且更快速地完成開發部署的需求. 可以參考今年的 docker con 2017 上的簡介:
(以上影片引用自: https://www.youtube.com/watch?v=-h2VTE9WnZs)
另外後面一個 session 也有介紹 FaaS 專案, 這種使用像 AWS Lamda 的架構, 用 docker 輕鬆就部署完成了, 真的超方便好用.
想體驗看看嗎? 馬上來個快速的 wordpress docker :
http://play-with-docker.com/?stack=https://raw.githubusercontent.com/docker-library/docs/0cb43ce8ad1da073bbc30c6245cdffb433ba51ba/wordpress/stack.yml
或是到 https://hub.docker.com/_/wordpress/ 找到 Try PWD 點下去就明白了.
在 windows 下, 若要查詢開機時間(啟動時間)如 linux 下的 uptime, 可以使用以下方式:
還有 uptime 指令, 不過是需要安裝的, 可以參考這篇其他的查詢方式: https://stackoverflow.com/questions/11606774/how-to-get-the-system-uptime-in-windows
之前介紹過一家便宜又大碗的雲端主機商, DigitalOcean – https://diary.tw/tim/1103 最低單價是 USD 5/month, 現在要介紹這家是另一家便宜又大碗的主機商, Vultr – http://www.vultr.com/?ref=7131638
這家雲端主機商, 最低的單位是 USD 2.5/month, 和 DigitalOcean 的比較如下:
| Digital Ocean | Vultr | Vultr | |
|---|---|---|---|
| 每月費用 | USD 5 | USD 2.5 | USD 5 |
| CPU Core | 1 | 1 | 1 |
| Memory | 512MB | 512MB | 1024MB |
| SSD Disk | 20GB | 20GB | 25GB |
| Transfer | 1TB | 500GB | 1TB |
只有在傳輸上有差異, 其他的部分基本上是一樣的, 尤其若是 Vultr 也用 USD 5/month 時, 則可以得到更多的記憶體與更多的 SSD, 傳輸達到一樣是 1TB. 相關費用可以參考:
Digital Ocean: https://www.digitalocean.com/pricing/#droplet
Vultr: https://www.vultr.com/pricing/
還有不同的地方, 主要在 Vultr 還有直援自行上傳 ISO 檔建立主機與 Windows Server 2012R2 的主機 (不過會多需要支付每月 USD16 與最小主機規模為 USD 10 的費用). 還有在 Vultr 的服務除了建立主機外, 還有直接建立 application(就是直接已安裝好應用程式的主機) 的功能, 目前已有以下的 applications:
不過有些服務會需要指定大小的主機, 費用可能會稍高一點.
實測了下載速度如下圖(主機在新加坡, 使用 wget 下載: http://speedtest.ftp.otenet.gr/files/test1Gb.db)
目前申請 Vultr 服務, 還有儲值多少送多少的服務, 上限到 USD 100, 還蠻划算的, 有需要的朋友們可以使用看看, 記得使用我的推薦碼進行申請:
http://www.vultr.com/?ref=7131638
Happy Coding, Happy Deploying, Happy Hosting.
剛在 Channel 9 上看到的, 很棒的內容分享介紹, 給大家參考:
互聯網流媒體架構設計模式與實踐 – 如何使用 Azure Media Service 構建端到端的流媒體服務平臺
https://channel9.msdn.com/Events/DevOps-TW/DeveloperDay/A02
微軟的媒體雲端服務, 基本上包含了完整的媒體應用時所需要的所有功能, 包含了 VOD, Live Streaming, DRM, Player 等, 而且也與原來的 Azure Storage 結合, 可以存放大量內容與上傳轉檔等功能, 另外播放器也十分完整, 可以在各不同平台上提供播放功能, 而傳輸的協議上也同時提供了 MPEG-DASH, HLS, Smooth Streaming (影片中提到的 Azure Media Player 連結: https://ampdemo.azureedge.net/).
這篇影音很清楚地介紹許多在開發人員面對要實作 Media service 時的應用情境, 可以讓大家在開發這類的應用服務時, 有更快速方便的工具.
另外開發的程式語言支援了 .NET, JAVA, PHP, NODEJS 等, 基本上在 Azure 的服務上, 就算是不支援的程式語言也可以透過 Restful API 來操作, 更容易讓開發者使用自己熟悉的語言來進行開發.