在奇幻國度待了 十個月 ,瘦了 十公斤。說真的看到體重破五字頭時真的傻爆眼,那不是我國中的體重嗎?
成功轉職 DevOps
工程師快滿一年,原本以為再也回不去宅宅工程師的職涯了。
因為沒有奇幻的命格,成功再度轉職,非常感謝各方貴人的協助!
開始幫其他開源專案送技術類型的 PR (Pull Request)
,希望之後能持續貢獻。
加密貨幣大爆賠,當時雖然直覺告訴我不要繼續投,但我不信邪XD
iTalki
線上跟老師學習,準備雅思考試,但雅思的準備內容和目前所需比較脫鉤,新的一年會考慮用別的方法來增進英文實力
幫父母達成了他們一直以來的願望
佛系 Blog
成果如下圖:
4.66K
次點擊率海外訪客的國家變多樣了,人數也變多了!
以後會繼續佛系經營,今年總算破一萬個獨立瀏覽人數 (unique visitor,UV),開心 💖
目標 | 達標與否 | 狀態 |
---|---|---|
日文 N2 通過 | 未達標 | |
取得一張 CNCF 發行的 Kubernetes 相關證照 | 達標 | 春節撈了一張 CKA |
投稿成功一次海外的技術演講 | 未達標 | |
取得 Advanced Open Water 證照 | 未達標 | 等身體好轉點再完成。 |
每週固定去健身房或固定運動 | 另類達標 | 今年在牛鬼蛇神的摧殘下瘦了 10 公斤,當然飲食控制也是有幫助,但主要是壓力過大== |
繼續刷 LeetCode,目標先刷個 100 題 | 未達標 | 好懶。 |
父母家人身體健康 | 達標 | 今年以特殊方法達成父母願望,希望他們明年一樣健康 |
✨ 希望英文聽力能變好,至少能聽得懂七成內容,不然參加非中文聚會時根本像連續檢定考折磨
✨ 拓展新的人際交友圈,不然實在太宅了
✨ 每週固定去健身房或固定運動
✨ 熟悉 Rust
語言,並至少能貢獻一個開源專案
✨ 投稿成功一次海外的技術演講
✨ 嘗試 2
件沒有做過的事情
在新的工作內容中恰好碰到了客製化 Terraform Provider
的需求,所以寫一篇文章來記錄一下開發和 Release 的流程,本篇文章假設已經對於 Terraform
這套 IaC
工具使用有基礎的了解,如果沒有聽過或使用過的人可以先拜讀 Che-Chia (David) Chang 大大的 2021 鐵人賽文章 - Terraform Workshop - Infrastructure as Code for Public Cloud 疫情警戒陪你度過 30 天,有助新手們由淺入深了解這套深度整合各大公有雲的 IaC
工具。
對於 Providers
概念不夠清晰的人可以先從 Terraform - Plugin Development 看起,如下圖所示,基本上 Providers
就是一個連接 API
和 Terraform
的橋樑。
接下來要準備開發,首先確認環境有安裝 Go
。
1 | 確認你的 Go 安裝路徑 |
本篇會以 terraform-provider-stripe 來示範,可以直接 Clone
下來輸出執行檔:
1 | go build -o terraform-provider-stripe |
接下來我們要打開 ~/.terraformrc
這個 Terraform
命令列設定檔設定本機測試 Provider
的路徑,範例如下,並且要注意 Provider 的命名規則:
1 | # 這邊要把 Provider 路徑指到剛剛得到的 Go 環境變數,dev_overriders 會在本機開發時直接引用這個環境變數下的 Go 執行檔 |
接下來把剛剛輸出的 Go
執行檔複製到 Go
的執行目錄下:
1 | cp terraform-provider-stripe ${GOPATH} |
就可以開始寫我們測試用的 Terraform Code:
1 | terraform { |
本機測試成功!直接執行就會呼叫 Stripe
的 API
新增一項測試的 tax rate
⚠️ 備註 ⚠️
之前有搜尋到教學文章說要放在 ~/.terraform.d/plugins
底下,這的確是較多文章寫的標準做法,但是這個命名規則就有點冗長,就像以下範例:
1 | ~/.terraform.d/plugins/terraform-example.com/exampleprovider/example/1.0.0/linux_amd64/terraform-provider-example |
然後 provider
要這樣寫:
1 | terraform { |
思來想去覺得麻煩,就走了個比較簡便的方式來開發了。
開發完之後,如果想要推送到 Terraform Registry,可以參考 Terraform - Publishing Providers 的步驟來 Release
。
準備好 Providers
的文件,具體可以參照 Terraform - Provider Documentation
在根目錄下建立一份 terraform-registry-manifest.json
檔案,範例如下:
1 | # 因為 fork 的原作者 Release 的版本是 1,這邊為了做出區別,我從 2 開始 |
GitHub Provider Repo
建置 CI/CD
工具我這邊選擇使用 GitHub Action
當我的 CI/CD
工具,可以從 Terraform - Publishing Providers #github-actions-preferred 開始看。
基本上就是直接拷貝 .goreleaser.yml & .github/workflows/release.yml 這兩個檔案,並且按照目錄結構放置就好。
gpg key
並且分別設定在 GitHub Repo
和 Terraform Registry
可以參考 GitHub Doc - generating-a-new-gpg-key 產生 Private Key
& Public Key
1 | # 產生公鑰和私鑰,我這邊是選擇 (1) RSA and RSA |
公鑰貼在 GitHub > Settings > SSH and GPG keys > New GPG Key
私鑰貼在 Terraform Registry > Settings > Signing Keys > New GPG Key
Release Tag
打上去,然後推到 remote repo
就會自動 Release
到 Terraform Registry
了1 | git tag v2.0.2 |
Actions
標籤裡可以看到有 Release Workflow
在跑:
Release
之後可以在 Terraform Registry > Publish > Provider 列表裡面看到結果:
Released
的 Provider
示範 `Terraform code 如下:
1 | terraform { |
之後只要添加新功能,就打新的 Tag Version
就可以 Release
新版了,其實蠻方便的。
🍀 Lukasaron - Terraform-provider-stripe
🍀 Terraform - Plugin Development
🍀 MY FIRST TERRAFORM PROVIDER
🍀 Terraform - CLI Configuration File
🍀 Terraform - How to Develop a Custom Provider in Terraform
🍀 StackOverflow - Terraform cannot init custom provider written in Go
🍀 GitHub Doc - generating-a-new-gpg-key
GitHub
以及開發工作,最近遇到一個情況是要使用 GitHub API
去實作出一套 CMS 系統,讓內部開發者可以透過介面自動提交對應的檔案,申請 AWS
資源。 本篇會介紹實作自動化 GitHub Flow
時候,看到 API
規格時仍舊一頭霧水,原本以為自己已經很熟 Git
了,真正要實作時才發現對其運作的原理還有很大的進步空間,所以查了很多資料整理出來這篇筆記。文章會介紹直接對 GitHub repo 操作的流程,就不用再把整包程式碼 clone
到本地端了。
通常想到 GitHub
的 CICD
,第一直覺會想到用 GitHub Actions
來實作,但是 GitHub Actions
還是要透過提交 PR
來觸發,假設你遇到的情況是使用者完全不清楚他要提交什麼內容的時候,就會需要連同 PR
觸發也一起搞定的流程。
GitHub Flow
有很多種,如果想要了解的話可以參考 Git上的三種工作流程,已經有人整理好可以對照來看,在我的應用場景會需要使用到的是把 Upstream - Forked Repo - Local
的這種作法,詳見下圖示意:
這種作法會直接把 upstream repo
的 master(main)
分支拉到 local repo
的 feature branch
,開發後推送到 fork repo
的對應分支進行測試環境的 CI
工作,也就是觸發各種 GitHub Actions
/CI triggers
,最後合併進 upstream
的 master(main)
分支,往復循環。
這種作法的優點有兩個:
fork
的 repo
上,比較不會跟別人的分支名稱混在一起CI
測試,可以用 GitHub Actions
做在自己的 Repo 上面,這樣 Upstream
就只要進行綜合性的整合測試即可。從上面的示意圖可以看出如果要完成一次 PR
提交,主要有三個步驟:
如果是指令的操作,相信各位都蠻熟悉的。但假設我們今天是要在一台自動化的跳板機上面做這件事情,我不會想要花時間把整包 repo fork 下來,所以現在需要透過 GitHub API
直接對我們 fork 的 repo
進行操作。把上面的三個步驟對應到 GitHub API
,就會像下面這幾張圖,每張圖下面我會稍微講解一下這個步驟在做什麼,以及需要記下的資訊:
API
會幫你把 Upstream
的 master fetch and rebase 到 fork repo
的 master
分支,相當於這個按鈕的功能:API
會幫你把某個分支的最新的 commit
給抓出來,在這邊因為我需要從 master
分支開出新分支,所以實作的範例如下:1 | def get_latest_commit(host_name, repo_name, git_token): |
這邊的 latest_commit 實作時可以存在變數裡,創建 commit
會需要用到
reference
呢?基本上你可以視 reference
為 branch
,它就像是一個標籤,你可以更新它的 head
到某個 commit
,以下是實作的範例:1 | def create_new_branch(host_name, repo_name, git_token, branch_name, latest_commit): |
接下來會需要執行第二區塊,把新增的檔案加入一個提交 commit
,這邊會需要幫所有檔案創建出 blob
物件,並且拿到 GitHub Database
的 SHA256 code
, GitHub Database 的 API 的使用方法以及圖解可以參考 Getting started with the Git Database API,裡面有講解 commit
, tree
和 file
的關係。
每次我們使用 git add
指令加入檔案的時候,都會生成一個 blob
物件儲存在本地端的 git
,然後在提交 commit
的時候,會把這些 blob
物件的 SHA256 key
集合起來,生成一個 tree
(有點像是演算法的子樹的概念),最後推送到遠端的分支時,會更新遠端分支最新 commit
的整個 root tree
,並且生成新的 root tree
。
第四步開始,我們需要把所有想提交的檔案都呼叫遠端的 API
拿到 blob
的 SHA256 key
。原本使用指令的方式可以直接在本地的 git database
生成,但這次的目標是本地不要有任何 Git Repo
,只保留呼叫 API
的邏輯,所以有多少檔案就要呼叫多少次 API
,因為 GitHub
在檔案上傳這塊沒有提供一次上傳多個或是上傳一個資料夾的 API
。
這步驟使用的 API 是 Create a blob,這邊需要注意的點有兩個:
encode
成 uft-8
或是 base64
的邏輯 (GitHub API 的規格),再把產出物填到呼叫的 payload
裡root tree
從哪邊開始有關,我這邊是直接填寫 repo
根目錄到這個檔案的整條 filepath
這邊直接展示範例程式碼比較清楚:
1 | class Blob: |
第五步驟是要拿到現在這個分支最新 commit
的 tree
,呼叫 get tree API 之後會吐回來這個tree
的 SHA256 key
,這邊一樣實作時先存在變數裡,後續會需要用到。以下是範例程式碼,因為看 GitHub 文件的範例可能會有點疑惑,我這邊是直接拿 fork repo
的 master
分支的 tree
,開出來的分支一樣是指到 master branch
的最新 commit
,只要 commit
一致,tree
的 SHA256 key
就會一樣:
1 | def get_master_branch_tree(host_name, repo_name, git_token): |
第六步驟是要更新第五步驟拿到的整棵 root tree
,這邊我是拿整個 repo
的 root tree
,而不是更新某顆 sub tree
(就是其中的某個資料夾的意思),如果有特定的 sub tree
需要更新的話,從第四步驟上傳 blob
開始,就要注意填寫上傳檔案的相對路徑,不然會導致更新到錯誤的資料夾,甚至把資料刪掉這種慘事。有錯誤的話,在開 PR
的時候都會看到,所以不需要太擔心。
這個步驟算是比較難懂一點,而且跟你上傳檔案時填寫的路徑有關,所以我這邊畫了一張示意圖,會比較好懂點:
這個步驟會用到 Create a tree,範例如下:
1 | def create_new_tree_by_folder(host_name, repo_name, git_token, base_tree): |
第七步驟,透過 Create a commit API 提交 commit,這邊回傳的 commit SHA256
記下來,下步驟會用到,範例如下:
1 | def create_new_commit(host_name, repo_name, git_token, latest_master_commit, new_tree_sha): |
第八步驟,透過 Update a reference API 把新建的 branch (reference)
指到剛剛提交的 commit
,這樣才算是完整更新 branch
,範例如下:
1 | def bind_commit_to_branch(host_name, repo_name, git_token, new_branch, new_commit_sha): |
到這邊已經克服了最難的魔王了。第九步驟超簡單的,就是呼叫 開 PR 的 API,對 upstream 提交分支合併的請求。
這樣的工作流程算是步驟蠻多的,而且參數的傳遞需要稍微整理一下才不會搞混,但是還是有兩大優點:
第一是不需要花額外的儲存空間去存 clone
下來的 Repo
,這樣的特性讓這個自動化程式可以運行在各種 Infrastructure
架構,比方說 Kubernetes
上,因為開發者是用自己的 repo
在提交 PR
,所以不會存在分支名稱衝突,就算檔案有衝突,也會在開 PR
的時候看到衝突結果。
第二是統一幫開發者開 PR
,因為不能確保每個開發者提交 PR
的習慣都照著 fetch & rebase
的流程來,而且有些開發者會提交很多次的 commits
,這樣 PR
不夠簡潔,這個流程可以確保檔案的新增都在一個 PR
內。
或許有些用過 GitHub API
的人會提出為什麼不使用 Create or update file contents API 針對要新增的檔案做循序新增?
因為這個 API
做的事情是拿到 blob sha
+ 直接把檔案 commit
,假設要提交的檔案很多,最後開出來的 PR
一樣會有很多 commits
紀錄,這樣 PR 會很醜,身為工程師還是要有美感。
老實說我在第二步驟的 tree
的更新這邊卡超久,大概試了三個小時才終於開出正確的 PR
,而且因為步驟太多,所以中間一度要靠著不斷嘗試才知道錯誤出在哪個步驟。不過理清了順序和原理之後,這套流程就可以改成任何想要的自動化提交 PR
內部系統的功能,也算是花時間徹底了解整個 GitHub Flow
的原理和複習下 GitHub Database
。
🍀 Git上的三種工作流程
🍀 GitHub API - Create or update file contents
🍀 GitHub API - Sync a fork branch with the upstream repository
🍀 GitHub API - Get a reference
🍀 GitHub API - Create a reference
🍀 GitHub Docs - Getting started with the Git Database API
🍀 GitHub API - Create a pull request
🍀 GitHub API - Create a blob
🍀 GitHub API - Get a tree
🍀 GitHub API - Create a tree
🍀 GitHub API - Create a commit
🍀 GitHub API - Update a reference
🍀 GitHub API - Create or update file contents
🍀 Create a folder and push multiple files under a single commit through GitHub API
🍀 StackOverflow - How to create a commit and push into repo with GitHub API v3?
其實網站上的文章寫得非常詳盡,只是裡面有部分文字容易讓我看不懂,所以就做個紀錄,以防以後我老花忘記。
通常公有雲提供 Site-to-Site VPN 的目的主要是要提供雲端對地端的 Hybrid Cloud 連接場景,對照的業務應用情境就是:
我這邊沒有使用地端的環境,就把兩座公有雲環境網路打通,主要要注意的有兩點:
先上官方的超簡易參考架構圖,主要會需要碰到的組件都有在圖裡面:
但是實際上你會需要設定這麼多東西:
除了官方網站之外,我也有參考愛卡拉的 【手把手教學】如何透過 HA VPN 連接 GCP 和 AWS VPC,這篇文章的圖解非常詳盡易懂,有需要可以交叉參考。
另外我也有買 Google 傳教士推出的參考書籍,可以更方便從零開始了解 GCP 到底有什麼樣的功能可以使用:Visualizing Google Cloud: 101 Illustrated References for Cloud Engineers and Architects 1st Edition,主要是公有雲的產品其實蠻多的,有時候腦中只有場景,不知道要用什麼搭建起一套系統的話,直接看書中的例子是比較快的。
這只是照著官網陳述的命令做操作,你可以在 local 端使用命令行,也可以使用 Terraform 建置。
1 | gcloud compute networks create xx-vpc \ |
1 | gcloud compute networks subnets create test-subnet \ |
建置 VPN Gateway,region 也要跟上面一樣
1 | gcloud compute vpn-gateways create ha-vpc-gw-test --network gc-vpc --region us-east1 |
建完之後,GCP 會配給你兩個 Interface 的 Static IP,待會會用到。
建置 router,這邊填寫的 asn 是 BGP 的自治系統編號,可以填入 64512 到 65535 之間的其中一個數字,這個數字待會會用到。
1 | gcloud compute routers create cloud-router \ |
為什麼這邊會用到步驟 4 的 asn number 呢?基本上你可以看作是從 AWS 發起到 GCP 建立連線,所以要填入 GCP 方的 ASN number
1 | aws ec2 create-customer-gateway --type ipsec.1 --public-ip ${INTERFACE_0_IP_ADDRESS} --bgp-asn 65534 |
1 | aws ec2 create-vpn-gateway --type ipsec.1 --amazon-side-asn ${AWS_SIDE_ASN} |
這邊如果用 terraform 創建的話,要記得把這個 VPN Gateway 和 VPC 做 attachment。
Options 是給那些有預先規劃 Shared Key 的人用的,我這邊是沒有加這個參數,讓 AWS 自動設定
1 | aws ec2 create-vpn-connection \ |
選項照這張圖
總共會有兩份設定檔案,因為你創建了兩條從 AWS 出發的 VPN 連結
約莫拉到中間和尾端會有四個 IP,分別是 Outside IP Address 以及 Inside IP Address
每一份設定檔案會有 IPSec Tunnel #1 以及 IPSec Tunnel #2
你有兩份設定檔案,所以總共會是 4 (每個 IPSec Tunnel 的 4 個 IP addressws) * 2 個 IPSec Tunnel * 2 個 site-to-site VPN = 16 個 IP
這 16 個 IP Addresses 會再待會回到 GCP 做操作時用到,所以最好整理一下。
1 | gcloud compute external-vpn-gateways create PEER_GATEWAY_NAME --interfaces \ |
- AWS_GW_IP_1: Outside IP address for virtual private gateway for connection 1, tunnel 1- AWS_GW_IP_2: Outside IP address for virtual private gateway for connection 1, tunnel 2- AWS_GW_IP_3: Outside IP address for virtual private gateway for connection 2, tunnel 1- AWS_GW_IP_4: Outside IP address for virtual private gateway for connection 2, tunnel 2
示意圖如下:
1 | gcloud compute vpn-tunnels create tunnel-1 \ |
我知道這邊光看 Google 官方文件還是不懂。沒關係,示意圖如下:
1 | gcloud compute routers add-interface ROUTER_NAME \ |
一樣有示意圖,免煩惱。
1 | gcloud compute routers add-bgp-peer ROUTER_NAME \ |
1 | gcloud compute routers get-status ROUTER_NAME \ |
1 | gcloud compute vpn-tunnels list |
這邊依序輸入 tunnel-1 到 tunnel-4。
1 | gcloud compute vpn-tunnels describe tunnel-1 \ |
1 | gcloud compute routers get-status ${Your GCP Router Name} |
再來要確認 AWS EC2 可以 ping 到 GCP 的 instance。
AWS 端:
GCP 端:
通了~ 可喜可賀~
🍀 Build HA VPN connections between Google Cloud and AWS
🍀 【手把手教學】如何透過 HA VPN 連接 GCP 和 AWS VPC
🍀 Visualizing Google Cloud: 101 Illustrated References for Cloud Engineers and Architects 1st Edition
🍀 ASN 的定義
Verdaccio
是義大利文的棕綠、橄欖綠的意思,唸法: ver搭起偶,念起來潮度百分百,而且同事聽不懂你在說什麼。
這個工具是一套開源的 NPM 的套件包管理工具 (Registry),假設企業內部有些自有的 JavaScript 套件只能放在內部做管理,就可以自建這個 NPM Registry。假設企業內部有用 GitHub
或 GitHub Enterprise
,也可以使用 GitHub NPM Registry
,比較詳細的介紹以及使用方式可以參考這篇 - GitHub - Working with the NPM Registry,要注意的是如果你的專案設定是 private
就無法使用這個功能。本次安裝 Verdaccio
純粹是因為帳號可以獨立出來,不需要跟 GitHub
綁定。
關於 Verdaccio
的介紹,網路上有非常多的文章,本機安裝和基本的操作可以看一下這一篇 - 神Q超人 - 用 Verdaccio 快速建立專屬的 private npm proxy 並部署到 Heroku 上! 本篇是紀錄安裝在企業內部環境時可能會踩到的雷,還有一些建置時會需要考量的點。
如果是用 EC2
安裝的話,架構大概會長這樣:
ALB
可以自行替換成 Nginx
等他牌 Load Balancer
EFS
可以替換成 EBS
或其他 NAS
服務 (需要注意的是,EBS
一次只能給一台 EC2
掛載,若要建構多個 EC2
instances 做負載均衡的話,請使用 EFS
)除去建置 Nginx
以及添加域名等工作,純安裝大概可以分為四個步驟:
首先我是參考 Medium - Free Private NPM with Verdaccio and AWS 這篇文章作為安裝的步驟依據,中間根據自己環境加以修改:
1 | 安裝 NodeJS, Verdaccio 以及 pm2 |
安裝完畢,照著說明加入使用者就可以開始上傳 NPM 套件了,非常方便喔!
雖然安裝看起來很簡單,但實際上還是花了我不少時間,主要是在排除靜態資源顯示不出來的問題…,結果發現是域名要寫在環境變數裡,只能說文件要好好看XD
這是 Verdaccio
的服務單位 (Service Unit)
設定檔,假設 Daemon 跑不起來時,可以試著依照錯誤調整 Restart 的參數看看,也可以調整設定檔位置:
1 | [Unit] |
這個是環境變數的設定檔:
1 | [Service] |
記得要在設定檔中開放所有連線,把 localhost
改成 0.0.0.0
:
1 | listen: |
如果有覆寫路徑的需求的話,可以在設定檔裡的 url_prefix
加入覆寫的路徑 (subpath)
:
1 | # if you use nginx with custom path, use this to override links |
我覺得 Verdaccio
蠻好用的,在 GitHub
上面星星數有一萬三千多顆,如果能夠貢獻到的話,老年也可以跟孫子女們話當年(?)。如果想要對開源專案有所貢獻 (contribution) 的話,翻譯文件或是使用者介面算是最平易近人的貢獻方式了,而且這個專案使用的翻譯協作工具也提供蠻好的使用者體驗,所以如果有人想一起加入翻譯這個專案的話,歡迎加入翻譯行列喔!
🍀 神Q超人 - 用 Verdaccio 快速建立專屬的 private npm proxy 並部署到 Heroku 上!
🍀 StackOverFlow - How to yum install NodeJS on Amazon Linux
🍀 GitHub - Working with the NPM Registry
🍀 Medium - Free Private NPM with Verdaccio and AWS
🍀 Verdaccio 官方文件 - Overriding the Public URL
🍀 Verdaccio 翻譯專案
🍀 [Tsung’s Blog - Linux systemd 寫 可自動啟動的 Daemon Service](https://blog.longwin.com.tw/2018/02Linux systemd 寫 可自動啟動的 Daemon Service/linux-systemd-auto-start-daemon-service-2018/)
🍀 How to resolve start limit hit
🍀 使用verdaccio 搭建 私有npm库,使用nginx 代理https域名遇到的一些问题总结
🍀 環境變數使用方式大全
🍀 Verdaccio 官方文件 - Reverse Proxy
🍀 How to set environment variable in systemd service
Open Policy Agent Gatekeeper(a.k.a OPA Gatekeeper)
的起因還是在準備考 CKS(Certified Kubernetes Security Specialist)
這張證照的過程中有看到這個工具。一般來說,在管理 Kubernetes
時如果有想要做部署規範管理,會想到 Kubernetes 原生的 Pod Security Policies(PSP) 。
但是有在關注 Kubernetes
的公告的人,就會發現 PSP
在 Kubernetes
1.21 版本標示為 deprecated
,並且在 Kubernetes
1.25 版本將完全被移除 (fully removed)
,取而代之的是使用 Pod Security Standards (PSS)
。這意味這如果你是使用原生的方式去撰寫這些管理的 Policies
的話,未來會需要花費一番功伕去升級、改寫這些 Policies
,所以就開始研究第三方 (3rd-Party) 的規範管理工具。
建議可以先參照這幾篇文章:
由上而下,理解 OPA
以及 OPA Gatekeeper
的差別,會有比較詳細的背景知識。
在開發服務的時候,我們會需要注意到服務的 驗證(Authentication)
和 授權(Authorization)
這兩套機制要怎麼實作,區別如下:
而 OPA 的概念就是要 把 授權(Authorization)
的概念從服務中獨立出來,讓不同的服務都能夠呼叫同一個 OPA Server
做 授權(Authorization)
這件事,概念圖如下:
比方說 API Server
接收到了一個 Request
,在已經確認這個 Request
是由合法的使用者發出的請求後,API Server
會再發出一個請求到 OPA Server
,確認這個 Request
要做的事情和不合乎規範,若合乎系統規範,回傳成功,反之則回傳失敗。
那 OPA Gatekeeper
又是什麼? OPA Gatekeeper
封裝了 OPA
的程式碼,讓 OPA
可以以 Webhook Server
的方式運作在 Kubernetes
裡面,解決了 Kubernetes
各種部署的審核問題。當然 OPA
本身是可以不需要 Kubernetes
以 Daemon
的方式運行,比較通用的做法是透過程式碼呼叫 library
去實作 Policy
[註:Policy 是用 Rego 語法寫的,來自於一種數據查詢語言 – Datalog],比方說 Golang
有 Rego package
可以載來用。
差別如下,這是 Policy
:
1 | package k8s.labels |
這是 Kubernetes
用的 ConstraintTemplate
:
1 | apiVersion: templates.gatekeeper.sh/v1beta1 |
在經過一番研究之後,目前在 CNCF
生態系中,關於 策略(Policies)
以及 治理(governance)
的工具,大宗分為兩支:
先簡短講一下兩者的差異性好了。沿用上面的 ConstraintTemplate
,同樣規範 Pod
需要帶有特定 label
的情況來看,Kyverno
的寫法不需要額外學習新的語法,並且相容於 Kubernetes
原生的 yaml
撰寫方式:
1 | apiVersion: kyverno.io/v1 |
這張圖是 Kyverno
官方文件上描述的關係圖,非常清楚易懂:
但是最後我還是選擇 OPA Gatekeeper
來研究,網路上的比較文章很多,OPA Gatekeeper
在星星數以及實際的使用人數上也略勝一籌。雖然 Kyverno
簡單易用,Cluster Policy
和沿用它的 Rules
之間的關係也寫得蠻清楚易懂。但正所謂由奢入儉難,學習了 Rego
語法後,未來若有不是部署在 Kubernetes
的服務,也適用於這套部署規範管理工具,而且難保服務變多之後會需要更精細的控制程度。
♞ Kubernetes Pod Security Policy Deprecation: All You Need to Know
♞ Kyverno 介紹
♞ intro-to-gatekeeper-policies
♞ Open Policy Agent - REST API
♞ RBAC and PSP
♞ Differences between OPA and Gatekeeper for Kubernetes Admission Control
♞ Open Policy Agent – 快速導入 Authz 至 Microservice 架構
JavaScript
程式拉部落格程式碼下來,並且使用 hexo generate
指令發布新的文章,然而在耍廢很久之後,我發現發佈文章竟然失效了!這篇文章就這次的 Trouble Shooting
過程紀錄一下,以防下次失效又要再來一次…在我發現推送程式碼並沒有更新部落格後,第一步就是要去 GitLab
的 Webhook
戳戳看之前的 Webhook Server
,看有沒有反應
觀察後發現 response
是 200
,所以 Webhook Server
還沒掛掉,那就有可能是 Webhook
在處理 event
的過程出了問題,所以就這兩個步驟進行測試:
1 | # 拉最新文章 |
發現問題點,hexo
指令失效!
就算解除安裝並重新安裝最新版 hexo
也沒用,反而無法輸入產生文章的指令。
搜尋 “hexo 命令沒有作用” 關鍵字後看到了這幾篇文章:
開始意識到可能是 Node 版本過低,於是查到了這篇文章: 在 2021 可以使用 ESModule 了嗎?,文章裡面指出 Node 10
於 2021 年 EOL(End-of-life)
了。
果然,查詢版本之後發現用了 Node 10,於是乎使用 nvm
這個好用的 Node 版本切換工具下載 Node 12,並切換到該版本。
(2022.3.13 更新)
如果是使用 nvm
作為 Node 版本管理工具的話,要在關閉 terminal 之前把 nvm 的預設值改成當下的版本,否則關閉 terminal 之後會回到舊的 Node 版本
1 | nvm alias default 12.22.5 |
然後 hexo 就又又又可以使用了,可喜可賀!
本次超簡短分享就到這,感謝收看。
♞ Node版本管理之解決版本過高造成Hexo上傳報錯
♞ 快速切换Node版本之版本过高造成Hexo上传报错
♞ 在 2021 可以使用 ESModule 了嗎?
Red Hat
待滿 二年 ,達成以下目標並 畢業:
Red Hat
合作夥伴總計兩百多人的演講,並且報到率超過 90%
,很謝謝兩年來合作夥伴們的協助與力挺!參與 Cloud Native Taiwan User Group
二年又五個月 ,因諸多因素於十月結束合作關係,不過達成了以下成果:
Red Hat
的慷慨贊助,現在 CNTUG 終於有了專屬的 Infra Lab,有興趣的朋友可以聯絡管理員 Gene
,當然也歡迎大家共同投入贊助,畢竟這些設備都會需要人力和金錢維護。義洋
於七月底八月初主持了 CNTUG
在 COSCUP
的議程軌,邀請到翟本喬
擔任開場講者和請他擔任攤位主持人,還有來自北美的邱牛
在攤位連續主持了兩天XD,大家都玩得很開心。這個密集度…
4
場公開演講,其中包含了2
場的海外全英文演講。不過因為我的英文實在是太 poor,左思右想,還是決定用剪輯的方式產出影片:日期 | 主題 | 主辦單位 | 相關連結 |
---|---|---|---|
2021.9.26 | WTM Tech Sharing #2 – Open-Source Contribution Guide: From QA to Architect | Google Developer Groups | 🌎議程 |
2021.9.11 | CNTUG Introduction at OpenInfra Days Asia | OpenInfra Days | 🌎影片 |
2021.7.17 | Integrating Ansible Automation and ChatOps | HKOSCon 2021 | 🌎議程 🌎影片 |
2021.1.10 | PyLadies - Women Techician’s career diversity | PyLadies | 🌎簡報 🌎議程 |
Blog 成果如下圖:
2.26K
次點擊率在 2021 年算是成功建立起了 Red Hat
相關文章的流量了,感動。
2021 年初的時候為了更加深入的研究使用者的點擊活動和活躍的文章,塞了 GA,然後發現有來自歐美的訪客,看來有海外演講經驗還是有差。
陰陽師
累積玩了快要999
天,並且在 2021/3/24
達成角色收集全圖鑑成就
今年 (2022) 開始,我會每年拿去年的展望出來,並且結算是否達標,某方面來說真的是羞恥 Play 。
目標 | 達標與否 | 狀態 |
---|---|---|
日文 N2 通過 | 未達標 | 等待去年 12 月裸考結果出爐,但不樂觀就是了。 |
取得 RHCSA 證照以及至少一張和 OpenShift 有關的證照 | 未達標 | RHCSA 未達標,不過拿到了張 OCP 初階證照。 |
把目前手上有的線上課程都上完 | 未達標 | 線上課程持續增加中。 |
給出至少3 次的社群公開演講 | 達標 | |
體脂肪回到 22 | 未達標 | |
取得 Advanced Open Water 證照 | 未達標 | 等疫情好轉點再完成吧。 |
增加時間管理 的能力,能夠量化每週行程以及完成的事項並提出具體的報告 | 達標 | 克服了三冠王的我,已經沒什麼好說的了XD。 |
利用新買的 iPad 可以看完至少 20 本電子書 | 達標 | 超標四倍,看了快一百本,下圖還不含實體書籍。 |
破口罵人次數 0 次 | 達標 | 人生如斯,多點愛和包容才是長久之道。 |
🌟 日文 N2
通過
🌟 取得一張 CNCF 發行的 Kubernetes
相關證照
🌟 投稿成功一次海外的技術演講
🌟 取得 Advanced Open Water
證照
🌟 每週固定去健身房或固定運動
🌟 繼續刷 LeetCode,目標先刷個 100 題
🌟 父母家人身體健康,其他都好
]]>Ansible Automation Platform 2.0
於今年七月中釋出 Early Access
版本,我之後會寫一篇文章介紹與大家之前比較熟悉的 Ansible Tower
在特性上有什麼差別,有興趣的朋友可以先在新的環境玩玩看,先不要急著升級,因為之後會有更多新功能,也會在之後的文章一併介紹。本篇主要是介紹升級 Ansible Tower 3.8.4
(Ansible Tower
的最後一版) 到 Ansible Automation Platform 2.0
的作法。
之所以會有這篇文章的出現,主要是因為 Ansible Automation Platform 2.0
以及之後的版本對於 RHEL
作業系統和 Ansible-core
的版本都會有一些限制,所以先寫篇文章記錄一下,之後有朋友想升級也可以當個參考 。
Ansible Tower
升級可以參考 Upgrading an Existing Tower Installation,並且分為以下兩種情況:
(1) 假設您的 Ansible Tower
版本在 3.7 以上基本上可以總結為以下三步驟:
Ansible Tower
壓縮檔並解壓縮Ansible Tower
資料(包含 Templates
, Projects
等設定),備份步驟可以參考 Backing Up and Restoring TowerAnsible Tower
目錄下(2) 假設您的版本在 3.7 以下,則可以參考 Red Hat Ansible Tower Upgrade from 3.5 to 3.8 – when running setup.sh is not enough – or: I have made fire!
最保險的升級建議是升級到目前版本的最新小版本,再升級到下一個中版本,比方說目前版本是 3.7.2
,就建議升級到 3.7.5 (3.7系列的最後一版)
再往上升到 3.8.4
。
老實說 Ansible Tower
本身升級過程沒什麼問題,就是 Ansible-core
的版本問題和 AAP2.0
對 RHEL
的版本限制花了點時間。
先講一下我的升級路徑:
步驟 | Ansible Tower / AAP 版本 | 作業系統版本 | Ansible-core 版本 |
---|---|---|---|
1 | Ansible Tower 3.8.4 | RHEL7 | Ansible core 2.9.X |
2 | Ansible Tower 3.8.4 | RHEL8 | Ansible core 2.9.X |
3 | Ansible Automation Platform 2.0 | RHEL8 | Ansible core 2.11.X |
這邊如果有實驗精神的朋友想要跟我一樣試著退版從 RHEL7 試驗重裝,也可以參考 How to uninstall Ansible Tower,另外附帶一提,安裝 Ansible Tower 會需要用到兩個 package rhel-7-server-extras-rpms
& rhel-server-rhscl-7-rpms
,這兩個 package 都會需要安裝 epel-release
,可參考以下指令:
1 | rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm |
如果安裝時跑出一堆奇怪的 ansible playbook 語法錯誤,請參照上面表格中的 Ansible-core 版本
安裝對應的版本。使用錯誤的 Ansible-core
版本會連安裝腳本都跑不起來,pip
安裝指令如下:
1 | # Ansible Tower 3.8.4 |
這邊我的做法是:
RHEL7
上面的 Ansible Tower
備份起來RHEL8
這台主機的 Ansible Tower 3.8.4
資料夾底下RHEL8
這台主機的 Ansible Tower 3.8.4
資料夾底下跑還原命令就可以看到安裝好的 Ansible Tower 3.8.4
,裡面所有在 RHEL7
這台機器上的 Ansible Tower
設定好的 templates
都完好如初。
接下來照著我上述所提的安裝步驟,在 RHEL8
這台機器上下載 AAP2.0
安裝檔,使用跑 ./setup.sh
的方式安裝到 AAP2.0
,這邊連資料庫都不用備份還原。
可能會有朋友疑問:AAP2.0
限制一定要安裝在 RHEL8
上面嗎?
因為 Ansible Playbook
執行環境在 AAP2.0
上預設都是用容器去跑,原因會在之後的介紹文分享,總之這個環境要能夠透過 podman
指令去拉 Red Hat images
,更多的安裝條件可以參考這份安裝指南: Ansible Automation Platform 2.0 ea Installation Guide。
直接透過安裝的方式升級為 AAP2.0
會遇到第一個問題,就是 TLS
證書要重簽,不然打開瀏覽器會看到以下畫面:

使用 OpenSSL 自建 CA,然後簽發憑證,我是參考 [Centos7] SSL自簽憑證+APACHE+Selinux 重新複習如何在地端環境自簽憑證的,
在 Mac OS 的Chrome 瀏覽器還是不允許自簽憑證,所以會看到這個 error: NET::ERR_CERT_INVALID
,如果是要長期使用的環境,會建議把憑證匯進瀏覽器的 憑證管理小精靈
,允許這個憑證,詳情請參考我之前寫過的 vcenter 上傳失敗解法。
但是這邊因為我太懶了只想快點看到畫面,所以我參考了這篇 No “Proceed Anyway” option on NET::ERR_CERT_INVALID in Chrome on MacOS ,解決方式如下:
1 | * Right click, select inspect element |

讚啦!直接可以看到跟 Ansible Tower 3.8.4
一樣的 Templates
,連資料庫 restore
都不用做,因為資料庫的欄位和結構都是一樣的。
今天的分享就到這裡,感謝收看。
♞ Automation Controller
♞ How to uninstall Ansible Tower
♞ Ansible Automation Platform 2.0 ea Installation Guide
♞ Red Hat Ansible Tower Upgrade from 3.5 to 3.8 – when running setup.sh is not enough – or: I have made fire!
♞ Upgrading an Existing Tower Installation
♞ Backing Up and Restoring Tower
♞ Centos7 SSL自簽憑證+APACHE+Selinux
♞ vcenter 上傳失敗解法
♞ No “Proceed Anyway” option on NET::ERR_CERT_INVALID in Chrome on MacOS
trouble shooting
的過程以及反思。另外也會附上安裝好之後要部署 Internal Registry
的做法,在 OpenShift 要使用 s2i
或是自動構建容器映像檔,都會需要 Internal Registry
,身為 OpenShift 管理員是一定要裝這個的。
OpenShift 4.8.13
這張圖是我從 Red Hat OpenShift Installation Guide 拷貝下來的,可以看到前置作業都做好了之後,安裝流程會從 Bootstrap 機(點火機)開始、Controller Nodes (別稱 Master 節點)安裝、Computer Nodes (別稱 Worker 節點)安裝完畢。
基本上我在做建置規劃的時候,會參考 Red Hat 官方文件 - Installing a user-provisioned cluster on bare metal 做資源的規劃。如果環境不一樣,比方說使用公有雲、或是有地端虛擬化的環境也沒關係,看 Bare Metal 文件就是標竿,使用 User Provision Installation 在任何環境都可以裝起來,只是手動的部分有點小麻煩。
在 Minimum Resource Requirements 這個小節可以看到 OpenShift 最低需要配置的數量:
可以看到這張表格微妙的沒有寫出節點數量,這是因為我們除了安裝之外還需要考慮後續的擴展能力,經過測試,如果是在 master nodes 4 vCPU / 16 GB 的條件下,在 OpenShift 4.8.13 版本下可以同時啟動兩個 worker nodes,如果是三台 worker nodes,會在 worker nodes 安裝過程發現有些 cluster operators 永遠起不來。
這是因為 OpenShift 在安裝過程中非常吃 master nodes 的 CPU 運算資源,如果使用 ssh 指令觀察,會發現 master 的 kubernetes-api 有非常多的溝通紀錄。安裝過後 CPU 的資源就會緩和下來,不會再維持這麼高的消耗率。
那如果 CPU 不夠用怎麼辦,是不是安裝會比較慢? 一般來說,CPU 資源不夠常見結果就是效能變差,但是現在是在安裝的過程,所以有可能 worker 節點呼叫 master節點的 API 叫不到,有些重要的元件就安裝不起來,安裝過程就有可能失敗。
所以最保險的做法是,把 master 節點的資源規劃的充裕一點,比方說 8 vCPU / 16 GB memory 。
安裝完成可以透過 oc get nodes
以及 oc get co
兩條指令確認是否安裝完畢。
1 | [root@bastion install-dir]# oc get nodes |
像前一章提到的 master nodes 資源不足的情況,在下 oc get co
命令之後,會發現有部分的 cluster operators
的 AVAILABLE
狀態是呈現 False
的狀態。
另外分享兩個官方寫的 trouble shooting 文件給大家,在安裝過程中可能會需要針對節點和容器進行除錯,建議把這兩份文件列出來的指令複製貼上到自己整理的 hackmd 或是文字筆記本上,就不用一次記那麼多的指令了:
安裝完成之後,我們會需要試著部署容器測試這座 OpenShift 叢集是否可用
通常我會透過 Developer Console
的 Developer Catalog
頁面部署 Red Hat 提供的模板做確認。
如前言所述,因為 Internal Registry
部署沒有成功,所以也無法透過 s2i 的方式部署模板,啟動 pod
的時候會顯示如下錯誤訊息:
根據某個 Red Hat 的某個 ticket 敘述(我忘記在哪邊看到@@),openshift SDN 啟動的過程如果有 restart 的情況發生,會影響 registry 的啟動,所以我們先找出有 restart 紀錄的 pods:
1 | oc get pods -n openshift-sdn |
然後把有 restart 紀錄的 pods 全砍了,放心的砍沒關係,反正 pods 會重啟:
1 | [root@bastion install-dir]# oc get pods -n openshift-sdn |
砍完之後依照建置叢集的類別,選擇其中一種方式更新 image registry 的設定:
1 | oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}' |
1 | oc patch config.imageregistry.operator.openshift.io/cluster --type=merge -p '{"spec":{"rolloutStrategy":"Recreate","replicas":1}}' |
成功部署的話,在 openshift-image-registry
project 會有image-registry-xxxx
pod 存在:
OpenShift 安裝過程有點漫長,在安裝快要結束時,下達 oc get csr
命令可以看到這些 CSRs
,接著我們可以透過 oc get csr -o name | xargs oc adm certificate approve
去 approve 這些 CSRs。
Day-2 維運時,部分 Cluster Operators
在更新後也會產生 CSRs,這時候我們可以參考這個 repo建立 batch
,這個 batch
文件可以透過每一個小時執行一次上面所講的 approve
命令自動 approve CSRs,不然的話,有可能會出現 Pending
狀態而無法完成叢集更新:
1 | [root@bastion install-dir]# oc get csr |
以上是本次的分享。
♞ Red Hat OpenShift Installation Guide
♞ Installing a user-provisioned cluster on bare metal
♞ [Recommended host practices] (https://docs.openshift.com/container-platform/4.8/scalability_and_performance/recommended-host-practices.html)
♞ Troubleshooting installations
♞ Investigating pod issues
♞ Configuring the registry for vSphere
♞ vchintal/ocp4-auto-approve-csr
前兩篇主要是以 PaaS 的角度談收集 Metrics 的方法,本篇會細分到開發面,使用一個實例去示範如何透過 OpenShift 的 Dashboard 查看 Metrics
(指標)。
🌿 OpenShift 4.7
🌿 Prometheus Operator: 0.44.1
🌿 Thanos: 0.17.2.
🌿 Postman v8.2.1
🌿 Grok Exporter 1.0.0.RC5
此篇文會出現是因為我在 Developer Dashboard
下的 Custom Query
。
這個功能適合一個場景:假若我今天是一個開發者,而我只是想要在 OpenShift 部署 AP 觀察我程式的 API 呼叫次數、HTTP responses 次數(比方說 response 是 200 的次數),不想管那啥 Prometheus Server 建置問題的話,就可以使用這個功能!
如下示意圖所示,可以看到 Custom Query 是以 Projects 為單位(對應到 Kubernetes 的 namespace)。
雖然說我們可以 Don’t give 建置 a shit,但還是要知道該怎麼設定,在 Kubernetes 或 OpenShift 這樣的容器平台上,通常會使用 Operator 進行建置,OpenShift 本身的 Prometheus 亦如是,Prometheus 這個專案自己也有 Operator,讓 Operator 去煩惱 Prometheus 從建置到死而復生的生命週期。
Prometheus 的設計就是讓 Service Monitor
去監控 Kuberbetes Service 的 port,使用這個 port 回傳的 metrics 就會被收在 Prometheus Server 。
這個步驟也可以直接參考官方文件
首先請 OpenShift 管理者(亦即擁有 cluster-admin
role 的帳號)apply 以下 ConfigMap,這個動作是讓 OpenShift 上的 Prometheus 可以監管非 OpenShift 本身的 project。
註:OpenShift 4.7 版如果要使用 Custom Query 的話必須把先前安裝(不管什麼形式)、 非 OpenShift 內建的 Custom Prometheus Instances 拿掉。
1 | apiVersion: v1 |
1 | apiVersion: v1 |
除了把這個 ConfigMap 部署在 openshift-monitoring
之外,也可以選擇另外一種方式:修改在 openshift-user-workload-monitoring
這個 project 底下的 user-workload-monitoring-config
這個 ConfigMap,兩者效果一樣。
接下來可以用指令檢查結果
1 | oc -n openshift-user-workload-monitoring get pod |
建立 role binding,讓該使用者可以使用 OpenShift monitoring 監控自己的 Project,需要加入 monitoring-rules-view
、monitoring-rules-edit
以及 monitoring-edit
這三個權限。
1 | # oc policy add-role-to-user <role> <user> -n <namespace> |
另外再針對該名使用者加入可以在 openshift-user-workload-monitoring
修改 monitoring config 的權限。
1 | # oc -n openshift-user-workload-monitoring adm policy add-role-to-user user-workload-monitoring-config-edit <user> --role-namespace openshift-user-workload-monitoring |
首先部署 Red Hat 官方網站範例程式碼
1 | cat > prometheus-example-app.yaml |
部署完後可以透過 Developer Tab 或者是指令看到以下畫面
1 | oc get routes -n ns1 |
可以看到這支 AP 收集了兩條 metrics,待會在 Dashboard 上我們會用到
1 | http_requests_total{code="200",method="get"} |
接下來部署 ServiceMonitor
,讓 OpenShift 自帶的 promentheus server 能夠收集 metrics
1 | cat > example-app-service-monitor.yaml |
部署完後回到 Developer Dashboard > Monitoring > Metrics > 下拉式選單選 Custom Query
輸入剛剛看到那兩條 metrics 其中之一
看到 metrics 了!在這邊可以看到有 Service Name
、Pod Name
等資訊。
如果需要類似 API Manager 常常附帶的監控功能或是覺得另外買監控軟體太貴,可以使用 Custom Query 的功能,還可以針對想要看的數值寫 metrics 來收就好,彈性程度比較高。
有需要的人可以參照 Prometheus 官方文件 來學習 Metrics 的寫法,如果覺得 Prometheus Dashboard 呈現太陽春,甚至可以拉 Grafana Dashboard 做成如下圖漂亮的圖表。
🌟 Monitoring Quarkus apps using Micrometer and Prometheus into OpenShift
🌟 Monitoring your own workloads in the Developer Console in OpenShift Container Platform 4.6
🌟 Prometheus Operator
🌟 Enabling monitoring for user-defined projects on OpenShift 4.7
🌟 Manage Metrics on OpenShift with example codes
🌟 Prometheus Metrics Type
思來想去,工作時程又很趕,還是使用熟悉的
於是我花了一小時寫完 Ansible Module 並測試,然後花了兩小時半在查如何把這個 Module 弄成 Ansible Galaxy 看得懂的格式並且讓 Playbook 可以引用這個 Module。
如何貢獻的文件真的太分散了 XD
所以就有這篇整理文的誕生,順便簡單介紹一下 Ansible 的元件們,畢竟我也常常搞混…
這篇文章不會介紹 Ansible 是什麼、怎麼使用和撰寫 Ansible Playbook,本篇文章會專注於 Playbook 裡面可以重複使用的是哪些元件,以及這些元件的差異性。
專人介紹可以看這支影片,裡面有個列表很清楚地解釋了兩者的差異:
白話文翻譯就是:
假設今天我請了一位水電工,他會執行馬桶維修這個工作 (Playbook),那他可能會帶很多工具箱 (Modules) 來我家,然後執行以下修馬桶的步驟 (tasks):
1 | 1. 更換水管 - 呼叫解開、鎖緊水管模組,輸入水管長度參數 |
Modules 的開發成員來自世界各地,有以企業為單位,為了將 Ansible 整合自家產品會開發出可以直接呼叫產品功能的 Ansible Modules。也有熱心的自由開發者提供好用的模組,只是維護的持續性和穩定性可能就不太能保障。
比方說今天你想請他每執行完成一個步驟,就跟你回報一次,你可能就會在設定檔輸入 echo_when_every_task_done=yes 這樣的變數設定。而 plugins 的開發者大部分會是 Ansible 核心開發團隊,這些 Plugins 主要是針對 Ansible 本身的功能呈現而開發的。
既然 Modules 和 Plugins 都可以自己撰寫並重複利用,那 Playbooks 可不可以重複利用呢?
當然可以!
Ansible 的中心思想就是鼓勵使用 Ansible 的開發者在撰寫完 playbooks 或是 Module 都可以分享出來,讓其他有需要的開發者能夠使用、甚至是改成自己需要的版本!所以我們會很常聽到 Ansible 可以重複利用其他人寫好的 薪水海賊王。
本篇文章秉持著站在巨人肩膀上的精神,不會介紹
首先讓我們先來看看這篇
可以看到文章中表示
1 | Ansible Content Collections, or collections, represent the new standard of distributing, maintaining and consuming automation. By combining multiple types of Ansible content (playbooks, roles, modules, and plugins), flexibility and scalability are greatly improved. |
換句話說, Ansible 官方在 2019 年 11 月推出了 Ansible Content Collections(A.K.A. Collections),以後不管開發 playbook / roles / modules / plugins 都可以透過包裝成 collections 的方式上傳到 Ansible Galaxy 讓其他人下載。
OK,到這邊算是對接下來的會遇到名詞有個基本的認知了,首先先利用 ansible-galaxy
1 | ansible-galaxy collection init ${my_namespace}.${my_collection} |
my_namespace:你想拿來解釋這個 collection 最主要會拿來對應什麼組織、產品之下。假設今天我開發的是 Slack 相關的 Collection,namespace 就會取名一個跟 Slack 相關的名稱,這樣其他人要找你的 collection 也比較好找。
my_collection: 這個 collection 大致上的功能,假設這個 Collection 是做 Slack Bot 的發送連結、文字等功能,我可能會取一個 slack_chat
這樣的名字,功能一目了然。
🔼 使用指令創建好框架之後,透過 tree
檢視資料夾的結構,可以發現有以下幾個子資料夾:
然後可以再回到剛剛的
1 | docs/: local documentation for the collection |
這邊會用我最近寫的 line_notify
備註:這個 namespace
完全是錯誤示範XD
主體是 line_notify.py
這支檔案,用 Python 開發 Ansible Modules 需要使用
開發完之後就要準備把專案打包上傳到 Ansible Galaxy:
1 | # 進到 Collection 的根目錄 |
最省力的方式就是把 galaxy.yml
裡面跟這個專案有關的資訊都寫一寫,其他都不多弄也沒關係,之後再補上。
Import Role from GitHub
vs Upload New Collection
因為我寫的不是 Role , Role 更複雜而且要補的資訊更多,所以我選擇簡單上傳壓縮檔的方式(Upload New Collection)
上傳剛剛打包好的壓縮檔 (*.tar.gz)
檢視上傳結果,可以看到成功或失敗、失敗原因
大功告成啦!使用方法可以參照
Ansible 除了本身是個蠻不錯用的自動化腳本引擎之外,在撰寫 playbook 的時候也可以思索以下幾個問題:
1 | 1. 當一支 playbook 要做的功能太多的時候,是否可以拆成多支 Playbook 並且透過呼叫的方式完成工作(e.g. 使用別人寫好的 Roles) |
針對以上問題,每個人的應對作法可能都不太一樣,但是我想介紹一個省時又省力的工具 - 超棒der 🌟Ansible Tower🌟 !
Ansible Tower 是一個集中式 Playbooks 管理工具,有簡單的視覺化 Dashboard 可以看得到執行腳本成功失敗的統計結果、詳細的執行資訊。如果控制的節點數在 10
個以下的話 (以 IP 為計算單位),是可以免費使用的!
這篇文章會介紹的是 Ansible Tower 其中一項非常好用的功能 - ✨ Workflow✨
Workflow 運作示意圖如下,這支 Workflow 的應用情境是在 Azure 上面進行 Windows Server Provision & Deploy IIS Web Server。如果把這些流程都寫在一支 Playbook 裡面,這支 Playbook 會變得非常冗長且難以維護;假設再加上 error handling 的 tasks 的話,會變得更悲劇,因為還要去測試錯誤發生時執行的程式邏輯是不是對的。
所以在這個應用情境中我拆成三支 Playbooks 完成這個情境:
1 | 1. 於 Azure 上創建 Windows Server 2019 Data Center instance |
這邊解釋一下 Workflow 三種顏色代表的意義:
1 | 藍色的線:一定會執行的 Playbook <br> |
有興趣的讀者可以
介紹完 Workflow 和情境之後,重點就是要怎麼讓 Ansible Tower 的 Ansible Engine 會自動下載你指定的模組呢?一樣這邊拿出範例解釋:
requirements.yml
長得就像這樣,把 ${namespace}.${collection}
條列好:
然後透過指定 collections 的方式,就可以使用剛剛寫好的 modules 了,相當方便。
我自己是使用 GitHub 做 Ansible Playbooks 的專案管理,在 Ansible Tower 上可以透過 Project 的方式做到同步 Playbook:
使用 Templates 就可以使用 line_notify_playbook
,而因為我有在 requirements
以及 playbook
裡面指定我要下載和使用的 module,所以在第一次執行時,Ansible Tower 會直接從 Ansible Galaxy 下載需要的 Collections。
Playbook 執行結果,理想上寫法是要抓 credentials
,但我還在想怎麼寫 XD
可以實際在 LINE 上面收到訊息
打完收工,有興趣的人歡迎追蹤專案進度或直接送 PR 🙈
🔥 Ansible Tower Notification
🔥 LINE Notify Document
🔥 How Ansible Works
🔥 Ansible Modules
🔥 Ansible Plugins
🔥 Practical Ansible Solutions: Modules and Plugins|packtpub.com
🔥 凍仁翔 - 現代 IT 人一定要知道的 Ansible 自動化組態技巧 - 20. Roles 是什麼?
🔥 凍仁翔 - 現代 IT 人一定要知道的 Ansible 自動化組態技巧 - 21. 怎麼使用 Roles?
🔥 Getting Started With Ansible Content Collections
🔥 Ansible Reference: Module Utilities
🔥 Writing Ansible Modules in Bash
🔥 ansible-for-rubyists
🔥 Ansible Tower
🍁 API
Service 透過 Webform
等等的框架包起來,呼叫 API 等等的行為都是透過 GUI 手動操作
🍁 程式是由第三方開發,對於 API 規格並不清楚
🍁 你需要收集 API 相關資訊,並彙整到視覺化的工具上,比方說固定時間內的 API 呼叫次數、API 的回應延遲時間
最近因為本人因需求要在不改動程式的情況下,收集 API 的呼叫資訊。
在一番寒徹骨的研究之下,發現透過應用的工具呼叫系統 API 時,會有 API 名稱,只是一般來說 API 名稱會設計在 URL segments
上面,而這個應用是把 API 名稱包在 Webform 的 POST data
裡面。
如果對 RESTful API
有興趣的人,我非常推薦參考 Learn REST: A RESTful Tutorial,這篇文章用簡單陳述 RESTful API 的設計要點,讓讀者知道設計 REST API 的標準和方法。文章中也有點出好的/比較不好的 API 設計範例,比方說:
1 | # 在 URL 使用標識符(identifiers)而不是使用查詢字串(query string)去要求資源。使用 URL 查詢字符串當參數非常適合過濾要查詢的資源/資料,但不適合當作資源名稱。 |
Google Chrome 有 Inspector
可以觀察呼叫 API 所發出的 Request & Response,我就是用 Inspector 把 API 的 Request 錄下來,並且使用 Postman
這個 API 開發超好用的神器進行測試。
⬆️ Google Chrome Inspector 示意圖
設計完 REST API,如果需要寫 API 文件或者是進行測試,也非常推薦使用 Swagger UI。不僅可以讓 API 更容易被不是開發者的人了解和使用,如果團隊有新成員加入,一份好的 API 文件可以加速新成員上手的速度。
環境:
🌿 OpenShift 4.7
🌿 Prometheus Operator: 0.44.1
🌿 Thanos: 0.17.2.
🌿 Postman v8.2.1
🌿 Grok Exporter 1.0.0.RC5
這個應用是用 Apache 提供 Web Service 的,查看設定檔之後,發現可以通過解析 access_log
的方式,比方說透過 tail
指令可以看到每一個 request 的細節。
1 | tail -100 /etc/httpd/logs/access_log |
比較特別的是 webform 裡面所有的 request 都會透過 Apache 來處理,所以光是看 access log 就可以知道程式還會根據 Post data 對應的 API Name 再對 Apache 做一次 request,所以光是統計一段時間內有多少條相同 API Name 的紀錄,就可以知道這隻 API 被呼叫多少次。
要如何解析 access_log 呢?可以看看 /etc/httpd/conf/httpd.conf
,Apache 的設定檔裡面有沒有這個模組 mod_log_config
先在 httpd.conf
設定檔內加入設定(或移除註解)
1 | LoadModule log_config_module modules/mod_log_config.so |
可以看到底下會有預設的 log_config_module 設定檔案
1 | LogLevel warn |
可以根據需要拿的資訊做改寫,比方說這個設定:
1 | LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined |
出來的 log 結果就會長這樣:
1 | source IP - admin [01/Aug/2016:19:23:45 +0800] "GET / HTTP/1.1" 401 670 "http://xxx.com/" "Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1" |
知道如何格式化 Apache log 之後就要思考如何把這些 Log 變成 Prometheus Server 看得懂的 Log,這邊我們就要會使用到 exporter
這種專門轉換 log 的工具。
在 Prometheus 官方的列表 中可以看到有各種第三方或是原廠開發的 exporter,可自行參考取用。
因為要轉換的是 Apache 的 log,所以我們會使用到 grok exporter
,架構大致如下圖:
因為我是用 OpenShift
進行應用程式的部署,grok exporter 也要部署於 OpenShift 上,這邊就要思考如何讓 Apache 可以和 grok exporter 寫入和讀取到同一份 access_log,順序如下:
K8s Deployment
& K8s Service
Service Monitor
作為 target,讓 Prometheus Server 可以週期性(15s ~ 30s)的拉 Metrics這邊當然可以用 PV/PVC 的方式 Volume,但本人光陰有限,火燒屁股,所以決定把塞咖(sidecar)模式搬出來用,所以 access_log 的部分就先用 local path 的方式連動,K8s deployment
大致上會長這個樣子:
1 | volumes: |
上面做法是把 grok exporter 的設定檔案拉出來變成 configMap,不然每次測試都要進到 terminal 去改,不如重新部署後 rollout 最快,設定檔大致上如下:
1 | kind: ConfigMap |
K8s Service
這邊不贅述,最後一個是 Service Monitor
,因為我是用在同個 OpenShift Project 下部署 Prometheus Operator 的方式處理,所以透過同個 Operator 部署以下 Service Monitor CR 的方式可以對同個 Prometheus Server 新增 Prometheus target。
1 | apiVersion: monitoring.coreos.com/v1 |
到 Prometheus 的 Dashboard 上查看,有起來就可以 query 看看,拍謝這邊找不到當初的原圖,隨意放個示意圖讓大家看看。
然後 query 一下剛剛定義的 Metrics apache_http_response_codes_total
在 Dashboard 有沒有數值進來,有的話就成功了。
Special Thanks
特別超感謝同事
🌟 API 到底是什麼? 用白話文帶你認識
🌟 Getting started with the REST API
🌟 Learn REST: A RESTful Tutorial
🌟 Swagger UI
🌟 Apache Server 相關設定
🌟 Apache Module mod_log_config
🌟 Prometheus - EXPORTERS AND INTEGRATIONS
🌟 How to use grok exporter to create prometheus metrics from unstructured logs
本系列要談的主題會偏向
🌼 OpenShift Prometheus 的 3 種部署模式
🌼 用 Sidecar Container 收 Apache 的 Log
🌼 自己寫 Prometheus Metrics 收 Prometheus Metrics
而今天會介紹第一個主題 -
環境:
🌿 OpenShift 4.7
🌿 Prometheus Operator: 0.44.1
🌿 Thanos: 0.17.2.
OpenShift 原生已經自帶 Metrics
這個 Tab,打開就可以看到 Prometheus Metrics Dashboard
OpenShift Cluster 本身的 Metrics 都會 Prometheus Operator
部署的 Prometheus Server
收走,架構圖如下:
可以看到圖中的 Thanos Querier
元件會負責查詢所有節點的 Metrics,並負責將重複的 Metrics 透過 Deduplicate
& Merge
的功能認出散落在不同的 Prometheus 上 Label 相同的 Metrics,並且把重複的 Metrics 去掉之後,顯示在 Dashboard 上面,其中的原理可以參考底下來自
OpenShift 所有關於 Metrics 的元件都可以在
針對 OpenShift 上自行開發的 Pods 主要有 3 種部署 Prometheus 的模式可以收 Metrics:
模式 | 說明 | 適用場域 | 圖解 |
---|---|---|---|
撰寫 Customize Query Metrics,並且於 Developer > Metrics > Custom Query 在目標服務( target CR | 開發者會自行撰寫 Prometheus Metrics / 熟知 Prometheus Metrics Exporter 建置方法、收集 Metrics / 會寫 Sidecar 收穫 Metrics | ||
部署 Customize Prometheus Operator 透過部署 Prometheus Operator 的方式把不同 Project 或是不同 service 的 targets 透過不同的 Prometheus Server 管理。 | 比較大規模的組織,特別是需要各部門針對自己的應用收集 Metrics 的情況,建立獨立部署 Prometheus Operator ,但是要注意資源的使用量以及建置文件的配置。 | ||
部署 Prometheus Prometheus Server 獨立於 OpenShift Cluster 之外。 | 資源較為不足 / 對於監控的 Metrics 有保存的需求,需要特別獨立出來做管理的組織。 |
這三種模式,我都各自附上了建置的參考文件,有興趣動手實作的人可以自行建置,下面提到的範例程式以及操作僅限於 Custom Query
以及 Custom Prometheus Operator
這兩種模式。
🌟 Understanding the monitoring stack
🌟 Coscup 分享 - HA Prometheus Solution Thanos
🌟 GitHub - Thanos
🌟 利用 Grafana Operator 部署 Grafana 到 OpenShift,並建立客製化的 Dashboard。
🌟 集群外独立部署Prometheus+Grafana监控K8S全面解析
🌟 OpenShift 4.3 之 Quarkus(3)用独立的Prometheus监控Quarkus应用
🌟 Kubernetes Operations and Maintenance Using Prometheus Overall Monitoring K8S
🌟 FIRST STEPS WITH PROMETHEUS
2020年初曾經試過在 Mac 上面直接跑 Podman,可惜那時還沒有找到足夠的教學資料引導,就放棄了在我的 Mac 上使用 Podman 做打包,最近因為要回學校講課,就找了一找,沒想到還真的被我找到這篇文章:在 macOS 中使用 Podman,但文章內容有些指令的部分需要勘誤,索性寫一篇來紀錄過程。
差異的部分其實已經有許多人寫過相關的文章了,我這邊重新整理一下幾個重點:
圖源來自:Avengers of Container World - Episode 1: Podman Hands-On
最主要的差異在於 Podman 並不是透過 daemon 服務的方式去跟 kernel 溝通,當初 Docker 設計這個架構是基於傳統的 client/server 架構,Docker daemon 會負責控制所有 child process,所以當這個 Docker daemon 一死,底下的 child process,也就是那些容器,會全部掛掉。
有關於 Rootless Container 的概念,Red Hat 的 Principal Product Manager - Containers -Scott McCarty
有給出一篇 understanding-root-inside-and-outside-container解釋為何 Rootless Container 對企業的環境來說至關重要。
主要也是因為沒有統一的 Daemon 去創建 contianer process(不是用 root
在 linux
創建檔案等使用上會有限制),所以使用 podman 在創建 container 時可以自由使用不同 uid
& gid
去管理這個 container process。
Docker 可以做到的事情,podman 都可以做到。所以乾脆有使用者直接 alias podman='docker'
也不意外(笑) 。但有一點是,podman 可以跑 pods:
意味著我可以一次在 pod 裡面運行N個容器,並且也可以透過 podman 管理!
很遺憾的是,現在在非 Linux 的平台上面,Podman 還是要透過 Client 連進虛擬機的方式管理容器。
Podman 和 Docker 在 Linux 上都利用了 Linux Kernel 原生支援的容器方式實現資源和環境的隔離。然而在 MacOS 和 Windows 的環境下,在最初我們仍需要先行安裝 VirtualBox 或是 Vagrant 才能開啟虛擬機(比方說 ubuntu, centos),並且在上面運行容器,在 Windows 環境下還要先開啟 Hyper-V,實際的操作方法可以參考 浦島太郎的水族缸 - WSL, Docker, Virtual Box on Hyper-V。
但後來 Docker 改採用輕量的虛擬化框架 HyperKit 改善在 MacOS 上運行容器的效能,而在 Windows 上,始於 Windows 1809 版開始支援容器 以 Process 隔離模式 的方式啟動來改善效能,或是可以參照這篇 How to install Docker on Windows 10 or 7 without Hyper-V 用 Docker Toolbox 來運行容器。
而 Podman 在工具的發展完整度和對兩大平台整合度目前來講還不及 Docker 完備,但在 Mac 上我們可以使用 HyperKit、在 Windows 上面我們也可以善用 WSL 建立虛擬機 來使用,或者你也可以在 MacOS 上用 Paralles 開 Windows 虛擬機體驗巢狀虛擬化(X。
這篇文章主要參考來自掘金繁體版 - 在 macOS 中使用 Podman,我會直接安裝 multipass
使用 MacOS 的 Hyperkit 去幫我建立一個 ubuntu
VM。
Podman Client
1 | brew install --cask podman |
multipass
1 | brew install --cask multipass |
Ubuntu
VM1 | # 這邊建議是 disk 給到 20GB, memory 給到至少3G,否則你會發現容器根本跑不起來 |
1 | ubuntu@podman:~$ . /etc/os-release |
1 | # 查看 podman.socket 檔案是否處於監聽(listening)狀態 |
~/.ssh/id_rsa.pub
加進去 VM 的 /root/.ssh/authorized_keys
裡,讓 podman client 可以透過 ssh 的方式連到 VM 的 socket1 | # 加完之後,新增遠端連線 |
1 | # 登入 DockerHub |
podman client for Windows
podman.exe
cmd.exe 用 podman.exe <command>
powershell 用 ./podman.exe <command>
1 | PS C:\Users\hazel\Downloads> Get-Command ssh |
authorized_keys
就可以用了。本篇記錄一下 vcenter 卡在無法信任的簽核機構的瀏覽器憑證問題。
平常進到 vCenter 都可以靠著 advanced
大絕直接進到 Dashboard
但是當要上傳映像檔的時候就沒辦法用這招了,會直接上傳失敗
查 KB 之後發現解法是要下載 vCenter 自簽憑證
用 wget
命令將憑證壓縮檔下載、解壓縮之後會發現有三種憑證:
因為我的環境是 mac ,於是:
不改的話,瀏覽器證書管理小精靈不知道那是憑證
開啟 Chrome 的憑證管理小精靈:
Settings > 直接在搜尋欄打上 certificate
> 發現該欄位在 Security -> Advanced -> Manage certificates 裡
上傳剛剛改好的 XXXX.cer
會發現簽發這個憑證的機構不受信任,
連 Advanced
大法都沒用
莫急莫慌莫緊張
此時點選證書右鍵
選擇 Get Info
,就會看到以下畫面
然後把那該死的 Trust
Tab 展開來,把 Never Trust
改成 Always Trust
然後關掉,重整你的瀏覽器,就會發現可以上傳了。
可喜可賀。
我在上傳完文章後發現我前四天在 DISQUZ
設定的 Reactions
居然生效了
但好像只有新的文章才會有XD,這什麼神秘的部署機制…
如果有在看我部落格的人可以點點給我一個心得唷!
謝謝您 :D
本篇純屬個人於 2020 年做過的紀錄以及對於未來的展望。
Red Hat
待滿一年:接觸許多從來沒有做過的事,比方說 -
真的非常感謝同事們的各種帶領以及耐心
參加 SRE 讀書會 ROUND 4
,入門了 Linux 運作原理並且講了 4 場讀書會,涵蓋以下主題:
參與 Cloud Native Taiwan User Group
一年半,並且做了以下事情:
Red Hat
& 莎小姐
的慷慨贊助,於年末與夥伴們有一場史上最 今年的訂閱人數總共有 383
位,總觀看次數共有五千多次
今年共有 701
次點擊率
可以看到老東家帶來的影響力還是很可觀XD
5
次之後,考到汽車駕照
1
次,還直接結婚,但只能遠端當證婚人有點遺憾莎小姐
跑去高雄拍了網美照,還嘗試拍泳裝照
,只能說在好的相機和軟體底下效果真的蠻不錯的莎小姐
去墾丁潛水 2
次,總共接近 10
支氣瓶數,還認識非常專業又有耐心的 教練 蝦蝦
莎小姐
以及 Red Hat
的贊助,讓我有機會嘗試專業的韓系沙龍照
,效果真的美炸陰陽師
累積玩了快要兩年自給自足
的租屋生活,並且把家裡打造成辦公室環境長瀏海
,並且發現過渡期可以用燙瀏海
的方式度過55
公斤,那是高一才有的體重IPad 8
和那枝筆,希望可以利用時間看更多的書籍N2
通過RHCSA
證照以及至少一張和 OpenShift
有關的證照3
次的社群公開演講22
Advanced Open Water
證照時間管理
的能力,能夠量化每週行程以及完成的事項並提出具體的報告
20
本電子書0
次我被這個問題困擾了一週,身為外接式鍵盤愛好者,第一次遇到換掉轉接頭會導致鍵盤符號錯亂的問題
按下原本的@按鍵會出現“,其他的符號也都錯亂、甚至連vim都爛掉沒辦法移動游標
在各種 Google 查詢未果的情況下,我突然想到還有一招
照著調整精靈的指示一步一步調整鍵盤
設定字符編碼為 ANSI
結束設定
鍵盤就回來惹!!!!撒花 ~
這邊要注意的是如果有開 terminal 也要把 terminal 關掉重開才會生效。
]]>在某天休息時間滑手機找關鍵字時看到關鍵評論 - 《找回愛與尊重的自尊課》:練習「駁斥」,鬆動以別人觀點看待自己的舊模式 - 蘇絢慧 的這篇文章,看了不到一半就覺得心裡的盒子好像被打開了一般,於是乎便直奔博客來買了這本書的電子版,方便我在閒暇之餘把這本書嗑完。
書中環繞著一個主題:自尊。
從開頭的評量表可以看出在低自尊到高自尊的光譜中,自己位於哪個區間,很開心我自己還在中高自尊XD。
“有時候,我們之所以會毫不考慮就接受外界的負面評價,是因為我們心中早就這樣看待自己、認定自己。所以當別人這樣評論自己時,我們的心就墜落到谷底,
覺得被別人看出來了:「沒錯,我就是那麼差的人」。”
作者蘇絢慧心理師這句話算是點出了我長期納悶的一個點,就是為什麼來自外界的負評會那麼容易影響一個人的心情,即使我這麼冥頑不靈的人,也會因為聽到某些評價、甚至是別人的反應,而影響到自己的心情。
從小到大我們參與各種比賽、參加各種考試,我們早已習慣透過這些外界的標準來界定自己的價值所在。如果今天不是第一名,就沒有價值了嗎?
作者提醒我們要培養「駁斥」的能力,並且要對於自己有所了解,當外界的評價開始撻伐你內心的一方土地時,要能夠客觀認知自己真正的價值所在。
“你要試著了解,不論別人如何評價你,甚至擺出一副比你還瞭解你自己的姿態時,你都要回到相信自己是誰的立場上。”
“你實在不需要讓人牽著鼻子走,讓自己一直以為必須追逐某人的肯定及認同,自己才算是有能力、有資格。這種任人對待自己的方式,就像你接受了「吆喝別人一起來圍攻、霸凌自己」的事實,這會導致你不停的漠視及傷害自己,讓情緒始終受人操控,對自己的觀感一蹶不振。”
這句話實在是太打中我的心XD。
「穩定的高自尊者」並不會以傷害自己的方式來換取他人的快樂,也不會誇耀自己甚至危害他人的幸福,對於穩定高自尊的人而言,這世界並不是唯他獨尊,當然也不會視任何人為至高無上的存在。正因為這種人可以看見自己的自尊需求,同時也能看見別人的自尊需求,所以不會任意的傷害別人,正是成語「己所不欲,勿施於人」的體現。
我們都可以選擇離開總是看低自己、傷害自己的人,人生太長,活在這個世界上實在不需要任著他人來牽自己的鼻子走。
如果希望自己的情緒領土不要受到外界的干擾而妨礙生活和工作,區分課題其實很重要,這部分相信有看過阿德勒學派相關書籍的人都心有所感。
“若是你的情緒及思想的界線因外界的聲浪而模糊了,任由彼此相互干擾及侵入,那麼許多時候你所做的反應、選擇及決定,就不是來自你的自主,而是源於他人及外界的干擾及影響。即使你不那麼心甘情願,你也會糊裡糊塗地做了、答應了、給出去了,而留給自己萬分懊悔、忿忿不平和怨懟的情緒。”
練習分辨自己與別人的感受是重要的,每個人都有表達情緒的權利,但沒有人需要為自己以外的人的情緒負責。
處於失去冷靜的狀態下,而他人又想用情感操縱你時,事情往往會因為不夠客觀的判斷而給出錯誤的決策,進而導致無法挽回的情況。別認為自己永遠有義務和責任去滿足他人的期待是件很重要的事情,認知到自己的能力及情緒邊界,做不勉强自己的決定。
共勉之。
上次用 Windows OS 應該是我大學時代的事了吧(煙
近期因為工作需求又再一次接觸到,原以為很快就搞定,結果還是有些小檻要跨,在此紀錄一下方便之後有需求的人也可以查找。
另外我也有寫一些簡單的範例可以在這個 Repo上找到,有時間就會更新。
Bastion Node: Red Hat Enterprise Linux 8
Ansible version on Bastion Node: 2.9.6
Python version on Bastion Node: 3.6.8
Windows Server: Microsoft Windows 10 (64-bit)
防火牆先打開,不然 ping 不到
Openssh Server 要裝,不然沒辦法透過 ssh 連線,Ansible 執行腳本的方式不是透過 agent,而是透過 SSH 連線
UI 法: 在搜尋欄裡面找 `程式` > 新增選用功能Command Line 法:請參考[這篇](https://docs.microsoft.com/zh-tw/windows-server/administration/openssh/openssh_install_firstuse)裝完 Openssh 除了重新啟動之外該更新的還要更新,我當初還納悶為什麼重新開機之後 openssh 仍舊不在 service 列表裡面…
測試 Bastion 機是否可以連線到 Windows 機器,如果發現 SSH permission denied(Public Key),請 copy 一下 ssh key:
1 | ssh-copy-id ${Windows's Username}@${Windows Server IP} |
1 | netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow |
註. 不知道為啥 Windows 10 家用版拿掉了用 UI 啟動 Administrator 這個功能,可能是怕屁孩如我輩手賤改掉密碼,這邊提供不限於家用版的指令
1 | 啟動管理員帳號 |
開啟後記得去設定管理員密碼
1 | net user administrator ${你設定的管理員密碼} |
1 | set-executionpolicy remotesigned |
改完之後查看一下 PowerShell 的執行策略
1 | get-executionpolicy |
1 | # 配置 winrm service 並且啟動服務 |
成功啟動:
註1: 在這邊有些人在設定時可能會遇到以下這個問題
請修改網路設定,把現在的網路設定從公用網路變成私人網路
註2: 有些人會卡在這個問題,原因可以參照此篇,這也就是為什麼我們要設定AllowUnencrypted="true"
但是在正式環境的話,還是要[把 credentials 加密]([Ansible] Windows 連線設定 (basic、certificate authentication)
在 Ansible 腳本執行機器上上安裝 pywinrm 套件
1 | pip3 install winrm |
寫個 inventory file 註記 windows server IP 還有連線資訊,如果要測試也可以直接在 hosts 裡面加入群組
1 | [windows] |
對如何用 Ansible 更新 Windows KB 可參考此篇。