Inception

Intro::

42 서울 Inception 과제 정리입니다.

Subject

docker-compose 사용

각 도커 이미지는 그에 상응하는 서비스 이름과 같아야 한다.

컨테이너는 Alpine or Debian 의 두번째 안정화 버전을 사용해야한다.

각 서비스 별로 도커파일이 있어야함

makefile을 통해 docker-compse를 통해 dockerfiles 가 불려야한다.

NGINX with TLSv1.2 or TLSv1.3 컨테이너

WordPress + php-fpm 컨테이너

MariaDB 컨테이너

WordPress 데이터를 수용하는 volume

WordPress website files 를 가지는 두번째 볼륨

각 컨테이너는 도커 네트워크로 이어져 있다.

컨테이너가 crash 다면 재시작해야한다.

WordPress database 에 두 유저가 있어야한다.

administrator → X (e.g., admin, administrator, Administrator, admin-123, and so forth).

볼륨은 /home/login/data 폴더에서 사용할 수 있습니다.

domain name → jahlee.42.fr 리다이렉트해서 ip주소로

latest tag 사용금지

도커파일에 비밀번호 금지

환경변수를 사용해야 한다.

.env 파일을 사용하는것을 권장한다. /srcs/.env

443 포트만 사용

docker-compose

Version

Docker Compose 파일의 버전을 명시합니다. 이 버전은 사용할 수 있는 구성 옵션과 도커 엔진의 호환성을 결정합니다.

Services

이 파일에서 정의하고자 하는 서비스들의 시작점입니다.

MariaDB (Service 예시)

mariadb:: MariaDB 서비스의 시작을 나타냅니다.

container_name: mariadb: 이 서비스의 컨테이너 이름을 mariadb로 설정합니다.
build: requirements/mariadb: requirements/mariadb 디렉토리에 있는 Dockerfile을 사용하여 이미지를 빌드합니다.
restart: always: 컨테이너가 실패하거나 도커가 재시작될 때마다 자동으로 재시작합니다.
env_file: .env: 환경 변수를 .env 파일에서 불러옵니다.
volumes: - db-volume:/var/lib/mysql: db-volume 볼륨을 컨테이너의 /var/lib/mysql 디렉토리에 마운트합니다.
networks: - inception: 이 서비스를 inception 네트워크에 연결합니다.
ports: - {host 번호}:{container 번호}: 호스트 포트 번호를 컨테이너 포트 번호에 바인드합니다.
depends_on: - other 이 서비스가 시작되기 전에 other 서비스가 먼저 시작되어야 함을 명시합니다.

Volumes

volumes:: 사용할 볼륨들을 정의하는 섹션입니다.

db-volume:, wp-volume:: 각 서비스에 사용될 볼륨을 정의합니다.(예시 mariadb, wordpress 볼륨)

driver: local: 볼륨의 드라이버를 로컬로 설정합니다.
driver_opts:: 볼륨 드라이버에 대한 추가 옵션을 설정합니다.

type: none, device: /home/jahlee/data/db-data 또는 /home/jahlee/data/wp-files: 로컬 파일 시스템의 특정 경로를 볼륨의 데이터 소스로 사용합니다.
o: bind: 지정된 디바이스를 마운트 옵션으로 바인드합니다.

Networks

networks:: 사용할 네트워크들을 정의하는 섹션입니다.

inception:: inception 네트워크를 정의합니다.

driver: bridge: 네트워크 드라이버를 bridge로 설정합니다. 이는 컨테이너들이 독립된 공간에서 실행되면서도 서로 통신할 수 있게 해줍니다.

PID 1

PID는 'Process ID'의 약자로, 운영체제에서 각 프로세스를 식별하는 고유 번호입니다. 모든 운영체제에서 PID 1은 시스템이 부팅될 때 가장 먼저 시작되는 프로세스를 가리키며, 이는 시스템의 다른 모든 프로세스의 부모 프로세스 역할을 합니다.

