GN⁺: Docker Compose로는 충분하지 않습니다
(blog.tealok.tech)-
docker-compose는 Docker 컨테이너를 다루는 도구로, 복잡한 애플리케이션 배포 문제를 해결하지만 대중 시장을 위한 간단한 셀프 호스팅에는 충분하지 않음 - SQL 데이터베이스, 로컬 캐시, 내구성 있는 저장소, 서비스 발견, 자원 관리 개념을 포함한 더 높은 수준의 추상화가 필요함
Docker의 역할
- Docker는 컨테이너화를 대중화한 도구로, 호스트 시스템을 배로 비유할 수 있음.
- 하드웨어와 운영 체제, 컨테이너 런타임이 있으며, 컨테이너는 런타임 내에서 실행되고 데이터베이스나 웹 서버 같은 다른 서비스와 통신함.
Docker-compose의 역할
-
docker-compose는 함께 작동하는 컨테이너 그룹을 지정하는 도구로, 셀프 호스팅 애플리케이션 배포를 쉽게 해줌. - 그러나 표준화된 인터페이스를 깨고 컨테이너가 원래 해결했던 문제를 재현함.
- 예시: Pihole
- Pihole은 DNS 서버로, 복잡한
docker-compose파일을 필요로 함. - 컨테이너 이름, 이미지, 포트, 환경 변수, 볼륨, 추가 기능, 재시작 정책 등을 설정해야 함.
- 복잡한 설정은 사용자가 직접 관리해야 하며, 이는 Docker Compose의 단점
- Pihole은 DNS 서버로, 복잡한
- 예시: Jitsi Meet
- Jitsi Meet는 복잡한 소프트웨어로, 4개의 컨테이너, 7개의 볼륨, 9개의 포트, 200개 이상의 환경 설정을 포함한
docker-compose구성을 생성함.
- Jitsi Meet는 복잡한 소프트웨어로, 4개의 컨테이너, 7개의 볼륨, 9개의 포트, 200개 이상의 환경 설정을 포함한
- 예시: 다른 인기 있는 셀프 호스팅 애플리케이션들도 유사한 문제를 겪음
- Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX 등 다양한 애플리케이션이 있으며, 각각의
docker-compose구성은 수십에서 수백 개의docker명령을 대체함. - 각 애플리케이션은 자체적인 데이터베이스, 캐시, HTTP 핸들러를 포함할 수 있으며, 이는 중복된 자원 사용으로 이어짐.
- Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX 등 다양한 애플리케이션이 있으며, 각각의
문제점
-
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를 이용해서 운영 상황을 만들어서 들어가는 것은 필요하다 생각하지만...
자신만의 특수한 환경에서한 경험을 바탕으로 그것이 잘못이니 새로운걸 만들었어요.. 라는 것은 동의하기 힘드네요.. ㅎㅎㅎㅎ
자칫 오해할 수 있는 내용이네요 ㅎㅎㅎㅎㅎ...
제목만 보고 '엇 개발환경에서 사용하는거 정말 마음에 안들지....' 라는 생각이었던지라.. ㅎㅎㅎ
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가 잘못된 추상화 계층이라는 주장에 혼란스러움을 느낌- 특정 문제를 해결하기 위한 고수준 인터페이스를 기대하는 것 같음
- 중복 인스턴스 생성 문제는 대부분의 애플리케이션에서 큰 문제가 아님
- 특정한 방식으로 애플리케이션을 설계하도록 강요하는 것은 특정 상황에서만 잘 작동할 것임