You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.json is found for example, then use nodejs:latest)
then run npm install, and deploy app.
run code using npm start or find app.js, index.js, etc.
if not found, declare an error and call a back off.
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.
The text was updated successfully, but these errors were encountered:
shahidhk
changed the title
[Feature Request] Auto-detect base image to use if no Dockerfile is found
Auto-detect base image to use if no Dockerfile is found
Jul 2, 2018
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:
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:
package.json
,pom.xml
, etc.).package.json
is found for example, then usenodejs:latest
)npm install
, and deploy app.npm start
or findapp.js
,index.js
, etc.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.
The text was updated successfully, but these errors were encountered: