github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 13:49:15 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #1438] Headless/declarative setup (no dashboard) #6706

New Issue
Closed
opened 2026-04-25 15:36:58 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-25 15:36:58 -05:00
Owner
Copy Link

Originally created by @oschwartz10612 on GitHub (Sep 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1438

Originally assigned to: @oschwartz10612 on GitHub.

Discussed in https://github.com/orgs/fosrl/discussions/952

Originally posted by dystopiandev June 20, 2025
I've noticed the recommended way to programmatically setup pangolin is via the integration api, and that works with an api key, which one must logon to the admin dash to create. If it were possible to provide some init/seed data for sites, resources, etc, that would make it easier to provision in IaC.

Is it possible or planned to have pangolin setup entirely with no usage of the web ui, or have I missed a guide in the docs for achieving exactly this?

Originally created by @oschwartz10612 on GitHub (Sep 8, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1438 Originally assigned to: @oschwartz10612 on GitHub. ### Discussed in https://github.com/orgs/fosrl/discussions/952 <div type='discussions-op-text'> <sup>Originally posted by **dystopiandev** June 20, 2025</sup> I've noticed the recommended way to programmatically setup pangolin is via the integration api, and that works with an api key, which one must logon to the admin dash to create. If it were possible to provide some init/seed data for sites, resources, etc, that would make it easier to provision in IaC. Is it possible or planned to have pangolin setup entirely with no usage of the web ui, or have I missed a guide in the docs for achieving exactly this?</div>
GiteaMirror commented 2026-04-25 15:37:00 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Sep 8, 2025):

Also discussed in:

https://github.com/orgs/fosrl/discussions/108
https://github.com/orgs/fosrl/discussions/182

<!-- gh-comment-id:3264533192 --> @oschwartz10612 commented on GitHub (Sep 8, 2025): Also discussed in: https://github.com/orgs/fosrl/discussions/108 https://github.com/orgs/fosrl/discussions/182
GiteaMirror commented 2026-04-25 15:37:00 -05:00
Author
Owner
Copy Link

@marcschaeferger commented on GitHub (Sep 8, 2025):

@oschwartz10612 Thanks for moving this forward!

To make Pangolin future-proof and seamlessly integrable into CI/CD and IaC deployment workflows and to align with industry best practices, I suggest we combine the following approaches:

1. Kubernetes Operator for Declarative Management

I’ve already opened Issue #1439 for this.
A Kubernetes Operator would allow full management of Pangolin through CRDs (Custom Resources):

  • Automated initial bootstrap (Admin user + API Key seeded from Kubernetes Secrets).
  • All entities (sites, resources, endpoints, users, etc.) managed as declarative YAML manifests.
  • Continuous reconciliation of the desired state by the Operator (following the established Kubernetes pattern).
  • Enables GitOps flows through ArgoCD, Flux, etc.

As discussed, only alignment/agreements and some optimizations plus documentation remain. Before that, I would also like to complete full OTEL integration, security hardening, and further Docker image improvements.

2. Bootstrap and Seed Config for Docker & Traditional Deployments

For non-Kubernetes environments, a declarative configuration approach should also be possible:

  • bootstrap.yaml: One-time initialization for admin account and API key (run only at first startup).
  • seed.yaml: Idempotent application of initial resources.

Example:

bootstrap:
  createAdmin: true
  adminUser: admin
  adminPassword: (provided via ENV or auto-generated)
  createApiKey: true
  # API key is generated and logged only once at startup

seed:
  enabled: true
  path: /etc/pangolin/seed.yaml

Example: Docker Compose

services:
  pangolin:
    image: pangolin:1.9.4
    volumes:
      - ./bootstrap.yaml:/etc/pangolin/bootstrap.yaml
      - ./seed.yaml:/etc/pangolin/seed.yaml
    environment:
      PANGOLIN_ADMIN_PASSWORD: "${PANGOLIN_ADMIN_PASSWORD}"

3. CLI Tool (pangolinctl) for Declarative Management

After the bootstrap process, a dedicated CLI tool (similar to ceph, calicoctl, grafanactl or even kubectl) could provide:

  • Applying/updating resources from local files.
  • Exporting the current configuration (ideal for GitOps pull workflows).
  • API-connected mode for automation pipelines.

→ Ideally, both the Operator and CLI provide the same capabilities, ensuring parity between Kubernetes, Docker, and VM installations. They could both call a REST API for the Configuration. One Example: https://grafana.com/docs/grafana/latest/observability-as-code/grafana-cli/

4. Advantages of This Approach

  • Works in cloud-native (Kubernetes) and traditional (VM, bare metal, Docker) environments.
  • Enables completely UI-free provisioning.
  • 100% compatible with GitOps, CI/CD, and secret management solutions (Vault, SOPS, etc.).
  • Reproducible, idempotent deployments.

Tasks

  • Finalize schema definitions for bootstrap.yaml and seed.yaml.
  • Implement startup logic to detect and apply bootstrap/seed files on first launch.
  • Agree on CRD structure in #1439 for fully declarative Kubernetes-native control.
  • Develop a CLI concept for functional parity with the UI.

I’d be happy to contribute by helping draft a design document, creating sample manifests/configs, and assisting with implementation.

<!-- gh-comment-id:3264683273 --> @marcschaeferger commented on GitHub (Sep 8, 2025): @oschwartz10612 Thanks for moving this forward! To make Pangolin future-proof and seamlessly integrable into CI/CD and IaC deployment workflows and to align with industry best practices, I suggest we combine the following approaches: ## 1. **Kubernetes Operator for Declarative Management** I’ve already opened [Issue #1439](#1439) for this. A Kubernetes Operator would allow full management of Pangolin through CRDs (Custom Resources): - Automated initial bootstrap (Admin user + API Key seeded from Kubernetes Secrets). - All entities (sites, resources, endpoints, users, etc.) managed as declarative YAML manifests. - Continuous reconciliation of the desired state by the Operator (following the established Kubernetes pattern). - Enables GitOps flows through ArgoCD, Flux, etc. As discussed, only alignment/agreements and some optimizations plus documentation remain. Before that, I would also like to complete full OTEL integration, security hardening, and further Docker image improvements. --- ## 2. **Bootstrap and Seed Config for Docker & Traditional Deployments** For non-Kubernetes environments, a declarative configuration approach should also be possible: - **`bootstrap.yaml`**: One-time initialization for admin account and API key (run only at first startup). - **`seed.yaml`**: Idempotent application of initial resources. **Example:** ```yaml bootstrap: createAdmin: true adminUser: admin adminPassword: (provided via ENV or auto-generated) createApiKey: true # API key is generated and logged only once at startup seed: enabled: true path: /etc/pangolin/seed.yaml ``` **Example: Docker Compose** ```yaml services: pangolin: image: pangolin:1.9.4 volumes: - ./bootstrap.yaml:/etc/pangolin/bootstrap.yaml - ./seed.yaml:/etc/pangolin/seed.yaml environment: PANGOLIN_ADMIN_PASSWORD: "${PANGOLIN_ADMIN_PASSWORD}" ``` --- ## 3. **CLI Tool (`pangolinctl`) for Declarative Management** After the bootstrap process, a dedicated CLI tool (similar to `ceph`, `calicoctl`, `grafanactl` or even `kubectl`) could provide: - Applying/updating resources from local files. - Exporting the current configuration (ideal for GitOps pull workflows). - API-connected mode for automation pipelines. → Ideally, both the Operator and CLI provide the same capabilities, ensuring parity between Kubernetes, Docker, and VM installations. They could both call a REST API for the Configuration. One Example: https://grafana.com/docs/grafana/latest/observability-as-code/grafana-cli/ --- ## 4. **Advantages of This Approach** - Works in **cloud-native** (Kubernetes) and **traditional** (VM, bare metal, Docker) environments. - Enables **completely UI-free** provisioning. - 100% compatible with **GitOps**, **CI/CD**, and secret management solutions (Vault, SOPS, etc.). - Reproducible, **idempotent deployments**. --- ### Tasks - Finalize schema definitions for `bootstrap.yaml` and `seed.yaml`. - Implement startup logic to detect and apply bootstrap/seed files on first launch. - Agree on CRD structure in [#1439](#1439) for fully declarative Kubernetes-native control. - Develop a CLI concept for functional parity with the UI. I’d be happy to contribute by helping draft a design document, creating sample manifests/configs, and assisting with implementation.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#6706
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?