4.1. Choosing a Build Method
When to Read This Chapter
Read it before starting your first build. Decide here which of the routes to use, then move to the chapter for that route.
What a Container Image Is
It is a single file bundling an application together with what it needs to run: the runtime, libraries, and configuration.
With an image, it runs the same way on any server. The "it works on my PC but not on the server" problem is reduced, because the runtime environment is inside the image.
A pod creates and runs a container from an image (see 3.1). So an image has to exist before you can deploy.
Two Ways to Build an Image
| Method | Description | What you need |
|---|---|---|
| Dockerfile | You write which files to include and which commands to run | Knowledge of writing Dockerfiles |
| S2I | You give it source code and it builds the rest | Nothing |
A Dockerfile offers a lot of freedom, but it has to be rewritten for each language and build tool, and written badly it produces oversized images or security problems.
S2I uses a version of that work that has already been done.
What S2I Is
S2I (Source-to-Image) is a way of building a container image directly from source code.
Without writing a Dockerfile, a builder image matched to the language and build tool handles compilation and image creation on your behalf.
| Dockerfile | S2I | |
|---|---|---|
| What you prepare | You write a Dockerfile | You choose a builder image |
| Build style across teams | Each team differs | Unified |
| Security standards | Each team has to handle them | Already reflected in the builder image |
| Freedom | High | Within what the builder supports |
What S2I Does
The sequence is as follows.
| Order | What happens |
|---|---|
| 1 | The source is fetched from the Git repository |
| 2 | The builder image compiles the source (Maven, Gradle, npm, and so on) |
| 3 | The output is placed into the runtime image to create the container image |
| 4 | The created image is pushed to the registry (Harbor) |
Pushing to the registry is the final step. An image has to be somewhere the cluster can fetch it from before it can be deployed. Built only locally, the pod cannot find it.
What a Builder Image Is
It is an image containing both the compilation tooling and the runtime environment. There is one for each combination of language and build tool.
| Application | What the builder holds |
|---|---|
| Java web (WAR) | JDK + Maven/Gradle + Tomcat |
| Java executable (JAR) | JDK + Maven/Gradle + JRE |
| Node.js | Node.js + npm |
| Python | Python + pip |
Builder images are created and registered in advance by the organization. In an air-gapped environment, only the registered ones can be used.
Execution Routes
There are several ways to run an S2I build in COP. Whichever route you use, the resulting image is the same.
| Route | Where | This document |
|---|---|---|
| Console | Create and run a build configuration on the web screen | 4.2, 4.3 |
| Jenkins | Run a Job from the Jenkins web screen | 4.4 |
| Bastion | Connect to a server and run commands | 4.5 |
| Other CI tools | Call the same script from GitLab CI, GitHub Actions, and so on | 4.6 |
| ArgoCD | Deploy based on a Git repository (GitOps) | 4.7 |
Whichever route you use, how to sequence the deployment is decided separately — rolling update, Recreate, blue-green, and canary are compared in 4.8.
The last two routes do not replace the earlier ones; they sit on top of them. Jenkins, Bastion, and other CI tools all call the same shell script (see 4.5), and ArgoCD changes only the deployment step among those to be Git-based.
CI Tools Are Interchangeable
The build and deployment logic lives in shell scripts, and the CI tool only calls them. Even the Jenkins jobs COP
provides by default do nothing more than cd <directory> followed by running the script. So if your organization has
a standard CI tool, you can use it as is, and the only new thing to create is a single pipeline definition file
(see 4.6).
How to Choose
| Situation | Recommended route |
|---|---|
| You want to build simply from a screen and see the result right away | Console |
| You want to deploy the built image immediately as well | Console |
| You need to combine build and deploy and manage approvals and rollbacks | Jenkins |
| It has to repeat at set times | Jenkins |
| You need to create the build and deployment setup for a new application in one go | Jenkins |
| You need to embed it in an automation script or specify detailed options directly | Bastion |
| An exceptional case the first two cannot handle | Bastion |
| You already use a CI tool and cannot adopt Jenkins | Other CI tools |
| Deployment history has to be recorded in Git and controlled through an approval process | ArgoCD |
| Nothing must deviate from the settings the cluster has defined | ArgoCD |
The Console is limited to the builder images registered on the screen. If you need a builder that is not in the list, use Jenkins or Bastion, or ask operations staff to register it.
Permissions differ as well.
| Route | Permission required |
|---|---|
| Console | Edit permission for build configurations in that namespace (see 7.1) |
| Jenkins | A Jenkins account and Job execution permission |
| Bastion | A server sign-in account |
The Example Used in This Document
Chapters 4.2 through 4.8 use the same application.
| Item | Value |
|---|---|
| Application | The eGovFrame standard framework sample |
| Namespace | egov |
| Jenkins Jobs | 20-egov-build (build), 30-egov-deploy (deploy) |
To confirm that the result is the same across routes, read the three chapters in order.