Shannon's Blog 🐟 技術 | 生活 | 旅行

前言 在過去，Python 的世界裡安裝套件、打包專案各有各的工具（setup.py、requirements.txt、Pipfile 等），生態系相當分散。pyproject.toml 是 Python 社群為了統一這些標準而誕生的格式，從 PEP 518 開始逐漸成為官方推薦的專案設定入口。它就像專案的「身分證」與「說明書」，集中描述專案名稱、依賴套件、建置方式等所有關鍵資訊。 核心結構 pyproject.toml 主要由以下兩個區塊組成： [build-system]：宣告要用哪個工具來打包專案（常見為 setuptools 或 hatchling）。 [project]：最核心的區塊，包含專案名稱、版本、作者，以及執行時所需的依賴套件（dependencies）。 建立 pyproject.toml Step 1：建立專案資料夾 以一個需要 requests 套件的爬蟲程式為例，建立以下目錄結構： 123my_project/├── pyproject.toml└── main.py Step 2：撰寫 pyproject.toml 在 pyproject.toml...

前言 這裡是我寫Leetcode總結核心概念的地方，不同的情境會使用到的武器不同，這裡我會描述在什麼樣的情境滿足下，適合的資料結構或是演算法。而這個演算法的核心概念是什麼，同時我也會紀錄一些我在刷題時的心得，以及刷題的時間，來慢慢看到成長與進步。 Leetcode時間紀錄 Hash Table 情境1: 快速找元素 通常使用 Hash 的關鍵在於要用 O(1) 的時間複雜度來查找元素，這樣就可以不用遍歷整個 list 從 O(n) 變成 O(1) 的時間內完成整個問題。 相關題目： leetcode-1-two-sum: 給定一個 target 數值，從 list 中找到兩個數字相加等於 target leetcode-12-integer-to-roman: 整數轉羅馬數字 leetcode-13-roman-to-integer: 羅馬數字轉整數 情境2: 比對無序的東西 如果要比對兩個無序的東西，像是兩個字串是否是 Anagram，這時候可以使用 Hash 來記錄每個字元出現的次數，然後比對兩個 Hash 是否相同。 相關題目： leetcode-49-gr...

前言 最近嘗試在使用 Ansible 寫出針對 Inventory 的 Current State 狀態整理， Inventory 會記錄 kubernetes 中 cluster 所有的 nodes，但很多時候我們在開始執行 playbook 時才發現有些 node 的狀態不是健康的，所以希望寫出一個流程可以先做一些 precheck 捕捉 inventory 的狀態，這樣在執行 playbook 時就可以針對這些 unhealthy node 先排除，不會因為 node 的狀態不健康而導致 playbook 執行失敗。這種自己定義的邏輯我希望自己寫 .py 來實現，所以我在思考應該使用 module 還是 action plugin 來實現。這兩者的差異還是有點模糊，於是就寫下這篇文章來做個比較。 在開始之前，先來講一些 ansible 常見的術語： Modules: 透過 ansible 推送到各個節點的腳本 (像是那個 module 的 .py 檔案)，我們稱為module。 而需要注意的事情是，這些 module 是在 ansible 的目標主機上執行的，你在 Pl...

介紹 最近在開發 Ansible Module 時，想要在 Pycharm 中進行 Debug，不然每次去猜測每個變數裡面現在的值真的是太痛苦了…於是就嘗試使用 Pycharm 的 Debug 功能來進行除錯。 因為最近在開發 collection 的 module 所以本篇主要會以 collection 的 module debug 為主。 這篇文章會介紹如何在 Pycharm 中進行 Ansible Module 的 Debug，並且提供一些小技巧來讓你更有效率地進行除錯。 前置作業 先確保你已經安裝了 Pycharm 和 Ansible。 (這邊建議您使用 venv 或是 conda 來建立虛擬環境，這樣可以避免跟系統的 Python 衝突) 在 Pycharm 中建立一個新的專案，並且將 Ansible Module 的程式碼放到專案中。 12345678910111213141516171819202122# 可以使用 ansible-galaxy init 來建立 collection 的基本架構# 然後放在 collections 底下 .├── collect...

前言 你有沒有曾經想過，在部署程式碼之前，希望先檢查一下有沒有錯誤，或者程式碼格式有沒有符合規範？這時候，CI/CD 就可以派上用場。CI（持續整合）可以幫你自動檢查程式碼品質，而 CD（持續交付/部署）則可以自動化部署流程，讓你的程式碼從開發到上線都更順暢。 但是，如果你有很多專案，而且每個專案都需要寫一模一樣或非常相似的 CI/CD 腳本，這就會變成一件既繁瑣又浪費時間的事情。你可能會想：「有沒有辦法只要簡單放入某些內容，就可以套用特定的腳本？」 其實，GitLab CI/CD 就提供了這樣的功能。透過重複利用與共享配置，你可以「讓多個專案共用同一套 CI/CD 流程」，不但節省時間，還能確保所有專案都遵循相同的規範。 例如，你可以在 .gitlab-ci.yml 套用別人是先撰寫好的腳本： 1234include: - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0.0 inputs: stage: build 這樣，你的 stages 裡面就會載入 se...

