使用 Packer 自動化建立 AMI 時，需要先定義一個 Packer 模板文件，然後使用該模板文件生成 AMI 映像。 下面是一個基本的 Packer 示例，可以根據需求進行修改：

{
    "variables": {
        "aws_access_key": "",
        "aws_secret_key": "",
        "aws_region": "us-west-2"
    },
    "builders": [
        {
            "type": "amazon-ebs",
            "access_key": "",
            "secret_key": "",
            "region": "",
            "source_ami": "ami-0c55b159cbfafe1f0",
            "instance_type": "t2.micro",
            "ssh_username": "ec2-user",
            "ami_name": "Alma Linux 8.5 x86_64 HVM AMI "
        }
    ],
    "provisioners": [
        {
            "type": "shell",
            "script": "build.sh"
        }
    ]
}

在上述的 json 中，我定義了一個 amazon-ebs builder，它會使用 AWS EC2 作為基礎，並且使用 source_ami 指定了 Alma Linux 8.5 的 AMI ID。還定義了一個 shell provisioner，它會運行 build.sh 腳本以進行環境安裝。

設定好之後，使用以下命令來生成 AMI ：

packer build \
-var 'aws_access_key=MY_ACCESS_KEY' \
-var 'aws_secret_key=MY_SECRET_KEY' \
-var 'aws_region=MY_REGION' \
my_template.json

在上面的命令中，-var 選項用於指定模板文件中定義的變數值。您需要替換 MY_ACCESS_KEY 和 MY_SECRET_KEY 為 AWS Credentials，MY_REGION 為 AWS 服務所在區域。

目的

記錄一些 rsyslog 遇到的特殊情境或是問題

情境一、server 斷線五分鐘後再回到線上 client 還會傳送這段時間的 log 嗎？

這取決於 client 設置的機制。如果 client 設置為運行在遺失連接時緩存數據的模式下，則在與 server 斷開連接的五分鐘內產生的 log 將被緩存並在連接恢復後發送到 server。

然而，如果 client 的設置為不緩存數據，則在連接斷開期間產生的 log 將被丟失，並不會被發送到 server。

綜上所述，如果要確保在斷開連接期間產生的 log 不會丟失，建議設置 client 為緩存數據的模式。但也需要注意，過多的緩存可能會導致記憶體消耗過高，因此需要根據實際需求和系統資源來進行適當的設置。 client 緩存的設置可以通過修改 client 的配置文件進行。以下是一些常用的設置選項：

$ActionQueueType: 這個選項可以用來設置緩存類型。可選值有 “LinkedList”、”FixedArray”、”DirectFile”、”LinkedList-Reuse”、”FixedArray-Reuse”、”DirectFile-Reuse”，預設值為 “LinkedList”。

$ActionQueueSize: 這個選項可以用來設置緩存大小。設置值的單位是 KB。預設值是 100000。

$ActionQueueDiscardMark: 這個選項可以用來設置緩存滿時的丟棄策略。當緩存佔用的空間超過 $ActionQueueSize 的設置值時，如果還有新的數據要進入緩存，就需要進行一些處理。可選值有 “80%”、”90%”、”95%”，預設值為 “75%”。

$ActionQueueTimeoutEnqueue: 這個選項可以用來設置緩存等待新數據的超時時間。設置值的單位是秒。當緩存空間不足，需要等待數據被發送出去時，如果等待時間超過了 $ActionQueueTimeoutEnqueue 的設置值，就會自動丟棄這些數據。預設值為 1。

以下是一個簡單的範例，展示了如何將 client 的緩存設置為 “DirectFile” 類型，大小為 50 MB，滿時丟棄策略為 “80%”：

$ActionQueueType DirectFile
$ActionQueueFileName srvrfwd_queue
$ActionQueueMaxDiskSpace 50M
$ActionQueueSaveOnShutdown on
$ActionQueueDiscardMark 80%

需要注意的是，不同的 rsyslog client 版本可能支持不同的緩存設置選項，請參考該版本的官方文檔進行設置。另外，緩存的設置也需要根據系統的實際情況進行調整，以平衡緩存空間和系統資源的消耗。

目的

將 SVN 連同 commit 都轉移至 Git

難點

1. 在更新時，不中斷 SVN 上正在開發的專案
   1. 準備一個中繼站，作為持續 Migrate 的角色。當 svn 被更新時，中繼站用 git svn rebase 更新 svn 最新的 commit ，再用 git push 更新到 remote git repo，屆時，開發人員就可以改用 git clone migrate 好的 Git，把原本的 svn project 刪除，其他開發的 member 也可以透過 git pull 更新最新版本的 Git，該 member 原有的 svn 就立即停止使用。中繼站也是作為這個媒介直至所有 repo 都轉移完成為止。
2. 到了 Git 後還要保有，SVN commit 紀錄
   1. 基本 git svn clone 就可以保有 commit 紀錄，再藉 svn log -q 透過 awk 編輯器將 svn 上的作者都整理成一份清單，在 git svn clone 時，將對應的作者與 commit 串連

中繼站準備

1. 安裝 Git
2. 取得作者清單
   1. svn checkout svn://....
   2. svn log -q | awk -F '|' '/^r/ {gsub(/ /, "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt

Migrate 步驟

