Description
Summary
In layman's terms: It should be able to allow developers to git push to a gitkube-enabled cluster without a Dockerfile - or so called the "Heroku-style" deployment.
Intro
Heroku's architecture is composed of a dedicated builder for the source, where your project requires a Procfile to determine processes to execute, and a declarative app manifest that includes all the required dependencies and postinstall scripts that the builder will run.
Heroku builds an app using an approach called a Stack-Buildpack approach, whereas:
- use a Base image that has all the dev dependencies.
- use a Buildpack: a set of shell scripts that would automate the building and releasing of the code
- trim dev dependencies from the container and release to the runtime environment.
But in the case for gitkube, we do not need to implement the same flow as Heroku since we can take advantage of the rich Docker ecosystem in Kubernetes.
Process flow
Once the remote recieves the source from the push, it should be able to detect the dockerfile and the manifest, but we should look on two situations:
- Situation 1: Dockerfile found and manifest found.
- Use the current flow to dpeloy app.
- Situation 2: Dockerfile not found but manifest found
- Try to find manifest (
package.json,pom.xml, etc.). - Grab image that works for the specific app (
package.jsonis found for example, then usenodejs:latest) - then run
npm install, and deploy app. - run code using
npm startor findapp.js,index.js, etc.- if not found, declare an error and call a back off.
- Try to find manifest (
Conclusion
This is not intended to replace how gitkube currently works, rather, it is a enhancement on the current flow, and it allows migrating users from Heroku to their own provisioned Kubernetes cluster.
Feel free to extend this as well, as I only accounted for cases on migrating users from heroku.