在 HipChat 依然主流、Slack 尚未席捲市場的那個年代，那時建立 ChatBot 的工具還不像現在這麼豐富、中文教學資源也比較匱乏，但在當時就已有不少公司藉由 HipChat + ChatBot 的方式實現自動化及 ChatOps。由於透過此種方式，團隊成員只要在即時通訊工具中呼叫 ChatBot 即可自動完成許多重複性工作，可說是 Dev 與 Ops 兩方都十分喜愛的工具。 本文就讓我們試著運用 GitLab CI 搭配 Mattermost slash command 實現 ChatOps，試著在沒有 ChatBot 的狀況下，快速建立 ChatOps。（本文撰寫時，使用的 GitLab 版本為 13.8 。）
（本文同步發表於 Medium。）
過程紀錄 要透過 GitLab 實現 ChatOps 非常的簡單，基本概念就是將 GitLab CI Pipeline 視為是一個幫你執行自動化腳本的平台，在 CI Pipeline 中規劃各種 CI Job，接著再透過 Mattermost slash command 去 Trigger 特定的 CI Job 幫我們完成想要執行的重複性工作。
以下先說明必要的設定步驟。
啟用 Mattermost slash commands 首先請參考艦長上一篇文章《GitLab 啟用 Project integration - Mattermost slash commands》的步驟，建立一個專案，並且啟用此專案的 Project integration - Mattermost slash commands。...
上週比較忙，所以只整理了一篇較短的舊工作筆記。
由於專案環境的緣故，在某個專案遇到無法按往常慣例為服務設置多重的監控措施。經過討論後，最終在此專案使用了一種不太平常的做法來實現「只設置一項監控 Rule，即同時確認 NGINX、PHP-FPM、MySQL 三者是否正常運作」。該做法是透過 Cron job 定期執行自動化腳本，該腳本會啟用 Selenium 來實際登入網站，並進入特定網頁，最後根據是否能回傳正確的網頁結果，來判斷該服務是否仍正常上線。
（本文同步發表於 Medium。）
前言 如果要確認一個網站是否仍正常運作，我們可以使用多種不同的工具來監控它，例如 Zabbix 的 Web Scenarios、pingdom.com 的 Website Monitoring 或其他各式各樣的 Monitoring tools。
除了直接監控網站之外，有些人也會選擇以監控 Server 上的 Web service（例如 NGINX）或其他 Service 的 Status 是否正常，來確認網站是否仍正常運作。不過有經驗的人都知道，導致網站故障的原因很多，Web service status 正常，但網站依然故障也是有可能發生的。因此更多的人通常是並行多種層面的監控措施，並且設置合宜的 Dashboard 一覽從使用者送出 Request 開始直到 Response 回覆使用者為止的整條路線；倘若網站發生故障，只要一覽 Dashboard 何處出現紅燈，就能迅速定位故障問題點。例如 SRE Taiwan 社群的 Earou Huang 就曾經利用 Serverless Framework 做了一個可以監控系統內部各節點健康狀況的 Project - draft-mesh。 （艦長也曾經試用 Earou 的 draft-mesh 弄了一個 Dashboard。）
總之要確認網站是否仍正常運作的方法很多，可以搭建複雜的監控工具，反之也可以撰寫 shell script + curl command 來快速實現簡易的監控。...
日前收到私訊提問，GitLab 社群朋友在讓 GitLab 串接 Mattermost slash command 時遇到了一些狀況，但根據艦長的印象，slash command 的背後是直接透過 GitLab API 以 POST 的方式進行串接的，理論上不太會遇到問題。於是好奇心發作的艦長，就頭洗下去的做了一番測試，同時將串接步驟也留做紀錄於本篇文章中。（本文撰寫時，使用的 GitLab 版本為 13.7 。）
（本文同步發表於 Medium。）
過程紀錄 Mattermost 與 GitLab 相同，都可以選擇自架或使用官方提供的 SaaS，因此如果會出現問題，會不會是 Self-hosted 與 Cloud 的問題呢？故此我們會有以下四種串接情境。
gitlab.com + Mattermost Cloud gitlab.com + Self-hosted Mattermost Self-hosted GitLab + Mattermost Cloud Self-hosted GitLab + Self-hosted Mattermost 上面四種情境要串接 Mattermost slash commands 的操作步驟都是大同小異的，以下就讓我們逐一示範。
gitlab.com + Mattermost Cloud 第一個示範組是最不會出錯的 Cloud SaaS 組合。
在開始設定之前，請先確定你擁有 gitlab.com 與 Mattermost 的足夠權限，GitLab 這邊需要有權限設定 Project 的 Settings；而 Mattermost 則需要管理 Integrations 的權限。...
身為 GitLab Hero，善用（應該要用） GitLab Pages 來建立靜態網站也是理所當然的事情，之前都是把個人網頁放在自己長期租用的 VPS 上，但最近想要省一點錢，決定把 VPS 砍了，將靜態網站通通都搬到 GitLab Pages 上，所以本文就拿 chengweichen.com 作為案例，實際示範一遍給大家看。（本文撰寫時，使用的 GitLab 版本為 13.7 。）
（官方目前已經提供了多種 GitLab Pages 的 examples。） （本文同步發表於 Medium。）
過程紀錄 根據 GitLab 官方文件的說明，GitLab Pages 目前可以在 gitlab.com 上免費使用（既使該靜態網站是為了商業用途也可以免費使用），同時 GitLab Pages 也支援 HTTPS 及 Custom domain。因此我那個沒啥流量的個人網頁，是完全能夠以 GitLab Pages 架設的。
架設步驟十分簡單，首先是事前準備：
（非必要）準備好你的 Custom domain，如果你沒有自己的網域名稱，GitLab 也有免費提供如 xxx.gitlab.io 的預設子網域名稱可直接套用。 【小提醒】xxx.gitlab.io 其中的 xxx 其實是你 GitLab Project 的 Namespace。以下圖為例，我的 Project namespace 就是 chengwei.chen。 如果你想要使用 GitLab 免費提供的預設網域，同時又想要 GitLab 幫你自動使用免費的 SSL 憑證來啟用 HTTPS，那必須要注意該 Project 的 Namespace 不可以有 ....
休耕結束，決定要讓長草許久的 Blog 再次開張，雖然不見得有足夠時間撰寫長篇或深入論述的文章，但期許自己恢復文字紀錄，將工作上的點滴筆記保留下來。這篇是紀錄在 CentOS 上使用 Nginx 遇到的一個小狀況。
（在 Google 搜尋 500 internal server error 的結果。） （本文同步發表於 Medium）
TL;DR 在 CentOS 安裝 Nginx 時，預設會新增的 Linux User 是 nginx，同時在預設的 Config 檔案 /etc/nginx/nginx.conf裡面也會看見參數 user nginx;。如果你習慣修改 nginx.conf 的參數 user，例如改成 www-data，那麼要注意 /var/lib/nginx/ 也同時要開放權限給 www-data。不然當 Nginx 在處理較大的 Request 而需要寫入一些暫存資料時，就會因為權限不足而回傳 500 internal server error，同時在 Error log 中會出現類似 /var/lib/nginx/tmp/client_body/0000000001" failed (13: Permission denied) 的紀錄。
過程紀錄 某個專案開發完畢了，但將專案部署上線至 Production 環境後，卻出現了不同於測試環境的異常狀況。
異常的狀況是：
乍看之下網站功能都正常，前台似乎都能正常的讀取資料。 出現異常的功能都是 POST Request。 但大部分的 POST Request 也都正常，唯獨要上傳圖片時，瀏覽器會顯示 500 的 HTTP Status Code。 由於 Production 環境處於一個特別的私有網路之內，據說在 Production 主機之外有多了一層非我方設置的 Load balancer（或其他網路設備）。因此當下的第一個念頭是，這 500 到底是誰吐出來的？...
感謝 iThome 的邀請，有幸能擔任 iThome Cloud Edge Summit 2020 的講師，負責一場演講及大會稱之為「雲端體驗營」的其中一場 Lab。
這次準備的主題是目前正熱門的 GitOps。 （本文同步發表於 Medium）
時間非常巧的，在大會舉辦的前些日子，正好有其他厲害的講師（邱牛）於 Cloud Native Taiwan 社群分享相同的主題，因此最後決定改變演講內容，嘗試用不同的角度來切入分享 GitOps。
因此這次演講與 Lab 的關鍵字雖然是 GitOps，但比起如何在 K8S 上實踐 GitOps 及相關的技術實作細節，我想要分享的內容是：
實踐 GitOps 一定要透過 K8S 嗎？ 除了技術層面上帶來的優點之外，GitOps 還帶來哪些好處？ 另外，由於在上半年期間都沒有在社群中分享 GitLab 的相關演講，覺得有愧於 GitLab Hero 的身份，最終演講題目定為《From DevOps to GitOps with GitLab》，而 Lab 的題目則是《GitOps with GitLab》。借這次大會分享 GitLab 公司及我個人對於 GitOps 的一些看法。 已經有研究過 GitOps 的人應該都知道，GitOps 一詞來自於 Kubernetes（K8S）及 Cloud Native 社群，甚至可以說是來自於 WEAVEWORKS。因此早先關於 GitOps 的看法，幾乎都是來自於此。
不過與 DevOps 的狀況類似，當有一個新詞開始熱門時，各雲端服務供應商可是不會放過這股潮流趨勢，GitLab 公司當然也不落人後。目前在 GitLab 官網上已經提供了 GitOps 的相關內容。而且資料是越來越多，目前看來 GitLab 有計畫要將 GitOps 作為市場的切入點，從我開始準備題目，直到實際演講的這幾個月內，GitLab 官網就默默的新增許多值得參考的內容。...
今年艦長發了個瘋，在第二個小孩剛出生沒多久、即將舉辦 DevOpsDays Taipei 2019 （我擔任其中一位組織者）的狀態之下，參加了「第 11 屆 iT 邦幫忙鐵人賽(2019)」。
這次參賽的主題為「和艦長一起 30 天玩轉 GitLab」，本來想要用一個虛擬的團隊作為案例，分享關於 GitLab 的使用經驗，但實際上場之後才發現當初規劃的太美好，事前準備的不夠充分。雖然順利完賽，但案例規劃的並不完整、內容深度也不如計畫，最終撰寫的成果仍是較基礎的 GitLab 操作文章。
（This article has been translated into English.）
目前文章依然留存於「iT 邦幫忙」網站上，暫時先不一篇篇的搬到我私人的部落格，先用超連結的方式處理：
iT邦幫忙網站提供的30天文章列表 下面直接附上 30 篇文章連結，並做一個簡單的分類整理： （鐵人賽文章撰寫時，使用的 GitLab 版本主要是 12；後續出版為書籍《和艦長一起 30 天玩轉 GitLab》第一版時，版本為 13.x；2022 年改版《和艦長一起 30 天玩轉 GitLab》為第二版時，版本為 15.x。） 基本認識 前言 安裝 GitLab GitLab 管理與權限 Admin Area—維運 GitLab Server 的管理者後台 GitLab 的 User 與權限控管 GitLab Workflow GitLab: 從建立 Group 和 Project 開始 初探 GitLab Workflow & GitLab Flow GitLab 和 Mattermost GitLab: Issue、Issue Board 和 Kanban GitLab: To-Do List 與 Milestones GitLab: Commit & Merge Request GitLab: Issue Templates & Merge Request Templates GitLab: Project Wiki & GitLab Pages GitLab Cycle Analytics & Charts GitLab CI 架設 GitLab CI Runner GitLab: 建立第一條 CI/CD Pipeline CI/CD Pipeline 之 stage: build CI/CD Pipeline 之 stage: deploy CI/CD Pipeline 之 stage: test CI/CD Pipeline 之 stage: prod-deploy CI/CD Pipeline 之 Container CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦？ GitLab CI 之 CI trigger、API 與 ChatOps GitLab CI 之 Scheduling Pipelines GitLab Auto DevOps GitLab: Auto DevOps 之牛刀小試 GitLab: Auto DevOps 之牛刀小試 2 - K8S GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production) GitLab: Auto DevOps 之牛刀小試 4 - Auto Browser Performance Testing GitLab: Auto DevOps 之牛刀小試 5 - Auto Monitoring GitLab: Auto DevOps 之牛刀小試 6 - Customizing 回顧與總結 回顧與總結 以上就是 30 天鐵人賽的所有文章。...