tcjlj/OpenFlare
1
0
Fork 0
mirror of https://github.com/Rain-kl/OpenFlare.git synced 2026-10-11 17:56:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

[新增] 同步更新英文版文档

Browse Source
This commit is contained in:
ryan
2026-05-28 23:00:48 +08:00
parent 95d58eb724
commit b0117b7c84
11 changed files with 870 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/guide/first-site.md
+81 -13
View File
@@ -1,32 +1,100 @@
# Publish First Site
# Publishing Your First Configuration
OpenFlare publishes complete configuration versions. After editing a site, publish and activate a new version before Agents apply it.
You will learn: How to create your first site configuration, bind origins and certificates, publish a configuration version, and confirm that the Agent has applied it.
OpenFlare's release link is centered on complete configuration versions. After modifying site configurations on the management console, you need to publish and activate the new version before the Agent pulls and applies it in subsequent heartbeats.
## Pre-release Check
Confirm that the following conditions are met:
| Project | Expectation |
| --- | --- |
| Server | Can log into the management console |
| Agent | At least one node is online |
| Origin | The Agent node can access the origin address |
| Domain | The domain has been resolved to the OpenResty node, or you are ready to verify via local hosts / curl Host header |
| HTTPS | If HTTPS is required, the certificate has been uploaded or hosted |
## Create Site Configuration
Required fields:
When adding a site configuration on the management console, you need at least:
| Field | Description |
| --- | --- |
| Site name | Business-unique identifier; defaults to the primary domain when omitted |
| Domains | At least one domain; the first one is the primary domain |
| Origin URL | Valid `http://` or `https://` upstream URL |
| Enabled | Only enabled sites are rendered into releases |
| Site Name | Unique business identifier; defaults to the primary domain when omitted |
| Domains | At least one domain; the first item is treated as the primary domain |
| Origin URL | Valid `http://` or `https://` upstream address |
| Enabled | Only enabled site configurations participate in release rendering |
A domain can belong to only one site.
Example:
| Field | Example |
| --- | --- |
| Site Name | `app` |
| Domains | `app.example.com` |
| Origin URL | `http://10.0.0.20:8080` |
A domain can belong to only one site configuration. Site-level rate limits, reverse proxies, and cache configurations are shared by site.
## Bind Certificates
HTTPS certificates are bound per domain. Domains without certificates are not automatically rendered into `443 ssl` server blocks.
HTTPS certificates are bound per domain. Domains not bound to certificates will not be automatically placed in `443 ssl` server blocks.
If a site contains multiple domains, the publishing rendering will generate HTTPS configurations grouped by certificate and ensure all domains still belong to the same site snapshot.
## Publish and Activate
Standard link:
```text
Edit rules -> Preview / diff -> Publish -> Create full version -> Activate -> Agent pulls -> Agent applies -> Agent reports
Modify rules -> Preview / View diff -> Publish -> Generate complete configuration version -> Activate version -> Agent pulls -> Local application -> Report result
```
Server reads enabled sites, OpenResty template, performance options, and cache options, renders a full configuration, computes `checksum`, writes `config_versions`, then switches the active version.
When publishing, the Server reads all enabled site configurations, OpenResty main configuration templates, performance parameters, and cache parameters, renders the complete OpenResty configuration, calculates the `checksum`, writes to `config_versions`, and then switches the activated version.
## Verify
## Verify Results
Check that the node is online, the node version matches the active version, the latest apply log succeeded, and the version page marks the new version as active.
After publishing, confirm on the management console:
| Location | Expected Result |
| --- | --- |
| Node List | Node is online |
| Node Details | The current version is consistent with the activated version |
| Apply Logs | The most recent application succeeded |
| Version Page | The new version is in the activated state |
Confirm the Agent logs on the node:
```bash
journalctl -u openflare-agent -n 100 --no-pager
```
Access using the domain:
```bash
curl -I http://app.example.com
```
If the domain has not been officially resolved yet, you can temporarily specify the Host header to access the node IP:
```bash
curl -I -H 'Host: app.example.com' http://NODE_IP
```
HTTPS verification:
```bash
curl -I https://app.example.com
```
## Rollback
If the target version application fails and rolls back, the Agent will block repeated applications of the same `version + checksum` locally until the activated version or checksum on the control plane changes.
To roll back to an older version:
1. Open the configuration version page.
2. Find the previous confirmed working historical version.
3. Reactivate that version.
4. View the node application records to confirm that the Agent applied it successfully.