fabric8io-images/s2i

OpenShift S2I images for Java and Karaf applications

Source-to-Image Builder images

This repo holds the source for the fabric8's S2I builder images for OpenShift.

Java S2I Builder image

The S2I Java builder can be used to use generate Java S2I builds for flat classpath applications. It supports flat-classpath and fat-jar packaged applications, leveraging the run-java-sh project.

Karaf S2I Builder image

The Karaf S2I Builder image is used for creating S2I builds for Karaf based applications.

Development

The project use fish-pepper to generete images/Dockerfiles, so do not directly change run-java.sh. Instead:

• makes your change in run-java-sh project.
• download and install fish-pepper from master.
• run it like path/to/fishpepperrepo/fish-pepper.js both in ./java and .karaf directories.

If you have errors please remove .fp-git-blocks/ directories under both ./java and .karaf.

Release Notes

Please keep the CHANGELOG.md up-to-date.

Release Process

Simply creating a tag (and pushing it remote) will make Circle CI push a release of fabric8/s2i-java to Docker Hub:

git tag -a v3.0.0 -m "release v3.0.0"
git push origin v3.0.0

We also automatically publish from the master branch to latest-* tags.

s2i's Issues

assemble broken for Spring Boot and devtools since 2.3.0

The s2i assemble script is supposed to explode the Spring Boot fat JAR if Spring Boot devtools dependency is found. It is broken since 2.3.0 as unzip is not found anymore in the image.

build.gradle ignored during build process.

Hi,

I am using s2i build process to build an app in OpenShift from Git source having a gradle project.
Builder image is "registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift"

My project directory structure is as shown below

However, when I start the build process, the assemble script echoes "S2I source build with plain binaries detected" instead of echoing "S2I source build for Gradle detected, due to presence of a .gradle in ${S2I_SOURCE_DIR}"

Why is the assesmble script not detecting build.gradle from root folder?

Need help.

Thanks,

include "envsubst" in container?

My understanding is that the preferred way to pass non constant "configuration knobs" to container images is via environment variables. In OpenShift we have a the Environment UI tab for this.

The envsubst util would be very handy to replace values in configuration files by environment values during an S2I build if it could easily be used in .s2i/bin/assemble (or even .s2i/bin/run).

Would we open to including envsubst in the image? Or even in FROM jboss/base-jdk ?

Java 11

Issue to discuss eventually (not today or tomorrow) supporting Java 9.

NOK for the moment , master...vorburger:java9 :

Step 17/35 : RUN yum install -y java-9-openjdk
 ---> Running in f2920f7f4327
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
 * base: fr2.rpmfind.net
 * extras: mirrors.ircam.fr
 * updates: centos.crazyfrogs.org
No package java-9-openjdk available.
Error: Nothing to do
The command '/bin/sh -c yum install -y java-9-openjdk' returned a non-zero code: 1

Recently change default directory from `/opt/jboss` to '/' breaks backward compability and could cause issues to end-users

@rhuss & Co. I just ran into an interesting problem over on my OASIS-learn-study/s2i-minecraft-server#7 which I thought would be worthwhile to point out to you guys here:

Something (presumably #165) recently changed the default directory which scripts such as .s2i/bin/assemble start with from /opt/jboss (RW) to '/' (RO) - and this, technically, breaks backward compability, and could cause issues to end-users (like it has for me).

If you think we can forget about, I take no offense if you just close this issue again.

Or should we explicitly put a cd /opt/jboss (back) somewhere?

when to support karaf 4.1.5

I used karaf s2i to deploy my project into openshift. But i found it can work properly under 4.0.8, when i use karaf 4.1.2 or 4.1.5 ,it crashing frequently. I don't know why, Can you help me?
thanks!

Documentation how to use this for noobs?

I'm trying to figure out how to use this.. total S2I noob here - where is the "hello, world" example? 😄

PS: Also interested in possibly exending this to allow Gradle as well as Maven builds?

Self test, and CI for PRs

It could be neat to have a small self contained "self test" (and a CI with it, e.g. Travis, for all PRs) like:

docker build -t fabric8/s2i-java:latest
s2i build s2i-java-example fabric8/s2i-java fabric8/s2i-java-example

and then ideallly, not 100% sure how to do this best, something like:

docker run -p 8080:8080 vorburger:s2i-java-example &
# TODO how to do simplest possible HTTP GET http://localhost:8080 and fail/pass?
# TODO how to best stop docker again
kill $!

I'm happy to move the https://github.com/vorburger/s2i-java-example repo under https://github.com/fabric8io-images, or even just directly contribute that into this repo into some place like s2i/java/example, if either could be of interest or help to get this done.

sandbox/ ?

@apupier @rhuss is what is in sandbox/ in this repo still used & maintained, or should it be removed?

Which base image to use for rhel

We have valid RHEL Subscriptions so I would like to build
s2i/java/Dockerfile.rhel
But it can't find the references base image
$ docker pull jboss-base-7/jdk8:latest
Trying to pull repository registry.access.redhat.com/jboss-base-7/jdk8 ... not found
Trying to pull repository docker.io/jboss-base-7/jdk8 ... not found
Error: image jboss-base-7/jdk8:latest not found

adapt run-java-sh to adopt the auto-generation options for Java 11

@rhuss said in #160 that, quote:

major work will be to adapt https://github.com/fabric8io-images/run-java-sh to adopt the auto-generation options for the JDK. E.g. it would need a Java 8 / Java 11 dynamic detection (or taken from an env var) and use only the self-calculated cgroup based limits if not running on Java 11. Also, it would be awesome to update the fine-tuned options for Java 11 as well. A similar issue is open over there btw --> https://issues.jboss.org/browse/CLOUD-2839

But somewhat to my surprise, I seem to actually have been able to get a (basic) Java 11 working without touching run-java-sh ... I therefore propose that we work incrementally, and get #160 wrapped up and merged, and then iterate to improve things re. the point raised above under this issue.

DEPLOYMENTS_DIR override

I would like to override DEPLOYMENTS_DIR right now it seems to be fixed

unzip missing

Some tools need unzip and this command seems to be removed in later versions

make Gradle run without its daemon

Once the base #118 (#121) is in, I'll have to remember to follow-up with a minor optimization; cauz this:

./gradlew build
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

makes little sense in a short-lived container... there must be some arg to make it launc without daemon.

mvn build should use --batch-mode flag

This would avoid:

Using a minimum base image

In #160 @gunnarmorling suggested among other things, quote:

How about using a minimum image (e.g. registry.centos.org/centos/centos7-atomic or registry.fedoraproject.org/fedora-minimal) as a basis?

I propose that we work incrementally, and keep #160 focused on (a first version of) just Java 11 support, wrap that up and get it merged, and then iterate to improve things e.g. re. the point raised above under this issue.

Add build-time labels to generated docker image and allow to add custom ones

Currently my image built with the fabric8 maven plugin have labels like these ones even if the image has been build a few hours ago:

    build-date=20170605 
    io.fabric8.s2i.version.jolokia=1.3.6 
    io.fabric8.s2i.version.maven=3.3.3 
    io.k8s.description=Platform for building and running plain Java applications (fat-jar and flat classpath) 
    io.k8s.display-name=Java Applications 
    io.openshift.build.image=fabric8/s2i-java:2.0 
    io.openshift.build.name=svc-survey-s2i-1 
    io.openshift.build.namespace=it 
    io.openshift.build.source-location=/tmp/s2i-build511047928/upload/src 
    io.openshift.s2i.destination=/tmp 
    io.openshift.s2i.scripts-url=image:///usr/local/s2i 
    io.openshift.tags=builder,java 
    license=GPLv2 
    org.jboss.deployments-dir=/deployments 
    vendor=CentOS 

All these labels are not so interesting.

It would be great if the s2i-java builder could add labels to the generated docker image like those added to a generated deployment config (for instance fabric8.io/git-commit ) as well as custom ones.

According to this doc, it seems that this can be done by generating a /tmp/.s2i/image_metadata.json file.

Unable to build when maven project is in a sub-directory

It seems that the java build has an issue when the source code of the maven project is inside a sub-directory of the repository.

There is a check in the assemble script which checks for the existence of the pom.xml, but this uses S2I_SOURCE_DIR, which it seems cannot be overridden by the build.

My proposal would be to add some additional kind of environment variable (e.g. SOURCE_ROOT_DIR) which defaults to . and can be overridden.

Fish pepper blocks get not upated sometimes

We make use of some fish-pepper blocks for Jolokia and Jmxexporter. If I modify any of the block config params, the changes never see seem to show up in the fish-pepper generated Dockerfile(s).

Add JAVA_ARGS to support command line arguments

This is related to https://issues.jboss.org/projects/OSFUSE/issues/OSFUSE-475 to transport command line arguments to the run s2i script.

add test coverage for JVM metrics exposure

In #194 @alexkieling started looking at adding something to the existing test.sh to cover some of the metrics which we expose in this image. We realized there that #194 was about a Camel specific metric. Before tacklking that, this issue is to first take a step back and add a non-regression test for the basic (non-Camel) JVM metrics we expose.

Overriding s2i not working properly

In order to workaround #12 I tried to provide custom s2i scripts in OSE 3.2 by placing assemble and run scripts into .s2i/bin.

However, there seem to be several issues:

1. The variable STI_SCRIPTS_PATH is not available in the custom scripts
2. When using
   source /usr/local/s2i/assemble
   in the customer assemble script I get
   /usr/local/s2i/assemble: line 4: /tmp/scripts/s2i-setup: No such file or directory

Automatically naming the Jolokia port "jolokia"

If a sevice port in OpenShift is named "jolokia" a web link will automatically be added showing the JMX web console:

However when creating a new application by:

oc new-app fabric8/s2i-java~https://github.com/ctron/hono-example-bridge.git

Then the port will be present, but without a name. It would be awesome of fabric8/s2i could somehow trigger the name jolokia on that port.

EXPOSE 8080

Unless I'm missing something in how this is to be used, don't we need to have a way to specify which port, in addition to 8778 and 9779, is to be EXPOSE'd in the Dockerfile for the "microservices with a flat classpath" (quote from README) to be accessible by a Service and Route?

Because without hacking that, I cannot get e.g. this to work:

oc new-app fabric8/s2i-java~https://github.com/vorburger/s2i-java-example
oc expose svc/s2i-java-example --port=8080
oc status -v
...
Warnings:
  * route/s2i-java-example has a port specified (8080) but svc/s2i-java-example has no such targetPort.

PS: An oc expose svc/s2i-java-example will create a route on port 8778, which of course isn't what one would want.

add support for incremental Gradle builds

Once the base #118 (#121) is in, I'll follow-up on it to add support for --incremental Gradle builds.

I'll have to find a way to make Gradle write everything we want to preserve into ${S2I_ARTIFACTS_DIR}/gradle, which I've already used in the final clean-up commit of #121 for GRADLE_CLEAR_REPO.

We'll then also have to make java/templates/s2i/save-artifacts include that in the TAR (how, together with m2?), and I'm guessing somewhere "restore" it - @rhuss where does that happen?

I can then test this with the new test.sh (just manually unfortunately; I don't see how to reasonably easily automatically cover this...) and observe that the 2nd incremental Gradle run is not re-downloading anymore, and that the 2nd Maven incremental run still not re-downloading (as it currently, just to verify non-regression).

Missing one or more than one assembly archive file *.zip in /tmp/src/target

Hello

I am trying to build using the s2i builder fabric8/s2i-karaf but I get the below error.

I run the following command:

s2i build . fabric8/s2i-karaf karaf/test --loglevel=5

I0511 19:32:26.999666    2107 sti.go:679] [INFO] BUILD SUCCESS
I0511 19:32:26.999685    2107 sti.go:679] [INFO] ------------------------------------------------------------------------
I0511 19:32:27.000147    2107 sti.go:679] [INFO] Total time: 04:00 min
I0511 19:32:27.000364    2107 sti.go:679] [INFO] Finished at: 2018-05-11T07:32:26+00:00
I0511 19:32:27.207335    2107 sti.go:679] [INFO] Final Memory: 26M/136M
I0511 19:32:27.207373    2107 sti.go:679] [INFO] ------------------------------------------------------------------------
I0511 19:32:27.275942    2107 sti.go:679] Copying built artifacts from /tmp/src/target into /deployments...
I0511 19:32:27.312372    2107 sti.go:679] Missing one or more than one assembly archive file *.zip in /tmp/src/target
I0511 19:32:27.434833    2107 docker.go:1048] Waiting for container "78abf81020ba21ca3a6eb35df92f32f98e0fe05cf9bd68621114c716cb4ee580" to stop ...
I0511 19:32:27.772003    2107 docker.go:984] Removing container "78abf81020ba21ca3a6eb35df92f32f98e0fe05cf9bd68621114c716cb4ee580" ...
I0511 19:32:27.994757    2107 docker.go:994] Removed container "78abf81020ba21ca3a6eb35df92f32f98e0fe05cf9bd68621114c716cb4ee580"
I0511 19:32:28.007111    2107 cleanup.go:33] Removing temporary directory /tmp/s2i981732262
I0511 19:32:28.007769    2107 fs.go:236] Removing directory '/tmp/s2i981732262'
I0511 19:32:28.035146    2107 main.go:165] Build failed
E0511 19:32:28.035219    2107 errors.go:276] An error occurred: non-zero (13) exit code from fabric8/s2i-karaf