前言 在開發 Docker 應用程式時，有時候我們會需要進入到容器內部進行操作，例如查看 log、修改設定檔等等。這時候，我們可以透過 ssh 的方式連接到容器，這樣就不用每次都透過 docker exec 進入容器，更加方便快捷。本章節將會介紹如何在本機透過 ssh 的方式連到 Docker 容器。 步驟 步驟 1：建立 Ubuntu 22.04 的 Docker 容器 我們要使用 host 模式來讓容器共享主機的網路。先拉取 Ubuntu 22.04 輕量版的 Docker image 1docker pull ubuntu:22.04 運行容器並使用 --network host，--network host 讓容器直接使用主機的網路環境，因此不需要手動進行 port mapping。因為 ubuntu:22.04 是一個最小化的 Docker image，預設沒有執行任何長時間運行的程序，所以當 docker run 完成初始化後，容器就會立即退出。所以這裡可以使用 tail -f /dev/null 這會讓容器內一直執行，確保它不會退出。 tail 是一個用來查看文件...

前言 最近寫了很多腳本，但是有太多參數會忘記了，這篇文章主要是整理了一些常用的 bash 腳本技巧，包括變數、邏輯判斷、迴圈、重導向、子殼層、Here Documents 等等。 1. Built-in Variables 1234567$0, $1, $2 # 第 n 個參數，即 argv[n]$# # 參數數量，即 argc$@ # 所有的參數$* # 所有的參數，但是會把所有參數當成一個字串 可以搭配 IFS (Internal Field Separator) 使用來分割$? # 上一個指令的回傳值$$ # 目前程式的 pid$! # 上一個在背景執行的程式的 pid 2. Bash Builins 數學運算，這兩個寫法等價。 12echo $((1+1))echo $[1+1] 變數，{} 可省略 123456name="Shannon"echo $nameecho ${name}# 字串長度echo ${#name} # 7 指令替換，兩個寫法等價 12echo $(whoami)echo `whoami` ...

前言 因為最近為了撰寫 CI/CD Pipeline，因此有很大的時間都在寫 bash 腳本，寫著寫著就覺得應該來好好了解一些最佳實踐！因此整理出這篇教學。 在目前的世界裡面，Bash 繼承了 shell 的寶座，Bash 是可執行檔唯一允許的 shell 腳本語言。幾乎可以在所有 Linux 上找到，包括 Docker 鏡像。這是大多數後端運行的環境。因此，如果您需要編寫伺服器應用程式啟動、CI/CD 步驟或集成測試運行的腳本，Bash 隨時為您服務。 這篇主要參考了 google 所撰寫的 Shell Style Guide。然後還有網路常見的建議所組成，詳細可以參考 Reference。希望自己在寫腳本的時候可以養成良好的習慣… google 如果您正在編寫超過 100 行的腳本，或者使用不直覺的控制流邏輯，那麼現在應該用更結構化的語言重寫它。請記住，腳本會不斷增長。儘早重寫腳本，以避免以後更耗時的重寫。 Environment 所有錯誤消息都應轉到 STDERR 這使得更容易區分正常狀態和實際問題。 建議使用列印錯誤消息和其他狀態資訊的功能。 ps.我自己覺得還可以...

前言 在軟體開發過程中，版本控制工具是每個開發者都不可或缺的利器，而 Git 以其強大的功能和靈活的操作方式，成為目前最流行的版本控制系統之一。在 Git 中，合併（merge） 是一項極為重要的操作，有時候我們開發完一個新功能（例如一個新功能分支）後，需要將這個新功能合併到主分支像是 master, develop，我們不會直接在主分支上面進行 commit 和 push （往往 repository 的 maintainer 也會禁止這些操作）也因此我們需要發起一個合併請求（Merge Request）來進行合併操作。而這個合併請求有一些不同的策略，理解這些合併策略，不僅能幫助開發者選擇合適的合併方式，還能在團隊協作中保持清晰的版本歷史，避免衝突與混亂。 本篇部落格將深入探討 GitLab 中三種常見的合併方法：Merge Commit、Semi-Linear Merge、Fast Forward Merge。 我會詳細解釋每種方法的操作流程、適用場景及其優缺點，讓你能夠在面對不同的開發需求時選擇最合適的合併策略。希望讀者能夠了解這些常見的合併策略，並能將它們靈活運用於日常...

前言 今天要來介紹的是如何用 Terraform 建立 Google Kubernetes Engine，如果對使用 Terraform 建立、修改和刪除的指令不清楚可以參考我之前的文章 Terraform 基本操作，這篇文章主要是要介紹如何使用 Terraform 建立 GKE 叢集，並且建立 Nginx Load Balancer 來做為服務的入口，最後再透過 kubectl 來部署一個簡單的應用程式來測試負載平衡器是否正常運作。同時也會介紹要怎麼撰寫 Google Kubernetes Engine tf 檔案，應該參考什麼網站。 GKE 結構 GKE 的結構是： 叢集(cluster) > 節點池(node_pool) > 節點(node) 叢集 叢集是 Kubernetes 的核心單位，包含所有管理與執行工作負載所需的資源。它是由一組節點組成的容器管理平台。 節點池 節點池是一組具有相同配置的節點（虛擬機），是叢集資源的計算單位。 節點池內的所有節點使用相同的規格，例如機型、磁碟類型、映像類型等。 在 GKE 中，一個叢集可以有多個節點池。 節點 ...