“최대한 가볍게”
초기의 init은 오늘날의 systemd에 비해 훨씬 단순했다. 주된 역할은 부팅 과정에서 정해진 순서대로 서비스 켜기, 간단한 프로세스 관리, 종료와 재부팅 처리같은 것들이었다. 이것은 발전하면서 많은 기능들을 흡수하고 매우 무거워졌다.
컨테이너는 systemd를 올리지 않는다. 그냥 ENTRYPOINT나 CMD로 지정된 메인 프로세스를 PID 1로 실행해 버린다. 그래서 Docker의 장점을 얻으려면 관심사를 나누어 한 컨테이너가 여러 역할을 책임지지 않게 하는 것이 좋다(ref1). --init 명령어를 사용하면 Docker가 작은 init 프로세스를 넣어 주는데, 이편이 systemd 같은 full-fledged init을 쓰는 것보다 낫다(ref2).
언젠가 이 메모에 쓰이면 좋을 것 같은 재료들입니다.
1.
systemd는 단순한 프로세스 관리자만이 아니라, cgroup을 적극적으로 사용하는 서비스 관리자다. 그런데 컨테이너는 cgroup에 기반한 기술이다. 컨테이너 안의 PID 1로 systemd를 넣으면, 그 systemd도 cgroup을 관리하게 된다. 물론 안 된다는 것은 아니다. systemd의 Container Interface 문서도 컨테이너 안에서 systemd를 PID 1로 돌릴 때 필요한 mount, capability, environment variable, shutdown signal 같은 세부 조건들을 별도로 정리하고 있다. 다만 시스템이 복잡해진다는 것이다(ref3).
from: 이 메모에 쓰인 생각을 만든 앞의 생각들입니다. 앞의 생각과 연관관계를 설명합니다.
1.
a.
앞의 글에서 PID 1의 역할을 설명한다.
b.
커널 → PID 1 → 프로세스 관리
c.
docker 명령어에 --init 이라는 옵션도 PID 1이 전통적으로는 init 이라고 불렸던 역사와 깊은 연관성이 있다.
supplementary: 이 메모에 작성된 생각을 뒷받침하는 생각의 새로운 메모입니다.
opposite: 이 메모에 작성된 생각과 대조되는 생각의 새로운 메모입니다.
1.
to: 이 메모에 작성된 생각으로부터 발전된 생각의 새로운 메모입니다.
1.
ref: 생각에 참고한 자료입니다.
1.
A container's main running process is the ENTRYPOINT and/or CMD at the end of the Dockerfile. It's best practice to separate areas of concern by using one service per container. That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It's ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application. You can connect multiple containers using user-defined networks and shared volumes.
2.
The container's main process is responsible for managing all processes that it starts. In some cases, the main process isn't well-designed, and doesn't handle "reaping" (stopping) child processes gracefully when the container exits. If your process falls into this category, you can use the --init option when you run the container. The --init flag inserts a tiny init-process into the container as the main process, and handles reaping of all processes when the container exits. Handling such processes this way is superior to using a full-fledged init process such as sysvinit or systemd to handle process lifecycle within your container.
3.
Container managers and suchlike often want to control cgroups directly using the raw kernel APIs. That’s entirely fine and supported, as long as proper delegation is followed.
영구메모 템플릿 버전 2026.03.20