DEV Community: Javier Romero

Creating an s2i builder for Go (and a runtime image)

Javier Romero — Thu, 23 Jul 2020 01:03:37 +0000

This post is a continuation of:

Build an app image with s2i

Javier Romero ・ Jul 19 '20

#docker #devops #openshift #s2i

Objective

I will try to go through the process of creating an s2i builder for... go.

The goals of this builder are the following:

The builder should compile go programs.
The app image should not contain the source code.
The app image should not contain the go compiler.
The app image should not run as root.

App

First, we need an app to use as our test subject.

This is a simple http server app that uses mux for routing. This server could be written without the use of this library but I wanted to show how dependencies would be handled.

Let's look at the app contents...

$ tree test-app

test-app/
├── app.go    # app source
├── go.mod    # dependency declarations
└── go.sum    # dependency checksums

app.go:

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"

    "github.com/gorilla/mux"
)

const port = "8080"

func main() {
    log.Println("Starting app on port:", port)
    r := mux.NewRouter()
    r.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        _, _ = fmt.Fprintln(w, "This is a test app!")
    })
    r.HandleFunc("/host", func(w http.ResponseWriter, r *http.Request) {
        var name, _ = os.Hostname()
        _, _ = fmt.Fprintf(w, "This request was processed by host: %s\n", name)
    })
    r.HandleFunc("/hello/{object}", func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        _, _ = fmt.Fprintf(w, "Hello %v!\n", vars["object"])
    })
    http.Handle("/", r)
    if err := http.ListenAndServe(":"+port, nil); err != nil {
        log.Fatal(err)
    }
    log.Println("Shutting down")
}

go.mod:

module github.com/jromero/learning-s2i/s2i-golang/test/test-app

go 1.14

require github.com/gorilla/mux v1.7.4

go.sum:

github.com/gorilla/mux v1.7.4 h1:VuZ8uybHlWmqV03+zRzdwKL4tUnIp1MAQtp1mIFE1bc=
github.com/gorilla/mux v1.7.4/go.mod h1:DVbg23sWSpFRCP0SfiEN6jmj59UnW/n46BH5rLB71So=

Builder

The builder as we learned previously is an image that knows how to build a specific type of application. In this case, we will write a builder for a go app.

In order to do this we'll need the following files:

$ tree builder/

builder/
├── Dockerfile               # docker instructions to create builder
└── s2i
    └── bin
        ├── assemble         # script to build application
        ├── run              # script to run application
        ├── save-artifacts   # script to package cached items
        └── usage            # script that displays usage

Let's go into more detail about each one...

`s2i/bin/usage`

The usage script is very straight forward. We will use it as a way to assist users when they try to run the builder using docker run.

#!/bin/bash -e
cat <<EOF
This is the s2i-golang S2I image:
To use it, install S2I: https://github.com/openshift/source-to-image

Sample invocation:

s2i build <source code path/URL> s2i-golang <application image>

You can then run the resulting image via:
docker run <application image>
EOF

`s2i/bin/save-artifacts`

The save-artifacts script is a special script that is called as part of the build process directly into a tar stream. We will use it to specify what data we want cached so that users can leverage --incremental builds.

In go, we care about caching the following directories:

${GOPATH}/src
${GOPATH}/pkg

Important Note: Due to the way this script is used, no output other than the cache contents should be present.

#!/bin/sh -e
pushd ${GOPATH} >/dev/null
if [ -d src ]; then
    chmod -R +w src
    tar cf - src
fi
if [ -d pkg ]; then
    chmod -R +w pkg
    tar cf - pkg
fi
popd >/dev/null

`s2i/bin/assemble`

The assemble script is responsible for the following:

restoring cache
compiling code
relocating contents

# If the 's2i-golang' assemble script is executed with the '-h' flag, print the usage.
if [[ "$1" == "-h" ]]; then
    exec /usr/libexec/s2i/usage
fi

