Ithome鐵人賽

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day08 – SSL 並不是不能用 let’s encrypt 只是要換個方式

cloudfront的原站不能用 let's encrypt？ 整站套用CDN的時候最怕的是如果我使用了 let's encrypt 結果更新失敗了！ 這時候整個網站就都會顯示502 gateway time out 這時候該要怎樣避免這個問題 let's encrypt 的驗證方式 let's encrypt的驗證方式官方參考連結　<--連結--> 傳統上很多教學都是希望用HTTP-01來進行驗證 但是在CDN的環境之下很容易出錯 目前都是建議使用DNS-01 目前很多國際DNS服務都有支持這個方式了 如果還是用台灣傳統IDC代管的可能就無法使用該方式 建議還是用一些國際雲端服務比較安全 　使用acme.sh配合Route 53進行證書的申請作業與驗證的方式 因為文章及方法很多 就列出幾篇文章提供大家做為參考 Route 53 Let’s Encrypt wildcard certificate with acme.

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day07 – 讓AWS Cloudfront將主機的附載降低到10%以下， Cloudfront 快取行為設計

快取行為該如何設計 在 Day 05 Amazon Lightsail 也可以套用 CDN (AWS Cloudfront) 的時候建議預設是全部forword不做快取 這樣其實就會失去快取的效果但是最少是網站都是可以瀏覽的狀況 那要如何做快取才是最好的方式？ 其實快取的標的基本上是靜態資源 這個靜態資源不一定是指實際有存在的檔案 如果是以php模擬出來的html也是可以接受的存在 快取的作法 在設定完之後如果點到Behaviors因該只有預設的一行 Default (*)　在這邊的意思是指預設或者是說如果沒有其他的條件就可以套用他 在預設都沒有快取之下我們就可以開始針對各種靜態資源進行快取拉 這也是在幾年的經驗之下最保險也是最不會出現意外故障的作法 假設我們的圖片都是png類型的圖片那該怎樣做快取呢？ 先點選 Create Behaviors 現在新版的設定不多所以可以比較輕鬆的設定 設定重點 * Path Pattern 是指哪種檔案，如果要將所有png結尾的圖片作快取就可以在這邊填入『*.png』 * Cache Policy 選擇 Mana

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day06 – WordPress 上 Cloudfront 的最大貧頸 SSL

host與https 其實不只是wordpress，任何的框架都有相同的問題 我們都會在程式碼中判斷URL是否正確 如果不符合就就進行301或302跳轉 但是通常的判斷條件只會有URL而不含http或https判定 而wordpress是屬於兩者都會判斷的一套軟體 這時候程式判斷的處理就格外重要 再導入Cloudftont的時這時候我都會建議一定要fotword Hosts參數以避免問題 同時間原站點也是要上SSL證書以避免轉換上的問題 最好的方式一定是 https://URL 進行訪問 Cloudfront 也適用同一個URL是最不容易出狀況的 但是如果預算不允許就要注意這個問題『如何告知您的web server產生的連結均要變更為https』 如果連結都寫好在資料庫還好改但是如果是程式產生的URL就要注意如果沒有處理好 會發生網站以經是https了但是裡面程式產生的URL都還是http造成無法顯示的狀況 發生這種情境最常出現的狀況就是網站破了 因為http的資源被瀏覽器禁止了 這點是相對不容易克服的 如真的在源站無法放SSL證書再來嘗試下面連結 H

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day05 – Amazon Lightsail 也可以套用 CDN (AWS Cloudfront)

何謂CDN 內容傳遞網路（英語：Content Delivery Network或Content Distribution Network，縮寫：CDN）是指一種透過網際網路互相連接的電腦網路系統，利用最靠近每位使用者的伺服器，更快、更可靠地將音樂、圖片、影片、應用程式及其他檔案傳送給使用者，來提供高效能、可擴展性及低成本的網路內容傳遞給使用者。出自維基百科 為何要用CDN CDN其實有很多的好處 1.　讓USER離你的端點進一點，速度快點 2.　快取靜態資源，減低伺服器的負載 3.　降低被攻擊的風險，本土的陽春CDN除外，國際廠商的CDN基本上都幫你抵禦L3、L4的攻擊 4.　隱藏主機，很多人的主機還是低分散的狀態，知道的網站就可以猜說你的其他服務是不是在同一台 其實好處還有很多，只要是走http的服務基本上都一定可以套用到CDN上除非特殊需求不然很少沒辦法做到套用的。 AWS CDN (AWS Cloudfront) 使用說明前文 在列表跟事前準備文章的時候其實已經是一段時間之前了 在這段時間中AWS Lightsail 現在已經整合了Cloudfront 與

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day04 – Amazon Lightsail LAMP 建置方案