전통적인 리눅스 시스템에서 PID 1은 주로 init 프로세스가 차지합니다. 이 프로세스는 시스템이 부팅되는 동안 필요한 서비스와 프로그램을 시작하고, 종료 시에는 시스템을 안전하게 종료합니다. 또한, 시스템이 정상적으로 작동하는 동안에는 좀비 프로세스(자식 프로세스가 종료된 후에도 여전히 시스템 자원을 차지하는 프로세스)를 정리하는 역할을 합니다.

Docker PID 1

Docker 컨테이너 내에서의 PID 1은 컨테이너 내에서 가장 먼저 시작되는 프로세스를 의미합니다. Docker 컨테이너는 격리된 환경에서 단일 프로세스를 실행하는 방식으로 설계되었기 때문에, 컨테이너 내에서 실행되는 첫 번째 프로세스가 PID 1을 가지게 됩니다. 이는 그 프로세스가 컨테이너 내에서의 init 프로세스와 유사한 역할을 하게 됨을 의미합니다.

그러나 Docker 컨테이너에서 실행되는 PID 1 프로세스는 전통적인 리눅스 시스템의 init 프로세스와는 다르게, 자동으로 좀비 프로세스를 정리하지 않습니다. 이는 개발자가 컨테이너를 설계할 때 고려해야 할 중요한 사항 중 하나입니다. 좀비 프로세스가 계속 쌓이게 되면, 시스템 자원을 불필요하게 사용하여 성능 저하를 일으킬 수 있습니다. 이를 해결하기 위해, Docker 컨테이너에서는 tini와 같은 작은 init 시스템을 사용하여 PID 1의 역할을 보완할 수 있습니다. Tini는 좀비 프로세스를 적절히 처리하고, 시그널 전달과 같은 init 프로세스가 해야 할 일을 수행함으로써, 컨테이너 내부에서 보다 안정적인 환경을 유지할 수 있도록 도와줍니다.

Docker 컨테이너에서의 PID 1 관리는 컨테이너의 안정성과 성능에 직접적인 영향을 미치기 때문에 중요합니다. 따라서 개발자는 컨테이너를 설계하고 구성할 때 이러한 사항을 고려해야 합니다.

Tini

Tini는 Docker 컨테이너 내에서 PID 1의 역할을 효과적으로 수행하기 위해 만들어진 초경량 유틸리티입니다. Tini는 컨테이너 내에서 실행되는 첫 번째 프로세스로 동작하여, 전통적인 리눅스 시스템의 init 프로세스가 하는 일을 담당합니다. 주요 기능은 좀비 프로세스의 처리와 시그널의 적절한 전달입니다.

Tini의 주요 기능

좀비 프로세스 처리: 컨테이너 내에서 자식 프로세스가 종료될 때, 이들이 좀비 프로세스로 남지 않도록 처리합니다. 좀비 프로세스는 자원을 해제하지 않고 시스템에 남아있는 종료된 프로세스를 말합니다. Tini는 이러한 프로세스들이 시스템 자원을 계속 점유하는 것을 방지합니다.

시그널 핸들링: 시그널은 운영체제에서 프로세스에 보내는 통지 메시지입니다. 예를 들어, 컨테이너를 정상적으로 종료하려고 할 때 보내는 SIGTERM 시그널이 있습니다. Tini는 이러한 시그널을 적절히 자식 프로세스에 전달하여, 예를 들어 컨테이너가 정상적으로 종료될 수 있도록 합니다.

Tini 사용 방법

Docker 이미지에 Tini를 포함시키거나, Docker의 --init 플래그를 사용하여 컨테이너를 실행할 때 Tini를 활성화할 수 있습니다.

Dockerfile에 Tini 추가하기:


dockerfileCopy code
FROM ubuntu:latest
# Tini 설치
ADD https://github.com/krallin/tini/releases/download/v0.19.0/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--"]
# 실제 실행할 명령어
CMD ["your_application", "argument1", "argument2"]

Docker 실행 시 -init 플래그 사용: Docker 1.13.0 이상에서는 docker run 명령어에 -init 플래그를 추가하여 Tini를 활성화할 수 있습니다. 이 방법을 사용하면 별도로 Tini를 설치할 필요가 없습니다.


bashCopy code
docker run --init -d your_image

