spec
helmfile
spec | helmfile | |
---|---|---|
9 | 24 | |
7,629 | 3,205 | |
0.2% | 3.8% | |
6.2 | 9.6 | |
4 months ago | 2 days ago | |
Go | ||
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
spec
-
What's the status of Open Application Model?
There was recently score.dev, but that is also just used by one tool.
- One YAML to rule them all
-
Best events/conferences to participate for an open-source project?
Yesterday I was thinking about the roadmap and the discussions that are happening in the community (you can check them here and feel free to open one or contribute to an active one) and I am excited to see how much we have to look forward in 2023.
-
Thoughts on my new OSS tool launch + twitter space happening today
A month ago we open sourced Score. The community response has been really great so far (just over 1k stars in 4 weeks) and we got many questions thrown at us:
-
One YAML to rule them all!
Hi all, I am Giulia, Community Manager and part of the team that launched Score.dev a week ago. My team and I believe that developers shouldn’t fight with tooling and advocate for a workload-centric approach to development. We’re on a mission to reduce cognitive load on developers, minimize configuration drift and mismanagement, and improve the developer experience. Want to join us as a contributor? Read the official announcement to learn more. Or check us out on GitHub!
- One YAML to rule them all. We just open sourced a new workload config spec so you can configure once and deploy to any environment (local, cloud, etc.)
-
The pros and cons of managing configuration for multiple environments
Last week we released score-spec and I asked a few communities for feedback on how you manage configuration between multiple environments and a lot of you (thanks!) came up with some answers and more questions. Here I wanted to list the pros and cons, in my humble opinion, of the top approaches suggested. Feel free to add yours as well!
- Trouble with consistent config across environments?
helmfile
-
Installing multiple helm charts in one go [Approach 2 - using helmfile]
sudo wget https://github.com/helmfile/helmfile/releases/download/v0.159.0/helmfile_0.159.0_linux_amd64.tar.gz sudo tar -xxf helmfile_0.159.0_linux_amd64.tar.gz sudo rm helmfile_0.159.0_linux_amd64.tar.gz sudo mv helmfile /usr/local/bin/
-
Simplified Deployment: A Deep Dive into Containerization and Helm
Installation: https://github.com/helmfile/helmfile/releases
-
Helm-Compose – The Docker-compose like tool for K8s development
What are the benefits over using helmfile? https://helmfile.readthedocs.io/
-
self-built apps: do you like using helm or kustomize to deliver them to kubernetes
Helm charts and Helmfile
-
Download packages for different architectures in your Dockerfiles using dumb-downloader, instead of writing scripts or separate Dockerfiles
And now I can just run dudo -l "https://github.com/helmfile/helmfile/releases/download/v{{ version }}/helmfile_{{ version }}_{{ os }}_{{ arch }}.tar.gz" -i /tmp/helmfile.tar.gz -p $HELMFILE_VERSION
-
Declarative GitOps for...my ArgoCD itself?
I might be misunderstanding your question but we use https://github.com/helmfile/helmfile along with Argo, so essentially between eks and those I could rebuild our entire cluster in minutes.
- Docker helm
-
Which GitOps for very small teams?
I am asking which do you choose, Flux or Helmfile. edit: and what criteria do you use to select.
-
In a gitops world, what does your team do to reduce cycle time for devs?
do you publish your own helm chart for your internal services and use it in every environment? if so, you could try to use helmfile within the service's repo itself and store values in a helm/$env directory. then enhance your ci to deploy to dev after the merge/image build phase directly. to try and cut out what sounds like a "deployment/config repo" step you have in the middle that's making everything a pain.
-
Helm makes it overly complex, or is it just me?
I've used helmfile before to declaratively manage multiple helm charts. It's a higher-level tool, and still uses helm under the hood.
What are some alternatives?
kuuid - K-sortable UUID - roughly time-sortable unique id generator
vals - Helm-like configuration values loader with support for various sources
ulid - Universally Unique Lexicographically Sortable Identifier (ULID) in Python 3
helmwave - New 🌊 wave for @helm
dynamodb-onetable - DynamoDB access and management for one table designs with NodeJS
kpt - Automate Kubernetes Configuration Editing
python-ksuid - A pure-Python KSUID implementation
helmsman - Helm Charts as Code
uuid6-ietf-draft - Next Generation UUID Formats
flux2 - Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
ulid-lite - Generate unique, yet sortable identifiers
zarf - DevSecOps for Air Gap & Limited-Connection Systems. https://zarf.dev/