docs: Add documentation for FlatRun Agent#152
Conversation
Add docs.json manifest and 5 markdown files covering overview, installation, configuration, API reference, and security.
Code Review SummaryThis PR adds comprehensive documentation for the FlatRun Agent, including installation guides, configuration references, and a full OpenAPI 3.2 specification. 🚀 Key Improvements
💡 Minor Suggestions
|
| enabled: true | ||
| api_keys: | ||
| - "your-secure-api-key-here" | ||
| jwt_secret: "generate-a-secure-random-string-here" |
There was a problem hiding this comment.
Hardcoding a specific instruction to generate a secret is better than using a placeholder string which might be accidentally left in production configurations.
| jwt_secret: "generate-a-secure-random-string-here" | |
| jwt_secret: "REPLACE_WITH_SECURE_RANDOM_STRING" |
nfebe
left a comment
There was a problem hiding this comment.
Instead of manually documenting all endpoints... we could introduce the openapi standard
| { "title": "Installation", "path": "docs/installation.md" }, | ||
| { "title": "Configuration", "path": "docs/configuration.md" }, | ||
| { "title": "API Reference", "path": "docs/api-reference.md" }, | ||
| { "title": "Plugin Architecture", "path": "docs/PLUGIN_ARCHITECTURE.md" }, |
There was a problem hiding this comment.
Consistency: All other documentation files use kebab-case (e.g., api-reference.md). It is recommended to rename PLUGIN_ARCHITECTURE.md to plugin-architecture.md for consistency and better URL readability in some static site generators.
| { "title": "Plugin Architecture", "path": "docs/PLUGIN_ARCHITECTURE.md" }, | |
| { "title": "Plugin Architecture", "path": "docs/plugin-architecture.md" }, |
|
|
||
| [Service] | ||
| Type=simple | ||
| User=root |
There was a problem hiding this comment.
Security Best Practice: Running the agent as root is generally discouraged unless strictly necessary. Since the agent primarily needs access to the Docker socket, it is safer to create a dedicated system user and add them to the docker group.
| User=root | |
| User=flatrun | |
| Group=docker |
| [Service] | ||
| Type=simple | ||
| User=root | ||
| WorkingDirectory=/opt/flatrun |
There was a problem hiding this comment.
The installation guide should include a step to create the /opt/flatrun directory, otherwise the service will fail to start due to a missing WorkingDirectory.
| WorkingDirectory=/opt/flatrun | |
| WorkingDirectory=/opt/flatrun | |
| # Ensure you run: sudo mkdir -p /opt/flatrun && sudo chown flatrun:flatrun /opt/flatrun |
| Type=simple | ||
| User=root | ||
| WorkingDirectory=/opt/flatrun | ||
| ExecStart=/usr/local/bin/flatrun-agent --config /opt/flatrun/config.yml |
There was a problem hiding this comment.
The systemd service unit points to a config file in /opt/flatrun/config.yml, but the guide doesn't explicitly mention copying the config file to this directory. Users following this guide step-by-step will encounter a failure on startup.
| ExecStart=/usr/local/bin/flatrun-agent --config /opt/flatrun/config.yml | |
| ExecStart=/usr/local/bin/flatrun-agent --config /opt/flatrun/config.yml | |
| # Note: Ensure you copy your config.yml to /opt/flatrun/ before starting. |
| @@ -0,0 +1,14057 @@ | |||
| openapi: 3.2.0 | |||
There was a problem hiding this comment.
The OpenAPI version 3.2.0 is not yet a standard officially supported by most tooling (3.0.x and 3.1.0 are standard). Using 3.1.0 is recommended for better compatibility with Swagger UI/Redoc.
| openapi: 3.2.0 | |
| openapi: 3.1.0 |
| ### Reference | ||
|
|
||
| ```yaml | ||
| deployments_path: /home/user/deployments |
There was a problem hiding this comment.
The example path /home/user/deployments is a user-specific path. For a system-wide agent, it's better to suggest a path like /var/lib/flatrun/deployments to match standard Linux directory hierarchies.
| deployments_path: /home/user/deployments | |
| deployments_path: /var/lib/flatrun/deployments |
|
|
||
| nginx: | ||
| container_name: nginx | ||
| config_path: /deployments/nginx/conf.d |
There was a problem hiding this comment.
The configuration example uses /deployments/nginx/conf.d as a path, while the deployments_path at the top of the file suggests /home/user/deployments. This might confuse users about where the nginx configuration should reside relative to the deployments root.
| config_path: /deployments/nginx/conf.d | |
| config_path: /var/lib/flatrun/nginx/conf.d |
| ```ini | ||
| [Unit] | ||
| Description=FlatRun Agent | ||
| After=network.target docker.service |
There was a problem hiding this comment.
Adding After=docker.service is good, but for better robustness, BindsTo=docker.service or PartOf=docker.service ensures the agent stops if the Docker daemon crashes or is stopped, which is critical since the agent depends entirely on it.
| After=network.target docker.service | |
| After=network.target docker.service | |
| BindsTo=docker.service |
|
|
||
| nginx: | ||
| container_name: nginx | ||
| config_path: /deployments/nginx/conf.d |
There was a problem hiding this comment.
Consistency issue: The config_path refers to /deployments/... but the global deployments_path (line 12) is defined as /home/user/deployments. Using relative paths or consistent absolute paths is recommended to prevent confusion.
| config_path: /deployments/nginx/conf.d | |
| config_path: /home/user/deployments/nginx/conf.d |
| [Unit] | ||
| Description=FlatRun Agent | ||
| After=network.target docker.service | ||
| Requires=docker.service |
There was a problem hiding this comment.
Adding Requires=docker.service ensures the service fails if Docker isn't available, but BindsTo=docker.service is even stronger, ensuring that if Docker is stopped or restarted, the FlatRun Agent follows suit.
| Requires=docker.service | |
| Requires=docker.service | |
| BindsTo=docker.service |
| @@ -0,0 +1,23 @@ | |||
| ## Security | |||
|
|
|||
There was a problem hiding this comment.
The security section is currently a list of troubleshooting tips and basics. Consider adding a specific section about Docker socket security, as providing access to /var/run/docker.sock is equivalent to giving root access to the host.
| ## Security | |
| - Use strong, unique API keys. | |
| - Generate a secure JWT secret: `openssl rand -base64 32`. | |
| - Run behind a reverse proxy (nginx) with HTTPS in production. | |
| - **Restrict Docker socket access**: Ensure only the `docker` group and the `flatrun` user can access the socket. Avoid exposing the socket over TCP. | |
| - Keep the agent updated. |
| enabled: true | ||
| api_keys: | ||
| - "your-secure-api-key-here" | ||
| jwt_secret: "REPLACE_WITH_SECURE_RANDOM_STRING" # generate via: openssl rand -base64 32 |
There was a problem hiding this comment.
Security risk: While the comment suggests generating a secret, providing a placeholder in a documentation snippet often leads to users leaving it as-is. It is safer to use a prompt that clearly indicates action is required.
| jwt_secret: "REPLACE_WITH_SECURE_RANDOM_STRING" # generate via: openssl rand -base64 32 | |
| + jwt_secret: "GENERATED_VIA_OPENSSL_RAND" # generate via: openssl rand -base64 32 |
Add docs.json manifest and 5 markdown files covering overview, installation, configuration, API reference, and security.