Infrastructure as code has become the defacto standard for infrastructure delivery, and we strongly believe that IAC should benefit from kubernetes capabilities. Writing of YAML files shouldn't be the end goal. Infra team should be able to write Infra code in any language of choice and still be able to package such to run in kubernetes in the same vein our core application logic are not written in YAML still they are run in kubernetes. Alustan is serving as a gitops orchestrator that can take your infrastructure code and run it seamlessly in kubernetes using the user provided logic and script flow, unlike similar projects in the ecosystem
Org repo URL (provide if all repos under the org are in scope of the application)
[X] If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
[X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
Why CNCF?
We strongly believe that the project will be of immense help to platform engineering teams and those looking to move cloud native, and being part of CNCF will definitely foster awareness and adoption, above all get more hands to contribute and make the project better
Benefit to the Landscape
There are similar projects in the ecosystem, however haven gone through them, they all read infra configuration without enquiring of how the user wishes to execute this logic. Are there other required setup that needs to executed outside the core infra logic before applying the configuration? Are there post deploy logic that needs executing, example getting the health status of external services provisioned outside kubernetes and storing that in manifest status for observability purpose. As we are advocating heavily on need for platform engineering, the project wishes to serve as building block to achieve that, either as serving as an orchestrator for infrastructure delivery or part of a broader setup for a full platform orchestration
Cloud Native 'Fit'
No response
Cloud Native 'Integration'
No response
Cloud Native Overlap
No response
Similar projects
Crossplane- though not exactly but similar concept
Application contact emails
chichiuchenna@gmail.com
Project Summary
Infrastructure continuous delivery platform
Project Description
Infrastructure as code has become the defacto standard for infrastructure delivery, and we strongly believe that IAC should benefit from kubernetes capabilities. Writing of YAML files shouldn't be the end goal. Infra team should be able to write Infra code in any language of choice and still be able to package such to run in kubernetes in the same vein our core application logic are not written in YAML still they are run in kubernetes. Alustan is serving as a gitops orchestrator that can take your infrastructure code and run it seamlessly in kubernetes using the user provided logic and script flow, unlike similar projects in the ecosystem
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/alustan
Project repo URL in scope of application
https://github.com/alustan/alustan
Additional repos in scope of the application
No response
Website URL
No response
Roadmap
https://github.com/alustan/alustan/blob/main/roadmap.md
Roadmap context
No response
Contributing Guide
https://github.com/alustan/alustan/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/alustan/alustan/blob/main/CODE_OF_CONDUCT.md
Adopters
No response
Contributing or Sponsoring Org
No response
Maintainers file
https://github.com/alustan/alustan/blob/main/MAINTAINERS.md
IP Policy
Trademark and accounts
Why CNCF?
We strongly believe that the project will be of immense help to platform engineering teams and those looking to move cloud native, and being part of CNCF will definitely foster awareness and adoption, above all get more hands to contribute and make the project better
Benefit to the Landscape
There are similar projects in the ecosystem, however haven gone through them, they all read infra configuration without enquiring of how the user wishes to execute this logic. Are there other required setup that needs to executed outside the core infra logic before applying the configuration? Are there post deploy logic that needs executing, example getting the health status of external services provisioned outside kubernetes and storing that in manifest status for observability purpose. As we are advocating heavily on need for platform engineering, the project wishes to serve as building block to achieve that, either as serving as an orchestrator for infrastructure delivery or part of a broader setup for a full platform orchestration
Cloud Native 'Fit'
No response
Cloud Native 'Integration'
No response
Cloud Native Overlap
No response
Similar projects
Crossplane- though not exactly but similar concept
Landscape
No
Business Product or Service to Project separation
N/A
Project presentations
No response
Project champions
No response
Additional information
No response