S6 Overlay

Intro

docker에 기본 이념은 하나의 container에는 하나의 process만 두어야 한다는 것이다. 하지만, 이에 대해서 반대를 하고, 하나의 container에 여러 개의 process를 심고 이를 이용하겠다는 생각으로 만들어진 open source이다. 사용 예시는 main process 내부에 cronjob을 끼워넣는 것과 같은 경우가 있을 것이다.

이는 결론적으로 Dockerfile의 확장 버전이라고 볼 수도 있을 거 같다. 좀 더 복잡한 작업을 더 체계적으로 할 수 있는 틀을 제공한다. 아이디어 자체는 참신하나 남발하게 되면, stateless하던 container가 점점 stateful하게 되면서 시스템이 오염될 수도 있음을 유의하자.

아래 내용은 해당 opensource의 README를 직접 번역한 내용이니 의역도 많이 포함된다. 주의해서 읽도록 하자. 또한, 모르는 용어는 아래 Terminology를 확인해보도록 하자.

Goals

이미지 제작자가 쉽게 s6(s6는 process를 감독, 관리, logging, 초기화하는 기능들의 집합)를 활용할 수 있도록 지원
다른 docker image들처럼 동일하게 작동

Features

cont-init.d →초기화 작업과 같은 end-user 실행 작업을 허용하는 간단한 초기 작업
cont-finish.d → 마무리 작업
fix-attrs.d → ownership 권한을 수정
s6-overlay는 적당한 PID 1 기능을 제공한다.
- container에 걸리는 zombie process를 가지지 않고, 적당한 절차에 따라 제거될 것이다.
여러 개의 process를 하나의 container에서 작동시키는 것이 가능하다.
"The Docker Way"(아래에서 설명)에 따라 작동시키는 것이 가능하다.
모든 기반 이미지(Ubuntu, CentOS, Fedora, 심지어는 Busybox)를 사용하는 것이 가능하다.
이미지의 layer의 수를 작게 유지하기 위하여 하나의 tar, gz 파일로 배포한다.
s6 와 s6-portable-utils 는 손쉽고 작성이 쉬운 유틸리티 전체를 포함한다.
비밀리에 s6-log 를 사용하는 logutil-service는 오래된 로그의 순환을 수행한다.
특정 유저로 전체 process tree를 동작시키기 위하여, Docker의 USER 지침에 대하여 지원한다. 모든 feature에 대하여 지원하는 것은 아니라는 것을 알아두어야 한다. 자세한 사항은 여기서 확인가능하다.(🔗 notes)

The Docker Way

자주 강조되어지는 Docker의 신념은 "하나의 container에 하나의 process만 두어야 한다."는 것이다. 그러나, S6 overlay 팀은 이에 대하여 동의하지 않는다. 하나의 container에 여러 process를 동작시키는 것에 대한 본질적 문제는 없다. 더 추상적으로 "하나의 container에 하나의 thing만 두어야 한다."는 것이 해당 프로젝트의 목적이다. → 하나의 container는 하나의 것만 수행할 수 있다. 예로써, chatting service 또는 gitlab의 동작을 들 수 있다. 이것들은 여러 개의 process를 포함하지만, 하나의 thing이다. 따라서, 올바르다는 것이다.

이미지 제작자가 process supervisor를 피하는 이유는 하나의 process supervisor가 실패한 서비스를 다시 시작해야 한다고 생각하기 때문입니다. 이로 인해서 결국 Docker container는 절대 죽지 않을 것이다. 이러한 container가 죽지 않는 현상은 docker 생태계를 파괴할 것이다. 대부분의 이미지는 에러가 발생했을 때, 중단을 요청하는 하나의 process를 동작시킨다. 에러에 대해서 종료를 수행함으로써, 시스템 관리자는 실패를 원하는대로 다루는 것을 허락받는다. 만약 이미지를 절대 종료시키지 않는다면, 에러 회복과 실패 알림에 대한 대안책이 필요하다. 즉, container를 실패에도, 종료하지 않는 것은 매우 위험하다.

S6 overlay 팀의 정책은 만약 thing이 실패한다면, 그때 container가 반드시 실패햐야 한다는 것이다. 우리는 어떤 process들을 다시 동작시킬 수 있을지와 어떤 container를 끌어내릴지를 결정한다. 예를 들어, cron 이나 syslog에서 실패가 발생했을 때, container는 부정적 영향 없이 이것을 재시작하는 것이 가능할 것이다. 그러나 만약, ejabberd 가 실패했을 경우에는 container는 종료될 것이고, 이를 통해서 시스템 관리자는 이에 대한 대책을 수행할 수 있을 것이다.