OS選擇 基本上如果是php + mysql 基本上OS都是以免費的centos與ubuntu為主 當然其他OS也沒不好只是現有資源都是以這兩個OS為大宗 如果是新專案能選新OS就選新OS避免太快就被淘汰 Linux通常我們做完幾年內除了安全性更新都不大會去大量修改架構 LAMP還是LNMP的選擇 基本上 php跟mysql版本的選擇上都不太會有爭議 都是選擇較新的穩定版本比如現在最新的php是7.4 開發商的選擇我看大部分都是7.2 但是對於apache跟nginx就有很大的爭議了 不過基本上如果是新手我建議是apache配和php是比較簡單的作法 nginx雖說也不難但是相對應的文件上少了許多 常用的　.htaccess 支援程度也是較低的 建置文件 新手一定要看鳥哥這已經是必修課了 但是如果有時間壓力可以參考　linode　或 digitalocean 相應的內容都比一堆blog寫的完整 linode、digitalocean 當然如果是用Lightsail還可以直接選用現成的執行環境 或許有人眼尖看到cPanel 想說很方便！ 但是要

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day03 – 傳統感受 虛擬主機 Amazon Lightsail

特色 他就只是個有AWS招牌的VPS 如果您不瞭解啥是VPS 簡配的網路、簡配的負載平衡、檢配的防火強、檢配的規格 除了OS可能會給多一點東西之外一律都是檢配 這邊的簡配是相對的，他相對於linode、godaddy的VPS來說功能性上一點都不差 但是相對於AWS EC2擁有完整功能的VM來說的確少了些方便於擴展性 但是如果需要是可以隨時將Lightsail轉換至AWS EC2的 附帶一題現在Lightsail已經有提供快速的CDN整合服務不用再額外整合免費但是沒有台灣節點的cloudflxxx了 參考連結　使用Lightsail Content Delivery Network改善網站性能 建立方式 先擁有一個AWS帳號 然後登入 廢話 找到Lightsail就點進去準備開主機了 點選Create instance就可以開始建立了 建立主機只有三個重點 1.　選離自己進的主機或者是選客戶近的主機 2.　選自己要的OS 選好之後往下拉有其他選項 3.　建立並下載一把key，這邊需要講到AWS中的一個特點AWS的主機不喜歡用密碼登入，所有人都是用ke

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day02 – php+Mysql 開發可以怎樣進化

何謂進化 多樣性是進化的特徵之一 但在在台灣的IT市場存在著兩種聲音 1.　IT環境就是要上雲，Kubernetes 就是帥、microservices才是未來的主流。 2.　簡單就好實體主機跟VM都在自己家或IDC，東西都不要出自己家最安全。 但是思考怎樣的服務才是最適合使用者才是最重要的 Nokia的「科技始終來自於人性」才是IT人始終該去遵循的目標，奧客除外！！ 我看過某ISP的雲端部門招牌亂賣AWS lightsail給需要有網路架構的客戶 也看過同業為了業績賣 AWS Shield Advanced 給不適合的客戶　(點下去就是 三萬六美金阿～) 真正符合需要才是IT人要做的事情 為何php+Mysql進化 php+Mysql擁有絕佳的可能性 從單主機小網站到大型網站服務都有他的身影 但是處理好絕對是一件非常困難的事情 程式BUG到系統崩潰都是非常有可能的事 在處理的過程當中就算寫好了程式 環境可能難以配合 我認識的很多RD或IT對於上雲都有一定程度的排斥但是又不得不走 在現在這個想到就可以下下廣告衝衝流量的時代 一台主機不能走天下了

2020ironman 12th – Modern Web - PHP on AWS 進化論 - 從單主機一路進化到Serverless，以WordPress與 laravel 為例 (中斷)

2020ironman 12th – Modern Web – Day01 – 為什麼要寫這個主題以及進化路線

