以docker影像執行Gitea伺服器
Table of contents
背景
特色
docker 影像提供Gitea服務的好處與必要性如下
- 不會受到其他軟體設定的干擾
- 自動重啟:工作站停機再開,docker會自動重啟,不需人工維護。
- 隨時保持程式在最新的狀態
- 沒有後台登入、沒有維護的必要性
- 清楚的程式與資料界線,便於備份、隨時可以重啟、韌性超強。
- 即使面臨軟硬體或資安破壞,也可以在最短時間內復原。
- 具有移植與分殖能力、便於延展擴散。
- 當組織的庫存量增加時,延展與分殖是非常有必要的。
資源
- docker hub
- docker影像安裝及維運說明
- copilot assistant
docker與主機的使用者設定
- 影像與主機之間的對應是否正確、良好,將會決定系統維運的成敗。此處先討論身分的問題、檔案與安全性分述如後。
- 命令列Gitea的執行者必須是git:git,原因不明,可能與db的存取有關。但是docker影像內的執行者並沒有規定。
設定要求
- 此二者需要整合以利檔案的傳送
- docker範例為
1000:1000
,此組gid:uid
可以/必須在docker-compose.yml
或docker run -e
更改(詳up_giteaDoc.cs)。 - 命令列執行需為
git:git
。用以標示git所產生維護的檔案。除了Gitea的工作區檔案,也包括act_runner所產生及/或發布的檔案系統。
- docker範例為
- 需在主機上先新增使用者
git:git
(134:142
@eng06),並將其加在至少2個群組docker
:此群組內成員才能執行docker
系列指令SESAir
(或其他編修權限之群組):具有技術文件系統的編修權限,可以在後台提供補充或協助。
- 主機
APP_DATA_PATH
的所有者與權限:git:git
- 這個目錄也會有root來寫log資料。
跨主機設定
- 如果分散不同主機公用同一個
APP_DATA_PATH
,另外要特別注意gid:uid
的統一,以避免發生資料無法存入的問題。 - 如果
APP_DATA_PATH
要在samba
託管的nas上正確存取,還需要在samba
主機上正確新增。 必要時可以使用下列指令來更動
sudo usermod -u new_uid username sudo groupmod -g new_gid groupname sudo find / -group old_gid -exec chgrp new_gid {} \;
- 注意
- 使用者
git
必須先登出 - gitea docker image/gitea伺服器必須先下線
- 使用者
有關1000:1000的討論
為何docker image常常使用
1000:1000
做為實際執行的使用者編號?
- 在AnythingLLM的影像中,也是指定
1000:1000
- 可能原因只是方便辨識與
root:root
的差異。 - docker image不會知道主機的使用者安排,一般使用者與群組的編號都是3位數,給個4位數肯定不容易重複。
主機、影像工作目錄的對應
- 在伺服器移轉的過程中,指定正確的目錄是延續伺服器服務的關鍵。
- 除了
主機APP_DATA_PATH
- 命令列啟動Gitea,伺服器會在
/opt/gitea/data
目錄下開設並更新目錄內容。 - 如果拿此app.ini提供給docker,目錄將永遠無法對應。
- app.ini效力範圍,只限定在docker影像之內。
影像的APP_DATA_PATH
- gitea/gitea:latest影像中的
APP_DATA_PATH
設定很僵化,因此以主機上來調整會比較容易一些。 AppPath
、WorkPath
、CustomPath
、ConfigFile
- docker image上的設定值為:(詳下列docker logs輸出)
gitea | 2024/07/20 16:24:08 cmd/web.go:113:showWebStartupMessage() [I] * AppPath: /usr/local/bin/gitea
gitea | 2024/07/20 16:24:08 cmd/web.go:114:showWebStartupMessage() [I] * WorkPath: /data/gitea
gitea | 2024/07/20 16:24:08 cmd/web.go:115:showWebStartupMessage() [I] * CustomPath: /data/gitea
gitea | 2024/07/20 16:24:08 cmd/web.go:116:showWebStartupMessage() [I] * ConfigFile: /data/gitea/conf/app.ini
- AppPath是內設,與影像檔的內容有關,也不是app.ini所能設定的項目。
- 影像的app.ini 是ConfigFile路徑所指定。這個路徑,必須和’docker-compose.yml (或docker run -v)內容一致,然後由其中的設定來控制其他的路徑。
WorkPath
、CustomPath
理論上應該不會一樣,可能是因為後者沒有什麼內容、在app.ini 中也沒有設定、因此還沒有發生衝突。- 從後3者來看,影像檔內設的主要路徑都是在/data之下,這個訊息必須在’docker-compose.yml (或docker run -v)中反映。
二者之協調
- docker-compose.yml (或docker run -v)中的設定
- APP_DATA_PATH的映射
- app.ini位置的映射
- app.ini內容的設定
- WORK_PATH = /data/gitea/
- [server]APP_DATA_PATH = /data
- 這個路徑的設定是相對AppPath系統執行檔、宣告系統的資料來源。
- [repository]ROOT = /data/gitea/gitea-repositories
- Gitea把系統和倉儲檔案分開儲存,除了可以規劃最適合的儲存媒體,在資安上也有最高的彈性。
網路的需求
- docker-compose.yml有建議使用網路,但似乎不需要特別開設網路橋接。
- Gitea影像內設是有開啟網路功能的,會連到指定IP的資料庫。
- 將docker影像抛接到指定IP,似乎也沒有太大的問題。
影像檔的網路存取
up_giteaDoc.cs
執行
gitea/gitea:latest
影像的執行是否需要定期開/關?取決於服務所佔用的資源。- 資源佔用龐大,如果長期佔用,可能對主機造成壅塞,就需要考量定期開/關。
- gitea的資源與服務對象有絕對的關係。服務對象如果龐大、非但考量開/關,還必須考量開設共同的伺服器來分群服務。
- 使用
docker run
還是docker-compose
的考量- 這其實是個發展測試的歷程。理論上二者並無差別。
- AnythingLLM的影像可以接受
docker run ... --ip ...
指令,接受DNS辨識的網域,但似乎gitea影像並不接受,只能接受-p
指令。
程式碼
$ cat up_giteaDoc.cs
docker run \
-d --name=gitea \
-e USER_UID=134 \
-e USER_GID=142 \
-v /opt:/data \
-v ./app.ini:/data/gitea/conf/app.ini \
-v /etc/timezone:/etc/timezone:ro \
-v /etc/localtime:/etc/localtime:ro \
-p ***(ip):3000:3000 \
-p 222:22 gitea/gitea:latest
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea:latest
container_name: gitea
environment:
- USER_UID=134
- USER_GID=142
restart: always
volumes:
- /opt:/data
- ./app.ini:/data/gitea/conf/app.ini
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "***(ip):3000:3000"
- "222:22"