Env variables used in JAVA_OPTIONS are not expanded

For example, if I pass -Dsome-property=${CONTAINER_CORE_LIMIT:-1} in the JAVA_OPTIONS, the env variable is not expanded.

AB_JOLOKIA_PORT customization probably isn't working, because it's hard-coded in the Dockerfile

The README says:

AB_JOLOKIA_PORT : Port to use (Default: 8778)

but I doubt customizing this actually works - because while it's dynamic here, it's then hard-coded in the Dockerfile ...

Take advantage of multi-stage builds and modular JDK images

Hey @rhuss, over the weekend I've been musing how the "ideal" Dockerfile for a Java app would look like. My requirements essentially are these:

• Small base image and small result image; I'm not counting beans here, so e.g. I prefer the Fedora/CentOS/RHEL minimal image with proper glibc over Alpine with musl; But I don't want multiple hundred MB either
• Avoidance of unneccessary re-building image layers

You can find the Dockerfile I came up with here: debezium/debezium-examples#42.

It's doing three things:

• One stage creates a minimal JDK with just the required modules
• One stage builds the project and adds the dependencies
• The final stage assembles all required files

The first and second stages do only "heavy" work if needed, i.e. if the POM has changed (for the dependencies that's done automatically by virtue of leveraging mvn dependency:gooffline, for the latter it's a manual process). It's using the Fedora minimal image as base for the resulting image. So the size and rebuilding penalties are quite neat:

• ~180 MB overall, out of which only a very thin layer must be rebuilt upon actual code changes. Lower layers (dependencies, JDK) must only be rebuilt if actually needed. Also the Maven repo is not part of the resulting image itself, still no re-downloads of all the Maven deps are needed, as the repo lives in an (untagged) image produced by the earlier build stage.
• Only the last image layer containing the actual application JAR must be re-built most of the times, resulting in very quick turn-around times in terms of building and redistributing the image.

So my question is: can we achieve something comparable with S2I? If so, how? If not, could we make it happen? Let me know what you think, looking foward to hearing from you :)

Executable fat WARs e.g. from Spring Boot should work without requiring setting JAVA_APP_JAR with fixed version

I'm finding that one currently has to put this e.g. into a .s2i/environment, e.g. to use this with Spring Boot:

ARTIFACT_COPY_ARGS=*-boot.war
JAVA_APP_JAR=alfio-1.14-SNAPSHOT-boot.war

when it would be much nicer (and avoid confusion on versin bumps) if we could support wildcard expansion in JAVA_APP_JAR, just like it is allowed in other environment variables:

ARTIFACT_COPY_ARGS=*-boot.war
JAVA_APP_JAR=*-boot.war

chmod: cannot access '/home/jboss': No such file or directory

Unless I'm misunderstanding something, this is currently broken? See this:

docker build https://github.com/fabric8io-images/s2i.git#master:java/images/jboss

hits this:

