buildpacks :
when we do a git push deis master for a buildpack type app. The code goes to builder and builder compresses the code to
tar file and uploads to configured object storage. Once this is done schedules a slugbuilder pod to provides the bucket and credentials to access the code
slugbuilder pod once starts fetches the tar file from object storage and extracts the file compiles the code according to buildpack specified if not
defaults to language specific buildpacks. Once the code is compiled it generates a slugfile which again it uploads to the same bucket.
Once the upload is done and slugbuilder pod finishes builder checks for the file existence and creates build hook to the controller.
which launches slugrunner pod encapsulating it in a RC or deployment. slugrunner pod gets the slug file from the bucket and extracts the file
and runs the code according to the slug file.
dockerfile apps:
The process is almost same as described above but here dockerbuilder pod after extracting the code looks for dockerfile and builds the image according to the file Pushes the image to the configured registry and builder calls a build hook. The controller creates an RC or deployments with the image from the registry.
Deis pull apps:
When we do a deis pull image. the controller pulls the image and retags it with the configured registry and app name, pushes to registry
and rest of the case is similar to dockerfile apps. The controller creates an RC or deployments with the image from the registry.
. If something fails first thing we have to see is if we are able to reach k8s API then if object storage is working