從 0 開始搭建這個 Blog

架設初衷

可以追朔到好幾年前，因為我有做紙本筆記的習慣，因此有想要將它們電子化的想法。

本來的主力是使用 Notion (雖然現在也是)，但用久總覺得 Notion 比較適合當 Local 的資料庫。

若只是單純與朋友分享筆記或許可以，但如果要公開成 Public Site，網址的分享與整理就會變得非常凌亂，有的筆記可能想公開，有些可能否，但這些筆記交雜在同一個資料庫中時，我好懶得再新增一個 Tag 去追蹤哪些筆記是公開的。

而且不知道從什麼時候開始，我就莫名想要學 Web 相關的知識(可能身邊很多大佬吧)，而最直觀的學習方式就是建立自己的網站。

「那不如，就來架自己的 Blog 吧！」ー從來不覺得架網站開心過就是了

Hexo

會選擇 Hexo 作為框架、Redefine 作為主題的原因，主要是在參加成大資安社的社課時，偶然發覺社長的 Blog 的 UI 好戳中我，所以就去摸索 Redefine 這個主題，也因而使用 Hexo 作為框架了。

Hexo 是利用 Node.js 製作靜態網頁(無後端)的框架，剛好切合 Blog 不需後端的需求，支援將 Markdown 快速編譯成 html、css、js

由於 Hexo 是基於 Node.js 的框架，所以要先把 Node.js 載下來。

有個小丑因為想同時在 arm64 Macbook 上和 x64 Windows 桌機上開發，因此在解決 npm 的相容問題上花了大量精力 🤡

nvm 與 npm

nvm (node version manager)：管理 Node.js 的版本
- 確認安裝的 Node 版本有比 Hexo 當前版本所需最低 Node 版本還高就好
- 懶得查的話 (這我) 可以直接用 Node 的 LTS (Long-Term Support) 版本，應該都能滿足 Hexo 的需求
  1
  2
  nvm install --lts
  nvm use --lts

npm (node package manager)：用來下載我們需要的 Node.js Module

Dependency：這個 Node 專案所需引用的資源模組

由於 npm 會將所有 Dependency Module 安裝在當前專案目錄，而這些檔案我們通常會 .gitignore，所以專案內會需要 package.json 和 package-lock.json 紀錄所需安裝的 Module 及版本

npm install # 將所有 package.json 所紀錄的 Dependency Module 下載到當前目錄

# 若想額外新增某個 Module 到專案中，則
npm install <module_name> # 除了會下載到當前目錄外，也會新增紀錄到 package.json

接著參考了這篇【學習筆記】如何使用 Hexo + GitHub Pages 架設個人網誌 by Heidi-Liu

用 hexo init 初始化目錄後，確認 hexo generate -> hexo server 有成功顯示 hexo 預設網頁在 localhost，就接著開始用 Redefine 了。

hexo generate 是將 Markdown 編譯成 html, css, js 的過程，轉完之後會放在 /public/ 下，而 hexo server 或 hexo deploy 就是拿這個 /public/ 當作網頁資源部署在本地端或指定端口

Redefine

Redefine Docs

.gitkeep 和 .gitmodule

兩個新學到的 git 產物：

.gitkeep：如果某個目錄是空的，git 預設是不會追蹤，因此若想讓 git 追蹤該目錄，只需在該目錄中放置 .gitkeep 檔案即可
.gitmodules：專案中有時可能會放入別人寫好的 Repo 內容，這時不需要手動下載並放入專案，只需在專案根目錄放置 .gitmodules 紀錄所有需要下載的 Module Repos：
1
2
3
[submodule "module 名稱"]
path = <module 要放的位置>
url = <module 的 repo url>
並且在 Terminal 輸入
1
2
git submodule init
git submodule update
git 就會自動下載並放入目錄了
(submodule 還有一個好處是省自己 Repo 的空間)

基本上只要照著官方文件走一遍，基礎設置就能簡單完成

部署到 Github Page

一樣是參考【學習筆記】如何使用 Hexo + GitHub Pages 架設個人網誌 by Heidi-Liu

架設在 jtsai1120.github.io (目前已停更)

部署到 AWS S3

其實 Github Page 已經挺不錯的了，既免費、部署又簡單，但有個不容忽視缺點：只有 1GB 的空間。
儘管目前還未碰到這個問題，但想到未來持續更新遲早要面對，所以就把頭轉向付費的雲端。

問了一下 GPT，依我的需求(單純的靜態網頁、不需太多功能)，AWS 中最實惠的服務應該是 S3 了

S3 本身好像只是雲端存儲的服務，但是有提供作為靜態網頁存取的功能

因此參考了這篇：hexo 部署在 AWS S3 上面

部分要改動的地方

Bucket Name 使用網域的名稱 ex. jtsai1120.com
Object Ownership 改為 ACLs enabled，小選項選擇 Object Writer
Credential (即 Access Key) 是用來讓遠端存取 AWS 的密鑰，而 .csv 取得方式有簡單的方法：
- 右上角點選帳號 -> Security credentials -> Access Key -> Create Access Key
- 取得 .csv

其他部分都照著做，最後順利用 hexo deploy 上傳到 S3 Bucket

靜態網頁架設在：http://jtsai1120.com.s3-website-ap-northeast-1.amazonaws.com/

買域名

但 AWS S3 提供的域名太長了，因此想說買個的域名指到該 Bucket。

打開 Google 搜尋域名購買，SEO 第一個跳出來是 Godaddy，所以就選擇它了。

隨意嘗試幾個網域名稱，找 cp 值最高、最符合審美觀（？的選項，最後還是回到 jtsai1120.com，因此嘗試性的先簽約了一年。

再來就是將 jtsai1120.com DNS 轉到 http://jtsai1120.com.s3-website-ap-northeast-1.amazonaws.com 的過程，過程中學到很多名詞與概念：

網域、子網域與 DNS 紀錄

網域 (域名)
- 網站所屬的伺服器在網路中的地址
- 分為多層級域名，以 . 分開表示層級
  - 域名結尾為 頂級域，用來表示網站目的與開放程度，通常就固定那幾個在選 ex. .com, .tw, .gov, etc.
  - 越往前的域名，層級越小，稱為 子域名
  - 以 jtsai1120.com 為例，頂級域是 com，二級域是 jtsai120
  - 頂級域＋二級域 就是屬於我的伺服器了，而伺服器中不一定只能放一個網站，所以有更多級域的產生，每個不同的子網域都是個別不同的網站
  - 三級域以上通常只是為了細分網站用途，比如
    - www.jtsai1120.com: (World Wide Website) 開放給全世界看的
    - zh.jtsai1120.com: 中文的
    - blog.jtsai1120.com: 專門用來寫 blog 的
DNS (Domain Name System)
- 網路的終端伺服器能讀懂的地址是 IP 地址，由 4 組數字組合而成，因此 DNS 就是將 網域名 轉成 IP 地址 的服務
  ex. jtsai1120.com -> 3.5.156.122
- 應該是由一台大型伺服器作為 DNS 的 Hash Table，我們平常在瀏覽器輸入網址後都會先經過這個 DNS 服務的轉換
- DNS 紀錄
  - 用來告知 DNS 伺服器要如何轉成 IP 的描述
  - 描述類型有很多種，常見的有 A 跟 CNAME
    - A: 把 頂級域＋二級域 (以@表示) 直接轉成特定 IP
    - CNAME: 把 子域名 轉到別的域名地址或直接轉成特定 IP
- 其他還有很多接觸到的東西，之後再慢慢補上
  - http 與 https 差別: 都是協定，但是一個比較安全（？
  - 轉址: 把域名轉成別的域名，有點類似 CNAME（？
  - 名稱伺服器: 指定託管 DNS 紀錄的對象，原本預設是 Godaddy，後來我有轉為 AWS Route53
  - Cookie: 瀏覽器對特定網站的暫存資料，目前好像知道會影響 DNS，但不知道影響在哪裡
  - $dig <域名>: 在本地 Terminal 查詢特定域名的 DNS 紀錄
  - (待補)