# Restore artifacts from the previous build (if they exist).
echo
echo "---> Checking for cache..."
if [ "$(ls /tmp/artifacts 2>/dev/null)" ]; then
  pushd /tmp/artifacts >/dev/null
  echo "-----> Pulling cache..."
  shopt -s dotglob
  if [ -d src ]; then
    echo "Restoring cache ${GOPATH}/src/..."
    mv src ${GOPATH}/src
  fi
  if [ -d pkg ]; then
    echo "Restoring cache ${GOPATH}/pkg/..."
    mv pkg ${GOPATH}/pkg 
  fi
  shopt -u dotglob
  popd >/dev/null
fi

# Compile app to final location
echo
echo "---> Building application from source..."
pushd /tmp/src/ >/dev/null
go build -o ${APP_ROOT}/bin/app
popd >/dev/null

`s2i/bin/run`

The run script will be what is executed on the produced app image. In our case it will simply call the compiled executable.

#!/bin/sh -e
${APP_ROOT}/bin/app

`Dockerfile`

Finally, we'll put it all together by composing our builder image using a standard Dockerfile.

# s2i-golang
FROM openshift/base-centos7

      # the maintainer
LABEL maintainer="Javier Romero <root@jromero.codes>" \
      # specify where s2i scripts are located
      io.openshift.s2i.scripts-url="image:///usr/libexec/s2i/bin"

# configuration
ARG GO_VERSION=1.14
ARG GO_INSTALL_DIR=/usr/local/

# env vars
ENV APP_ROOT=/opt/app-root
ENV BUILDER_VERSION 1.0
ENV GOPATH ${APP_ROOT}/src/go
ENV PATH=${PATH}:${GOPATH}/bin:${GO_INSTALL_DIR}/go/bin

# build dependencies
RUN curl -sSL https://dl.google.com/go/go${GO_VERSION}.linux-amd64.tar.gz -o go${GO_VERSION}.linux-amd64.tar.gz && \
    tar -C ${GO_INSTALL_DIR} -xzf go${GO_VERSION}.linux-amd64.tar.gz && \
    rm -f go${GO_VERSION}.linux-amd64.tar.gz && \
    mkdir -p ${GOPATH}

# s2i scripts
COPY s2i /usr/libexec/s2i

# set permissions
RUN chown -R 1001:1001 ${APP_ROOT} && \
    chown -R 1001:1001 /usr/libexec/s2i

# default user
USER 1001

# default CMD for the image
CMD ["/usr/libexec/s2i/usage"]

Note: user 1001 and group 1001 have been created by the base image openshift/base-centos7.

Build!

Now that we've got all the pieces together let's test out our builder.

Build our builder image

Building the image using docker should be as easy as:

docker build -t s2i-golang ./builder

Build our app using the builder

To build our app we will use our builder:

$ s2i build --copy test-app/ s2i-golang my-go-app --incremental

---> Checking for cache...

---> Building application from source...
go: downloading github.com/gorilla/mux v1.7.4
Build completed successfully

Note: Because we are caching go dependencies, if we re-ran the same build command (with --incremental) we should see that mux is not downloaded again.

Run our app

With the app image built, we can run it using docker:

docker run --rm -it -p 8080:8080 my-go-app

... and verify that it works by going to http://localhost:8080

$ curl -s http://localhost:8080

This is a test app!

App Image

Let's take a look at what we've ended up with.

Checking what user we are running as yields default. 👍

$ docker run --rm my-go-app /bin/bash -c "whoami"

default

Our app ended up being 7.5MBs.

$ docker run --rm my-go-app /bin/bash -c "ls -lh /opt/app-root/bin/app"

-rwxr-xr-x 1 default root 7.5M Jul 22 15:53 /opt/app-root/bin/app

And our image... is 725MBs!!!

$ (docker images | head -1 && docker images | grep my-go-app) | awk '{print $1, $NF}'

REPOSITORY SIZE
my-go-app 725MB

If we dive into our app image we can see that this is because of a few things:

The base image of the app image is the builder image which in itself has a lot of stuff our app doesn't care about.
The go compiler and build tools are present in the final app image.
All the intermittent artifacts such as cache and source code are on the final app image.

In addition to the size, all this extra stuff has the additional negative side-effect of increasing our attack surface. 😈

If we review our goals, it's clear that we haven't satisfied them all.

✅ The builder should compile go programs.
❌ The app image should not contain the source code.
❌ The app image should not contain the go compiler.
✅ The app image should not run as root.

Runtime Image

We can try to optimize our app image by using a runtime image to meet our initial goals.

A runtime image is an image that will be used instead of the builder as the base for the app image.

In order to make this runtime image work with s2i we need the following:

$ tree runtime/

runtime/
├── Dockerfile                 # docker instructions to create image
└── s2i
    └── bin
        ├── assemble-runtime   # script to relocate assets
        └── run                # script to run our application

`s2i/bin/run`

Just like the run script for the builder this script will simply execute our binary. In this case we are executing it the current working directory since that's where we'll be placing it.

#!/bin/sh -e
./app

`s2i/bin/assemble-runtime`

The assemble-runtime is analogous to assemble but for the runtime image. In our case, there is nothing additional to do so we'll just echo. Unfortunately this script is required even if we don't actually need it.

#!/bin/sh -e
echo "Nothing special to do here..."

`Dockerfile`

Lastly, but most importantly, we'll define our image with the right permissions on the minimal base image we need. In this case we are going to go with the base cento7 image.

# s2i-golang-runtime
FROM centos:7

      # the maintainer
LABEL maintainer="Javier Romero <root@jromero.codes>" \
      # specify where s2i scripts are located
      io.openshift.s2i.scripts-url="image:///usr/libexec/s2i/bin"

# s2i scripts
COPY s2i /usr/libexec/s2i

# create user/group
RUN groupadd -g 1001 app && \
    adduser -u 1001 -g 1001 default

# default user
USER 1001

Build! (w Runtime Image)

Let's build our app again but this time providing a separate runtime image in an effort to improve the final app image.

Build our runtime image

Again, building the image using docker should be as easy as:

docker build -t s2i-golang-runtime ./runtime

Build our app using the builder and runtime

To build our app we will use our builder and newly build runtime image:

$ s2i build --copy test-app/ s2i-golang my-go-app --runtime-image s2i-golang-runtime --runtime-artifact /opt/app-root/bin/app

---> Checking for cache...

---> Building application from source...
go: downloading github.com/gorilla/mux v1.7.4
Build completed successfully

A few things to note:

We can no longer use --incremental 😞. See issue #824.

We must provide the location of what artifacts we want to "transfer" over to the runtime image. This requires the end user to know more than they should about the internals of the builder. 😥

Run our app

Now that we've built our app (again) we can run it:

docker run --rm -it -p 8080:8080 my-go-app

Cool it still works!

App Image (Redux)

Let's hope we have a better app image. 🤞

Checking the running user...

$ docker run --rm my-go-app /bin/bash -c "whoami"

default

Still good.

Image size?

$ (docker images | head -1 && docker images | grep my-go-app) | awk '{print $1, $NF}'

REPOSITORY SIZE
my-go-app 212MB

Nice! We've saved >500MBs!!! This is data that we don't have to store or transfer. 🙌

Plus, much less of an attack surface. 👿

A dive into the image:

This looks much better!

... and we've met all our original goals.

✅ The builder should compile go programs.
✅ The app image should not contain the source code.
✅ The app image should not contain the go compiler.
✅ The app image should not run as root.

Conclusion

So what did we learn?

Builders are fairly easy to construct and can be generally used with multiple applications (unlike pure Dockerfiles).
Built-in caching can be used to improve local development via --incremental.
--incremental does not currently work with --runtime-image.
To use --runtime-image you must have intimate knowledge about what artifacts will be produced.
We gain a performance and security boost from using a seperate runtime image.

If you'd like to look at the source used in this tutorial, you may find it here: https://github.com/jromero/learning-s2i