為什麼要寫這個主題 歸納出多套屬於自己的獨特的技術體系因該是每個工程師一直以來的必修功課 從七八年前以Wordpress作出大量的行銷用網頁與電商系統供公司同仁使用 到後幫客戶搬遷與優化各種服務到雲端上 由簡至繁、由繁至簡，一直是一個很大的課題 我們可以使用很複雜但是很棒的工具達成目的，但是絕大部分的人只會希望給我個解決方案直接使用就好 如果凡事都可以那麼簡單就好了 就如同PHP，入門很容易但是要做到專家需要非常大的努力 我在PHP領域中不是個專家，但是我對於PHP底層能怎樣拆分已經練就一身功夫 藉由這次活動整理出對於自身的一個技術體系，整理出到底還有哪邊是可以補足相關技術細節 PHP網站底層進化路線 傳統上大多數的PHP網站本著能用就用一台打天下的形式運行，但就這幾年網路行銷的興起與廣告難度降低，人人都可以對網站進行大幅度的導流，不進行服務進化勢必會造成障礙。就本系列粗估拆分的工作上就可以看出一個網站如果進行拆分可以分出多少服務項目。在整理技術體系的同時也進行自身的提升。 本次進化路線 * VPS(web+db)(Lightsail) * CDN(cl

2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰

2019ironman 10th – Cloud Native – Day30 – 總結! (4)

Day30 - 總結! (4) 最簡單的 AWS Devops 在已經建立好Elastic Beanstalk的狀況之下 只要利用AWS CodePipeline 就可以將CodeCommit、S3、GitHub中的程式碼部署進Elastic Beanstalk 且完全自動化 簡單整合就可以讓開發者脫離FTP更新的困境 對於未來還可以結合Amazon Elastic Container Service (ECS) 達到更好的服務效果 對於AWS上的自動化 用得好可以讓你事半功倍

2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure

2019ironman 10th – Everything on Azure – Day30 – 常用服務 7.CDN

Day30 - 常用服務 7.CDN 所有的雲端服務基本上都免不了用上CDN 雖說AZURE CDN價格不給力 但是一般小使用者也達不到優惠的量 AZURE 有三大雲端當中最豐富的CDN類型可以做挑選 1. 標準 Microsoft 2. 標準 Akamai 3. 標準 Verizon 4. 進階 Verizon 在這些服務如果要挑選可以參考官方文件內的比較表格 比較 Azure CDN 產品功能 相信四種就讓人難以選擇了對吧 但是他還有第五種 針對中國市場所特地開發出來的 1. 中國Azure CDN Azure CDN （内容交付网络）概述 當然要使用中國的CDN就一定要備案 CDN設定上不複雜 要設定的好就仰賴對web服務協議的熟悉度 如果CDN弄的好 通常機器的規格跟費用都可以化腐朽為神奇 仰賴自己對于服務的熟悉程度了

2019ironman 10th - Cloud Native - AWS Elastic Beanstalk & Devops 網站維運實戰

2019ironman 10th – Cloud Native – Day29 – 總結! (3)

Day29 - 總結! (3) EB的調整 在於EB的調整重要的地方在於幾點 1. log的存放：往cloudwatch與S3 2. data的存放：關鍵是不要存local 3. 擴展到底多少才夠：看監控的數值來一次又一次的調整 4. 告警的設定：附載過高要說啊.... 快速講解影片如下

2019ironman 10th - Everything on Azure - LAMP系統營運者 on Azure

2019ironman 10th – Everything on Azure – Day29 – 常用服務 6.VPN

Day29 - 常用服務 6.VPN 如果在雲端上面講VPN 通常都會直接聯想到跟雲端的網路做IPsec VPN 如果這邊只介紹這個就沒什麼特別的 如果只是建立IPsec VPN 那就可以參考 使用 Azure PowerShell 模組建立和管理 VPN 閘道 但是azure上面有個比較特別的是建立USER專門連入AZURE的服務『點對站 VPN』 這可提供給所有的USER來連入雲端內的網路 且可以通過AD驗證(因為他都是使用Azure Active Directory 所以LDAP也是可以整合做驗證之用的) 設定概念可以參考此篇文章 關於點對站 VPN 如果是設定可以參考 使用原生 Azure 憑證驗證設定 VNet 的點對站連線：Azure 入口網站 使用 RADIUS 驗證設定 VNet 的點對站連線：PowerShell