openshift/source-to-image
1
0
Fork 0
mirror of https://github.com/openshift/source-to-image.git synced 2026-02-05 12:44:54 +01:00
Code Issues Releases Activity

Fix some nits in documentation

Browse Source 
- s/Golang/Go/
- Make similar paragraphs similar, include the same list of languages.
  The paragraph in docs/runtime_image.md contains more detailed
  information.
- Spurious whitespace changes.
This commit is contained in:
Rodolfo Carvalho
2016-07-13 23:34:44 +02:00
parent 3b06f53dee
commit a92ecdd11a
2 changed files with 7 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/runtime_image.md
View File

@@ -4,7 +4,7 @@
For dynamic languages like PHP, Python, or Ruby, the build-time and run-time environments are the same. In this case using the builder as a base image for a resulting application image is natural.
For compiled languages like C/C++, Java, or Golang, the dependencies necessary for compilation might dramatically outweigh the size of the actual runtime artifacts, or provide attack surface areas that are undesirable in an application image. To keep runtime images slim, S2I enables a multiple-step build processes, where a binary artifact such as an executable or Java WAR file is created in the first builder image, extracted, and injected into an second image that simply places the executable in the correct location for execution. To give you even more abilities to customize a resulting image, S2I is also executing an `assemble-runtime` script inside of this (runtime) image. In this way you may do final adjustments by modifying files before an image will be committed.
For compiled languages like C, C++, Go, or Java, the dependencies necessary for compilation might dramatically outweigh the size of the actual runtime artifacts, or provide attack surface areas that are undesirable in an application image. To keep runtime images slim, S2I enables a multiple-step build processes, where a binary artifact such as an executable or Java WAR file is created in the first builder image, extracted, and injected into a second image that simply places the executable in the correct location for execution. To give you even more abilities to customize a resulting image, S2I is also executing an `assemble-runtime` script inside of this (runtime) image. In this way you may do final adjustments by modifying files before an image will be committed.
The following diagram illustrates the build workflow:
@@ -84,4 +84,3 @@ Builder and runtime containers have the same environment. In other words `assemb
### Extended build and incremental build
In the current implementation it is not possible to do an extended incremental build. This combination is invalid and the build will fail.