Additional Reading

Build an app image with s2i

Javier Romero — Sun, 19 Jul 2020 17:45:15 +0000

What is `s2i`?

source-to-image, or s2i as commonly abbreviated, is a build tool that allows an app developer and/or operator the ability to take the app source code and construct an OCI image (aka docker image, aka container image).

Concepts

Builder

A builder is an image that knows how to build a specific type of source code. Although it would be possible for a single builder to support multiple languages it is common that a builder only builds one language family.

The following publically available builders are available:

Build image

The base image in which the build process is executed.

Run image

The base image in which the built application runs.

Features

Separation of concerns

By using a tool such as s2i, the app developer can focus on adding features and maintaining the application. On the other side, DevOps can ensure that the application is built in a secure and reproducible manner by providing builders that should be used by developers.

Minimal to no configuration

In most cases, no additional s2i configuration is necessary and it's able to build the application. In the cases where a more complex application needs to be built there are various configuration points (to be covered in a separate tutorial).

Process

The process, as well defined in the project README.md:

The s2i build workflow is:

s2i creates a container based on the build image and passes it a tar file that contains:

The application source in src, excluding any files selected by .s2iignore

The build artifacts in artifacts (if applicable - see incremental builds)

s2i sets the environment variables from .s2i/environment (optional)

s2i starts the container and runs its assemble script

s2i waits for the container to finish

s2i commits the container, setting the CMD for the output image to be the run script and tagging the image with the name provided.

Install

Now that we've got some idea on what s2i is and why we might want to use it let's start by installing it.

You may find the latest releases here.

These are the command I ran to install it in /usr/local/bin/ on a macOS:

curl -sSL https://github.com/openshift/source-to-image/releases/download/v1.3.0/source-to-image-v1.3.0-eed2850f-darwin-amd64.tar.gz -o /tmp/s2i.tgz
tar -xvf /tmp/s2i.tgz -C /usr/local/bin/
s2i version

Build

Next, we'll build the app.

Let's use Spring's sample project, petclinic, as the source.

s2i build https://github.com/spring-projects/spring-petclinic fabric8/s2i-java pet-clinic

Breakdown

If we breakdown the command, this is what it all means:

s2i                                             
build                                                 # command
https://github.com/spring-projects/spring-petclinic   # source (in)
fabric8/s2i-java                                      # builder image (in)
pet-clinic                                            # image name (out)

Output

The [truncated] output is as follows. Nothing spectacular to look at but we do see that it built our image.

==================================================================
Starting S2I Java Build .....
S2I source build for Maven detected
Using MAVEN_OPTS '-XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:+ExitOnOutOfMemoryError'
Found pom.xml ...
Running 'mvn -Dmaven.repo.local=/tmp/artifacts/m2 package -DskipTests -Dmaven.javadoc.skip=true -Dmaven.site.skip=true -Dmaven.source.skip=true -Djacoco.skip=true -Dcheckstyle.skip=true -Dfindbugs.skip=true -Dpmd.skip=true -Dfabric8.skip=true -e -B '
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)
Maven home: /opt/maven
Java version: 1.8.0_252, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64/jre
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.19.76-linuxkit", arch: "amd64", family: "unix"
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
...
(Downloading a bunch of dependencies)
...
[INFO] Building jar: /tmp/src/target/spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar
[INFO]
[INFO] --- spring-boot-maven-plugin:2.3.1.RELEASE:repackage (repackage) @ spring-petclinic ---
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 06:43 min
[INFO] Finished at: 2020-07-19T16:00:45Z
[INFO] ------------------------------------------------------------------------
Copying Maven artifacts from /tmp/src/target to /deployments ...
Running: cp -v *.jar /deployments
'spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar' -> '/deployments/spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar'
Checking for fat jar archive...
Found spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar...
... done
Build completed successfully

Pro-tip: Incremental Build