(...)
Removing intermediate container 0c135ef3fbca
Step 24/28 : RUN mkdir -p /deployments/data  && chmod -R "g+rwX" /deployments  && chown -R jboss:root /deployments  && chmod -R "g+rwX" /home/jboss  && chown -R jboss:root /home/jboss  && chmod 664 /etc/passwd
 ---> Running in d6a33b78d783
chmod: cannot access '/home/jboss': No such file or directory
The command '/bin/sh -c mkdir -p /deployments/data  && chmod -R "g+rwX" /deployments  && chown -R jboss:root /deployments  && chmod -R "g+rwX" /home/jboss  && chown -R jboss:root /home/jboss  && chmod 664 /etc/passwd' returned a non-zero code: 1

same if you do it like in the circle.yml:

git clone [email protected]:fabric8io-images/s2i.git
cd images/jboss
docker build -t fabric8/s2i-java:latest .

UseCGroupMemoryLimitForHeap ?

Shouldn't run-java.sh be adding that UseCGroupMemoryLimitForHeap JVM option?

JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

Smaller JDK base image using Java 11 modularity (jlink)

once and after we'll have #160, then I think the idea also in raised #180 by @gunnarmorling re. a modular small JDK base image (jlink) is worth a dedicated issue ... let's discuss this further and some day implement under this issue? -- One of the points to IMHO clarify is:

1. Could we just settle on a suitable list of JDK modules to hard code into the Java S2I base image (e.g. like what @gunnarmorling has done over here) ? Like obviously no UI stuff, and ditch really old and in practice un-used modules in modern server side containerized Java apps.

2. Or is this an illusion and there would have to have some (complicated...) mechanism to chose modules, and have a multi-stage build, for JDK and application? (Urgh, with S2I.)

3. May be a middle way and a (hopefully small) set of pre-baked S2I Java 11 image types with different JDK modules?

"Permission Denied" when running in OpenShift

Getting the following error when running the redhat-openjdk18-openshift s2i builder in OpenShift:

Starting the Java application using /opt/run-java/run-java.sh ...
 /opt/run-java/run-java.sh: line 44: cd: /home/jboss: Permission denied

Any ideas?

images/fedora/openjdk/11 instead of fedora-java11 etc.

@rhuss has pointed out that instead of the "flat" images/fedora-java11 structure which #189 introduces for #160, we could in the future use FishPepper's "combinatorial multi-level" support to build e.g. images/fedora/openjdk/11/64bit/jdk (at the most extreme, or a suitable shortened version of this - depending on how much variability we ever anticipate).

The (non-S2I!) https://github.com/fabric8io-images/java project does this in its images.yml, note its 3 level params (base, version, type), the respective config and the related ignore-for in line 56.

Error while pushing image to docker registry

Hi there!

I have openshift origin installed in clodes environmet, so images cannot be pulled from public repositories. I need to push images manualy. My steps:

1. pull fabric8/s2i-java:2.0 on computer with internet
2. save this image to file
3. copy saved image to server where openshift is installed
4. on master node load image
5. get token with: oc whoami -t
6. login to docker: docker login -p 172.30.1.1:5000
7. tag image: docker tag fabric8/s2i-java:2.0 172.30.1.1:5000/fabric8/s2i-java:2.0
8. push image: docker push 172.30.1.1:5000/fabric8/s2i-java:2.0
   last command failed with exception:
   The push refers to a repository [172.30.1.1:5000/fabric8/s2i-java]
   5f70bf18a086: Preparing
   d32ed8bcc29a: Preparing
   7a3918f43401: Preparing
   8794367458d9: Preparing
   7b2b8ba72018: Preparing
   ef12ec351380: Waiting
   aa97a88ab73b: Waiting
   976e0cc32ff4: Waiting
   d709326f53ea: Waiting
   cea2ed19e339: Waiting
   33e60bc17c03: Waiting
   8515814a316b: Waiting
   7fa540ae36b6: Waiting
   509be91f37b7: Waiting
   23308a2d4711: Waiting
   9d53f6387fe5: Waiting
   0219e8c42d4a: Waiting
   ed3fbbd74f2c: Waiting
   fef12de4c7da: Waiting
   3bf2c105669b: Waiting
   85c6e373d858: Waiting
   dc1e2dcdc7b6: Waiting
   unauthorized: authentication required

