接手了一台 Jenkins server 他的Infrastructure as Code設計概念很棒
他用 aufs 來掛載 EBS data volume,AMI 的 rebuild 是透過 ansible 和 yaml 來設定,再透過 CloudFormation 自動 deploy
所以要更新的時候只要 commit 更新後的版本號碼進去 repo 就會有一個 fully patched AMI,然後再把 EBS volume 用 overlay fs 掛載到新的 /var/lib/jenkins 目錄
/etc/fstab 是這樣寫的:
但長久以來一直有個問題是,每次重新開機後,/var/lib/jenkins 的目錄並沒有正確的疊上 EBS data volume 裡的資料
所以 workaround 都是 umount /var/lib/jenkins 再 mount -a 卻又好了
最近又要更新 Jenkins ,實在是很討厭每次都要手動進去把 fs 重新 mount 起來
原本以為是 jenkins service 啟動時間和 overlay fs 是不是有 in-use lock 之類,或者是 aufs.ko 載入的時候和 fstab 先後的問題
無意間看到有人說 /etc/fstab 的載入順序不保證是按照設定檔裡寫的順序的!!
df -h 一看,發現第一次開機有問題的 mount /var/lib/jenkins 比 /mnt/jenkins 還前面
mount -a 正常的版本是 /mnt/jenkins 會比 /var/lib/jenkins 早
(其實以前也一直沒注意 df -h 的顯示順序)
最後只要加上 x-systemd.requires=/mnt/jenkins 就好囉!
Ref:
https://github.com/systemd/systemd/commit/3519d230c8bafe834b2dac26ace49fcfba139823
他用 aufs 來掛載 EBS data volume,AMI 的 rebuild 是透過 ansible 和 yaml 來設定,再透過 CloudFormation 自動 deploy
所以要更新的時候只要 commit 更新後的版本號碼進去 repo 就會有一個 fully patched AMI,然後再把 EBS volume 用 overlay fs 掛載到新的 /var/lib/jenkins 目錄
/etc/fstab 是這樣寫的:
LABEL=cloudimg-rootfs / ext4 defaults,discard 0 0
LABEL=jenkins-ebs-fs /mnt/jenkins ext4 defaults,nofail 0 2
none /var/lib/jenkins aufs br=/mnt/jenkins=rw:/var/lib/jenkins=ro,udba=reval 0 0
但長久以來一直有個問題是,每次重新開機後,/var/lib/jenkins 的目錄並沒有正確的疊上 EBS data volume 裡的資料
所以 workaround 都是 umount /var/lib/jenkins 再 mount -a 卻又好了
最近又要更新 Jenkins ,實在是很討厭每次都要手動進去把 fs 重新 mount 起來
原本以為是 jenkins service 啟動時間和 overlay fs 是不是有 in-use lock 之類,或者是 aufs.ko 載入的時候和 fstab 先後的問題
無意間看到有人說 /etc/fstab 的載入順序不保證是按照設定檔裡寫的順序的!!
df -h 一看,發現第一次開機有問題的 mount /var/lib/jenkins 比 /mnt/jenkins 還前面
mount -a 正常的版本是 /mnt/jenkins 會比 /var/lib/jenkins 早
(其實以前也一直沒注意 df -h 的顯示順序)
最後只要加上 x-systemd.requires=/mnt/jenkins 就好囉!
Ref:
https://github.com/systemd/systemd/commit/3519d230c8bafe834b2dac26ace49fcfba139823
留言
張貼留言