總之，我原本是讓 Godaddy 託管 DNS 紀錄，但過了一兩天都遲遲轉不到 S3 Bucket 的靜態網頁，因此後來改使用 AWS 本身的 Route53 託管服務，最後順利成功轉進去

http://jtsai1120.com

參考：AWS — 自訂義網域架設網站(透過 Route53、S3) by Kurt

接著，有趣的事情是，此時還只有 http 協定可以進去而已，但瀏覽器好像都會自動幫沒有註明協定的連結補上 https 協定，所以接著去跟 ChatGPT 一問一答：

要讓你的網站透過 HTTPS 協定訪問，你需要完成以下步驟：

步驟 1：申請並配置 SSL/TLS 憑證
AWS 提供了免費的 AWS Certificate Manager (ACM)，你可以透過它為你的域名申請 SSL 憑證。
1. 進入 ACM
  - 開啟 AWS Management Console。
  - 搜尋並進入 Certificate Manager (ACM)。
2. 申請新的憑證
  - 點擊 Request a Certificate。
  - 選擇 Request a public certificate（公開憑證）。
  - 在 Domain name 中填入你的域名，例如：
    - jtsai1120.com
    - www.jtsai1120.com（如果你也希望子域名透過 HTTPS 訪問）。
  - 選擇 DNS validation（推薦方式）。
  - 點擊 Request。
3. 驗證憑證
  - AWS 會提供一條 CNAME 記錄，你需要將這條記錄添加到你的 Route 53 Hosted Zone 中。
  - 在 Route 53 的 Hosted Zone 中，找到你的域名，添加以下記錄：
    - 類型：CNAME
    - 名稱：AWS 提供的值（如 _1234abcdef.jtsai1120.com）。
    - 值：AWS 提供的目標（如 abcde.cloudfront.net）。
  - 驗證過程需要幾分鐘到幾小時。
    完成後，你的 SSL 憑證會變成 Issued 狀態。
步驟 2：將 S3 和 CloudFront 配合 HTTPS 使用
S3 靜態網站不原生支援 HTTPS，因此需要透過 CloudFront（AWS 的 CDN 服務）來啟用 HTTPS。
1. 創建 CloudFront 發行分配
  - 搜尋並進入 CloudFront。
  - 點擊 Create Distribution。
  - 在 Origin domain 中選擇你的 S3 靜態網站終端點（如 jtsai1120.com.s3-website-ap-northeast-1.amazonaws.com）。
  - 設定：
    - Viewer Protocol Policy：選擇 Redirect HTTP to HTTPS。
    - Cache Policy：使用預設的 CachingOptimized 或其他適合的策略。
    - Alternate Domain Names (CNAMEs)：填入你的域名，例如：
    - jtsai1120.com
    - www.jtsai1120.com
    - SSL/TLS Certificate：
    - 選擇 Custom SSL Certificate，然後選擇步驟 1 中發行的 ACM 憑證。
  - 完成後點擊 Create Distribution，等待 CloudFront 配置完成（約 15 分鐘）。
2. 將 Route 53 的 DNS 記錄指向 CloudFront
  - 回到 Route 53 Hosted Zone。
  - 將域名的 A 記錄改為指向 CloudFront 發行分配的終端點，例如：abcdef12345678.cloudfront.net。
    - 記得使用 Alias Record 指向 CloudFront。
步驟 3：驗證 HTTPS 訪問
- 等待 CloudFront 發行完成（通常 15~30 分鐘）。
- 打開瀏覽器，輸入 https://jtsai1120.com 或 https://www.jtsai1120.com。
- 如果成功，瀏覽器應該會顯示 HTTPS 鎖定圖示。
可選步驟：強制 HTTPS
如果你希望所有 HTTP 請求都重定向到 HTTPS：
- 確保 CloudFront 的 Viewer Protocol Policy 設定為 Redirect HTTP to HTTPS。
- 可以在 S3 靜態網站的「重新導向規則」中添加重定向規則（但 CloudFront 處理更高效）。

完成以上步驟，你的網站將能透過 HTTPS 安全協定訪問！

最後完成後，就能夠順利用 https 協定進入網站了！

jtsai1120.com

jtsai1120's blog