Skip to content
This repository has been archived by the owner on Feb 8, 2020. It is now read-only.

Latest commit

 

History

History
106 lines (85 loc) · 5.31 KB

source-to-image.adoc

File metadata and controls

106 lines (85 loc) · 5.31 KB
Raw

Source-to-Image

OpenShift provides different options for building and deploying application containers. These include:

  • Build and deploy from application source code - Users can specify the location of their application source code in a Git repository. OpenShift will build the application using steps appropriate for the programming language and software stack being used, then build a container image that includes the application and deploys it. Users can instead supply a Dockerfile as the source for instructions to build the container image. OpenShift will build the container image from the Dockerfile, within OpenShift, and deploy it.

  • Build and deploy from application binaries - Users can specify the location of their application binaries, generated from their existing application build process and tools. OpenShift will build the container image that includes the supplied application binaries and deploy it.

  • Deploy an existing container image - Users can build the application and container image completely outside of OpenShift, using existing application and container image build processes and tools, or use an existing container image supplied by a third party. OpenShift will pull down the nominated image and deploy it.

When you deployed the Python web application in the last exercise, OpenShift pulled down the application source code from a Git repository hosted by GitHub, built an image from it, and deployed it. This process of building the container image from the application source code is facilitated using a tool provided by the Source-to-Image (S2I) project.

The S2I project is described as:

"Source-to-Image (S2I) is a toolkit and workflow for building reproducible Docker images from source code. S2I produces ready-to-run images by injecting source code into a Docker container and letting the container prepare that source code for execution. By creating self-assembling builder images, you can version and control your build environments exactly like you use Docker images to version your runtime environments."

Visually the process can be depicted as:

Source-to-Image

OpenShift provides S2I builder images for a range of programming languages and environments, including support for Java, NodeJS, PHP, Python and Ruby.

The operation of the S2I builder is split into two phases. These are the assemble and run phases.

The assemble phase covers actions run by a S2I builder when preparing a container image for deployment. In the case of the Python S2I builder, during the assemble phase it will detect the presence of a requirements.txt file in the application source code and install using pip any Python packages required by the application which are listed.

The run phase covers actions run when the container image is deployed and the application is to be started. In the case of the Python S2I builder it will look at the application source code and determine how the web application should be started. A simplified version of the algorithm it uses, covering common cases, is as follows:

  1. If a program file named app.sh exists in the top level directory of the application source code, it will be executed to start the application. You can run from app.sh any application, so long as it accepts inbound HTTP connections on port 8080.

  2. If a Python code file named app.py exists in the top level directory of the application source code, it will be executed as a Python script. You can run from app.py any Python web server or application framework, so long as it accepts inbound HTTP connections on port 8080.

  3. If the gunicorn package has been installed via the requirements.txt file, and a wsgi.py file is located in the top level directory of the source code repository, the Gunicorn WSGI server will be used to host the WSGI application. The name of the WSGI application entry point callable contained in the wsgi.py file should be called application.

  4. If the Django package has been installed via the requirements.txt file and a manage.py file is located in the top level directory of the source code repository, it will be assumed that a Django based application is being used. For this case the Django application will be started using the Django development server. As the Django development server is not suitable for production use, this method should only be relied on for initial setup or testing.

For the web application used in this workshop, it supplied an app.sh file which in turn ran mod_wsgi-express.

A full discussion of S2I is beyond the scope of this workshop, but you can find more information about it in the OpenShift S2I documentation or the S2I project repository.

The key concept to understand about S2I is that it takes your application source code and creates from it a container image which can then be deployed, without you needing to know the specifics of how to construct the image.

S2I can be compared to cartridges from OpenShift 2 (prior version of OpenShift), or buildpacks from Heroku and Cloud Foundry. The difference compared to older systems such as buildpacks, is that S2I has been purpose built for creating container images using Docker and OCI image formats.