A story stuck with log output in Docker + Play framework environment

This article is the 15th day of WebCrew Advent Calendar 2020. Yesterday was @ piwi's "I was worried when I created a site with private Nuxt.js (coder)".

Introduction

I'm usually a person doing server-side implementation. I have a chance to touch the front desk a little. Most recently, I'm doing scala, java, nuxtjs, etc. I couldn't come up with the right material, so recently I'll write about some problems with the environment settings and how to deal with them.

Log output and rolling settings

environment CentOS Docker + Playframework(scala) + Logback

Issue: When replacing a tool in a new environment, I want to set the log file output as part of the production / development environment settings.

Assumption: Log confirmation with stdout has already been done at the time of implementation. Log output is Logback (default)

First thing I did

--Change log file output settings in logback.xml --Added mount settings for output destination folder to docker-compose.yml ↓ Additions and changes (Note that the xml file before the change is almost the same as logback.xml that was automatically generated when it was initialized with the play framework)

logback.xml

  <property name="LOG_HOME" value="/home/appserver" />

  <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_HOME}/logs/rolling_application.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- Daily rollover with compression -->
      <fileNamePattern>${LOG_HOME}/logs/application-log-%d{yyyy-MM-dd}.gz</fileNamePattern>
      <!-- keep 90 days worth of history -->
      <maxHistory>90</maxHistory>
    </rollingPolicy>
    <encoder>
      <pattern>%date{yyyy-MM-dd HH:mm:ss ZZZZ} [%level] from %logger in %thread - %message%n%xException</pattern>
    </encoder>
  </appender>

  <appender name="ASYNCFILE" class="ch.qos.logback.classic.AsyncAppender">
    <appender-ref ref="ROLLING" />          <!--Change-->
  </appender>

  <root level="WARN">
    <appender-ref ref="ASYNCFILE" />        <!--Change-->
    <appender-ref ref="ASYNCSTDOUT" />
  </root>

docker-compose.yml

version: '3'

services:
  play-runtime:
    image: play-runtime:latest
    container_name: play-runtime
    restart: always
    ports:
      - "9000:9000"
    stdin_open: true
    volumes:                                <!--add to-->
      - ./logs:/home/appserver/logs         <!--add to-->

For confirmation, I tried setting the log rolling setting in minutes on my own PC to see if there was a problem. I checked the operation locally and there was no problem, so when I uploaded it to the development environment, the log was not output and I twisted my head. By the way, to separate files by minutes, fileNamePattern ends with % d {yyyy-MM-dd} to % d {yyyy-MM-dd-HH-mm}.

The problem that seems to have occurred

The corresponding log folder was created, but the file was not output. It is expected that the owner authority of the folder is a bottleneck, referring to the following article. By the way, in docker, a general user (user name appserver) is created to start the container and application. https://qiita.com/yohm/items/047b2e68d008ebb0f001

RUN groupadd --gid 1001 appserver \
 && useradd --gid 1001 --uid 1001 -m appserver

USER appserver 

Correspondence

Added a command to create a folder in Dockerfil.

RUN mkdir -p -m 777 /home/appserver/logs \              #add to
 && chown appserver:appserver /home/appserver/logs

I was able to confirm the log output safely. You may create it with the application startup script as in the reference article.

Correspondence that tried and did not work

For reference only.

Create a directory in Dockerfile before switching users → give ownership to general users I tried both chmod and chown, but when I checked the authority with exec after starting the container, only the root user was given possession / write authority and could not output the log.

Also, the reason why there was no problem in the local environment is that docker for mac seems to be able to improve the authority without permission, and in the same way, linux is not good for Mac environment! There was a person who wrote an article like this.

Tomorrow is @ ee4839! Thank you.