dan
/
improwised-charts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
improwised-charts/charts/polymorphic-app
History
Shyam Vyas fb95801eb7
feat: update polymorphic-app chart by adding initcontainer, toleratio… (#17) 
* feat: update polymorphic-app chart by adding initcontainer, tolerations and lifecyclehooks

* Fix CI and added maintainers

* Fix the tag error in freeipa

* fixed service port

* updated dependencies for healthcheck

* fixed comment space errors

* fix comment space errors

* Fix CI

* fixing CI

* fixing readness probes template in statefulset

* Fix previous changes

* Disable testing of freeipa temporarily

---------

Signed-off-by: Rakshit Menpara <205111+deltasquare4@users.noreply.github.com>
Co-authored-by: ANNAVAR.SATISH <annavarsatish@gmail.com>
Co-authored-by: Annavar satish <annavarsatish10@gmail.com>
Co-authored-by: Rakshit Menpara <205111+deltasquare4@users.noreply.github.com>
 		2023-06-01 09:29:15 +05:30
..
templates feat: update polymorphic-app chart by adding initcontainer, toleratio… (#17) 2023-06-01 09:29:15 +05:30
.helmignore feat: Add polymorphic-app chart (#14) 2022-03-08 15:30:24 +05:30
Chart.yaml feat: update polymorphic-app chart by adding initcontainer, toleratio… (#17) 2023-06-01 09:29:15 +05:30
Readme.md feat: Add polymorphic-app chart (#14) 2022-03-08 15:30:24 +05:30
values.yaml feat: update polymorphic-app chart by adding initcontainer, toleratio… (#17) 2023-06-01 09:29:15 +05:30

Readme.md

Polymorphic Application Chart

This chart provides an abstraction layer over Kubernetes resources to easily represent wide ranges of different cloud-native applications. It is designed to be very flexible and can be used to various configurations. The primary aim for this chart is to make it easy to deploy and maintain cloud native applications on top of Kubernetes.

This chart is ideal for deploying applications that support polymorphic container pattern. A polymorphic container has multiple entrypoints and behaves differently depending on the entrypoint. This is particularly useful in creating event-driven monolithic applications, where some of the codebase (interfaces etc.) is shared, and the application needs to have multiple, independently scalable "workers" that process these events.

Features

  • Supports the following kind of deployments:
    • API: Consists of a kubernetes Deployment, Service, and optionally Ingress and HorizontalPodAutoscaler. Typically used to deploy REST/gRPC API services.
    • Worker: Consists of a kubernetes Deployment and optionally a HorizontalPodAutoscaler. Typically used to deploy long-running services that are not consumed through a TCP/HTTP server. e.g. Queue Workers and Stream Processors
    • Jobs: Typically used to run one-off jobs, mostly helm hooks, to be run when installing/uninstalling/upgrading the helm deployment. Used to run database migrations by default. Backed by Kubernetes Job.
    • CronJobs: Typically used to run scheduled jobs. Used for triggering events and batch processing jobs at a regular interval. Backed by Kubernetes CronJob.
  • Designed to be used with Flux Helm Controller, Helmfile, and any other mechanism that is backed by helm values-file override.