따라서, S6 team에서 생각하는 "The Docker Way"란 다음과 같다.

Container는 반드시 하나의 thing만 수행해야 한다.
Container는 thing이 멈춘다면, 반드시 멈춰야 한다.

그리고, 우리의 초기 시스템은 이를 위해서 설계되었다. 이미지는 여전히 다른 Docker 이미지처럼 동작할 것이고, 이미 존재하는 이미지들의 생태계와 함께 어우러질 것이다.

Init stages

S6 overlay init은 container화된 환경에 적당하게 동작하기 위해 적당하게 맞춤화한 프로그램이다. 해당 section에서는 어떻게 stage들이 동작하는지 간단히 설명한다. 만약 더 자세한 사항이 궁금하다면, 다음 article을 읽기를 추천한다. (How to run s6-svscan as process 1)

stage 1 : 해당 단계의 목적은 두 번째 단계에 진입하기 위해서 이미지를 준비하는 것이다. 다른 것들 사이에서, 이것은 container 환경변수들을 준비하는 것과 s6 가 효과적으로 시작될 때까지 두 번째 stage의 시작을 막는 것에 대한 책임이 있다.
stage 2 : end-user가 제공한 대부분의 파일들이 수행되어지는 단계이다.
1. /etc/fix-attrs.d를 사용하여, 소유권과 권한을 고정한다.
2. /etc/cont-init.d에 기술된 초기화 script를 실행시킨다.
3. /etc/services.d에 적힌 user service들을 s6가 supervision을 동작 중인 폴더에 복사하고, signal을 보냄으로써 적절하게 supervising을 시작할 수 있다.
stage 3 : 해당 단계는 종료 단계이다. 이는 다음과 같은 동작을 수행한다.
1. TERM signal을 모든 관리 중인 service에게 전송한다.
2. /etc/cont-init.d에 포함된 종료 scripts를 수행한다. 이는 서비스가 여전히 종료되어지는 중에도 종료되어질 수 있다.
3. 모든 service가 종료되기를 기다린다.(S6_SERVICES_GRACETIME milliseconds를 넘지 않는 선에서 - default 3000)
4. 모든 process에게 TERM signal을 보낸다.
5. S6_KILL_GRACETIME milliseconds(default 3000)만큼 sleep을 수행한다.
6. 모든 process에게 KILL signal을 전송한다.

Usage

해당 project는 표준 tar, gz으로 배포되어졌다. 이를 사용하기 위해서는 image의 root에 이를 추출하고, ENTRYPOINT에 /init 을 기입해주면 된다. (만약, 기존 ENTRYPOINT가 있다면, 이를 cont-init으로 옮겨주어야 할 것이다. 또는 S6_CMD_ARG0를 이용하면 된다.)

여기서, 해당 project는 wget 또는 curl을 수행할 때, Docker의 RUN보다 ADD 지시어를 사용할 것을 추천한다. (왜냐하면, 이를 이용하면, Docker가 https URL을 다룰 수 있다.)

여기서부터, 서비스를 작성할 때에는 두 쌍의 선택지를 갖게 된다.

1. image의 CMD 를 이용하여 service/program을 실행시킨다.


1FROM busybox
2ADD https://github.com/just-containers/s6-overlay/releases/download/v1.21.8.0/s6-overlay-amd64.tar.gz /tmp/
3RUN gunzip -c /tmp/s6-overlay-amd64.tar.gz | tar -xf - -C /
4ENTRYPOINT ["/init"]


1# run
2docker-host $ docker build -t s6demo .
3docker-host $ docker run -ti s6demo /bin/sh
4[fix-attrs.d] applying owners & permissions fixes...
5[fix-attrs.d] 00-runscripts: applying... 
6[fix-attrs.d] 00-runscripts: exited 0.
7[fix-attrs.d] done.
8[cont-init.d] executing container initialization scripts...
9[cont-init.d] done.
10[services.d] starting services
11[services.d] done.
12
13# ps
14docker-host $ docker ps
15PID   USER     COMMAND
16    1 root     s6-svscan -t0 /var/run/s6/services
17    21 root     foreground  if   /etc/s6/init/init-stage2-redirfd   foreground    if     s6-echo     [fix-attrs.d] applying owners & permissions fixes.
18    22 root     s6-supervise s6-fdholderd
19    23 root     s6-supervise s6-svscan-log
20    24 nobody   s6-log -bp -- t /var/log/s6-uncaught-logs
21    28 root     foreground  s6-setsid  -gq  --  with-contenv  /bin/sh  import -u ? if  s6-echo  --  /bin/sh exited ${?}  foreground  s6-svscanctl  -t
22    73 root     /bin/sh
23    76 root     ps
24
25# exit
26/bin/sh exited 0
27docker-host $

