1

I have a Spring application built into a Docker image with the following command in dockerfile

CMD cd /opt/app/jar \
    && java -Dspring.config.location=file:/opt/app/config/ -Dspring.profiles.active=test -jar *.jar

When creating app on OpenShift with 

oc new-app --name=test-app --docker-image=MyImage

and inspect the log with oc logs <pod_name>, I see this error:

java.lang.IllegalStateException: Logback configuration error detected: 
ERROR in ch.qos.logback.core.rolling.RollingFileAppender[LOGFILE] - Failed to create parent directories for [/opt/app/jar/../log/debug.log]
ERROR in ch.qos.logback.core.rolling.RollingFileAppender[LOGFILE] - openFile(/opt/app/jar/../log/debug.log,true) call failed. java.io.FileNotFoundException: /opt/app/jar/../log/debug.log (No such file or directory)

However, when I run the image directly with docker run -it <image_ID> /bin/bash, and then execute the java -jar command above, it runs fine.

Here is the snippet from my logback.xml file:

<appender name="LOGFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${user.dir}/../log/debug.log</file>
        <encoder>
            <pattern>${FILE_LOG_PATTERN}</pattern>
            <charset>utf8</charset>
        </encoder>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${user.dir}/../log/archived/debug.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <maxFileSize>50MB</maxFileSize>
            <maxHistory>10</maxHistory>
        </rollingPolicy>
    </appender>

Could you please advise what I miss?

Versions I use:

*# oc version
oc v3.7.14
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth GSSAPI Kerberos SPNEGO

# docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Wed Dec 13 12:18:58 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Wed Dec 13 12:18:58 2017
 OS/Arch:         linux/amd64*
hydradon
  • 1,316
  • 1
  • 21
  • 52
  • FWIW. When running stuff in containers you should be logging to stdout/stderr, not to a file. That way the logs can be captured by the platform and are accessible through the platform. Logging into the container file system means they aren't readily accessible and would be lost when the container exits. – Graham Dumpleton Sep 07 '18 at 05:05
  • @GrahamDumpleton I have `` too – hydradon Sep 07 '18 at 07:43

2 Answers2

3

Is it possible that it is an issue with permissions?

Unless something has changed...for better security OpenShift by default runs containers using a user with random UID; that user is a member of the root group.

So, in addition to the command @Rico suggested to be added to Dockerfile, I would add:

RUN mkdir -p /opt/app/log \
 && chown -R :root /opt/app/log \
 && chmod -R 0775 /opt/app/log

This blog article has more info about running Docker containers with non-root users or random user IDs. (Disclaimer: I am affiliated with that web site)

apisim
  • 4,036
  • 1
  • 10
  • 16
0

${user.dir} is probably different when you run oc and when you run docker.

I'd start by checking that value in both environments.

In the case of oc it obviously doesn't exist in the containers so one workaround is to create a container from MyImage that has it.

Rico
  • 58,485
  • 12
  • 111
  • 141
  • Here says `${user.dir}` is wherever the `java` command is run from: https://stackoverflow.com/questions/16239130/java-user-dir-property-what-exactly-does-it-mean In both case, I execute the command where the jar resides – hydradon Sep 07 '18 at 05:52
  • In both cases, I execute the command where the jar resides. And from the error, I can see `${user.dir}` resolves to `/opt/app/jar`. I expect the log to go in `/opt/app/log` – hydradon Sep 07 '18 at 06:09
  • How about adding to your dockerfile RUN mkdir -p /opt/app/log. – Rico Sep 07 '18 at 06:44
  • I tried that and it didn't work either. So I removed file-logging entirely and log everything to STDOUT and let the platform handle the storing of logs – hydradon Sep 12 '18 at 06:29