1. Clone Repo git svn clone --trunk=/Trunk --tags=/Tag --branches=/Branch --authors-file=authors.txt [http://svn/url/www](http://<svn-remote>) www

2. Create Git Remote endpoint origin git remote add origin <repository-url>

3. Convert ignore file git svn show-ignore > .gitignore git add . git commit -m "convert ignore file"

4. Push to endpoint git push -u origin master

狀況處理

1. Migrate 完成後 SVN 再被更新，導致新的 Git repo 也要被更新 git svn rebase git pull origin master --rebase 整線 git push

SQL server 的 CLR 啟用方式

在 Query 的地方下

EXEC sp_configure 'clr enabled', 1; 
GO

在 AWS RDS Console 的 CLR 啟用方式

1. Click Parameter groups
2. Create new parameter group or select an already have group
3. Click Edit parameters
4. Type CLR in search input
5. Change value 0 to 1 in title is “clr enabled”

確認是否成功

在 Query 的地方下

EXEC sp_configure ‘clr enabled’

小技巧 - 修改作者 Config

在工作過程中遇到，做個紀錄

config 有兩種，一種是全部 Repo 都使用的，一種是只在當下這個 repo 使用 用 --global 來區別設定

1. 第一種是修改預設 config 中的 name 與 email，僅針對沒有設定作者的 repo 有效（預設）！

    git config --global user.name "YOUR NAME"
    git config --global user.email "E-mail"
   

2. 第二種是只修改這個 Repo 要用的 name 與 email，比方說公司專案，不想拿在外闖蕩的名稱 commit 上去的話，建議設定

   git config user.name "YOUR NAME"
   git config user.email "E-mail"
   

3. 最後傳到遠端分支上

   git push Remote Branch
   

設定完成後可以先藉由 git config --edit 或 git config --global --edit 查看作者資訊

小技巧 - 修改上次提交的 commit

1. 編輯上次的 commit

   git commit --amend --reset-author
   

   

2. 查看修改

   git log
   

   

3. 最後傳到遠端分支上

   git push Remote Branch
   

小技巧 - 修正某個節點的 commit

假設今天有 A->B->C->D->E->F(HEAD)，而我要修改 C,D,E 這三個 commit 的作者資訊

1. 在該 Repo 的目錄下指令

   git rebase -i B
   

2. 將要修改的 commit pick 都改為 edit :wq 儲存，這時候 commit 會停在 C 上

3. 此時當下的 HEAD 在 C
   • --amend: 修改當前 commit
   • --no-edit: 除了 commit 訊息外不要更動其他修改

     git commit --amend --no-edit --author="Author Name E-mail"
     

4. 進入 D，重複步驟 3 , 4 到結束即可

   git rebase --continue
   

小技巧 - 修改 git 預設編輯器

在 ubuntu 下 git config --amend ... 相關指令時，會以 nano 編輯器打開

這時候可以下 git config --global core.editor "vim" 改以 vim

要是你有其他慣用的編輯器只要把 vim 換掉即可

小技巧 - 保持最新又能保留修改過的檔案

開發人員每天上班第一件事情就是將本地分支更新到最新

若是能順便整線以及同步，便是甚好

但要是遇到修改的過的檔案與同事衝突可以試試以下方法

1. git stash -u : 將修改過的檔案丟進暫存
2. git pull --rebase origin master : 把遠端有修改的部分都加進本地分支歷史，並更新到最新版本
3. git stash pop : 把修改過的檔案丟出來

另外也有人透過另外一種方法做到相同目的

1. git commit -am "like statsh" : 將修改過的檔案丟進本地分支，並成為最新版本
2. git pull --rebase origin master : 把遠端有修改的部分都加進本地分支歷史，並更新到最新版本
3. git reset HEAD~1 : 將本地分支回復到前一版本並保留修改過的檔案

小技巧 - 多點合併

開發過程中有可能會有許多修正，可能寫好一個即 commit 一次

這樣開發到最後，這條線必定有成堆的版本

假設我們今天有兩條線 master , develop

在遵守 git-flow 原則下，master 會是最主要佈上去的版本

所以點越少越好，才不會亂，但 Dev 是開發過程

中間可能會有很多未完成品，最後才慢慢開發完成

假設 N 是我測試完成準備要佈上正式機的版本，可以這樣做

1. 到 master 線上

   git checkout master
   

2. 基於 C 結點之後的變更全部合併到 Master，變成節點 M

   git merge --squash dev
   

   變為 ▽

3. 把線路調整一下讓 Dev 基於 master 的 M 節點開始開發

git checkout develop
git pull origin master

變為 ▽

小技巧 - 把某檔案從所有 commit 中拔掉

假設今天發現好幾個 commit 之前有個不該出現的檔案就存在 repo 裡面

可以利用 git filter-branch 來完成需求，將這個檔案徹底從所有 commit 中移除

git filter-branch --tree-filter "rm -f folder/xxxx.xxx"
Rewrite xsdfwhthwgqdsxcwe543ty4gdf322ghtbsdvs (99/99) (0 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten

這樣看起來好像刪除成功了，但其實它還在暫存之中

隨時都可以取消這個指令

git reset origin master --hard
HEAD is now at 27f6ed6 add dog 2

如果確定你不會後悔的話可以這樣

git filter-branch -f --tree-filter "rm -f folder/xxxx.xxx"
Rewrite xsdfwhthwgqdsxcwe543ty4gdf322ghtbsdvs (99/99) (0 seconds passed, remaining 0 predicted)
Ref 'refs/heads/master' was rewritten

跟前面不太一樣，這次多加了參數 -f 是因為要強制覆寫 filter-branch 的備份

最後還需要清除一下殘餘的垃圾，先切斷 master 的線

rm .git/refs/original/refs/heads/master

強制更新 reflog，請求 reflog 現在就過期 (預設是30天)

git reflog expire --all --expire=now

確認受到影響的 commit (unreachable)

git fsck --unreachable

用 git 本身的回收機制回收不需要的檔案

git gc --prune=now

再檢查一次

git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (14/14), done.

最後，更新遠端的 master 線

git push origin master --force

以上，有可能的問題我已經盡量列出來了，有錯誤還請指正！

參考

• Git