2. s6-overlay를 활용하는 쉬운 방법이라고 할 수 있다.

Dockerfile이 build할 때, 작성하거나 runtime에 command line으로 입력이 가능하다. 이것은 s6 supervisor에 의해서 실행되어질 것이다. 그리고 실패나 종료 시에 해당 container는 종료되어질 것이다. interactive program도 s6 supervisor 하위에서도 동작시킬 수 있다. service script를 작성하여 실행시킨다.

/etc/services.d/myapp/run


1  !/usr/bin/execlineb -P
2  nginx -g "daemon off;"

관리되는 서비스를 제작하는 것은 단지 /etc/services.d에 service directory를 만들고, 장기간 존재할 process 실행에 대한 내용을 적은 run 파일을 이 안에 만드는 것보다 더 쉬워질 수 없다. 이거면 다다. 만약 s6 supervision에 대한 더 많은 내용을 알기를 원한다면 다음 문서를 살펴보아라. ([servicedir](<http://skarnet.org/software/s6/servicedir.html>))

소유권 및 권한 고정

때때로, 진행 전에 소유권과 권한을 고정하는 것이 필요할 때가 있다. 대표적인 예시가 container 내부에 host folder와 mount된 folder가 있을 때이다. overlay는 /etc/fix-attrs.d의 파일을 사용하여 이를 헤쳐나갈 방법을 제공한다.

Format
- path : File 또는 Directory의 경로
- recurse : folder가 발견되었다면, 해당 folder 내부의 내용도 포함할지를 결정합니다. (true or false)
- account : target의 account이다. account를 찾을 수 없을 경우 default로 예비 uid:gid(user id, group id)를 사용할 수 있다. 예를들어, nobody, 32768:32768 이라고 입력할 경우, nobody account를 첫번째로 사용하기 위한 시도를 하고, 예비로 uid가 32768인 대상을 예비로 찾는다. 예를들어, daemon 의 계정이 UID=2이고, GID=2인 경우 다음과 같은 account 도 사용할 수 있다.
  - daemon: UID=2 GID=2
  - daemon,3:4: UID=2 GID=2
  - 2:2,3:4: UID=2 GID=2
  - daemon:11111,3:4: UID=2 GID=11111
  - 11111:daemon,3:4: UID=11111 GID=2
  - daemon:daemon,3:4: UID=2 GID=2
  - daemon:unexisting,3:4: UID=2 GID=4
  - unexisting:daemon,3:4: UID=3 GID=2
  - 11111:11111,3:4: UID=11111 GID=11111
- fmode : target file의 mode → example 0644
- dmode : target directory의 mode → example 0755
path recurse account fmode dmode

Example

/etc/fix-attrs.d/01-mysql-data-dir


1/var/lib/mysql true mysql 0600 0700

/etc/fix-attrs.d/02-mysql-log-dirs


1/var/log/mysql-error-logs true nobody,32768:32768 0644 2700
2/var/log/mysql-general-logs true nobody,32768:32768 0644 2700
3/var/log/mysql-slow-query-logs true nobody,32768:32768 0644 2700

초기화 작업 실행하기

/etc/fix-attrs.d에 따라 속성을 고정하는 작업을 수행한 후, /etc/services.d에 적힌 user에게 제공되는 서비스를 시작하기 전에, overlay는 /etc/cont-init.d 에서 발견된 모든 script를 실행시킨다.

/etc/cont-init.d/02-confd-onetime


1#!/usr/bin/execlineb -P
2
3with-contenv
4s6-envuidgid nginx
5multisubstitute
6{
7  import -u -D0 UID
8  import -u -D0 GID
9  import -u CONFD_PREFIX
10  define CONFD_CHECK_CMD "/usr/sbin/nginx -t -c {{ .src }}"
11}
12confd --onetime --prefix="${CONFD_PREFIX}" --tmpl-uid="${UID}" --tmpl-gid="${GID}" --tmpl-src="/etc/nginx/nginx.conf.tmpl" --tmpl-dest="/etc/nginx/nginx.conf" --tmpl-check-cmd="${CONFD_CHECK_CMD}" etcd

부가적인 종료 작업 작성하기

기본적으로, /etc/services.d 에 의해 생성된 서비스는 자동적으로 재시작된다. 만약, 서비스가 container를 down 시켜야한다면, finish script를 통해서 이를 수행할 수 있다.

/etc/services.d/myapp/finish


1#!/usr/bin/execlineb -S0
2
3s6-svscanctl -t /var/run/s6/services

더 발전된 기능을 사용할 수도 있다.

/etc/services.d/myapp/finish


1#!/usr/bin/execlineb -S1
2if { s6-test ${1} -ne 0 }
3if { s6-test ${1} -ne 256 }
4
5s6-svscanctl -t /var/run/s6/services

Logging

S6 overlay는 즉시 [s6-log](<http://skarnet.org/software/s6/s6-log.html>)를 통한 logging mechnism으로 쉽게 logging을 관리하는 방법을 제공한다.

또한, logging을 하나의 바이너리 호출로 만들 수 있도록 logutil-service라는 도움 장치를 제공한다.

이는 다음 순서에 따라 진행된다.

s6-log가 어떻게 S6_LOGGING_SCRIPT에 적힌 logging script를 읽을지를 조회합니다.
nobody user의 root 권한을 삭제한다.(만약, 존재하지 않는다면, 기본적으로 32768:32768 에게 넘겨집니다.)
모든 환경 변수를 지웁니다.
s6-log를 실행함으로써 logging을 시작합니다.

주의사항

권한이 자동적으로 삭제된 이후로, s6-setuidgid로 user를 변경할 필요가 없다.
둘 중 하나의 내용을 log folder에서 보장해야 한다.
1. 존재한다면, nobody user에 의해 작성이 가능해야 한다.
2. 존재하지 않는다면, 상위 폴더가 nobody user에 의해 작성이 가능해야 한다.

log foder는 cont-init.d script에서 또는 run script 안에서 생성하는 것이 가능하다.

Example

1. cont-inid.d를 활용한 방법

/etc/cont-init.d/myapp-logfolder


1#!/bin/sh
2mkdir -p /var/log/myapp
3chown nobody:nogroup /var/log/myapp

2. run script를 활용한 방법

/etc/services.d/myapp/log/run


1#!/bin/sh
2# input stdin을 기반으로 하는 logging
3exec logutil-service /var/log/myapp
4
5#!/bin/sh
6# fifo에 따른 log를 쌓기를 원한다면, 다음과 같이 수행하는 것도 가능하다.
7exec logutil-service -f /var/run/myfifo /var/log/myapp

권한 삭제

서비스 실행이 다가오면, 실행 전에 권한을 부여하는 것은 서비스이건 logging 서비스이건 매우 중요한 작업이다. s6는 이미 이러한 작업을 위한 기능을 포함하고 있다.

In execline


1#!/usr/bin/execlineb -P
2s6-setuidgid daemon
3myservice

In sh


1#!/bin/sh
2exec s6-setuidgid daemon myservice

만약 이러한 기능에 대하여 더 알고 싶다면, 다음 문서들을 살펴 보아라. s6-setuidgid, s6-envuidgid, s6-applyuidgid

Container 환경

만약 container 환경을 제공하기 위해서 직접 만든 script를 원한다면, with-contenv를 통해서 이를 수행하는 것이 가능하다.

/etc/cont-init.d/01-contenv-example


1#!/usr/bin/with-contenv sh
2echo $MYENV

Read-Only Root 파일 시스템

최근 dokcer의 버전에서 read-only 파일 시스템으로 container를 동작시키는 것을 허용하였다. 2단계 과정에서, overlay는 사용자가 제공하는 cont-init.d 의 권한을 변경하는 부가작업을 수행한다. 만약, root 파일 시스템이 read-only라면, S6_READ_ONLY_ROOT=1 라는 설정을 해주어 stage 2에서 이를 알 수 있도록 해야 한다. 이를 통해서 permission을 변경하기 이전에, /var/run/s6 에 사용자의 파일을 복사하게 된다.

이는 /var 가 수정이 가능한 권한을 갖게된다는 것이고, 이는 tmpfs 라는 파일시스템에 의해서 가능하다.

→ 다음과 같이 사용하면, 수행이 가능하다.


1$ docker run -e S6_READ_ONLY_ROOT=1 --read-only --tmpfs /var:rw,exec [image name]