GN⁺: Docker Compose로는 충분하지 않습니다

• docker-compose는 Docker 컨테이너를 다루는 도구로, 복잡한 애플리케이션 배포 문제를 해결하지만 대중 시장을 위한 간단한 셀프 호스팅에는 충분하지 않음
• SQL 데이터베이스, 로컬 캐시, 내구성 있는 저장소, 서비스 발견, 자원 관리 개념을 포함한 더 높은 수준의 추상화가 필요함

Docker의 역할

• Docker는 컨테이너화를 대중화한 도구로, 호스트 시스템을 배로 비유할 수 있음.
• 하드웨어와 운영 체제, 컨테이너 런타임이 있으며, 컨테이너는 런타임 내에서 실행되고 데이터베이스나 웹 서버 같은 다른 서비스와 통신함.

Docker-compose의 역할

• docker-compose는 함께 작동하는 컨테이너 그룹을 지정하는 도구로, 셀프 호스팅 애플리케이션 배포를 쉽게 해줌.
• 그러나 표준화된 인터페이스를 깨고 컨테이너가 원래 해결했던 문제를 재현함.
• 예시: Pihole
  • Pihole은 DNS 서버로, 복잡한 docker-compose 파일을 필요로 함.
  • 컨테이너 이름, 이미지, 포트, 환경 변수, 볼륨, 추가 기능, 재시작 정책 등을 설정해야 함.
  • 복잡한 설정은 사용자가 직접 관리해야 하며, 이는 Docker Compose의 단점
• 예시: Jitsi Meet
  • Jitsi Meet는 복잡한 소프트웨어로, 4개의 컨테이너, 7개의 볼륨, 9개의 포트, 200개 이상의 환경 설정을 포함한 docker-compose 구성을 생성함.
• 예시: 다른 인기 있는 셀프 호스팅 애플리케이션들도 유사한 문제를 겪음
  • Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX 등 다양한 애플리케이션이 있으며, 각각의 docker-compose 구성은 수십에서 수백 개의 docker 명령을 대체함.
  • 각 애플리케이션은 자체적인 데이터베이스, 캐시, HTTP 핸들러를 포함할 수 있으며, 이는 중복된 자원 사용으로 이어짐.

문제점

• docker-compose는 너무 유연하고 세부적이며 잘못된 추상화 계층에서 작동함.
• 각 애플리케이션은 HTTP 처리 프로세스, 캐시 또는 데이터베이스를 가짐. 데이터베이스 백업은 시스템 운영자의 몫임.
• 예시: Reverse HTTP 프록시
  • Reverse HTTP 프록시는 들어오는 HTTP 요청을 다른 프로그램으로 전달하는 프로그램임. 각 프로그램은 웹 서버를 포함할지 여부를 결정해야 함.
  • 웹 서버 포함
    • 웹 서버를 포함하면 프로그램이 작동하지만, 특정 포트에서만 작동하며, 여러 컨테이너가 있을 경우 포트를 재매핑해야 함.
  • 웹 서버 미포함
    • 웹 서버를 포함하지 않으면 리소스를 낭비하지 않지만, 관리 인터페이스 없이 애플리케이션을 구성해야 함.
  • DNS
    • 웹 인터페이스는 주소를 가지며, TLS를 원할 경우 이름이 필요함. 여러 서비스를 단일 호스트에서 실행할 경우 도메인 이름이나 경로로 요청을 라우팅해야 함.
  • 포트
    • docker-compose는 포트 노출과 재매핑을 허용하지만, 실제로는 복잡한 네트워킹 설정을 지원해야 함.
• 예시: 데이터베이스
  • 데이터베이스는 컨테이너가 삭제될 때 모든 파일 변경 사항이 삭제됨. 데이터베이스 컨테이너는 데이터베이스 내용을 저장하기 위해 볼륨을 추가해야 함.
  • N+1=2 또는 그 이상
    • 데이터베이스를 백업하려면 오프사이트 백업이 필요함. 각 서비스가 별도의 데이터베이스 서버 프로세스를 번들로 제공하면 컴퓨팅 리소스를 낭비함.

해결책

• 더 높은 추상화 계층으로 이동하여 데이터베이스, 리버스 웹 프록시, 캐시, 정적 웹 자산 등의 컨테이너 유형을 구분하는 의미론을 추가함.
• 의미론의 예
  • 새로운 구성 형식을 도입하여 애플리케이션 이름, 빌드, HTTPS 역방향 프록시, 캐시 서비스를 지정함.
• 해결책 #1
  • 각 프로그램이 역방향 프록시를 요청하고, 중복과 낭비를 방지함. 역방향 프록시는 DNS 이름을 제공하고, 모든 경로를 프로그램으로 전달함.
• 해결책 #1.5
  • 데이터베이스 섹션을 추가하여 SQL 표준을 준수하는 데이터베이스를 요청하고, 프로그램이 "전체" 권한을 기대함.
• 포트에 대한 해결책
  • 각 프로그램은 자체 IPv6 주소를 받아 표준 포트 번호를 사용할 수 있음. 보안을 위해 방화벽을 사용하여 역방향 프록시만 포트에 접근하도록 함.

Tealok - 새로운 컨테이너 런타임

• Tealok은 더 높은 추상화와 표준화된 인터페이스를 제공하는 새로운 컨테이너 런타임임.
  • TLS 인증서, 리버스 프록시 설정, DNS 기록, 백업 관리 등을 자동으로 처리함.
  • IPv6를 활용하여 각 컨테이너가 독립적인 IP 주소를 가지며, 표준 포트 번호를 사용할 수 있음.
  • 애플리케이션 개발자는 복잡한 설정 없이 표준 인터페이스를 통해 애플리케이션을 배포 가능함.
• 운영자에게는 일관된 모범 사례 제공, 리소스 낭비 감소, 관리 부담 완화.
• 개발자에게는 배포 방식의 단순화와 결정 부담 감소.
• 사용자는 데이터 소유권과 클라우드 컴퓨팅의 독립성을 보장받을 수 있음.