Using S2I to Build Cloud Native Applications

1. What Problem S2I Solves

It is foreseeable that a large number of applications will be deployed as containers in the future.

Container platforms care about images and containers, while application development cares about business code, and ultimately the code needs to be deployed as an image. From code to image — that is Source To Image, or S2I.

In an earlier article, buildpack for PaaS deployment, I described how an application needs some essential configuration before it can run. That configuration includes runtime dependencies, environment variables, service addresses, and so on.

S2I provides functionality similar to buildpack, but the approach S2I offers is more generalized and more containerized.

2. Characteristics of S2I

The figure above is the S2I workflow; the S2I CLI depends on a Docker environment.

It mainly divides into two steps:

Build the application’s base image from the BASE IMAGE and S2I Scripts
Move the source code into the application’s base image, adding only one layer of files, to obtain the final image file

The BASE IMAGE is a general-purpose image, for example Python, CentOS, Nodejs, and so on. S2I Scripts are usually a fixed set of procedural scripts, such as migrating the database, copying static files, and so on.

Characteristics of S2I:

Speed: S2I can carry out quite complex operation logic without creating a new image layer, so it runs very fast.
Patching: if the images you depend on need a security patch, S2I lets you rebuild all images in one pass.
Efficiency: during the build process, S2I does not allow arbitrary yum install commands, to prevent slowing down development iteration.
Ecosystem: S2I encourages a shared image ecosystem. That way your application can achieve best practices.

S2I can detect the language from files in the directory; if there is a Dockerfile, it degrades to the non-S2I approach of building with the Dockerfile.

Detected Language	Detected File
java	pom.xml
nodejs	app.json, package.json
perl	cpanfile、index.pl
php	composer.json、index.php
python	requirements.txt、setup.py
ruby	Gemfile, Rakefile、config.ru
scala	build.sbt
golang	Godeps, main.go

3. Differences Between S2I and buildpack

buildpack is a tool provided by CloudFoundry for packaging applications. buildpack builds, packages, and updates an application and its dependencies, letting developers focus more on implementing business logic.

buildpack ultimately produces a droplet. A droplet is a runnable instance of an application, running on a dea (droplet execution agent).

S2I is a container-based application image build tool introduced by OpenShift. S2I is container-oriented and tries to solve a more general problem.

S2I ultimately produces an image that can be deployed on any container platform.

4. Trying Out S2I

Before you begin, make sure you have a working Docker environment locally.

Create a Django project

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
pip install django==1.11
django-admin startproject django_example
echo django==1.11 > ./django_example/requirements.txt
tree -L 3
.
└── django_example
    ├── django_example
    │   ├── __init__.py
    │   ├── settings.py
    │   ├── urls.py
    │   └── wsgi.py
    ├── manage.py
    └── requirements.txt

The reason for adding requirements.txt is to let the script recognize the application.

Install S2I, using OS X as an example:

1
brew install source-to-image

Build the application image

The build command format

1
2
3
s2i build -h
Usage:
  s2i build <source> <image> [<tag>] [flags]

source, the build source code. It can be a local repository or a remote repository
image, the base image
tag, the generated image
flags, build parameters, such as adding certificates, setting the network, and so on

Start building the application

centos/python-35-centos7 is an S2I base image for Python 3.5 applications, click to view.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
s2i build django_example centos/python-35-centos7 hello-django
---> Installing application source ...
---> Installing dependencies ...
Collecting django==1.11 (from -r requirements.txt (line 1))
Downloading https://files.pythonhosted.org/packages/47/a6/078ebcbd49b19e22fd560a2348cfc5cec9e5dcfe3c4fad8e
64c9865135bb/Django-1.11-py2.py3-none-any.whl (6.9MB)
Collecting pytz (from django==1.11->-r requirements.txt (line 1))
Downloading https://files.pythonhosted.org/packages/87/76/46d697698a143e05f77bec5a526bf4e56a0be
61d63425b68f4ba553b51f2/pytz-2019.2-py2.py3-none-any.whl (508kB)
Installing collected packages: pytz, django
Successfully installed django-1.11 pytz-2019.2
You are using pip version 7.1.2, however version 19.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
---> Collecting Django static files ...
WARNING: could not run 'manage.py collectstatic'. To debug, run:
python ./manage.py collectstatic --noinput
Ignore this warning if you're not serving static files with Django.
Build completed successfully

View the image

1
2
3
docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
hello-django               latest              042c6143ecf9        50 seconds ago      669MB

Run the application

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
docker run --security-opt apparmor=unconfined --security-opt seccomp=unconfined -p 8080:8080 hello-django
---> Migrating database ...
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying sessions.0001_initial... OK
---> Serving application with 'manage.py runserver' ...
WARNING: this is NOT a recommended way to run you application in production!
Consider using gunicorn or some other production web server.
Performing system checks...
System check identified no issues (0 silenced).
August 26, 2019 - 08:08:36
Django version 1.11, using settings 'django_example.settings'
Starting development server at http://0.0.0.0:8080/
Quit the server with CONTROL-C.

View the application