Kubernetes powered PaaS that runs in your own cloud. https://porter.run
|
|
5 лет назад | |
|---|---|---|
| cli | 2878611187 comment | 5 лет назад |
| cmd | 3ca584ab73 init on startup | 5 лет назад |
| dashboard | 4c21affec1 graph yaml scroll and resize fixed | 5 лет назад |
| docker | 3ca584ab73 init on startup | 5 лет назад |
| docs | d8b67db846 update developing build docs | 5 лет назад |
| internal | c0a935db7c quick fix | 5 лет назад |
| server | d482360246 Merge pull request #67 from porter-dev/onboarding | 5 лет назад |
| .air.toml | e71b846b93 ignore dashboard in air.toml | 5 лет назад |
| .dockerignore | d7b83fb445 onboarding with default sqlite | 5 лет назад |
| .gitignore | e00e0bbf39 gitignore yaml | 5 лет назад |
| .goreleaser.yml | d8b67db846 update developing build docs | 5 лет назад |
| README.md | baf156f021 add roadmap to docs | 5 лет назад |
| docker-compose.dev.yaml | 9eb5469cc8 yaml in nodes | 5 лет назад |
| go.mod | d8b67db846 update developing build docs | 5 лет назад |
| go.sum | 558c04888a cli generate command | 5 лет назад |
| package-lock.json | 97c6704158 handle specrel in default namespace | 5 лет назад |
Porter is a dashboard for Helm with support for the following features:
values.yamlWhat's next for Porter? View our roadmap, or read our mission statement.
To view the dashboard locally, download our CLI and grab the latest release via:
TBD
Then run the dashboard (Docker engine must be running on the host machine):
porter start
TBD
kubectl for your fundamental operations. Porter for everything else.
Our mission is to be the go-to tool for interacting with complex Kubernetes deployments as both a beginner and an expert. While our initial focus is on visualizing Helm components, we believe this visualization and editing can be extended to a number of other tools and concepts, including alternative templating tools (kustomize, Terraform), other deployment tools (CI/CD tools, Terraform), Kubernetes package repositories (ChartMuseum, JFrog Artifactory), and even popular Kubernetes packages (nginx-ingress, cert-manager, prometheus, velero).
More specifically, we have the following long-term goals:
Why did we begin with Helm? Helm is the most popular auxiliary Kubernetes tool, and can function in nearly all parts of deployment lifecycle. We think of the various features of Helm in the following manner, adapted from Brian Grant's Helm Summit talk (slides here): package management, dependency management, application metadata, parameterization, templating, deployment/config revision management, lifecycle management hooks, and application probes. Along with these fundamental features, an expanding number of command plugins for more specific use-cases have started to become popular in the Helm ecosystem. If we can build a better workflow for both application developers and application operators by improving the user experience for most of these Helm features, we can generalize and expand this workflow to support alternative tooling that exists in the Kubernetes application management ecosystem.