Any ideas how it can be fixed?

Clean /tmp after build

It seems that

s2i/karaf/templates/s2i/assemble

doesn't clean the /tmp dir.

There is an option to delete the m2 (MAVEN_CLEAR_REPO=) but the /tmp dir contains also a ~/src with many files including the maven target dir with the .zip.

This makes the image to be ~two times bigger.

SpringBoot exploded mode broken if class name is long

When the Spring Boot application class name is long, the manifest spec says that it should span 2 lines and thus the extraction is wrong and the application cannot be started as the class name given to the launcher is truncated

error to run github.com/dhirajsb/camel-hello-world

i run following command under openshift:

oc new-app --strategy=source fabric8/s2i-karaf~git://github.com/dhirajsb/camel-hello-world

error is

[INFO] ------------------------------------------------------------------------
--
  | [INFO] BUILD SUCCESS
  | [INFO] ------------------------------------------------------------------------
  | [INFO] Total time: 02:27 min
  | [INFO] Finished at: 2018-04-22T00:19:03+00:00
  | [INFO] Final Memory: 22M/425M
  | [INFO] ------------------------------------------------------------------------
  | Copying built artifacts from /tmp/src/target into /deployments...
  | Missing one or more than one assembly archive file *.zip in /tmp/src/target
  | error: build error: non-zero (13) exit code from fabric8/s2i-karaf@sha256:b6fe6bc41c263242dfa42076acd57198087bd9f067aab32bae1c520f3ebbc738

can you help me?

add support for Gradle builds in addition to Maven

Would there be any interest in a contribution to this project to build Gradle projects, in addition to Maven?

It doesn't seem that hard to add a something like this here:

if [ -f "${S2I_SOURCE_DIR}/*.gradle*" ]; then

note the use of *.gradle* in order to also allow build.gradle.kts for the Gradle Kotlin DSL, and myProjectName.gradle.

if present, then run something like ./gradlew --gradle-user-home=${S2I_ARTIFACTS_DIR}/gradle-home --project-cache-dir=${S2I_ARTIFACTS_DIR}/gradle-project-cache build (TBC, probably with a GRADLE_ARGS and/or GRADLE_ARGS_APPEND, similar to the MAVEN_ARGS and MAVEN_ARGS_APPEND).

