以docker影像執行Gitea伺服器

Table of contents

背景

特色

docker 影像提供Gitea服務的好處與必要性如下

  • 不會受到其他軟體設定的干擾
  • 自動重啟:工作站停機再開,docker會自動重啟,不需人工維護。
  • 隨時保持程式在最新的狀態
  • 沒有後台登入、沒有維護的必要性
  • 清楚的程式與資料界線,便於備份、隨時可以重啟、韌性超強。
    • 即使面臨軟硬體或資安破壞,也可以在最短時間內復原。
  • 具有移植與分殖能力、便於延展擴散。
    • 當組織的庫存量增加時,延展與分殖是非常有必要的。

資源

docker與主機的使用者設定

  • 影像與主機之間的對應是否正確、良好,將會決定系統維運的成敗。此處先討論身分的問題、檔案安全性分述如後。
  • 命令列Gitea的執行者必須是git:git,原因不明,可能與db的存取有關。但是docker影像內的執行者並沒有規定。

設定要求

  • 此二者需要整合以利檔案的傳送
    • docker範例為1000:1000,此組gid:uid可以/必須在docker-compose.ymldocker run -e更改(詳up_giteaDoc.cs)。
    • 命令列執行需為git:git。用以標示git所產生維護的檔案。除了Gitea的工作區檔案,也包括act_runner所產生及/或發布的檔案系統。
  • 需在主機上先新增使用者git:git134: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設定很僵化,因此以主機上來調整會比較容易一些。
  • AppPathWorkPathCustomPathConfigFile
  • 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)內容一致,然後由其中的設定來控制其他的路徑。
  • WorkPathCustomPath理論上應該不會一樣,可能是因為後者沒有什麼內容、在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,似乎也沒有太大的問題。

影像檔的網路存取

  • 這裡的網路使用事實上只有一個,就是MySQL伺服器的連線。
    • 主機的網路存取

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"