preface

Writing Dockerfile is the most common way to build Docker image, Docker contact children’s shoes more or less know. Some time ago, I studied OpenShift(a PaaS) and found another way to build Docker images: S2i.

S2I introduction

S2I stands for source-to-image.

S2i is a toolkit and workflow for building repeatable Docker images from source code.

S2i is a framework that makes it easy to write mirrors. It takes the program source code as input and generates a new image of the assembled application running as output.

Details of S2I and how to use it can be referred to the following official documentation. I won’t repeat Fan Yi here.

  • Source-To-Image (S2I)
  • S2I Requirements
  • How to Create an S2I Builder Image

The process of building two ways

Talk is Cheap, Show me the Picture. The above first.

Source code is just one of the many inputs used to build an image, along with other inputs such as binaries. The process of mirroring is also complex. The diagram below is made simple for clear comparison.

As you can see from the above diagram, the Dockerfile build process is straightforward:

  • Follow the steps defined by Dockerfile to read the source code and generate the image (the finished product).

The construction process of S2I is “tortuous” :

  • According to the steps defined by Dockerfile, prepare the mirror environment, read the S2I script, and build the Image (middle)< also known as the Builder Image Builder Image>.
  • Based on the image generated in the previous step (middle), read the source code, follow the steps defined in the S2i script to compile the source code, deploy the binaries, prepare the service startup, and build the image (finished product).

As you can see from the above process, the S2i approach is one step ahead of the Dockerfile approach, with two more things: S2i scripts and mirroring (middle).

S2i script introduction

There are four types of S2I scripts.

  • Assemble the program. C: Assemble the program.
  • Run: is responsible for launching the application.
  • Save-artifacts responsible for incremental constructs (mirroring) that are not currently used.
  • Usage: Responsible for printing the instructions for the builder image.

Benefits of the S2I approach

About the benefits of introducing S2I to build mirroring, written class description can refer to the official documentation, here to talk about the personal experience and understanding after practice.

First, understand why S2I was introduced.

If you had to divide the build image into two parts, you could

  1. Environment to prepare

    • Define the underlying image;
    • Install the required components, such as Maven, Java JDK;
    • Copy/move files/directories;
    • Define users;
    • Expose ports, etc.

  2. Source code correlation

    • Compile source code;
    • Deploy binaries;
    • Define how to start a service, etc.

S2I was introduced to separate these two pieces of work.

Where the environment preparation is handed over to the builder image,

The builder image, once generated, remains unchanged and can be understood as a static part.

The source code is left to the S2i script.

During the process of building the image (the finished product), S2I follows the steps defined by the S2I script for source code compilation, binary deployment, and service startup preparation, which can be understood as the dynamic part.

This separation brings the following benefits.

  1. For programs with similar environment dependencies and similar build, deployment and startup processes, because of the presence of builder images, the build process does not need to prepare the environment again, thus saving the time of building the image (the finished product).
  2. Clear division of labor. The separation of build efforts allows application developers to make changes to their code without knowing the details of Dockerfile or Docker images. If mirroring builds are delivered to S2I or PaaS(Platform as a Service) platforms, the development engineer does not need to understand Docker to contribute to the project. This is very useful in an enterprise environment where there are many people with different specialties and who are not directly involved in the building process of their projects.

The above benefit 2 is cited in the article: A description of using Source-to-Image (S2I) to build an image