argo-helm
openapi-generator
argo-helm | openapi-generator | |
---|---|---|
20 | 236 | |
1,598 | 20,326 | |
3.2% | 2.1% | |
9.5 | 9.9 | |
3 days ago | 5 days ago | |
Mustache | Java | |
Apache License 2.0 | Apache License 2.0 |
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.
argo-helm
-
Using ArgoCD & Terraform to Manage Kubernetes Cluster
data "aws_eks_cluster_auth" "main" { name = aws_eks_cluster.main.name } resource "helm_release" "argocd" { depends_on = [aws_eks_node_group.main] name = "argocd" repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" version = "4.5.2" namespace = "argocd" create_namespace = true set { name = "server.service.type" value = "LoadBalancer" } set { name = "server.service.annotations.service\\.beta\\.kubernetes\\.io/aws-load-balancer-type" value = "nlb" } } data "kubernetes_service" "argocd_server" { metadata { name = "argocd-server" namespace = helm_release.argocd.namespace } }
-
ArgoCD: Use of Risky or Missing Cryptographic Algorithms in Redis Cache
FWIW: The Helm chart has network policy in place:
https://github.com/argoproj/argo-helm/blob/main/charts/argo-...
If you're using a CNI that supports network policy (e.g. AWS VPC CNI on EKS, Calico, etc.), I think this should more or less cover you, but I haven't personally tested it.
I think it's also probably a better practice to install "control plane" type software like Argo on a different, dedicated cluster. Argo supports this concept (and can in fact manage deployments in multiple clusters remotely). This way your main mission workloads are completely segmented from your privileged control plane software. Just as another defense-in-depth measure
-
Using ArgoCD Image Updater with ACR
resource "helm_release" "image_updater" { name = "argocd-image-updater" repository = "https://argoproj.github.io/argo-helm" chart = "argocd-image-updater" namespace = "argocd" values = [ <
-
Introducing ArgoCD: A GitOps Approach to Continuous Deployment
kubectl create namespace argocd helm repo add argo https://argoproj.github.io/argo-helm helm repo update helm install argocd argo/argo-cd --namespace argocd
-
2- Your first ARGO-CD
We will use Helm to install Argo CD with the community-maintained chart from argoproj/argo-helm because The Argo project doesn't provide an official Helm chart. We will render thier helm chart for argocd locally on our side, manipulate it and overrides its default values, and also we can helm lint the chart and templating to see if there is some errors or not, We gonna use the chart version 5.50.0 which matches appVersion: v2.8.6 you can find all details for the chart and also we gonna override some values @ default-values.yaml
-
Having an issue connecting to git repo configured through helm using ssh private key
resource "helm_release" "argocd" { name = "${var.environment}-argocd" namespace = "${var.environment}-argocd" create_namespace = true repository = "https://argoproj.github.io/argo-helm" version = "${var.helm_version}" chart = "argo-cd" set { name = "server.service.type" value = "LoadBalancer" } set { name = "server.service.loadBalancerIP" value = "${var.loadBalancerIP}" } values = [ <<-YAML --- global: image: tag: "${var.image_tag}" configs: repositories: gitops-homelab: url: [email protected]:myprivaterepo/gitops-homelab.git name: private-repo type: git sshPrivateKey: file("${path.module}/sa_keys/private/${var.environment}_id_rsa") server: extraArgs: - --insecure YAML ] } output "file_location" { value = file("${path.module}/sa_keys/private/${var.environment}_id_rsa") }
-
Issue with helm_release on terraform destroy
"argo-cd" = { repository = "https://argoproj.github.io/argo-helm", chart = "argo-cd", namespace = "argocd" values_file = templatefile("./values/argocd.yml", { ingress_scheme = "internal" #internet-facing or internal elb_name = aws_lb.this["${local.name}-int-a"].name })
-
How to Install ArgoCD using Helm through Terraform
repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" namespace = "argo" version = "5.34.5"
- How to determine ordering in a bunch of helm sub charts?
-
Dump Kustomize with 20 lines of TypeScript
I think your example with the ArgoCD Helm chart says it all. It can get incredibly complicated, and I had tremendous trouble getting it working, it broke all the time, getting the indentation right was a nightmare ... very unpleasant experience. I mean look at that chart, the authors have to constantly specify the indentation level everywhere.
openapi-generator
-
Next-generation web framework Teo, supports Node.js, Python and Rust
You would use OpenAPI (formerly Swagger) [1] for that, which includes JSONSchema for data types but also adds specs for defining REST apis. There are plenty of generators and other tools that work with OpenAPI [2]
[1] https://www.openapis.org/
[2] https://openapi-generator.tech/
-
Which tricks do you use to write less code?
I found some "tricks" to write less code, hence less code to maintain if there are any changes. Also less code with bugs just by changing the inputs.
For example, OpenAPI spec file + OpenAPI generator (https://github.com/OpenAPITools/openapi-generator). Any changes in the OpenAPI spec are reflected in the final code with a build step.
Another example: MapStruct (https://mapstruct.org/) to avoid passing data from Entity classes to DTO and back. Saves looots of boilerplate code.
Which are your tricks?
-
The Stainless SDK Generator
Disclaimer: We're an early adopter of Stainless at Mux.
I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.
Excited to see more SDK languages come to Stainless!
[1] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...
[2] https://github.com/OpenAPITools/openapi-generator
-
FastAPI Got Me an OpenAPI Spec Really... Fast
As a result, the following specification can be used to generate clients in a number of different languages via OpenAPI Generator.
-
Show HN: Manage on-prem servers from my smartphone
Of course you can compile the server from source if you have Go and the OpenAPI generator JAR (https://github.com/OpenAPITools/openapi-generator?tab=readme...)
Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...
And then :
(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o /app/rebootx-on-prem-http-server-go-openbsd-amd64 -v)
By adapting the arch if needed. Not tested, but it should work.
- OpenAPI Generator v7.3.0 has new generators for Rust, Kotlin, Scala and Java
-
Stop creating HTTP clients manually - Part I
TL;DR: Start generating your HTTP clients and all the DTOs of the requests and responses automatically from your API, using openapi-generator instead of writing your own.
-
How to Automatically Consume RESTful APIs in Your Frontend
As an alternative, you can also use the official OpenAPI Generator, which is a more generic tool supporting a wide range of languages and frameworks.
-
Building a world-class suite of SDKs is easy with Speakeasy
I trialed generating SDKs using the OpenAPI Generator package, which was largely unsatisfactory.
-
Best way to implement base class for API calls?
If Swagger/OpenAPI is available, save yourself a lot of trouble and generate the client using OpenAPI Generator. If not, use a library like RestEase to make it significantly easier to create the client.
What are some alternatives?
charts - Public helm charts
NSwag - The Swagger/OpenAPI toolchain for .NET, ASP.NET Core and TypeScript.
cp-helm-charts - The Confluent Platform Helm charts enable you to deploy Confluent Platform services on Kubernetes for development, test, and proof of concept environments.
oapi-codegen - Generate Go client and server boilerplate from OpenAPI 3 specifications
argo-cd - Declarative Continuous Deployment for Kubernetes
SvelteKit - web development, streamlined
helm-charts - OpenSourced Helm charts
smithy - Smithy is a protocol-agnostic interface definition language and set of tools for generating clients, servers, and documentation for any programming language.
charts - OpenEBS Helm Charts and other utilities
django-ninja - 💨 Fast, Async-ready, Openapi, type hints based framework for building APIs
argocd-vault-plugin - An Argo CD plugin to retrieve secrets from Secret Management tools and inject them into Kubernetes secrets
autorest - OpenAPI (f.k.a Swagger) Specification code generator. Supports C#, PowerShell, Go, Java, Node.js, TypeScript, Python