Builds and Deployments

Simple Application

Let's try to deploy a simple web application written in Python using Flask framework from GitHub.

The Build and Deployment are automatically created.

Here is how the application looks like:

Build Strategy

Consider the web application we deployed previously, Kubernetes expects a Docker image of this application.

Docker Build

  • We build Docker image by writing a Dockerfile
  • This requires us to provide the list of instructions to build the Docker image in the Dockerfile.

Source-to-Image (S2I)

  • This is a framework that takes your application codes and convert into a reusable Docker image.
  • You don't need to provide the instructions in Dockerfile.
  • It uses, in this case, a pre-built Python builder image and injects the application code into it.
  • We used this strategy in previous deployment of simple web application.
  • If you need to modify the build strategy, you must edit the build configuration or the YAML file.

Custom Build

  • In case you want to build individual artifacts like JAR file, Python package, GEM file.

Image Stream

  • In case you want to build your different applications using S2I:
    • For your Python application, you may want to use Docker image available on Docker Hub.
    • For your Java application, you may want to use custom image in the internal Docker registry within OpenShift.
    • For your Ruby application, you may want to use image from other private registry.
  • Then you need to refer to these image in build configuration using different naming schemes like this:

Relying on images like this has its own risk. If the images gets updated without our knowledge, those updates can impact our application in unexpected ways.

  • To prevent such scenarios and to provide a consistent referencing technique for Docker images, OpenShift introduced Image Streams.
  • Image Streams map actual Docker images hosted at different locations to image names within projects in OpenShift.
  • All of dependent images for Java, Python, and Ruby will now have a consistent reference and the actual location of these images is abstracted by Image Stream.

  • When an image is created by Image Stream, it does not really point to the target image by the name.
  • Instead, it points to the image ID which is unique across builds.
  • Even the image on the target gets updated, it still points to the previous known good image using the image ID.
  • The image stream can be updated as required.

Image Streams are just pointers to the actual Docker image and they are not Docker images themselves.

Image Streams are only metadata that provides us with a layer of abstraction for referencing Docker images from within OpenShift.