docs: add zh-tw folder (#195)

Signed-off-by: appleboy <[email protected]>
Reviewed-on: https://gitea.com/gitea/docs/pulls/195
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: appleboy <[email protected]>
Co-committed-by: appleboy <[email protected]>
This commit is contained in:
appleboy
2025-04-04 23:28:16 +00:00
committed by Lunny Xiao
parent 3275094871
commit dbfa0ba454
835 changed files with 72590 additions and 5155 deletions
@@ -0,0 +1,145 @@
---
date: "2018-05-07T13:00:00+02:00"
slug: "comparison"
sidebar_position: 5
aliases:
- /zh-tw/comparison
---
# 與其他 Git 託管的比較
為了幫助您決定 Gitea 是否適合您的需求,這裡是它與其他 Git 自託管選項的比較。
請注意,我們不會定期檢查其他產品的功能變更,因此此列表可能已過時。如果您發現需要在下表中更新的內容,請[打開一個問題](https://github.com/go-gitea/gitea/issues/new/choose)。
_表格中使用的符號:_
- _✓ - 支持_
- _ - 支持但功能有限_
- _✘ - 不支持_
- _⚙️ - 通過第三方軟件支持_
## 一般功能
| 功能 | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
| ------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
| 開源且免費 | ✓ | ✘ | ✓ | ✘ | ✘ | ✓ | ✓ |
| 低 RAM/ CPU 使用量 | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
| 多數據庫支持 | ✓ | ✘ | ⁄ | ⁄ | ✓ | ✓ | ✓ |
| 多操作系統支持 | ✓ | ✘ | ✘ | ✘ | ✘ | ✓ | ✓ |
| 易於升級 | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
| 遠程遙測 | **✘** | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| 第三方渲染工具支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✘ | ✘ |
| WebAuthn (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
| 廣泛的 API | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 內置包/容器註冊表 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 同步提交到外部倉庫(推送鏡像) | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
| 從外部倉庫同步提交(拉取鏡像) | ✓ | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
| 淺色和深色主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 自定義主題支持 | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ | ✓ |
| Markdown 支持 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| CSV 支持 | ✓ | ✓ | ✘ | ✘ | ✓ | ✘ | ✘ |
| 'GitHub / GitLab 頁面' | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin] | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Gists / Snippets | [⚙️][opengist] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 特定倉庫的 wiki(作為倉庫本身) | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
| 部署令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 具有寫權限的倉庫令牌 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| RSS 提要 | ✓ | ✓ | ✘ | ✘ | ✘ | ✓ | ✓ |
| 內置 CI/CD | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 子組:組內組 | [](https://github.com/go-gitea/gitea/issues/1872) | ✘ | ✓ | ✓ | ✘ | ✓ | ✓ |
| 與其他實例的交互 | [/](https://github.com/go-gitea/gitea/issues/18240) | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
| Markdown 中的 Mermaid 圖表 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Markdown 中的數學語法 | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ | ✓ |
## 代碼管理
| 功能 | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
| ------------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
| 倉庫主題 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 倉庫代碼搜索 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 全局代碼搜索 | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
| Git LFS 2.0 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 組里程碑 | [](https://github.com/go-gitea/gitea/issues/14622) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 細粒度用戶角色(代碼、問題、Wiki 等) | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 驗證提交者 | ⁄ | ? | ✓ | ✓ | ✓ | ✘ | ✘ |
| GPG 簽名提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| SSH 簽名提交 | ✓ | ✓ | ✓ | ✓ | ? | ✘ | ✘ |
| 拒絕未簽名的提交 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 從其他服務遷移倉庫 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 倉庫活動頁面 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 分支管理器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 創建新分支 | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| 網頁代碼編輯器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 提交圖 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 模板倉庫 | ✓ | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ |
| Git Blame | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 圖像更改的可視比較 | ✓ | ✓ | ? | ? | ? | ✘ | ✘ |
- Gitea 具有內置的倉庫級代碼搜索
- 更好的代碼搜索支持可以通過[使用倉庫索引器](../administration/repo-indexer.md)來實現
## 問題跟踪器
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
| ----------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
| Issue tracker | ✓ | ✓ | ✓ | ✓ | / | ✘ | ✘ |
| Issue templates | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Labels | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Time tracking | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Multiple assignees for issues | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ |
| Related issues | ✘ | ⁄ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Confidential issues | [](https://github.com/go-gitea/gitea/issues/3217) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Comment reactions | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Lock Discussion | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Batch issue handling | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Projects | [/](https://github.com/go-gitea/gitea/issues/14710) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Create branch from issue | [](https://github.com/go-gitea/gitea/issues/20226) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Convert comment to new issue | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Issue search | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Global issue search | [/](https://github.com/go-gitea/gitea/issues/2434) | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Issue dependency | ✓ | ✘ | ✘ | ✘ | ✘ | ✘ | ✘ |
| Create issue via email | [](https://github.com/go-gitea/gitea/issues/6226) | ✘ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Service Desk | [](https://github.com/go-gitea/gitea/issues/6219) | ✘ | ✓ | ✓ | ✘ | ✘ | ✘ |
## Pull/Merge requests
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
| ----------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
| Pull/Merge requests | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Squash merging | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Rebase merging | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Pull/Merge request inline comments | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Pull/Merge request approval | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Pull/Merge require approval | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
| Pull/Merge multiple reviewers | ✓ | ✓ | ✘ | ✓ | ✓ | ✓ | ✓ |
| Merge conflict resolution | [](https://github.com/go-gitea/gitea/issues/9014) | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Restrict push and merge access to certain users | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Revert specific commits | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Pull/Merge requests templates | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ | ✘ |
| Cherry-picking changes | ✓ | ✘ | ✓ | ✓ | ✘ | ✘ | ✓ |
| Download Patch | ✓ | ✓ | ✓ | ✓ | / | ✓ | ✓ |
| Merge queues | ✓ | ✓ | ✘ | ✓ | ✘ | ✘ | ✘ |
## 3rd-party integrations
| Feature | Gitea | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
| ---------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
| Webhooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Git Hooks | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| AD / LDAP integration | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Multiple LDAP / AD server support | ✓ | ✘ | ✘ | ✓ | ✓ | ✓ | ✓ |
| LDAP user synchronization | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
| SAML 2.0 service provider | [](https://github.com/go-gitea/gitea/issues/5512) | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
| OpenID Connect support | ✓ | ✓ | ✓ | ✓ | ? | ✘ | ✓ |
| OAuth 2.0 integration (external authorization) | ✓ | ⁄ | ✓ | ✓ | ? | ✘ | ✓ |
| Act as OAuth 2.0 provider | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✘ |
| Two factor authentication (2FA) | ✓ | ✓ | ✓ | ✓ | ✓ | ✘ | ✓ |
| Integration with the most common services | ✓ | ⁄ | ✓ | ✓ | ⁄ | ✓ | ✓ |
| Incorporate external CI/CD | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
[gitea-caddy-plugin]: https://github.com/42wim/caddy-gitea
[gitea-pages-server]: https://codeberg.org/Codeberg/pages-server
[opengist]: https://github.com/thomiceli/opengist
@@ -0,0 +1,371 @@
---
date: "2020-01-16"
slug: "database-prep"
sidebar_position: 10
aliases:
- /zh-tw/database-prep
---
# 數據庫準備
您需要一個數據庫來使用 Gitea。Gitea 支持 PostgreSQL (>= 12)、MySQL (>= 8.0)、MariaDB (>= 10.4)、SQLite(內置)和 MSSQL (>= 2012 SP4)。本頁將指導您準備數據庫。由於這些數據庫引擎在生產中廣泛使用,這裡將只涵蓋 PostgreSQL 和 MySQL。如果您計劃使用 SQLite,您可以忽略本章。
:::warning
將一種數據庫類型轉換為另一種數據庫類型不是一個經過充分測試的過程,您可能會遇到問題。最好在第一次安裝時選擇最終的數據庫類型。請注意,SQLite 無法擴展;如果您預計您的實例將來會增長,您應該選擇另一種數據庫類型。
:::
如果您使用不受支持的數據庫版本,請[與我們聯繫](/help/support)以獲取有關我們擴展支持合同的信息。我們可以為舊數據庫提供測試和支持,並將這些修復集成到 Gitea 代碼庫中。
數據庫實例可以與 Gitea 在同一台機器上(本地數據庫設置),也可以在不同的機器上(遠程數據庫)。
:::note
以下所有步驟都要求您選擇的數據庫引擎已安裝在您的系統上。對於遠程數據庫設置,請在數據庫實例上安裝服務器應用程序,並在您的 Gitea 服務器上安裝客戶端程序。客戶端程序用於測試從 Gitea 服務器到數據庫的連接,而 Gitea 本身使用 Go 提供的數據庫驅動程序來完成相同的事情。此外,請確保服務器和客戶端使用相同的引擎版本,以便某些引擎功能正常工作。出於安全原因,請使用安全密碼保護 `root`MySQL)或 `postgres`(PostgreSQL)數據庫超級用戶。這些步驟假設您在 Linux 上運行數據庫和 Gitea 服務器。
:::
## MySQL/MariaDB
1. 對於遠程數據庫設置,您需要使 MySQL 監聽您的 IP 地址。在數據庫實例上的 `/etc/mysql/my.cnf` 中編輯 `bind-address` 選項:
```ini
bind-address = 203.0.113.3
```
2. 在數據庫實例上,以 root 身份登錄到數據庫控制台:
```sh
mysql -u root -p
```
按提示輸入密碼。
3. 創建將由 Gitea 使用的數據庫用戶,通過密碼進行身份驗證。本示例使用 `'gitea'` 作為密碼。請為您的實例使用安全密碼。
對於本地數據庫:
```sql
SET old_passwords=0;
CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
```
對於遠程數據庫:
```sql
SET old_passwords=0;
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
```
其中 `192.0.2.
---
date: "2020-01-16"
slug: "database-prep"
sidebar_position: 10
aliases:
- /zh-tw/database-prep
---
# Database Preparation
You need a database to use Gitea. Gitea supports PostgreSQL (>= 12), MySQL (>= 8.0), MariaDB (>= 10.4), SQLite (builtin), and MSSQL (>= 2012 SP4). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter.
:::warning
Converting one database type to another is not a well-tested process and you may experience issues. It is better to choose the final database type at the type of the first installation. Be aware that SQLite does not scale; if you expect your instance to grow at a later time, you should choose another database type.
:::
If you use an unsupported database version, please [get in touch](/help/support) with us for information on our Extended Support Contracts. We can provide testing and support for older databases and integrate those fixes into the Gitea codebase.
Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database).
:::note
All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server application on database instance and client program on your Gitea server. The client program is used to test connection to the database from Gitea server, while Gitea itself use database driver provided by Go to accomplish the same thing. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers.
:::
## MySQL/MariaDB
1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
```ini
bind-address = 203.0.113.3
```
2. On database instance, login to database console as root:
```sh
mysql -u root -p
```
Enter the password as prompted.
3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
For local database:
```sql
SET old_passwords=0;
CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
```
For remote database:
```sql
SET old_passwords=0;
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
```
where `192.0.2.10` is the IP address of your Gitea instance.
Replace username and password above as appropriate.
4. Create database with UTF-8 charset and case-sensitive collation.
`utf8mb4_bin` is a common collation for both MySQL/MariaDB.
When Gitea starts, it will try to find a better collation (`utf8mb4_0900_as_cs` or `uca1400_as_cs`) and alter the database if it is possible.
If you would like to use other collation, you can set `[database].CHARSET_COLLATION` in the `app.ini` file.
```sql
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin';
```
Replace database name as appropriate.
5. Grant all privileges on the database to database user created above.
For local database:
```sql
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
FLUSH PRIVILEGES;
```
For remote database:
```sql
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
FLUSH PRIVILEGES;
```
6. Quit from database console by `exit`.
7. On your Gitea server, test connection to the database:
```
mysql -u gitea -h 203.0.113.3 -p giteadb
```
where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database.
You should be connected to the database.
## PostgreSQL
1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
```ini
listen_addresses = 'localhost, 203.0.113.3'
```
2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
```ini
password_encryption = scram-sha-256
```
Restart PostgreSQL to apply the setting.
3. On the database server, login to the database console as superuser:
```
su -c "psql" - postgres
```
4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
```sql
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
```
Replace username and password as appropriate.
5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
```sql
CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
```
Replace database name as appropriate.
6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
For local database:
```ini
local giteadb gitea scram-sha-256
```
For remote database:
```ini
host giteadb gitea 192.0.2.10/32 scram-sha-256
```
Replace database name, user, and IP address of Gitea instance with your own.
:::note
Rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.
:::
Restart PostgreSQL to apply new authentication rules.
7. On your Gitea server, test connection to the database.
For local database:
```bash
psql -U gitea -d giteadb
```
For remote database:
```bash
psql "postgres://[email protected]/giteadb"
```
where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance.
You should be prompted to enter password for the database user, and connected to the database.
## Database Connection over TLS
If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
### Prerequisites
- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA.
- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute.
- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect.
- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.
### PostgreSQL TLS
The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
1. On the server with the database instance, place the following credentials:
- `/path/to/postgresql.crt`: Database instance certificate
- `/path/to/postgresql.key`: Database instance private key
- `/path/to/root.crt`: CA certificate chain to validate client certificates
2. Add following options to `postgresql.conf`:
```ini
ssl = on
ssl_ca_file = '/path/to/root.crt'
ssl_cert_file = '/path/to/postgresql.crt'
ssl_key_file = '/path/to/postgresql.key'
ssl_min_protocol_version = 'TLSv1.2'
```
3. Adjust credentials ownership and permission, as required by PostgreSQL:
```
chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
```
4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
For PostgreSQL 12:
```ini
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=verify-full
```
For PostgreSQL 11 and earlier:
```ini
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=1
```
Replace database name, user, and IP address of Gitea instance as appropriate.
5. Restart PostgreSQL to apply configurations above.
6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
- `~/.postgresql/postgresql.crt`: Database client certificate
- `~/.postgresql/postgresql.key`: Database client private key
- `~/.postgresql/root.crt`: CA certificate chain to validate server certificate
:::note
Those file names above are hardcoded in PostgreSQL and it is not possible to change them.
:::
7. Adjust credentials, ownership and permission as required:
```
chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
```
8. Test the connection to the database:
```
psql "postgres://[email protected]/giteadb?sslmode=verify-full"
```
You should be prompted to enter password for the database user, and then be connected to the database.
### MySQL/MariaDB TLS
While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details.
In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
1. On the database instance, place the following credentials:
- `/path/to/mysql.crt`: Database instance certificate
- `/path/to/mysql.key`: Database instance key
- `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS.
2. Add following options to `my.cnf`:
```ini
[mysqld]
ssl-ca = /path/to/ca.crt
ssl-cert = /path/to/mysql.crt
ssl-key = /path/to/mysql.key
tls-version = TLSv1.2,TLSv1.3
```
3. Adjust credentials ownership and permission:
```
chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
```
4. Restart MySQL to apply the setting.
5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
```sql
DROP USER 'gitea'@'192.0.2.10';
CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
FLUSH PRIVILEGES;
```
Replace database user name, password, and Gitea instance domain as appropriate.
6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
7. On the server running Gitea, test connection to the database:
```
mysql -u gitea -h example.db -p --ssl
```
You should be connected to the database.
@@ -0,0 +1,389 @@
---
date: "2017-06-19T12:00:00+02:00"
slug: "install-from-binary"
sidebar_position: 15
aliases:
- /zh-tw/install-from-binary
---
# 從二進制安裝
所有下載都支持 SQLite、MySQL 和 PostgreSQL,並內置資產。這可能與 Gogs 不同。
## 下載
您可以從[下載頁面](https://dl.gitea.com/gitea/)找到與您的平台匹配的文件,然後導航到您要下載的版本。
### 選擇正確的文件
**對於 Linux**,您可能需要 `linux-amd64`。它適用於 64 位 Intel/AMD 平台,但還有其他可用平台,包括 `arm64`(例如 Raspberry PI 4)、`386`(即 32 位)、`arm-5``arm-6`
**對於 Windows**,您可能需要 `windows-4.0-amd64`。它適用於所有現代版本的 Windows,但還有一個 `386` 平台可用,專為舊的 32 位版本的 Windows 設計。
:::info
還有一個 `gogit-windows` 文件可用,它是為了解決一些[性能問題](https://github.com/go-gitea/gitea/pull/15482)而創建的,這些問題是一些 Windows 用戶在舊系統/版本上報告的。如果您遇到性能問題,應該考慮使用此文件,並讓我們知道它是否改善了性能。
:::
**對於 macOS**,如果您的硬件使用 Apple Silicon,您應該選擇 `darwin-arm64`,或者對於 Intel 選擇 `darwin-amd64`
**對於 FreeBSD**,您應該選擇 `freebsd12-amd64`,適用於 64 位 Intel/AMD 平台。
### 使用 wget 下載
複製以下命令並將 URL 替換為您希望下載的 URL。
```shell
wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
chmod +x gitea
```
請注意,上述命令將下載 64 位 Linux 的 Gitea @version@。
## 驗證 GPG 簽名
Gitea 使用 [GPG 密鑰](https://keys.openpgp.org/search?q=teabot%40gitea.io) 簽署所有二進制文件,以防止二進制文件被未經授權的修改。
要驗證二進制文件,請下載您下載的二進制文件的簽名文件,該文件以 `.asc` 結尾,並使用 GPG 命令行工具。
```sh
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-@[email protected] gitea-@version@-linux-amd64
```
查找文本 `Good signature from "Teabot <[email protected]>"` 以確認二進制文件良好,
儘管有 `This key is not certified with a trusted signature!` 之類的警告。
## 推薦的服務器配置
:::note
以下許多目錄也可以使用[環境變量](../administration/environment-variables.md)進行配置!
值得注意的是,配置 `GITEA_WORK_DIR` 將告訴 Gitea 將其工作目錄設置在哪裡,並簡化安裝過程。
:::
### 準備環境
檢查服務器上是否安裝了 Git。如果沒有,請先安裝它。Gitea 需要 Git 版本 >= 2.0。
```sh
git --version
```
創建一個用戶來運行 Gitea(例如 `git`
```sh
# 在 Ubuntu/Debian 上:
adduser \
--system \
--shell /bin/bash \
--gecos 'Git 版本控制' \
--group \
--disabled-password \
--home /home/git \
git
# 在 Fedora/RHEL/CentOS 上:
groupadd --system git
adduser \
--system \
--shell /bin/bash \
--comment 'Git 版本控制' \
--gid git \
--home-dir /home/git \
--create-home \
git
```
### 創建所需的目錄結構
```sh
mkdir -p /var/lib/gitea/{custom,data,log}
chown -R git:git /var/lib/gitea/
chmod -R 750 /var/lib/gitea/
mkdir /etc/gitea
chown root:git /etc/gitea
chmod 770 /etc/gitea
```
:::note
> `/etc/gitea` 暫時設置為用戶 `git` 的寫入權限,以便 Web 安裝程序可以寫入配置文件。安裝完成後,建議將權限設置為只讀:
> :::
> ```sh
> chmod 750 /etc/gitea
> chmod 640 /etc/gitea/app.ini
> ```
如果您不希望 Web 安裝程序能夠寫入配置文件,可以使配置文件對 Gitea 用戶(所有者/組 `root:git`,模式 `0640`)只讀,但您需要手動編輯配置文件以:
- 設置 `INSTALL_LOCK= true`
- 確保所有數據庫配置詳細信息正確設置
- 確保設置了 `SECRET_KEY``INTERNAL_TOKEN` 值。(您可能需要使用 `gitea generate secret` 來生成這些密鑰。)
- 確保設置了您需要的任何其他密鑰。
有關使用 `gitea generate secret` 的信息,請參閱[命令行文檔](../administration/command-line.md)。
### 配置 Gitea 的工作目錄
:::note
如果您計劃將 Gitea 作為 Linux 服務運行,則可以跳過此步驟,因為服務文件允許您設置 `WorkingDirectory`。否則,請考慮(半)永久性地設置此環境變量,以便 Gitea 始終使用正確的工作目錄。
:::
```sh
export GITEA_WORK_DIR=/var/lib/gitea/
```
### 將 Gitea 二進制文件複製到全局位置
```sh
cp gitea /usr/local/bin/gitea
```
### 添加 bash/zsh 自動補全(從 1.19 開始)
可以在 [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete) 找到啟用 bash 補全的腳本。這可以複製到 `/usr/share/bash-completion/completions/gitea`
或在您的 `.bashrc` 中引用。
## 同樣,zsh 補全的腳本可以在 [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete) 中找到。這可以複製到 `/usr/share/zsh/_gitea` 或在您的
date: "2017-06-19T12:00:00+02:00"
slug: "install-from-binary"
sidebar_position: 15
aliases:
- /zh-tw/install-from-binary
---
# Installation from binary
All downloads come with SQLite, MySQL and PostgreSQL support, and are built with
embedded assets. This can be different from Gogs.
## Download
You can find the file matching your platform from the [downloads page](https://dl.gitea.com/gitea/) after navigating to the version you want to download.
### Choosing the right file
**For Linux**, you will likely want `linux-amd64`. It's for 64-bit Intel/AMD platforms, but there are other platforms available, including `arm64` (e.g. Raspberry PI 4), `386` (i.e. 32-bit), `arm-5`, and `arm-6`.
**For Windows**, you will likely want `windows-4.0-amd64`. It's for all modern versions of Windows, but there is also a `386` platform available designed for older, 32-bit versions of Windows.
:::info
There is also a `gogit-windows` file available that was created to help with some [performance problems](https://github.com/go-gitea/gitea/pull/15482) reported by some Windows users on older systems/versions. You should consider using this file if you're experiencing performance issues, and let us know if it improves performance.
:::
**For macOS**, you should choose `darwin-arm64` if your hardware uses Apple Silicon, or `darwin-amd64` for Intel.
**For FreeBSD**, you should choose `freebsd12-amd64` for 64-bit Intel/AMD platforms.
### Downloading with wget
Copy the commands below and replace the URL within the one you wish to download.
```shell
wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
chmod +x gitea
```
Note that the above command will download Gitea @version@ for 64-bit Linux.
## Verify GPG signature
Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
```sh
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-@[email protected] gitea-@version@-linux-amd64
```
Look for the text `Good signature from "Teabot <[email protected]>"` to assert a good binary,
despite warnings like `This key is not certified with a trusted signature!`.
## Recommended server configuration
:::note
Many of the following directories can be configured using [Environment Variables](../administration/environment-variables.md) as well!
Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working directory, as well as ease installation.
:::
### Prepare environment
Check that Git is installed on the server. If it is not, install it first. Gitea requires Git version >= 2.0.
```sh
git --version
```
Create a user to run Gitea (e.g. `git`)
```sh
# On Ubuntu/Debian:
adduser \
--system \
--shell /bin/bash \
--gecos 'Git Version Control' \
--group \
--disabled-password \
--home /home/git \
git
# On Fedora/RHEL/CentOS:
groupadd --system git
adduser \
--system \
--shell /bin/bash \
--comment 'Git Version Control' \
--gid git \
--home-dir /home/git \
--create-home \
git
```
### Create required directory structure
```sh
mkdir -p /var/lib/gitea/{custom,data,log}
chown -R git:git /var/lib/gitea/
chmod -R 750 /var/lib/gitea/
mkdir /etc/gitea
chown root:git /etc/gitea
chmod 770 /etc/gitea
```
:::note
> `/etc/gitea` is temporarily set with write permissions for user `git` so that the web installer can write the configuration file. After the installation is finished, it is recommended to set permissions to read-only using:
> :::
> ```sh
> chmod 750 /etc/gitea
> chmod 640 /etc/gitea/app.ini
> ```
If you don't want the web installer to be able to write to the config file, it is possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`) however you will need to edit your config file manually to:
- Set `INSTALL_LOCK= true`,
- Ensure all database configuration details are set correctly
- Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
- Ensure that any other secret keys you need are set.
See the [command line documentation](../administration/command-line.md) for information on using `gitea generate secret`.
### Configure Gitea's working directory
:::note
If you plan on running Gitea as a Linux service, you can skip this step, as the service file allows you to set `WorkingDirectory`. Otherwise, consider setting this environment variable (semi-)permanently so that Gitea consistently uses the correct working directory.
:::
```sh
export GITEA_WORK_DIR=/var/lib/gitea/
```
### Copy the Gitea binary to a global location
```sh
cp gitea /usr/local/bin/gitea
```
### Adding bash/zsh autocompletion (from 1.19)
A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This can be copied to `/usr/share/bash-completion/completions/gitea`
or sourced within your `.bashrc`.
Similarly a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
`.zshrc`.
YMMV and these scripts may need further improvement.
## Running Gitea
After you complete the above steps, you can run Gitea two ways:
### 1. Creating a service file to start Gitea automatically (recommended)
See how to create [Linux service](installation/run-as-service-in-ubuntu.md)
### 2. Running from command-line/terminal
```sh
GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
```
## Updating to a new version
You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance.
The binary file name should not be changed during the update to avoid problems in existing repositories.
It is recommended that you make a [backup](../administration/backup-and-restore.md) before updating your installation.
If you have carried out the installation steps as described above, the binary should
have the generic name `gitea`. Do not change this, i.e. to include the version number.
### 1. Restarting Gitea with systemd (recommended)
As we explained before, we recommend to use systemd as the service manager. In this case, `systemctl restart gitea` should be fine.
### 2. Restarting Gitea without systemd
To restart your Gitea instance, we recommend to use SIGHUP signal. If you know your Gitea PID, use `kill -1 $GITEA_PID`, otherwise you can use `killall -1 gitea`.
To gracefully stop the Gitea instance, a simple `kill $GITEA_PID` or `killall gitea` is enough.
:::note
We don't recommend to use the SIGKILL signal (`-9`); you may be forcefully stopping some of Gitea's internal tasks, and it will not gracefully stop (tasks in queues, indexers, etc.)
:::
See below for troubleshooting instructions to repair broken repositories after
an update of your Gitea version.
## Troubleshooting
### Old glibc versions
Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the
Gitea binary, usually producing an error such as `./gitea: /lib/x86_64-linux-gnu/libc.so.6:
version 'GLIBC\_2.14' not found (required by ./gitea)`. This is due to the integrated
SQLite support in the binaries provided by dl.gitea.com. In this situation, it is usually
possible to [install from source](installation/from-source.md), without including
SQLite support.
### Running Gitea on another port
For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
bind: address already in use`, Gitea needs to be started on another free port. This
is possible using `./gitea web -p $PORT`. It's possible another instance of Gitea
is already running.
### Running Gitea on Raspbian
As of v1.8, there is a problem with the arm7 version of Gitea, and it doesn't run on Raspberry Pis and similar devices.
It is recommended to switch to the arm6 version, which has been tested and shown to work on Raspberry Pis and similar devices.
<!---
please remove after fixing the arm7 bug
--->
### Git error after updating to a new version of Gitea
If during the update, the binary file name has been changed to a new version of Gitea,
Git Hooks in existing repositories will not work any more. In that case, a Git
error will be displayed when pushing to the repository.
```
remote: ./hooks/pre-receive.d/gitea: line 2: [...]: No such file or directory
```
The `[...]` part of the error message will contain the path to your previous Gitea
binary.
To solve this, go to the admin options and run the task `Resynchronize pre-receive,
update and post-receive hooks of all repositories` to update all hooks to contain
the new binary path. Please note that this overwrites all Git Hooks, including ones
with customizations made.
If you aren't using the Gitea built-in SSH server, you will also need to re-write
the authorized key file by running the `Update the '.ssh/authorized_keys' file with
Gitea SSH keys.` task in the admin options.
@@ -0,0 +1,109 @@
---
date: "2016-12-01T16:00:00+02:00"
slug: "install-from-package"
sidebar_position: 20
aliases:
- /zh-tw/install-from-package
---
# 從包安裝
## 官方包
### macOS
目前,在 MacOS 上安裝的唯一支持方法是 [Homebrew](http://brew.sh/)。
按照[從二進制部署](installation/from-binary.md)指南可能有效,
但不受支持。要通過 `brew` 安裝 Gitea
```
brew install gitea
```
## 非官方包
### Alpine Linux
Alpine Linux 在其社區存儲庫中有 [Gitea](https://pkgs.alpinelinux.org/packages?name=gitea&branch=edge),該存儲庫遵循最新的穩定版本。
```sh
apk add gitea
```
### Arch Linux
滾動發行版在其官方額外存儲庫中有 [Gitea](https://www.archlinux.org/packages/extra/x86_64/gitea/),並且隨著新的 Gitea 發行版提供包更新。
```sh
pacman -S gitea
```
### Arch Linux ARM
Arch Linux ARM 提供 [aarch64](https://archlinuxarm.org/packages/aarch64/gitea)、[armv7h](https://archlinuxarm.org/packages/armv7h/gitea) 和 [armv6h](https://archlinuxarm.org/packages/armv6h/gitea) 的包。
```sh
pacman -S gitea
```
### Gentoo Linux
滾動發行版在其官方社區存儲庫中有 [Gitea](https://packages.gentoo.org/packages/www-apps/gitea),並且隨著新的 Gitea 發行版提供包更新。
```sh
emerge gitea -va
```
### Canonical Snap
有一個 [Gitea Snap](https://snapcraft.io/gitea) 包,它遵循最新的穩定版本。
_注意:Gitea snap 包是[嚴格隔離的](https://snapcraft.io/docs/snap-confinement)。嚴格隔離的快照完全隔離運行,因此某些 Gitea 功能可能無法與隔離一起使用_
```sh
snap install gitea
```
### SUSE 和 openSUSE
OpenSUSE 構建服務提供 [openSUSE 和 SLE](https://software.opensuse.org/download/package?package=gitea&project=devel%3Atools%3Ascm) 的包
在開發軟件配置管理存儲庫中
### Windows
[Chocolatey](https://chocolatey.org/) 提供了一個適用於 Windows 的 [Gitea](https://chocolatey.org/packages/gitea) 包。
```sh
choco install gitea
```
或者按照[從二進制部署](installation/from-binary.md)指南進行操作。
### FreeBSD
有一個 FreeBSD 端口 `www/gitea` 可用。要安裝預構建的二進制包:
```
pkg install gitea
```
要獲取最新版本,或使用自定義選項構建端口,
[從端口安裝](https://www.freebsd.org/doc/handbook/ports-using.html)
```
su -
cd /usr/ports/www/gitea
make install clean
```
該端口使用標準的 FreeBSD 文件系統佈局:配置文件位於 `/usr/local/etc/gitea`
捆綁的模板、選項、插件和主題位於 `/usr/local/share/gitea`,啟動腳本
位於 `/usr/local/etc/rc.d/gitea`
要使 Gitea 作為服務運行,請運行 `sysrc gitea_enable=YES` 並使用 `service gitea start` 啟動它。
### 其他
存在各種其他第三方 Gitea 包。
要查看策劃列表,請前往 [awesome-gitea](https://gitea.com/gitea/awesome-gitea/src/branch/master/README.md#user-content-packages)。
您知道有現有的包不在列表中嗎?發送 PR 以將其添加!
@@ -0,0 +1,372 @@
---
date: "2016-12-01T16:00:00+02:00"
slug: "install-from-source"
sidebar_position: 30
aliases:
- /zh-tw/install-from-source
---
# 從源代碼安裝
您應該[安裝 go](https://go.dev/doc/install) 並正確設置您的 go 環境。特別是,建議設置 `$GOPATH` 環境變量並添加 go bin 目錄或目錄 `${GOPATH//://bin:}/bin``$PATH`。請參閱 Go wiki 條目 [GOPATH](https://github.com/golang/go/wiki/GOPATH)。
接下來,[安裝帶有 npm 的 Node.js](https://nodejs.org/en/download/),這是構建 JavaScript 和 CSS 文件所必需的。支持的最低 Node.js 版本是 @minNodeVersion@,建議使用最新的 LTS 版本。
:::note
需要 Go 版本 @minGoVersion@ 或更高版本。但是,建議獲取與我們的持續集成相同的版本,請參閱[在 Gitea 上進行黑客攻擊](development/hacking-on-gitea.md) 中的建議
:::
## 下載
首先,我們必須檢索源代碼。由於 go 模塊的出現,最簡單的方法是直接使用 Git,因為我們不再需要在 GOPATH 中構建 Gitea。
```bash
git clone https://github.com/go-gitea/gitea
```
(本文檔的早期版本建議使用 `go get`。這不再是必需的。)
決定要構建和安裝的 Gitea 版本。目前,有多種選擇可供選擇。`main` 分支代表當前的開發版本。要使用 main 構建,請跳到[構建部分](#build)。
要使用標記的版本,可以使用以下命令:
```bash
git branch -a
git checkout @sourceBranch@
```
要驗證拉取請求,請首先啟用新分支(`xyz` 是 PR id;例如 [#2663](https://github.com/go-gitea/gitea/pull/2663) 的 `2663`):
```bash
git fetch origin pull/xyz/head:pr-xyz
```
要從特定標記版本(如 @sourceVersion@)的源代碼構建 Gitea,請列出可用標記並檢出特定標記。
使用以下命令列出可用標籤。
```bash
git tag -l
git checkout @sourceVersion@ # 或 git checkout pr-xyz
```
## 構建
要從源代碼構建,系統上必須存在以下程序:
- `go` @minGoVersion@ 或更高版本,請參閱[此處](https://go.dev/dl/)
- `node` @minNodeVersion@ 或更高版本,帶有 `npm`,請參閱[此處](https://nodejs.org/en/download/)
- `make`,請參閱[此處](development/hacking-on-gitea.md#installing-make)
提供了各種[make 任務](https://github.com/go-gitea/gitea/blob/main/Makefile),以使構建過程盡可能簡單。
根據要求,可以包括以下構建標籤。
- `bindata`:構建單個整體二進制文件,包含所有資產。生產構建所需。
- `sqlite sqlite_unlock_notify`:啟用對 [SQLite3](https://sqlite.org/) 數據庫的支持。僅建議用於小型安裝。
- `pam`:啟用對 PAM(Linux 可插拔身份驗證模塊)的支持。可用於驗證本地用戶或擴展身份驗證到 PAM 可用的方法。
- `gogit`:(實驗性)使用 go-git 變體的 Git 命令。
將所有資產(JS/CSS/模板等)捆綁到二進制文件中。使用 `bindata` 構建標籤是生產部署所必需的。當您開發/測試 Gitea 或能夠正確分離資產時,可以排除 `bindata`
要包括所有資產,請使用 `bindata` 標籤:
```bash
TAGS="bindata" make build
```
在我們的持續集成系統的默認發布構建中,構建標籤是:`TAGS="bindata sqlite sqlite_unlock_notify"`。因此,從源代碼構建的最簡單推薦方法是:
```bash
TAGS="bindata sqlite sqlite_unlock_notify" make build
```
`build` 目標分為兩個子目標:
- `make backend` 需要 [Go @minGoVersion@](https://go.dev/dl/) 或更高版本。
- `make frontend` 需要 [Node.js @minNodeVersion@](https://nodejs.org/en/download/) 或更高版本。
如果存在預構建的前端文件,則可以僅構建後端:
```bash
TAGS="bindata" make backend
```
## 測試
按照上述步驟操作後,工作目錄中將有一個 `gitea` 二進制文件。
可以從此目錄進行測試或移動到具有測試數據的目錄。當 Gitea 從命令行手動啟動時,可以通過按 `Ctrl + C` 將其終止。
```bash
./gitea web
```
## 更改默認路徑
Gitea 將從 _`CustomPath`_ 中搜索許多內容。默認情況下,這是運行 Gitea 時當前工作目錄中的 `custom/` 目錄。它還將在 `$(CustomPath)/conf/app.ini` 中查找其配置文件,並將當前工作目錄用作許多可配置值的相對基本路徑 _`AppWorkPath`_。最後,靜態文件將從 _`StaticRootPath`_ 提供,默認為 _`AppWorkPath`_
這些值雖然在開發時很有用,但可能會與下游用戶的偏好發生衝突。
一種選擇是使用腳本文件來影子 `gitea` 二進制文件並在運行 Gitea 之前創建適當的環境。但是,在構建時,您可以使用 `make``LDFLAGS` 環境變量更改這些默認值。適當的設置如下
- 要設置 _`CustomPath`_,請使用 `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
-
---
date: "2016-12-01T16:00:00+02:00"
slug: "install-from-source"
sidebar_position: 30
aliases:
- /zh-tw/install-from-source
---
# Installation from source
You should [install go](https://go.dev/doc/install) and set up your go
environment correctly. In particular, it is recommended to set the `$GOPATH`
environment variable and to add the go bin directory or directories
`${GOPATH//://bin:}/bin` to the `$PATH`. See the Go wiki entry for
[GOPATH](https://github.com/golang/go/wiki/GOPATH).
Next, [install Node.js with npm](https://nodejs.org/en/download/) which is
required to build the JavaScript and CSS files. The minimum supported Node.js
version is @minNodeVersion@ and the latest LTS version is recommended.
:::note
Go version @minGoVersion@ or higher is required. However, it is recommended to
obtain the same version as our continuous integration, see the advice given in
[Hacking on Gitea](development/hacking-on-gitea.md)
:::
## Download
First, we must retrieve the source code. Since, the advent of go modules, the
simplest way of doing this is to use Git directly as we no longer have to have
Gitea built from within the GOPATH.
```bash
git clone https://github.com/go-gitea/gitea
```
(Previous versions of this document recommended using `go get`. This is
no longer necessary.)
Decide which version of Gitea to build and install. Currently, there are
multiple options to choose from. The `main` branch represents the current
development version. To build with main, skip to the [build section](#build).
To work with tagged releases, the following commands can be used:
```bash
git branch -a
git checkout @sourceBranch@
```
To validate a Pull Request, first enable the new branch (`xyz` is the PR id;
for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)):
```bash
git fetch origin pull/xyz/head:pr-xyz
```
To build Gitea from source at a specific tagged release (like @sourceVersion@), list the
available tags and check out the specific tag.
List available tags with the following.
```bash
git tag -l
git checkout @sourceVersion@ # or git checkout pr-xyz
```
## Build
To build from source, the following programs must be present on the system:
- `go` @minGoVersion@ or higher, see [here](https://go.dev/dl/)
- `node` @minNodeVersion@ or higher with `npm`, see [here](https://nodejs.org/en/download/)
- `make`, see [here](development/hacking-on-gitea.md#installing-make)
Various [make tasks](https://github.com/go-gitea/gitea/blob/main/Makefile)
are provided to keep the build process as simple as possible.
Depending on requirements, the following build tags can be included.
- `bindata`: Build a single monolithic binary, with all assets included. Required for production build.
- `sqlite sqlite_unlock_notify`: Enable support for a
[SQLite3](https://sqlite.org/) database. Suggested only for tiny
installations.
- `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
be used to authenticate local users or extend authentication to methods
available to PAM.
- `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
Bundling all assets (JS/CSS/templates, etc) into the binary. Using the `bindata` build tag is required for
production deployments. You could exclude `bindata` when you are developing/testing Gitea or able to separate the assets correctly.
To include all assets, use the `bindata` tag:
```bash
TAGS="bindata" make build
```
In the default release build of our continuous integration system, the build
tags are: `TAGS="bindata sqlite sqlite_unlock_notify"`. The simplest
recommended way to build from source is therefore:
```bash
TAGS="bindata sqlite sqlite_unlock_notify" make build
```
The `build` target is split into two sub-targets:
- `make backend` which requires [Go @minGoVersion@](https://go.dev/dl/) or greater.
- `make frontend` which requires [Node.js @minNodeVersion@](https://nodejs.org/en/download/) or greater.
If pre-built frontend files are present it is possible to only build the backend:
```bash
TAGS="bindata" make backend
```
## Test
After following the steps above, a `gitea` binary will be available in the working directory.
It can be tested from this directory or moved to a directory with test data. When Gitea is
launched manually from command line, it can be killed by pressing `Ctrl + C`.
```bash
./gitea web
```
## Changing default paths
Gitea will search for a number of things from the _`CustomPath`_. By default this is
the `custom/` directory in the current working directory when running Gitea. It will also
look for its configuration file _`CustomConf`_ in `$(CustomPath)/conf/app.ini`, and will use the
current working directory as the relative base path _`AppWorkPath`_ for a number configurable
values. Finally the static files will be served from _`StaticRootPath`_ which defaults to the _`AppWorkPath`_.
These values, although useful when developing, may conflict with downstream users preferences.
One option is to use a script file to shadow the `gitea` binary and create an appropriate
environment before running Gitea. However, when building you can change these defaults
using the `LDFLAGS` environment variable for `make`. The appropriate settings are as follows
- To set the _`CustomPath`_ use `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
- For _`CustomConf`_ you should use `-X \"code.gitea.io/gitea/modules/setting.CustomConf=conf.ini\"`
- For _`AppWorkPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.AppWorkPath=working-path\"`
- For _`StaticRootPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.StaticRootPath=static-root-path\"`
- To change the default PID file location use `-X \"code.gitea.io/gitea/cmd.PIDFile=/run/gitea.pid\"`
Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable and run `make build`
with the appropriate `TAGS` as above.
Running `gitea help` will allow you to review what the computed settings will be for your `gitea`.
## Cross Build
The `go` compiler toolchain supports cross-compiling to different architecture targets that are supported by the toolchain. See [`GOOS` and `GOARCH` environment variable](https://go.dev/doc/install/source#environment) for the list of supported targets. Cross compilation is helpful if you want to build Gitea for less-powerful systems (such as Raspberry Pi).
To cross build Gitea with build tags (`TAGS`), you also need a C cross compiler which targets the same architecture as selected by the `GOOS` and `GOARCH` variables. For example, to cross build for Linux ARM64 (`GOOS=linux` and `GOARCH=arm64`), you need the `aarch64-unknown-linux-gnu-gcc` cross compiler. This is required because Gitea build tags uses `cgo`'s foreign-function interface (FFI).
Cross-build Gitea for Linux ARM64, without any tags:
```
GOOS=linux GOARCH=arm64 make build
```
Cross-build Gitea for Linux ARM64, with recommended build tags:
```
CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build
```
Replace `CC`, `GOOS`, and `GOARCH` as appropriate for your architecture target.
You will sometimes need to build a static compiled image. To do this you will need to add:
```
LDFLAGS="-linkmode external -extldflags '-static' $LDFLAGS" TAGS="netgo osusergo $TAGS" make build
```
This can be combined with `CC`, `GOOS`, and `GOARCH` as above.
### Adding bash/zsh autocompletion (from 1.19)
A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This should be altered as appropriate and can be `source` in your `.bashrc`
or copied as `/usr/share/bash-completion/completions/gitea`.
Similarly, a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
`.zshrc`.
YMMV and these scripts may need further improvement.
## Compile or cross-compile using Linux with Zig
Follow [Getting Started of Zig](https://ziglang.org/learn/getting-started/#installing-zig) to install zig.
- Compile (Linux ➝ Linux)
```sh
CC="zig cc -target x86_64-linux-gnu" \
CGO_ENABLED=1 \
CGO_CFLAGS="-O2 -g -pthread" \
CGO_LDFLAGS="-linkmode=external -v"
GOOS=linux \
GOARCH=amd64 \
TAGS="bindata sqlite sqlite_unlock_notify" \
make build
```
- Cross-compile (Linux ➝ Windows)
```sh
CC="zig cc -target x86_64-windows-gnu" \
CGO_ENABLED=1 \
CGO_CFLAGS="-O2 -g -pthread" \
GOOS=windows \
GOARCH=amd64 \
TAGS="bindata sqlite sqlite_unlock_notify" \
make build
```
## Compile or cross-compile with Zig using Windows
Compile with `GIT BASH`.
- Compile (Windows ➝ Windows)
```sh
CC="zig cc -target x86_64-windows-gnu" \
CGO_ENABLED=1 \
CGO_CFLAGS="-O2 -g -pthread" \
GOOS=windows \
GOARCH=amd64 \
TAGS="bindata sqlite sqlite_unlock_notify" \
make build
```
- Cross-compile (Windows ➝ Linux)
```sh
CC="zig cc -target x86_64-linux-gnu" \
CGO_ENABLED=1 \
CGO_CFLAGS="-O2 -g -pthread" \
CGO_LDFLAGS="-linkmode=external -v"
GOOS=linux \
GOARCH=amd64 \
TAGS="bindata sqlite sqlite_unlock_notify" \
make build
```
## Source Maps
By default, gitea generates reduced source maps for frontend files to conserve space. This can be controlled with the `ENABLE_SOURCEMAP` environment variable:
- `ENABLE_SOURCEMAP=true` generates all source maps, the default for development builds
- `ENABLE_SOURCEMAP=reduced` generates limited source maps, the default for production builds
- `ENABLE_SOURCEMAP=false` generates no source maps
@@ -0,0 +1,42 @@
---
date: "2016-12-01T16:00:00+02:00"
slug: "install-on-cloud-provider"
sidebar_position: 90
aliases:
- /zh-tw/install-on-cloud-provider
---
# 在雲提供商上安裝
## Cloudron
Gitea 可在 [Cloudron](https://cloudron.io) 上一鍵安裝。
Cloudron 使您可以輕鬆地在服務器上運行 Gitea 等應用程序,並保持它們的最新和安全。
[![安裝](/cloudron.svg)](https://cloudron.io/button.html?app=io.gitea.cloudronapp)
Gitea 包由[此處](https://git.cloudron.io/cloudron/gitea-app)維護。
有一個[演示實例](https://my.demo.cloudron.io)(用戶名:cloudron 密碼:cloudron),您可以在其中試驗運行 Gitea。
## Linode
[Linode](https://www.linode.com/) 在其市場中有 Gitea 作為應用程序。
要將 Gitea 部署到 Linode,請查看 [Linode Marketplace](https://www.linode.com/marketplace/apps/linode/gitea/)。
## alwaysdata
[alwaysdata](https://www.alwaysdata.com/) 在其市場中有 Gitea 作為應用程序。
要將 Gitea 部署到 alwaysdata,請查看 [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/)。
## Exoscale
[Exoscale](https://www.exoscale.com/) 在其市場中提供由 [Glasskube](https://glasskube.eu/) 管理的 Gitea。
Exoscale 是一家歐洲雲服務提供商。
該包由開源 [Glasskube Kubernetes Operator](https://github.com/glasskube/operator) 維護和更新。
要將 Gitea 部署到 Exoscale,請查看 [Exoscale Marketplace](https://www.exoscale.com/marketplace/listing/glasskube-gitea/)。
@@ -0,0 +1,63 @@
---
date: "2020-03-19T19:27:00+02:00"
slug: "install-on-kubernetes"
sidebar_position: 80
aliases:
- /zh-tw/install-on-kubernetes
---
# 在 Kubernetes 上安裝
Gitea 提供了一個 Helm Chart 以允許在 kubernetes 上安裝。
可以使用以下命令進行非自定義安裝:
```
helm repo add gitea-charts https://dl.gitea.com/charts/
helm install gitea gitea-charts/gitea
```
如果您想自定義安裝,包括 kubernetes ingress,請參閱完整的 [Gitea helm chart 配置詳細信息](https://gitea.com/gitea/helm-chart/)
## 健康檢查端點
Gitea 帶有一個健康檢查端點 `/api/healthz`,您可以在 kubernetes 中這樣配置它:
```yaml
livenessProbe:
httpGet:
path: /api/healthz
port: http
initialDelaySeconds: 200
timeoutSeconds: 5
periodSeconds: 10
successThreshold: 1
failureThreshold: 10
```
成功的健康檢查響應將返回 http 代碼 `200`,示例如下:
```json
HTTP/1.1 200 OK
{
"status": "pass",
"description": "Gitea: Git with a cup of tea",
"checks": {
"cache:ping": [
{
"status": "pass",
"time": "2022-02-19T09:16:08Z"
}
],
"database:ping": [
{
"status": "pass",
"time": "2022-02-19T09:16:08Z"
}
]
}
}
```
有關更多信息,請參考 kubernetes 文檔 [定義 liveness HTTP 請求](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request)
@@ -0,0 +1,65 @@
---
date: "2017-07-21T12:00:00+02:00"
slug: "linux-service"
sidebar_position: 40
aliases:
- /zh-tw/linux-service
---
# 作為 Linux 服務運行
您可以使用 systemd 或 supervisor 將 Gitea 作為 Linux 服務運行。以下步驟在 Ubuntu 16.04 上測試,但應該適用於任何 Linux 發行版(稍作修改)。
## 使用 systemd
將示例 [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) 複製到 `/etc/systemd/system/gitea.service`,然後使用您喜歡的編輯器編輯該文件。
取消註釋需要在此主機上啟用的任何服務,例如 MySQL。
更改用戶、主目錄和其他所需的啟動值。如果使用默認端口,請更改 PORT 或刪除 -p 標誌。
在啟動時啟用並啟動 Gitea
```
sudo systemctl enable gitea
sudo systemctl start gitea
```
如果您擁有 systemd 版本 220 或更高版本,您可以一次性啟用並立即啟動 Gitea:
```
sudo systemctl enable gitea --now
```
## 使用 supervisor
通過在終端中運行以下命令安裝 supervisor
```
sudo apt install supervisor
```
為 supervisor 日誌創建一個日誌目錄:
```
# 假設 Gitea 安裝在 /home/git/gitea/
mkdir /home/git/gitea/log/supervisor
```
將示例中的配置附加到 `/etc/supervisor/supervisord.conf`
[supervisord 配置](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea)。
使用您喜歡的編輯器,更改用戶 (`git`) 和主目錄 (`/home/git`) 設置以匹配部署環境。如果使用默認端口,請更改 PORT 或刪除 -p 標誌。
最後在啟動時啟用並啟動 supervisor
```
sudo systemctl enable supervisor
sudo systemctl start supervisor
```
如果您擁有 systemd 版本 220 或更高版本,您可以一次性啟用並立即啟動 supervisor
```
sudo systemctl enable supervisor --now
```
@@ -0,0 +1,89 @@
---
date: "2021-09-02T16:00:00+08:00"
slug: "upgrade-from-gitea"
sidebar_position: 100
aliases:
- /zh-tw/upgrade-from-gitea
---
# 從舊版 Gitea 升級
按照以下步驟確保順利升級到新版本的 Gitea。
## 檢查變更日誌中的重大變更
為了使 Gitea 更好,一些重大變更是不可避免的,特別是對於大里程碑版本。
在升級之前,請閱讀 [Gitea 博客上的變更日誌](https://blog.gitea.com/)
並檢查這些重大變更是否會影響您的 Gitea 實例。
## 驗證沒有已棄用的配置選項
Gitea 的新版本通常會帶有更改的配置語法或選項,這些選項通常會在站點管理面板頂部顯示至少一個發布週期。如果這些警告未解決,Gitea 可能會拒絕在下一版本中啟動。
## 降級備份
Gitea 保持對補丁版本的兼容性,其前兩個字段相同(`a.b.x` -> `a.b.y`),
這些補丁版本可以使用相同的數據庫結構進行升級和降級。
否則(`a.b.?` -> `a.c.?`),較新的 Gitea 版本將升級舊數據庫
到可能與舊版本不同的新結構。
例如:
| 從 | 到 | 結果 |
| ----- | ----- | ------------------------------------------------------------------------------------------------- |
| 1.4.0 | 1.4.1 | ✅ |
| 1.4.1 | 1.4.0 | ⚠️ 不建議,請自行承擔風險!雖然如果數據庫結構沒有更改,它可能會工作,但強烈建議使用備份進行降級。 |
| 1.4.x | 1.5.y | ✅ 數據庫已升級。您可以直接從 1.4.x 升級到最新的 1.5.y。 |
| 1.5.y | 1.4.x | ❌ 數據庫已經升級,無法用於舊版 Gitea,請使用備份進行降級。 |
**由於您無法運行升級後的數據庫的舊版 Gitea,
在數據庫升級之前應始終進行備份。**
如果您在生產環境中使用 Gitea,強烈建議在升級之前進行備份,
即使升級是在補丁版本之間進行的。
備份步驟:
- 停止 Gitea 實例
- 備份數據庫
- 備份 Gitea 配置
- 備份 `APP_DATA_PATH` 中的 Gitea 數據文件
- 備份 Gitea 外部存儲(例如:S3/MinIO 或其他使用的存儲)
如果您使用雲服務或具有快照功能的文件系統,
為 Gitea 數據卷和相關對象存儲創建快照更方便。
在所有步驟準備就緒後,下載新版本,停止應用程序,執行備份,
然後啟動新應用程序。在每次啟動時,Gitea 會驗證數據庫是否是最新的,並自動
執行任何必要的遷移。根據數據庫的大小,這可能會在
首次啟動期間需要一些額外時間,期間應用程序將不可用。
## 使用 Docker 升級
- `docker pull` 最新的 Gitea 版本。
- 停止運行的實例,備份數據。
- 使用 `docker``docker-compose` 啟動較新的 Gitea Docker 容器。
## 從包升級
- 停止運行的實例,備份數據。
- 使用您的包管理器將 Gitea 升級到最新版本。
- 啟動 Gitea 實例。
## 從二進制文件升級
- 將最新的 Gitea 二進制文件下載到臨時目錄。
- 停止運行的實例,備份數據。
- 用下載的二進制文件替換已安裝的 Gitea 二進制文件。
- 啟動 Gitea 實例。
可以在 Gitea 的源代碼樹中找到一個自動執行這些步驟的腳本,用於在 Linux 上部署 [`contrib/upgrade.sh`](https://github.com/go-gitea/gitea/blob/main/contrib/upgrade.sh)。
## 注意自定義模板
Gitea 的模板結構和變量可能會在版本之間發生變化,如果您使用自定義模板,
請注意您的模板是否與您使用的 Gitea 版本兼容。
如果自定義模板與 Gitea 版本不匹配,您可能會遇到:
`50x` 服務器錯誤,頁面組件丟失或故障,頁面佈局異常,...
刪除或更新不兼容的模板,Gitea 網頁將再次正常工作。
@@ -0,0 +1,71 @@
---
date: "2016-12-21T15:00:00-02:00"
slug: "windows-service"
sidebar_position: 50
aliases:
- /zh-tw/windows-service
---
# 註冊為 Windows 服務
## 先決條件
在 C:\gitea\custom\conf\app.ini 中進行以下更改:
```ini title="app.ini"
RUN_USER = COMPUTERNAME$
```
將 Gitea 設置為以本地系統用戶身份運行。
COMPUTERNAME 是命令行中 `echo %COMPUTERNAME%` 的響應。如果響應是 `USER-PC`,則 `RUN_USER = USER-PC$`
### 使用絕對路徑
如果您使用 SQLite3,請更改 `PATH` 以包含完整路徑:
```ini title="app.ini"
[database]
PATH = c:/gitea/data/gitea.db
```
## 註冊 Gitea
要將 Gitea 註冊為 Windows 服務,請以管理員身份打開命令提示符 (cmd),
然後運行以下命令:
```sh
sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\""
```
不要忘記將 `C:\gitea` 替換為正確的 Gitea 目錄。
打開“Windows 服務”,搜索名為“gitea”的服務,右鍵單擊它並單擊
“運行”。如果一切正常,Gitea 將在 `http://localhost:3000`(或配置的端口)上可訪問。
### 服務啟動類型
觀察到在加載系統期間啟動時,Gitea 服務可能會在 Windows 事件日誌中記錄超時並且無法啟動。
在這種情況下,將啟動類型更改為“自動延遲”。這可以在服務創建期間完成,也可以通過運行配置命令完成
```sh
sc.exe config gitea start= delayed-auto
```
### 添加啟動依賴項
要向 Gitea Windows 服務添加啟動依賴項(例如 Mysql、Mariadb),請以管理員身份運行以下命令:
```sh
sc.exe config gitea depend= mariadb
```
這將確保當 Windows 機器重新啟動時,Gitea 的自動啟動將推遲到數據庫準備就緒,從而減少啟動失敗。
## 註銷 Gitea
要將 Gitea 註銷為 Windows 服務,請以管理員身份打開命令提示符 (cmd) 並運行:
```sh
sc.exe delete gitea
```
@@ -0,0 +1,362 @@
---
date: "2020-02-09T20:00:00+02:00"
slug: "install-with-docker-rootless"
sidebar_position: 60
aliases:
- /zh-tw/install-with-docker-rootless
---
# 使用 Docker(無根)安裝
Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以
始終使用最新的穩定標籤或使用另一個處理更新的服務
Docker 映像。
無根映像使用 Gitea 內部 SSH 提供 Git 協議,不支持 OpenSSH。
此參考設置指導用戶通過基於 `docker-compose` 的設置,但 `docker-compose` 的安裝
不在本文檔的範圍內。要安裝 `docker-compose` 本身,請遵循
官方[安裝說明](https://docs.docker.com/compose/install/)。
## 基礎
最簡單的設置只是創建一個卷和一個網絡,並啟動 `docker.gitea.com/gitea:latest-rootless`
作為服務的映像。由於沒有可用的數據庫,可以使用 SQLite3 進行初始化。
`data``config` 創建一個目錄:
```sh
mkdir -p gitea/{data,config}
cd gitea
touch docker-compose.yml
```
然後將以下內容粘貼到名為 `docker-compose.yml` 的文件中:
```yaml
version: "2"
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
```
請注意,卷應由配置文件中指定的 UID/GID 的用戶/組擁有。默認情況下,docker 中的 Gitea 將使用 uid:1000 gid:1000。如果需要,您可以使用以下命令設置這些文件夾的所有權:
```sh
sudo chown 1000:1000 config/ data/
```
> 如果您未授予卷正確的權限,則容器可能無法啟動。
對於穩定版本,您可以使用 `:latest-rootless``:1-rootless` 或指定某個版本,例如 `:@dockerVersion@-rootless`,但如果您想使用最新的開發版本,則 `:nightly-rootless` 將是一個合適的標籤。如果您想運行來自發布分支的最新提交,您可以使用 `:1.x-nightly-rootless` 標籤,其中 x 是 Gitea 的次要版本。(例如 `:1.16-nightly-rootless`
## 自定義端口
要在不同的端口上綁定集成的 ssh 和 web 服務器,請調整
端口部分。通常只需更改主機端口並保持容器內的端口不變。
```diff
version: "2"
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- - "3000:3000"
- - "2222:2222"
+ - "80:3000"
+ - "22:2222"
```
## MySQL 數據庫
要將 Gitea 與 MySQL 數據庫結合使用,請將這些更改應用到
上面創建的 `docker-compose.yml` 文件。
```diff
version: "2"
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
+ environment:
+ - GITEA__database__DB_TYPE=mysql
+ - GITEA__database__HOST=db:3306
+ - GITEA__database__NAME=gitea
+ - GITEA__database__USER=gitea
+ - GITEA__database__PASSWD=gitea
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
+ depends_on:
+ - db
+
+ db:
+ image: docker.io/library/mysql:8
+ restart: always
+ environment:
+ - MYSQL_ROOT_PASSWORD=gitea
+ - MYSQL_USER=gitea
+ - MYSQL_PASSWORD=gitea
+ - MYSQL_DATABASE=gitea
+ volumes:
+ - ./mysql:/var/lib/mysql
```
## PostgreSQL 數據庫
要將 Gitea 與 PostgreSQL 數據庫結合使用,請將這些更改應用到
上面創建的 `docker-compose.yml` 文件。
```diff
version: "2"
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
environment:
+ - GITEA__database__DB_TYPE=postgres
+ - GITEA__database__HOST=db:5432
+ - GITEA__database__NAME=gitea
+ - GITEA__database__USER=gitea
+ - GITEA__database__PASSWD=gitea
restart: always
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
+ depends_on:
+ - db
+
+ db:
+ image: docker.io/library/postgres:14
+ restart: always
+ environment:
+ - POSTGRES_USER=gitea
+ - POSTGRES_PASSWORD=gitea
+ - POSTGRES_DB=gitea
+ volumes:
+ - ./postgres:/var/lib/postgresql/data
```
## 命名卷
要使用命名卷而不是主機卷,請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動
創建所需的卷。您不需要擔心命名卷的權限;Docker 會自動處理。
```diff
version: "2"
+volumes:
+ gitea-data:
+ driver: local
+ gitea-config:
+ driver: local
+
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
restart: always
volumes:
- - ./data:/var/lib/gitea
+ - gitea-data:/var/lib/gitea
- - ./config:/etc/gitea
+ - gitea-config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
```
MySQL 或 PostgreSQL 容器需要單獨創建。
## 自定義用戶
您可以選擇使用自定義用戶(遵循 --user 標誌定義 https://docs.docker.com/engine/reference/run/#user)。
例如,要克隆主機用戶 `git` 定義,請使用命令 `id -u git` 並將其添加到 `docker-compose.yml` 文件中:
請確保掛載的文件夾可由用戶寫入。
```diff
version: "2"
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@-rootless
restart: always
+ user: 1001
volumes:
- ./data:/var/lib/gitea
- ./config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "2222:2222"
```
## 啟動
:::note
從 2023 年 7 月起,Compose V1 停止接收更新。它也不再可用於 Docker Desktop 的新版本中。
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
:::
要基於 `docker-compose` 啟動此設置,請執行 `docker-compose up -d`
在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否
正確啟動。可以使用 `docker-compose logs` 查看日誌。
要關閉設置,請執行 `docker-compose down`。這將停止
並殺死容器。卷將仍然存在。
:::note
如果在 http 上使用非 3000 端口,請更改 app.ini 以匹配
`LOCAL_ROOT_URL = http://localhost:3000/`
:::
## 安裝
通過 `docker-compose` 啟動 Docker 設置後,應該可以使用
喜愛的瀏覽器完成安裝。訪問 http://server-ip:3000 並按照
安裝向導進行操作。如果數據庫是使用 `docker-compose` 設置啟動的,
如上所述,請注意 `db` 必須用作數據庫主機名。
## 自定義
[此處](../administration/customizing-gitea.md) 描述的自定義文件應
放置在 `/var/lib/gitea/custom` 目錄中。如果使用主機卷,則可以很容易地訪問這些
文件;對於命名卷,這是通過另一個容器或直接訪問
`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea` 來完成的。配置文件將保存在
安裝後的 `/etc/gitea/app.ini` 中。
## 升級
:::warning
:exclamation::exclamation: **確保您已將數據卷掛載到 Docker 容器外的某個位置** :exclamation::exclamation:
:::
要將您的安裝升級到最新版本:
```bash
# 編輯 `docker-compose.yml` 以更新版本(如果已指定)
# 拉取新映像
docker-compose pull
# 啟動新容器,自動刪除舊容器
docker-compose up -d
```
## 從標準映像升級
- 備份您的設置
- 將卷掛載點從 /data 更改為 /var/lib/gitea
- 如果您使用了自定義 app.ini,請將其移動到掛載到 /etc/gitea 的新卷中
- 將文件夾(在卷內)重命名為 gitea 為 custom
- 如有需要,編輯 app.ini
- 設置 START_SSH_SERVER = true
- 使用映像 docker.gitea.com/gitea:@dockerVersion@-rootless
## 使用環境變量管理部署
除了上述環境變量外,`app.ini` 中的任何設置都可以設置
或使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量覆蓋。
這些設置在每次 docker 容器啟動時應用,不會傳遞到 Gitea 的子進程中。
完整信息[此處](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini)。
這些環境變量可以在 `docker-compose.yml` 中傳遞給 docker 容器。
以下示例將啟用 smtp 郵件服務器,如果所需的環境變量
`GITEA__mailer__FROM``GITEA__mailer__HOST``GITEA__mailer__PASSWD` 在主機上設置
或在與 `docker-compose.yml` 相同的目錄中的 `.env` 文件中設置。
這些設置也可以通過定義形式為的環境變量來設置或覆蓋:
`GITEA__section_name__KEY_NAME__FILE` 指向文件。
```bash
...
services:
server:
environment:
- GITEA__mailer__ENABLED=true
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
- GITEA__mailer__PROTOCOL=smtp
- GITEA__mailer__HOST=${GITEA__mailer__HOST:?GITEA__mailer__HOST not set}
- GITEA__mailer__IS_TLS_ENABLED=true
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
```
要設置所需的 TOKEN 和 SECRET 值,請考慮使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。
# SSH 容器透傳
由於 SSH 在容器內運行,因此如果需要 SSH 支持,則需要將 SSH 從主機透傳到容器。一種選擇是將容器 SSH 運行在非標準端口上(或將主機端口移動到非標準端口)。另一種可能更直接的方法是將 SSH 命令從主機轉發到容器。以下說明了這種設置。
本指南假設您已在主機上創建了一個名為 `git` 的用戶,該用戶有權運行 `docker exec`,並且 Gitea 容器名為 `gitea`。您需要修改該用戶的 shell 以使用 `docker exec` 將命令轉發到容器內的 `sh` 可執行文件。
首先,在主機上創建文件 `/usr/local/bin/gitea-shell`,內容如下:
```bash
#!/bin/sh
/usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@"
```
請注意,docker 命令中的 `gitea` 是容器的名稱。如果您命名不同,請不要忘記更改它。
您還應確保已正確設置 shell 包裝器的權限:
```bash
sudo chmod +x /usr/local/bin/gitea-shell
```
包裝器就位後,您可以將其設置為 `git` 用戶的 shell
```bash
sudo usermod -s /usr/local/bin/gitea-shell git
```
現在所有的 SSH 命令都轉發到容器,您需要在主機上設置 SSH 認證。這是通過利用 [SSH AuthorizedKeysCommand](../administration/command-line.md#keys) 將密鑰與 Gitea 接受的密鑰匹配來完成的。在主機上的 `/etc/ssh/sshd_config` 中添加以下塊:
```bash
Match User git
AuthorizedKeysCommandUser git
AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -c /etc/gitea/app.ini -e git -u %u -t %t -k %k
```
(從 1.16.0 開始,您不需要設置 `-c /etc/gitea/app.ini` 選項。)
剩下的就是重啟 SSH 服務器:
```bash
sudo systemctl restart sshd
```
**注意**
這實際上並未使用 docker SSH - 它只是使用周圍的命令。
理論上,您可以不運行內部 SSH 服務器。
@@ -0,0 +1,345 @@
---
date: "2020-03-19T19:27:00+02:00"
slug: "install-with-docker"
sidebar_position: 70
aliases:
- /zh-tw/install-with-docker
---
# 使用 Docker 安裝
Gitea 在其 Docker Hub 組織中提供自動更新的 Docker 映像。可以始終使用最新的穩定標籤或使用其他服務來處理 Docker 映像的更新。
此參考設置指導用戶基於 `docker-compose` 進行設置,但 `docker-compose` 的安裝不在本文檔的範圍內。要安裝 `docker-compose` 本身,請按照官方的[安裝說明](https://docs.docker.com/compose/install/)進行操作。
## 基本
最簡單的設置只需創建一個卷和一個網絡,並將 `docker.gitea.com/gitea:latest` 映像作為服務啟動。由於沒有可用的數據庫,可以使用 SQLite3 進行初始化。創建一個名為 `gitea` 的目錄,並將以下內容粘貼到名為 `docker-compose.yml` 的文件中。請注意,卷應由配置文件中指定的 UID/GID 的用戶/組擁有。如果您未給卷正確的權限,容器可能無法啟動。對於穩定版本,您可以使用 `:latest``:1` 或指定某個版本,如 `:@dockerVersion@`,但如果您想使用 Gitea 的最新開發版本,則可以使用 `:nightly` 標籤。如果您想運行來自發布分支的最新提交,可以使用 `:1.x-nightly` 標籤,其中 x 是 Gitea 的次要版本。(例如 `:1.16-nightly`
```yaml
version: "3"
networks:
gitea:
external: false
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
```
## 端口
要在不同的端口上綁定集成的 OpenSSH 守護進程和 Web 服務器,請調整端口部分。通常只需更改主機端口並保持容器內的端口不變。
```diff
version: "3"
networks:
gitea:
external: false
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- - "3000:3000"
- - "222:22"
+ - "8080:3000"
+ - "2221:22"
```
## 數據庫
### MySQL 數據庫
要將 Gitea 與 MySQL 數據庫結合使用,請對上面創建的 `docker-compose.yml` 文件進行以下更改。
```diff
version: "3"
networks:
gitea:
external: false
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
+ - GITEA__database__DB_TYPE=mysql
+ - GITEA__database__HOST=db:3306
+ - GITEA__database__NAME=gitea
+ - GITEA__database__USER=gitea
+ - GITEA__database__PASSWD=gitea
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
+ depends_on:
+ - db
+
+ db:
+ image: docker.io/library/mysql:8
+ restart: always
+ environment:
+ - MYSQL_ROOT_PASSWORD=gitea
+ - MYSQL_USER=gitea
+ - MYSQL_PASSWORD=gitea
+ - MYSQL_DATABASE=gitea
+ networks:
+ - gitea
+ volumes:
+ - ./mysql:/var/lib/mysql
```
### PostgreSQL 數據庫
要將 Gitea 與 PostgreSQL 數據庫結合使用,請對上面創建的 `docker-compose.yml` 文件進行以下更改。
```diff
version: "3"
networks:
gitea:
external: false
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
+ - GITEA__database__DB_TYPE=postgres
+ - GITEA__database__HOST=db:5432
+ - GITEA__database__NAME=gitea
+ - GITEA__database__USER=gitea
+ - GITEA__database__PASSWD=gitea
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
+ depends_on:
+ - db
+
+ db:
+ image: docker.io/library/postgres:14
+ restart: always
+ environment:
+ - POSTGRES_USER=gitea
+ - POSTGRES_PASSWORD=gitea
+ - POSTGRES_DB=gitea
+ networks:
+ - gitea
+ volumes:
+ - ./postgres:/var/lib/postgresql/data
```
## 命名卷
要使用命名卷而不是主機卷,請在 `docker-compose.yml` 配置中定義並使用命名卷。此更改將自動創建所需的卷。使用命名卷時,您不需要擔心權限問題;Docker 會自動處理。
```diff
version: "3"
networks:
gitea:
external: false
+volumes:
+ gitea:
+ driver: local
+
services:
server:
image: docker.gitea.com/gitea:@dockerVersion@
container_name: gitea
restart: always
networks:
- gitea
volumes:
- - ./gitea:/data
+ - gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
```
MySQL 或 PostgreSQL 容器需要單獨創建。
## 啟動
:::note
從 2023 年 7 月起,Compose V1 停止接收更新。它也不再包含在 Docker Desktop 的新版本中。
Compose V2 包含在所有當前支持的 Docker Desktop 版本中。請使用 V2 進行以下操作。
:::
要基於 `docker-compose` 啟動此設置,請執行 `docker-compose up -d`,以在後台啟動 Gitea。使用 `docker-compose ps` 將顯示 Gitea 是否正確啟動。可以使用 `docker-compose logs` 查看日誌。
要關閉設置,請執行 `docker-compose down`。這將停止並殺死容器。卷仍然存在。
:::note
如果在 http 上使用非 3000 端口,請更改 app.ini 以匹配 `LOCAL_ROOT_URL = http://localhost:3000/`
:::
## 安裝
通過 `docker-compose` 啟動 Docker 設置後,應該可以使用喜愛的瀏覽器來完成安裝。訪問 http://server-ip:3000 並按照安裝向導進行操作。如果數據庫是使用上述 `docker-compose` 設置啟動的,請注意,數據庫主機名必須使用 `db`
## 使用環境變量配置 Gitea 內的用戶
- `USER`: **git**: 在容器內運行 Gitea 的用戶名。
- `USER_UID`: **1000**: 在容器內運行 Gitea 的用戶的 UID(Unix 用戶 ID)。如果使用主機卷,請將其與 `/data` 卷的所有者的 UID 匹配(使用命名卷時不需要)。
- `USER_GID`: **1000**: 在容器內運行 Gitea 的用戶的 GID(Unix 組 ID)。如果使用主機卷,請將其與 `/data` 卷的所有者的 GID 匹配(使用命名卷時不需要)。
## 自定義
[此處](../administration/customizing-gitea.md)描述的自定義文件應放置在 `/data/gitea` 目錄中。如果使用主機卷,訪問這些文件非常容易;對於命名卷,可以通過另一個容器或直接訪問 `/var/lib/docker/volumes/gitea_gitea/_data` 來完成。安裝後,配置文件將保存在 `/data/gitea/conf/app.ini`
## 升級
:::warning
確保您已將卷數據保存到 Docker 容器外的某個位置
:::
要將您的安裝升級到最新版本:
```bash
# 編輯 `docker-compose.yml` 以更新版本(如果已指定)
# 拉取新映像
docker-compose pull
# 啟動新容器,自動刪除舊容器
docker-compose up -d
```
## 使用環境變量管理部署
除了上述的環境變量外,`app.ini` 中的任何設置都可以使用形式為 `GITEA__SECTION_NAME__KEY_NAME` 的環境變量進行設置或覆蓋。這些設置在每次 Docker 容器啟動時應用,不會傳遞到 Gitea 的子進程中。完整信息[在此](https://github.com/go-gitea/gitea/tree/master/contrib/environment-to-ini)。
這些環境變量可以在 `docker-compose.yml` 中傳遞給 Docker 容器。以下示例將在設置所需的環境變量 `GITEA__mailer__FROM``GITEA__mailer__HOST``GITEA__mailer__PASSWD` 時啟用 SMTP 郵件服務器。
這些設置也可以通過定義形式為 `GITEA__section_name__KEY_NAME__FILE` 的環境變量並指向文件的內容來設置或覆蓋。
```yaml
---
services:
server:
environment:
- GITEA__mailer__ENABLED=true
- GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
- GITEA__mailer__PROTOCOL=smtps
- GITEA__mailer__SMTP_ADDR=${GITEA__mailer__SMTP_ADDR:?GITEA__mailer__SMTP_ADDR not set}
- GITEA__mailer__SMTP_PORT=${GITEA__mailer__SMTP_PORT:?GITEA__mailer__SMTP_PORT not set}
- GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
- GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
```
Gitea 將自動為每個新安裝生成新的密鑰/令牌並將其寫入 app.ini。如果您想手動設置密鑰/令牌,可以使用以下 Docker 命令來使用 Gitea 的內置[生成實用程序函數](../administration/command-line.md#generate)。安裝後請勿丟失/更改您的 SECRET_KEY,否則加密數據將無法解密。
以下命令將輸出新的 `SECRET_KEY``INTERNAL_TOKEN``stdout`,然後您可以將其放置在您的環境變量中。
```bash
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret SECRET_KEY
docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret INTERNAL_TOKEN
```
```yaml
---
services:
server:
environment:
- GITEA__security__SECRET_KEY=[value returned by generate secret SECRET_KEY]
- GITEA__security__INTERNAL_TOKEN=[value returned by generate secret INTERNAL_TOKEN]
```
## SSH 容器透傳
由於 SSH 在容器內運行,如果需要 SSH 支持,則需要將 SSH 從主機透傳到容器。一個選項是將容器 SSH 運行在非標準端口(或將主機端口移動到非標準端口)。另一個可能更直接的選項是讓 Gitea 用戶 SSH 到主機上的 Gitea 用戶,然後將這些連接中繼到 Docker。或者,如果主機有多個 IP 地址,主機可以在一個上監聽,Gitea 在另一個上監聽。
### 理解對 Gitea 的 SSH 訪問(無需透傳)
要理解需要發生什麼,首先需要理解在沒有透傳的情況下會發生什麼。因此,我們將嘗試解釋這一點:
1. 客戶端使用網頁將其 SSH 公鑰添加到 Gitea。
2. Gitea 將為此密鑰在其運行用戶 `git``.ssh/authorized_keys` 文件中添加一個條目。
3. 此條目具有公鑰,但也具有 `command=` 選項。Gitea 使用此命令將此密鑰與客戶端用戶匹配並管理身份驗證。
4. 然後,客戶端使用 `git` 用戶向 SSH 服務器發出 SSH 請求,例如 `git clone git@domain:user/repo.git`
5. 客戶端將嘗試與服務器進行身份驗證,一次向服務器傳遞一個或多個公鑰。
6. 對於客戶端提供的每個密鑰,SSH 服務器將首先檢查其配置中的 `AuthorizedKeysCommand` 以查看公鑰是否匹配,然後檢查 `git` 用戶的 `authorized_keys` 文件。
7. 將選擇第一個匹配的條目,假設這是 Gitea 條目,則現在將執行 `command=`
8. SSH 服務器為 `git` 用戶創建一個用戶會話,並使用 `git` 用戶的 shell 運行 `command=`
9. 這將運行 `gitea serv`,接管 SSH 會話的其餘部分並管理 gitea 的身份驗證和授權。
現在,要使 SSH 透傳工作,我們需要主機 SSH 匹配公鑰,然後在 Docker 上運行 `gitea serv`。有多種方法可以做到這一點。然而,所有這些都需要將有關 Docker 的一些信息傳遞給主機。
### SSHing Shim(使用 authorized_keys
在此選項中,主機只需使用 gitea 創建的 `authorized_keys`,但在第 9 步中,主機運行的 `gitea` 命令是一個 shim,實際上運行 ssh 進入 docker,然後運行真正的 docker `gitea` 本身。
- 要使轉發工作,容器的 SSH 端口(22)需要在 `docker-compose.yml` 中映射到主機端口 2222。由於此端口不需要暴露給外界,因此可以映射到主機的 `localhost`
```yaml
ports:
# [...]
- "127.0.0.1:2222:22"
```
- 接下來在主機上創建與容器值 `USER_UID`/`USER_GID` 共享相同 `UID`/`GID` 的 `git` 用戶。這些值可以在 `docker-compose.yml` 中設置為環境變量:
```yaml
environment:
- USER_UID=1000
- USER_GID=1000
```
- 將主機的 `/home/git/.ssh` 安裝到容器中。這確保了 `authorized_keys` 文件在主機 `git` 用戶和容器 `git` 用戶之間共享,否則 SSH 身份驗證無法在容器內工作。
```yaml
volumes:
- /home/git/.ssh/:/data/git/.ssh
```
- 現在需要在主機