If you were to run the build command again you would notice that the build does EVERYTHING again. This includes downloading dependencies. By default, s2i aims to provide a safe reproducible build. If you'd like to leverage caching of such resources (dependant on builder implementation) you may enable incremental builds via --incremental.

s2i build https://github.com/spring-projects/spring-> petclinic fabric8/s2i-java pet-clinic --incremental

Run

Now that we've built our image we can run it just like we normally would any other image:

docker run -p 8080:8080 pet-clinic

We are binding port 8080 since that's the port our app uses by default.

Output

Here's the output of the petclinic app starting...

Starting the Java application using /opt/run-java/run-java.sh ...
exec java -javaagent:/opt/jolokia/jolokia.jar=config=/opt/jolokia/etc/jolokia.properties -javaagent:/opt/prometheus/jmx_prometheus_javaagent.jar=9779:/opt/prometheus/prometheus-config.yml -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar
I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://172.17.0.2:8778/jolokia/


              |\      _,,,--,,_
             /,`.-'`'   ._  \-;;,_
  _______ __|,4-  ) )_   .;.(__`'-'__     ___ __    _ ___ _______
 |       | '---''(_/._)-'(_\_)   |   |   |   |  |  | |   |       |
 |    _  |    ___|_     _|       |   |   |   |   |_| |   |       | __ _ _
 |   |_| |   |___  |   | |       |   |   |   |       |   |       | \ \ \ \
 |    ___|    ___| |   | |      _|   |___|   |  _    |   |      _|  \ \ \ \
 |   |   |   |___  |   | |     |_|       |   | | |   |   |     |_    ) ) ) )
 |___|   |_______| |___| |_______|_______|___|_|  |__|___|_______|  / / / /
 ==================================================================/_/_/_/

:: Built with Spring Boot :: 2.3.1.RELEASE


2020-07-19 16:06:40.218  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : Starting PetClinicApplication v2.3.1.BUILD-SNAPSHOT on 4920727ddb55 with PID 1 (/deployments/spring-petclinic-2.3.1.BUILD-SNAPSHOT.jar started by jboss in /deployments)
2020-07-19 16:06:40.226  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : No active profile set, falling back to default profiles: default
2020-07-19 16:06:42.947  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFERRED mode.
2020-07-19 16:06:43.168  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 195ms. Found 4 JPA repository interfaces.
2020-07-19 16:06:44.925  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2020-07-19 16:06:44.951  INFO 1 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2020-07-19 16:06:44.952  INFO 1 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.36]
2020-07-19 16:06:45.140  INFO 1 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2020-07-19 16:06:45.140  INFO 1 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 4797 ms
2020-07-19 16:06:46.331  INFO 1 --- [           main] org.ehcache.core.EhcacheManager          : Cache 'vets' created in EhcacheManager.
2020-07-19 16:06:46.375  INFO 1 --- [           main] org.ehcache.jsr107.Eh107CacheManager     : Registering Ehcache MBean javax.cache:type=CacheStatistics,CacheManager=urn.X-ehcache.jsr107-default-config,Cache=vets
2020-07-19 16:06:46.386  INFO 1 --- [           main] org.ehcache.jsr107.Eh107CacheManager     : Registering Ehcache MBean javax.cache:type=CacheStatistics,CacheManager=urn.X-ehcache.jsr107-default-config,Cache=vets
2020-07-19 16:06:46.498  INFO 1 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2020-07-19 16:06:47.133  INFO 1 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
2020-07-19 16:06:47.609  INFO 1 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2020-07-19 16:06:48.127  INFO 1 --- [         task-1] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default]
2020-07-19 16:06:49.586  INFO 1 --- [         task-1] org.hibernate.Version                    : HHH000412: Hibernate ORM core version 5.4.17.Final
2020-07-19 16:06:50.482  INFO 1 --- [         task-1] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.1.0.Final}
2020-07-19 16:06:51.609  INFO 1 --- [         task-1] org.hibernate.dialect.Dialect            : HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
2020-07-19 16:06:54.376  INFO 1 --- [         task-1] o.h.e.t.j.p.i.JtaPlatformInitiator       : HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.NoJtaPlatform]
2020-07-19 16:06:54.432  INFO 1 --- [         task-1] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2020-07-19 16:06:54.523  INFO 1 --- [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 13 endpoint(s) beneath base path '/actuator'
2020-07-19 16:06:54.605  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2020-07-19 16:06:54.608  INFO 1 --- [           main] DeferredRepositoryInitializationListener : Triggering deferred initialization of Spring Data repositories?
2020-07-19 16:06:56.055  INFO 1 --- [           main] DeferredRepositoryInitializationListener : Spring Data repositories initialized!
2020-07-19 16:06:56.073  INFO 1 --- [           main] o.s.s.petclinic.PetClinicApplication     : Started PetClinicApplication in 16.736 seconds (JVM running for 18.197)
^C2020-07-19 16:09:43.051  INFO 1 --- [extShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2020-07-19 16:09:43.056  INFO 1 --- [extShutdownHook] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'
2020-07-19 16:09:43.057  INFO 1 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
2020-07-19 16:09:43.074  INFO 1 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.
2020-07-19 16:09:43.085  INFO 1 --- [extShutdownHook] org.ehcache.core.EhcacheManager          : Cache 'vets' removed from EhcacheManager.

Verify

Lastly, let's verify that our app is running by opening our browser to http://localhost:8080

That's it. With one simple command we've converted our java app source code to an OCI image.

This OCI image can then be pushed to any container registry (DockerHub, ECR, GCR, ACR, etc) and ran in any platform that supports OCI images such as #kubernetes.

Pitfalls

Below are a few pitfalls to consider when using s2i. These may very well be moot points if they are resolved using the --runtime-image option. Something I plan to explore further in another post.

Source leak

Depending on your requirements this may or not be an issue but given the way the basic process works the source code is persisted on the final app image. This not only increases the size unnecessarily but also exposes information that you otherwise might not have liked to be exposed.

Build tools leak

This is very well dependent on the builder to a certain extent. s2i build without providing a separate run image from the build image means that all the tools necessary for building the application are carried over to the app image.

There are two immediate concerns:

From a security perspective, the additional build tools may increase the potential attack vectors.
From an optimization perspective, the image size is unnecessarily larger increasing storage space usage and transport data and time.

Update

07/22/2020: A new post is up that goes into more detail about how to resolve these pitfalls:

Creating an s2i builder for Go (and a runtime image)

Javier Romero ・ Jul 23 ・ 8 min read

#docker #devops #openshift #s2i

DEV Community: Javier Romero

Creating an s2i builder for Go (and a runtime image)

Build an app image with s2i

Javier Romero ・ Jul 19 '20

Objective

App

Builder

s2i/bin/usage

Contents

s2i/bin/save-artifacts

Contents

s2i/bin/assemble

Contents

s2i/bin/run

Contents

Dockerfile

Contents

Build!

Build our builder image

Build our app using the builder

Run our app

App Image

Runtime Image

s2i/bin/run

s2i/bin/assemble-runtime

Dockerfile

Build! (w Runtime Image)

Build our runtime image

Build our app using the builder and runtime

Run our app

App Image (Redux)

Conclusion

Additional Reading

Build an app image with s2i

What is s2i?

Concepts

Builder

Build image

Run image

Features

Separation of concerns

Minimal to no configuration

Process

Install

Build

Breakdown

Output

Pro-tip: Incremental Build

Run

Output

Verify

Pitfalls

Source leak

Build tools leak

Update

Creating an s2i builder for Go (and a runtime image)

Javier Romero ・ Jul 23 ・ 8 min read

`s2i/bin/usage`

`s2i/bin/save-artifacts`

`s2i/bin/assemble`

`s2i/bin/run`

`Dockerfile`

`s2i/bin/run`

`s2i/bin/assemble-runtime`

`Dockerfile`

What is `s2i`?