3P by neo 21일전 | favorite | 댓글 6개
  • 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 주소를 가지며, 표준 포트 번호를 사용할 수 있음.
    • 애플리케이션 개발자는 복잡한 설정 없이 표준 인터페이스를 통해 애플리케이션을 배포 가능함.
  • 운영자에게는 일관된 모범 사례 제공, 리소스 낭비 감소, 관리 부담 완화.
  • 개발자에게는 배포 방식의 단순화와 결정 부담 감소.
  • 사용자는 데이터 소유권클라우드 컴퓨팅의 독립성을 보장받을 수 있음.

docker compose를 본문과 같은 용도로 사용하려는게 애초에 잘못된 접근이라는 생각이 듭니다

말씀에 일부 동의는 합니다만, 접근이 잘못되지는 않았다고 생각합니다.
그들이 할 수 있는 환경에서는 최선이었을꺼에요 :)

tealok 들어가서 보니까 대안이 될만한 상태가 아닌데요?

런타임도 제거해 줬으면 참 좋았을텐데요

아직도 docker-compose를 이용해서 운영 상황을 만들어서 들어가는 것은 필요하다 생각하지만...

자신만의 특수한 환경에서한 경험을 바탕으로 그것이 잘못이니 새로운걸 만들었어요.. 라는 것은 동의하기 힘드네요.. ㅎㅎㅎㅎ

자칫 오해할 수 있는 내용이네요 ㅎㅎㅎㅎㅎ...

제목만 보고 '엇 개발환경에서 사용하는거 정말 마음에 안들지....' 라는 생각이었던지라.. ㅎㅎㅎ

Hacker News 의견
  • 포트 매핑과 데이터 볼륨 백업 문제에 대한 간단한 해결책이 존재함

    • 개발 환경을 위한 별도의 docker-compose 파일을 사용하여 환경별로 설정을 다르게 정의할 수 있음
    • 백업을 위한 간단한 Bash 스크립트를 작성하여 S3에 업로드할 수 있음
  • 개인 서버에서 Docker를 사용하여 셀프 호스팅하는 사람으로서, Docker 설정의 자유로움을 긍정적으로 평가함

    • 초기 설정은 시간이 걸렸지만, 이후에는 쉽게 관리할 수 있게 됨
    • 새로운 서비스를 추가하는 데 시간이 거의 걸리지 않으며, 보안을 위해 각 서비스에 비루트 사용자를 생성함
    • macvlan 네트워크를 사용하여 각 컨테이너에 고유한 IP와 MAC 주소를 할당함
    • Nginx Proxy Manager를 사용하여 리버스 프록시를 관리하며, 데이터베이스로 여러 인스턴스를 실행해도 문제가 없음
  • docker-compose는 주로 개발 또는 개인 용도로 사용되며, V2는 V1과 다르게 Docker에 통합된 플러그인임

  • 프로덕션 환경에서는 Kubernetes를 사용하는 것이 좋으며, docker-compose는 로컬 개발에 적합함

  • docker-compose는 소규모 셀프 호스팅을 위한 제품으로, 기술적 배경이 없는 사람들을 대상으로 함

    • TOML로 전환한다고 해서 셀프 호스팅이 쉬워질 것이라는 점에 회의적임
  • Docker를 제어하는 프로그램을 작성하는 것은 생각보다 간단하며, Python 스크립트를 사용하여 문제를 해결할 수 있음

  • canine.sh를 사용하여 Kubernetes 클러스터를 Heroku처럼 쉽게 사용할 수 있도록 개발 중임

    • 개인 프로젝트에 사용 중이며, 저렴한 비용으로 여러 앱을 호스팅할 수 있음
  • Tealok이 docker-compose의 대안을 개발 중이라는 점이 흥미로움

  • docker-compose, Kubernetes, Helm은 잘못된 추상화 계층이라고 생각함

    • 다양한 컨테이너 실행 및 통신 방법을 개발하는 시도가 많음
  • docker-compose가 잘못된 추상화 계층이라는 주장에 혼란스러움을 느낌

    • 특정 문제를 해결하기 위한 고수준 인터페이스를 기대하는 것 같음
    • 중복 인스턴스 생성 문제는 대부분의 애플리케이션에서 큰 문제가 아님
    • 특정한 방식으로 애플리케이션을 설계하도록 강요하는 것은 특정 상황에서만 잘 작동할 것임