I would limit this to support only the Gradle wrapper, and not even bother to add a Gradle distribution into the image. Just because using the wrapper is VERY widespread in Gradle based project (contrary to the maven-wrapper), and saves a ton of "which version" hassles, which for frequently releasing Gradle is even more important than with Maven (BTW surprised we're on ancient Maven 3.3.3 instead of latest 3.5.2 here...). The overhead of downloading a Gradle distribution IMHO is manageable with incremental builds by preserving the --gradle-user-home and --project-cache-dir accross builds; in the bigger picture of typically many many dependencies, the Gradle distribution itself is really just another such dependency.

BTW incremental builds with Gradle should be blazingly fast, not only avoiding dependency re-downloads, but truly incrementallying building code changes themselves (which never really works reliably in Maven; BTW I'm surprised we don't do clean package instead of just package here).

It should also include the equivalent of #110.

JMX exporter: quoted property values captured incorrectly

Object names with quoted property values are being incorrectly captured by regular expression defined in the JMX exporter configuration.

Current behavior
The quotes and the value enclosed by the quotes are being captured.

Expected behavior
Only the value enclosed by quotes should be captured.

Example of Prometheus metric after name object name property has been converted to processor label:

org_apache_camel_ExternalRedeliveries{context="MyCamel",processor="\"log1\"",type="processors",} 0.0

See file with more examples: metrics.txt

Mismatch between archive type generated by docker-maven-plugin and one needed by deploy-and-run.sh

According to karaf quickstart's pom the archive type is zip whereas deploy-and-run.sh expects a zip, this cause the following error to appear when deploying with f8-local-deploy :

Missing or more than one assembly archive file *.tar.gz in /deployments

I'll try to submit a PR

Java 11 with CentOS instead of Fedora base image

Once a CentOS 7.6 with Java 11 packages is available (it is not yet, at the time of opening this), then the Fedora based Java 11 support introduced in #160 could switch the base image.

Would we like to keep the Fedora one, or remove it again?

See also #192.

FROM fixed centos:7.5.1804 or just centos:7 ?

@rhuss while looking more closely at #165 than I had before (because of #171), I was just wondering why you chose FROM centos:7.5.1804 (fixed version from that month) instead of just using centos:7 ? Shall we change this?

Add wildcard into nonProxyHosts

s2i/karaf/images/rhel/run-java.sh

Line 465 in c8452f3

ret="$ret -Dhttp.nonProxyHosts=\"$(echo $noProxy | sed -e 's/,[[:space:]]*/|/g')\""

Hi,

nonProxyHosts allows to use * for pattern matching. For example -Dhttp.nonProxyHosts=” *.foo.com|localhost”

But Openshift doesn't accept does not accept * attached to a domain suffix.

Your script can be improved to prefix .foo.com with a *. I've got this need on a professional and private project and we solve it with this script :

# Replace separator "," by "|"
JAVA_NO_PROXY=$(echo $no_proxy |  sed -e 's/,[[:space:]]*/|/g')
# Prefix hosts with a wildcard '*' (ex: '.svc' -> '*.svc') because OpenShift doesn't allow wildcards in  $no_proxy
JAVA_NO_PROXY=$(echo $JAVA_NO_PROXY | sed -e 's/^\./*./g'  | sed -e 's/|\./|*./g')

I hope it will help.

Kind regards,

Mathieu

references :

• https://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html
• https://docs.openshift.com/container-platform/3.9/install_config/http_proxies.html#configuring-no-proxy

Automatically ignore *-javadoc.jar and *-sources.jar

This strikes me as a bit dumb and would be nice to have be more intelligent out-of-the-box:

(...)
Copying Maven artifacts from /tmp/src/spring/target to /deployments ...
Running: cp -v *.jar /deployments
'org.opendaylight.bot.spring-javadoc.jar' -> '/deployments/org.opendaylight.bot.spring-javadoc.jar'
'org.opendaylight.bot.spring-sources.jar' -> '/deployments/org.opendaylight.bot.spring-sources.jar'
'org.opendaylight.bot.spring.jar' -> '/deployments/org.opendaylight.bot.spring.jar'
Checking for fat jar archive...
... done
Build completed successfully

$ docker run --rm -p 8080:8080 opendaylight-bot
Starting the Java application using /opt/run-java/run-java.sh ...
ERROR: Neither JAVA_MAIN_CLASS nor JAVA_APP_JAR is set and 3 found in /deployments (1 expected)

Execute mvn clean to reduce image size

After https://github.com/fabric8io-images/s2i/blob/master/karaf/s2i/assemble#L127 a mvn clean should also be executed to remove build artifacts. This should result in an even smaller image size.

Support for incremental build

fabric8/s2i-java should support incremental build so that build time will get reduced

Docker builds fail attempting to download Maven 3.3.3

Seems that Maven 3.3.3 is no longer available here:

http://www.apache.org/dist/maven/maven-3/

It's available here though:

https://archive.apache.org/dist/maven/maven-3

Should we stick with 3.3.3 or upgrade to 3.3.9?

Why isn't Jolokia accessible?

I tried s2i/java/example with Docker as follows:

cd s2i/java/example
s2i build --copy . fabric8/s2i-java fabric8/s2i-java-example
docker run -d -p 8080:8080 -p 8778:8778 -e AB_JOLOKIA_USER=admin -e AB_JOLOKIA_PASSWORD=admin --name s2i-java-example fabric8/s2i-java-example

The app looks working fine, as http://localhost:8080 returns hello, world. However, accessing Jolokia endpoint doesn't work:

$ curl -v -u admin:admin http://localhost:8778/jolokia/version
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8778 (#0)
* Server auth using Basic with user 'admin'
> GET /jolokia/version HTTP/1.1
> Host: localhost:8778
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
* Authentication problem. Ignoring this.
< Www-authenticate: Basic realm="jolokia"
< Date: Thu, 19 Apr 2018 02:53:27 GMT
< Content-length: 0
< 
* Connection #0 to host localhost left intact