Tini의 사용은 컨테이너가 보다 안정적으로 동작하도록 하며, 특히 여러 프로세스를 관리해야 하는 복잡한 애플리케이션에서 그 중요성이 커집니다. Tini는 신호 전달과 좀비 프로세스 처리를 자동화하여, 컨테이너의 생명주기 관리를 단순화하고, 개발자가 애플리케이션 로직에 더 집중할 수 있도록 돕습니다.

WordPress와 PHP-FPM

WordPress는 세계에서 가장 널리 사용되는 콘텐츠 관리 시스템(CMS) 중 하나로, 사용자가 블로그, 개인 웹사이트, 포트폴리오, 심지어는 전자 상거래 사이트와 같은 다양한 유형의 웹사이트를 쉽게 만들고 관리할 수 있게 해줍니다. WordPress는 PHP로 작성되었으며 MySQL 또는 MariaDB 데이터베이스를 사용합니다.

php-fpm (PHP FastCGI Process Manager)은 PHP 스크립트를 처리하기 위한 고성능 백엔드 프로세스 매니저입니다. FastCGI의 구현체 중 하나로, 동적 콘텐츠를 제공하는 웹 애플리케이션을 위해 설계되었습니다. PHP-FPM은 웹서버와 PHP 스크립트 사이의 인터페이스 역할을 하며, 웹서버로부터 PHP 스크립트 실행 요청을 받아 처리합니다.

WordPress와 PHP-FPM의 연동

WordPress 웹사이트에서 PHP-FPM을 사용하는 것은 웹 사이트의 성능과 안정성을 크게 향상시킬 수 있습니다. PHP-FPM은 각각의 요청을 독립된 자식 프로세스로 처리하기 때문에, 요청 처리 시 발생할 수 있는 문제가 다른 요청에 영향을 미치지 않습니다. 또한, PHP-FPM은 요청 처리량에 따라 자동으로 자식 프로세스의 수를 조절할 수 있으며, 이는 트래픽이 많은 시간에도 웹사이트가 안정적으로 운영될 수 있도록 돕습니다.

PHP-FPM 설정하기

PHP-FPM을 WordPress와 함께 사용하기 위해서는 몇 가지 설정이 필요합니다:

PHP-FPM 설치: 서버에 PHP-FPM을 설치해야 합니다. 대부분의 Linux 배포판에서는 패키지 관리자를 통해 쉽게 설치할 수 있습니다.

웹 서버 구성: Apache 또는 Nginx 같은 웹 서버를 사용하여 PHP-FPM과 연동해야 합니다. 각 웹 서버마다 설정 방법이 조금씩 다를 수 있으니, 서버 문서를 참고하여 올바르게 설정합니다.

Nginx의 경우, location 블록 내에서 fastcgi_pass 지시어를 사용하여 PHP-FPM과 통신합니다.

Apache의 경우, mod_proxy_fcgi 모듈을 사용하여 PHP-FPM과 연동할 수 있습니다.

PHP-FPM 풀(pool) 구성: PHP-FPM 설정 파일(일반적으로 www.conf)에서 프로세스 풀을 구성할 수 있습니다. 이 설정을 통해 자식 프로세스의 수, 시작 프로세스 수, 요청 대기열의 크기 등을 조절할 수 있습니다.

이점

성능 향상: PHP-FPM은 웹 애플리케이션의 처리 속도와 응답 시간을 개선할 수 있습니다.

자원 효율성: 자원 사용을 더 잘 관리하고, 필요에 따라 프로세스를 동적으로 조절할 수 있습니다.

안정성: 각 요청을 독립된 프로세스에서 처리하기 때문에, 하나의 요청이 실패해도 전체 시스템에 영향을 미치지 않습니다.

WordPress와 PHP-FPM의 조합은 특히 동적 콘텐츠가 많고, 높은 트래픽을 처리해야 하는 웹사이트에 적합한 해결책을 제공합니다.

VM 설정

Inception Step 3: vm 설정

vm 환경 설정하기

https://velog.io/@aseungbo/Inception-Step-3-vm-설정-평가-준비