Docker Compose vs Kubernetes: 작은 앱을 위한 체크리스트

당신이 실제로 선택하려는 것

Docker Compose와 Kubernetes의 실제 선택은 ‘단순함 대 고급’이 아닙니다. 한 서버에서 잘 관리된 작은 기계처럼 앱을 운용할지, 일부가 실패해도 계속 동작하도록 설계된 시스템처럼 운용할지를 고르는 차이입니다.

대부분의 소규모 팀은 플랫폼이 필요한 것이 아니라 기본이 지루하고 예측 가능하기를 원합니다: 앱을 시작하고, 실행 상태를 유지하고, 업데이트를 큰 소동 없이 진행하며, 문제가 생기면 빠르게 복구하는 것.

컨테이너 도구는 이미지 빌드, 서비스 실행, 시간 경과에 따른 변경 관리라는 세 가지 역할을 포함하는데, 이들이 종종 섞여 있습니다. Compose는 주로 한 호스트에서 앱, 데이터베이스, 캐시 같은 여러 서비스를 함께 실행하는 데 초점이 있습니다. Kubernetes는 클러스터 전반에서 서비스를 실행하고 스케줄링, 상태 검사, 점진적 변경 규칙을 제공하는 데 초점이 있습니다.

그래서 실제 결정은 보통 이런 트레이드오프에 관한 것입니다:

• 전체를 끝까지 이해할 수 있는 단일 호스트인가, 아니면 더 많은 움직이는 부품이 있는 다중 노드인가
• 수동/예약된 업데이트인가, 아니면 안전 장치가 있는 자동 배포인가
• 기본 재시작이면 충분한가, 아니면 중복을 통한 자체 치유가 필요한가
• 미리 용량 계획을 할 것인가, 아니면 부하에 반응하는 스케일 규칙을 사용할 것인가
• 단순한 네트워킹과 시크릿 관리로 충분한가, 아니면 트래픽과 설정을 관리할 컨트롤 플레인이 필요한가

목표는 신뢰성 요구를 충족하는 가장 작은 설정에 앱을 맞추는 것입니다. 처음부터 과도하게 구축해 나중에 후회하지 않도록요.

전문 용어 빼고 빠른 정의

한 문장으로 Docker Compose: 다중 컨테이너 앱(웹, API, DB, 워커)을 하나의 머신에서 하나의 설정 파일로 함께 실행하게 해줍니다.

한 문장으로 Kubernetes: 컨테이너를 클러스터 전반에서 실행하고 건강 상태를 유지하며 업데이트하고 스케일링하는 오케스트레이터입니다.

네트워킹은 둘 다 비교적 직관적이지만 범위가 다릅니다. Compose에서는 서비스들이 한 호스트 내에서 서비스 이름으로 서로 통신합니다. Kubernetes에서는 여러 머신에 걸쳐 안정적인 Service 이름 뒤로 통신하고, 진입점을 깔끔하게 만들고 싶을 때 Ingress 같은 라우팅 규칙을 추가합니다.

스토리지는 흔히 결정적 요소가 됩니다. Compose는 보통 호스트의 로컬 볼륨이나 직접 관리하는 네트워크 디스크를 사용합니다. Kubernetes는 스토리지를 별도의 리소스(Persistent Volumes)로 취급해 이식성에는 유리하지만 설정 작업과 더 많은 움직이는 부품이 생깁니다.

시크릿도 실제 운영에서 다릅니다. Compose는 환경변수 주입이나 시크릿 파일 사용이 가능하지만 호스트와 배포 과정을 보호해야 합니다. Kubernetes는 내장 시크릿 시스템과 접근 규칙을 제공하지만, 이제는 그 리소스와 정책을 관리해야 합니다.

일상에서의 차이

변화하는 부분은 대부분 코드가 아니라 운영 부담입니다.

Compose에서는 설정을 바꾸고 새 이미지를 당겨서 서비스를 재시작하고 한 대의 서버에서 로그를 확인합니다. 백업과 디스크 관리는 보통 수동이지만 직관적입니다.

Kubernetes에서는 매니페스트를 적용하고 파드를 모니터링하며 네임스페이스와 권한 문제를 다루고, 여러 노드에 걸친 문제를 디버그해야 할 수 있습니다. 백업, 스토리지 클래스, 업그레이드는 강력하지만 실제 계획이 필요합니다.

AppMaster 같은 노코드 플랫폼으로 빌드하면 앱 로직 변경은 빨라질 수 있지만, 호스팅 선택이 배포와 런타임을 얼마나 많이 돌봐야 하는지를 결정합니다.

Docker Compose로 충분한 경우

많은 소규모 팀에게 Docker Compose와 Kubernetes의 초기 경쟁은 보통 치열하지 않습니다. 앱이 몇 개의 서비스이고 트래픽이 대체로 예측 가능하다면, Compose는 모든 것을 함께 실행하는 명확하고 단순한 방법을 제공합니다.

Compose는 전체 스택을 단일 VM이나 소형 온프레미스 서버 같은 안정적 한 대의 머신에서 운영할 수 있을 때 적합합니다. 일반적인 구성은 웹 프런트엔드, API, 워커, 데이터베이스입니다.

업데이트 중 잠깐의 다운타임이 허용된다면 Compose로도 충분한 경우가 많습니다. 많은 소규모 비즈니스 앱은 조용한 시간대에 재시작을 예약할 수 있습니다.

다음 조건 대부분에 해당하면 Compose로 괜찮습니다: 대략 2~6개의 서비스가 있고 자주 구조가 바뀌지 않으며, 한 서버가 피크 부하를 감당할 여유가 있고 이미지 당겨서 컨테이너를 재시작하는 수동 배포가 괴롭지 않으며 업데이트 중 짧은 중단이 허용되는 경우.

구체적 예: 지역 서비스 업체가 고객 포털과 관리자 도구를 운영합니다. 로그인, 데이터베이스, 이메일 알림이 필요하고 사용량은 주로 영업시간에 몰립니다. 앱과 데이터베이스를 하나의 VM에 Compose로 올리는 것이 전체 클러스터를 운영하는 것보다 비용과 관리 면에서 더 쉽습니다.

또 다른 신호: 앱 개발이 주요 걱정거리이고 운영이 걱정거리가 아닐 때 Compose는 운영 범위를 작게 유지합니다. AppMaster도 이 점에서 도움을 주는데, 완전한 앱(백엔드, 웹, 모바일)을 생성하도록 설계되어 인프라를 처음부터 구축하느라 몇 주를 낭비하지 않게 해줍니다.

Kubernetes가 적절해지는 시점

Docker Compose와 Kubernetes 사이에서 망설일 때, 전환점은 보통 ‘앱이 커졌다’가 아니라 ‘여러 대에서 예측 가능한 가동 시간과 더 안전한 운영이 필요하다’일 때입니다.

Kubernetes는 앱이 더 이상 단일 박스 설정이 아니고 일부가 실패해도 플랫폼이 계속 운영되길 원할 때 의미가 있습니다.

Kubernetes 영역으로 들어갈 때의 일반적 신호:

• 배포 중 무중단(또는 매우 짧은 중단)을 목표로 하고 재시작 창을 받아들일 수 없다
• 여러 서버에서 운영하고 한 VM이 죽었을 때 자동 복구가 필요하다
• 트래픽이 스파이크가 심해 부하에 따라 용량을 올리고 내리고 싶다
• 릴리즈가 문제를 일으킬 때 안전한 롤아웃과 빠른 롤백이 필요하다
• 규정 준수나 고객 요구로 시크릿, 접근, 감사 추적에 강한 통제가 필요하다

구체적 예: 작은 비즈니스가 API, 웹 프런트엔드, 백그라운드 워커를 운영합니다. 처음에는 Compose로 한 서버에서 잘 돌아가는데, 이후 2~3대의 머신으로 옮겨 단일 호스트 장애로 앱이 다운되는 것을 줄이려 합니다. 이때 배포가 야간 체크리스트가 되고, Kubernetes는 작업을 재스케줄하고 헬스체크 기반 재시작을 하며 표준화된 방식으로 변경을 롤아웃할 수 있게 해줍니다.

팀이 성장하면 명확한 역할, 더 안전한 권한 관리, 반복 가능한 배포가 중요해집니다. 이때 Kubernetes가 더 맞습니다.

AppMaster로 빌드하고 클라우드 인프라에서 운영할 계획이면, 진짜 고가용성, 제어된 배포, 강한 운영 가드레일이 필요할 때 Kubernetes가 ‘지루한’ 기반이 될 수 있습니다.

롤링 업데이트: 진짜 필요한가?

사람들이 Docker Compose와 Kubernetes를 비교할 때 ‘롤링 업데이트’가 필수처럼 들립니다. 작은 비즈니스 앱에서는 매주 느끼는 실질적 문제를 해결하지 못하면 추가 설정이 과할 수 있습니다.

다운타임을 명확히 정의하세요. 배포 중 앱이 2~5분 정도 다운되어도 괜찮나요? 아니면 매 분이 주문 손실, 지원 채팅 누락, 내부 워크플로 중단으로 이어져 사실상 무중단이 필요합니까?

유지보수 창을 예약할 수 있다면 롤링 업데이트는 과한 선택일 수 있습니다. 많은 소규모 팀은 야간이나 한가한 시간에 배포하고 짧은 유지보수 메시지를 보여줍니다. 사용량이 예측 가능하고 앱이 24/7 필수 서비스가 아니라면 이 전략은 타당합니다.

롤링 업데이트가 주는 것은 점진적 교체로 일부 용량을 온라인으로 유지할 수 있다는 점입니다. 그렇다고 배포를 자동으로 안전하게 만드는 건 아닙니다. 데이터베이스 변경의 하위 호환성(또는 마이그레이션 계획), 실제 준비 상태를 반영하는 헬스체크, 새 버전이 동작은 하지만 문제를 일으킬 때의 롤백 계획, 문제를 빠르게 알아차릴 모니터링이 필요합니다.

현실 점검: 서비스 인스턴스가 리버스 프록시 뒤에 한 개만 있다면, 롤링 업데이트도 긴 요청이나 메모리 세션 때문에 잠깐의 문제가 발생할 수 있습니다.

자주 쓰는 대안

Compose 환경에서는 많은 팀이 간단한 블루-그린 스타일 방법을 씁니다: 새 버전을 다른 포트로 옆에 띄우고 프록시를 전환한 뒤 옛 컨테이너를 제거합니다. 약간의 스크립트와 규율이 필요하지만 전체 클러스터를 도입하는 것 없이 대부분의 이점을 제공합니다.

Kubernetes의 롤링 업데이트는 여러 레플리카와 견고한 헬스체크, 잦은 배포가 있을 때 빛을 발합니다. AppMaster 프로젝트를 자주 재생성하고 새 빌드를 밀어 넣는 경우 부드러운 릴리즈 흐름이 중요할 수 있지만, 다운타임이 실제로 비용일 때만 말이 됩니다.

자동 확장: 작은 앱에 대한 현실적 고찰

자동 확장은 공짜 성능처럼 들립니다. 실제로 잘 작동하려면 앱이 이를 위해 설계되어야 하고 확장 여지가 있어야 합니다.

자동 확장은 보통 세 가지가 필요합니다: 여러 복제본으로 문제 없이 동작하는 서비스(무상태), 신뢰할 수 있는 메트릭(CPU, 메모리, 요청량, 큐 깊이), 그리고 확장할 여유(더 많은 노드나 클라우드 용량).

간단한 이유로 실패하는 경우가 많습니다. 세션을 메모리에 저장하면 새 복제본에는 세션이 없어 사용자가 로그아웃됩니다. 시작 시간이 2~3분이면(콜드 캐시, 무거운 마이그레이션) 확장은 너무 늦게 반응합니다. 시스템의 병목이 데이터베이스나 단일 큐, 외부 API라면 앱 컨테이너만 늘려도 효과가 없습니다.

Kubernetes를 자동 확장 때문에 도입하기 전에 더 단순한 방법을 시도하세요: VM 크기 올리기, CPU/RAM 여유 추가, CDN이나 캐시로 정적/반복 콘텐츠 분산, 예측 가능한 피크에 대한 스케줄링 기반 스케일링, 시작 시간 단축과 요청 비용 절감, 기본적인 레이트 리밋 추가.

자동 확장은 트래픽이 매우 불규칙하고 과다 프로비저닝이 비용일 때, 서비스를 여러 복제본으로 안전하게 운영할 수 있고 데이터베이스가 새 병목이 되지 않을 때 가치가 있습니다. AppMaster로 생성된 서비스를 배포한다면 초기에 무상태 설계와 빠른 시작에 집중해 나중에 스케일링이 현실적인 옵션이 되게 하세요.

데이터와 상태: 선택을 좌우하는 부분

대부분의 소규모 앱 장애는 웹 컨테이너에서 발생하지 않고 데이터(데이터베이스, 파일, 재시작 후에도 살아 있어야 하는 것)에서 옵니다. Docker Compose 대 Kubernetes 결정에서 상태는 보통 결정적 요소입니다.

데이터베이스는 세 가지 지루한 일을 잘 해야 합니다: 백업, 마이그레이션, 예측 가능한 스토리지. Compose에서는 Postgres 컨테이너와 네임드 볼륨으로 개발이나 아주 작은 내부 툴에서 작동할 수 있지만, 호스트 디스크가 가득 차거나 VM이 교체되거나 누군가가 docker compose down -v를 실수로 실행하면 어떻게 되는지를 솔직히 생각해야 합니다.

Kubernetes도 데이터베이스를 운영할 수 있지만 더 많은 구성요소가 필요합니다: 스토리지 클래스, Persistent Volumes, StatefulSets, 오퍼레이터 업그레이드 등. 팀들은 너무 일찍 클러스터 내부에 DB를 넣었다가 ‘그냥 옮기는’ 일이 주말 프로젝트가 되는 경우에 당합니다.

실용적인 기본은 단순합니다: 앱 컨테이너는 무상태로 두고 데이터는 관리형 서비스에 두세요.

상태에 대한 빠른 체크리스트

다음 중 하나라도 참이면 상태를 1순위 요구사항으로 취급하고 직접 DIY를 피하세요: 시점 복구(point-in-time recovery)가 필요하다, 릴리스마다 마이그레이션을 하고 롤백 계획이 필요하다, 잃어버리면 안 되는 사용자 파일을 저장한다, 재시작 시 살아 있어야 하는 큐나 캐시가 있다, 보존과 접근 통제에 대한 규정 준수 요구가 있다.

상태가 있는 서비스는 클러스터링을 어렵게 만듭니다. 큐, 공유 파일 스토리지, 서버 측 세션은 적절히 설계되지 않으면 쉬운 스케일링을 막습니다. 그래서 많은 팀이 세션을 쿠키나 Redis로 옮기고 파일은 오브젝트 스토리지로 보냅니다.

AppMaster로 빌드하면 PostgreSQL 중심 데이터 모델링이 이 기본에 잘 맞습니다: PostgreSQL은 관리형으로 유지하고 생성된 백엔드와 웹/모바일 앱은 운영이 가장 단순한 곳에 배포하세요.

데이터베이스를 꼭 ‘내부’에서 운영해야 한다면

관리형 백업과 복구 테스트, 명확한 스토리지 및 업그레이드 절차, 디스크/메모리/커넥션 한도 모니터링, 문서화된 재해 복구 런북, 그리고 이를 이해하는 온콜 담당자가 있는 경우에만 시도하세요.

건너뛸 수 없는 운영의 기본

Compose든 Kubernetes든 앱을 생산 환경에서 건강하게 유지하려면 몇 가지 지루하지만 필수적인 것이 필요합니다. 이를 건너뛰면 단순한 배포가 야간 소방전으로 바뀝니다.

모니터링과 로그(비협상 사항)

무슨 일이 일어나고 있는지 볼 수 있어야 하고, 5분 전 무슨 일이 있었는지 기록이 있어야 합니다. 즉, 모든 서비스(앱, 워커, DB, 리버스 프록시)의 로그를 한 곳에서 보고, “서비스가 내려갔다”, “에러율이 급증했다” 같은 기본 알림과 헬스체크, CPU/메모리/디스크/DB 연결 모니터링 대시보드, 릴리즈 태깅으로 사건과 배포를 매치할 방법이 필요합니다.

작은 예: 온라인 예약 앱이 타임아웃을 시작하면 웹 컨테이너가 크래시한 건지, DB 연결이 부족한 건지, 백그라운드 작업이 막힌 건지 빨리 판단할 수 있어야 합니다.

시크릿, 설정, 접근 제어

작은 팀은 종종 시크릿을 단순히 ‘env 파일 하나’로 취급합니다. 이는 자격 증명이 채팅 스크린샷이나 오래된 백업에 남게 되는 원인입니다.

최소 안전한 방법은 간단합니다: 시크릿을 저장소 밖에 두고 사람이 떠날 때 교체하세요; 설정을 코드와 분리해 dev/staging/production이 비밀번호를 공유하지 않게 하세요; 누가 배포하고 누가 프로덕션 데이터를 읽을 수 있는지 분리하세요(역할이 다릅니다); 누가 언제 무엇을 배포했는지 감사 추적을 남기세요.

Compose는 규율 있는 운영자 한 명으로 이걸 처리할 수 있습니다. Kubernetes는 더 많은 내장 가드레일을 제공하지만 설정을 해야만 효과가 있습니다.

컴플라이언스: Compose를 초과하게 만드는 조용한 이유

성능이 괜찮더라도 규정 준수가 나중에 답을 바꿀 수 있습니다. 감사 로그, 엄격한 접근 제어, 데이터 레지던시, 형식화된 변경 관리 같은 요구는 종종 팀을 Kubernetes나 관리형 플랫폼으로 밀어넣습니다.

AppMaster로 내부 도구를 빌드하고 생성된 서비스를 배포한다면 같은 규칙이 적용됩니다: 운영을 제품의 일부로 간주하세요, 나중에 추가하는 것이 아니라 처음부터 고려하세요.

흔한 함정과 피하는 방법

가장 큰 실수는 더 ‘전문적으로 보인다’는 이유로 가장 복잡한 옵션을 고르는 것입니다. 많은 팀에게 Docker Compose vs Kubernetes는 기술 논쟁이 아니라 시간과 집중의 문제입니다.

흔한 패턴은 트래픽을 과대평가해 첫날부터 Kubernetes를 선택하고 클러스터 설정, 권한, 배포 스크립트에 몇 주를 소비하는 동안 앱 개발이 지연되는 것입니다. 더 안전한 접근은 오늘의 요구를 충족하는 가장 단순한 설정으로 시작하고 언제 업그레이드할지에 대한 명확한 트리거를 적어두는 것입니다.

시간을 낭비하게 하는 함정들은 보통 다음과 같습니다:

• “혹시 모르니”라는 이유로 Kubernetes 선택하기. Compose로는 충족할 수 없는 한두 가지 필요항목(예: 다중 노드 운영, 단일 서버 이상의 자체 치유, 거의 무중단 릴리즈)을 적어 두고 그것이 실제로 생길 때만 옮기세요.
• Kubernetes가 모니터링과 백업을 대신한다고 가정하기. 그렇지 않습니다. 알림을 받을 사람, 로그가 가는 곳, DB 복구 방법을 먼저 정하세요.
• 모든 것을 상태ful로 취급하기. 상태는 한 곳에 모으고 앱 컨테이너는 폐기 가능하게 유지하세요.
• 네트워킹과 보안 작업을 과소평가하기. TLS, 방화벽 규칙, 시크릿 처리, 최소 권한 접근에 시간을 배정하세요.
• 너무 많은 도구를 너무 일찍 추가하기. Helm 차트, 서비스 메시, 화려한 CI 단계는 도움이 되지만 각자 디버그해야 할 시스템을 추가합니다.

예: 소규모 비즈니스가 AppMaster에서 앱을 내보내 배포합니다. 팀이 첫 달을 Kubernetes 애드온 튜닝에 쓰고 백업과 기본 알림을 설정하지 않으면 첫 장애는 여전히 큰 타격이 됩니다. 기본부터 시작하고 복잡성은 필요할 때만 추가하세요.

결정 체크리스트: Compose 또는 Kubernetes?

Docker Compose와 Kubernetes 사이에서 망설일 때 빠르게 필터로 쓰세요. 미래를 완벽히 예측할 필요는 없습니다. 실제 리스크를 커버하는 가장 작은 도구가 필요합니다.

Compose가 보통 충분한 경우

앱이 작고 밀접하게 결합되어 있고(대략 1~5 컨테이너), 업데이트 중 다운타임이 허용되고, 트래픽이 안정적이며, 배포가 수동이지만 통제 가능하고, 운영 시간이 제한되어 움직이는 부품이 적은 것이 장점일 때 Compose가 적절합니다.

Kubernetes가 가치가 되는 경우

여러 구성요소가 자동으로 치유되어야 하고, 더 높은 가용성 요구가 있으며, 트래픽이 불규칙하거나 스파이크가 있고, 안전한 릴리즈와 빠른 롤백이 필요하며, 운영(데이-2)을 담당할 팀이 있거나 관리형 Kubernetes와 관리형 DB를 사용하는 경우 Kubernetes 도입이 의미를 가집니다.

예: 관리자 포털과 예약 API를 운영하는 지역 비즈니스는 보통 Compose에 적합합니다. 잦은 릴리즈와 계절별 트래픽 스파이크가 있는 마켓플레이스는 Kubernetes나 배포를 대신 처리해 주는 플랫폼이 더 도움이 됩니다(예: AppMaster로 빌드된 앱은 AppMaster Cloud에서 운영할 수 있습니다).

예시 시나리오: 실제 소규모 비즈니스 앱을 위한 선택

미용실 예약 앱을 상상해 보세요. 간단한 웹 프런트엔드, API, 알림을 보내는 백그라운드 워커, Postgres 데이터베이스가 필요합니다. 소유주는 온라인 예약, 직원 일정, 기본 리포팅을 원합니다.

처음에는 신뢰할 수 있는 서버 한 대와 Docker Compose로 시작합니다. 하나의 compose 파일에 웹, API, 워커, Postgres 네 서비스를 띄웁니다. 야간 백업, 기본 모니터링, 재부팅 후 서비스가 자동으로 올라오게 하는 재시작 정책을 추가합니다. 작은 팀과 안정적 트래픽에는 이런 방식이 가장 평온하고 "Docker Compose vs Kubernetes" 문제가 산만하게 만드는 것을 막아줍니다.

몇 달 뒤 비즈니스가 성장합니다. 트래픽 스파이크가 현실화되어(휴일 프로모션) 단일 서버가 느려지거나, "예약은 24/7 가능" 같은 가동 약속을 하게 되거나, 여러 지역에서 응답 속도가 빨라져야 한다면 결정이 바뀌기 시작합니다.

그 시점에서 체크리스트는 보통 Kubernetes의 기능을 가리키지만, 팀이 실제로 그 기능을 활용할 것인지가 중요합니다. 자동 확장은 부하가 예측 불가능하고 API 레플리카를 여러 개로 안전하게 운영할 수 있을 때 가치가 있습니다. 롤링 업데이트는 업무 시간 중에도 눈에 띄지 않게 앱을 업데이트해야 할 때 중요합니다.

명확한 결정 예시는 이렇습니다: 한 서버와 제대로 된 백업이 약속을 충족하는 동안은 Compose를 유지하고, 진짜로 다중 노드, 안전한 배포, 제어된 스케일링이 필요할 때 Kubernetes로 옮기세요. AppMaster 같은 노코드 플랫폼으로 앱을 빌드했다면 생성된 서비스를 어디에 어떻게 배포할지 동일한 사고방식을 적용하세요.

다음 단계: 경로를 정하고 유지보수 가능하게 만드세요

일단 선택하면 목표는 완벽한 설정이 아니라 공황 없이 운영, 업데이트, 복구할 수 있는 설정을 갖추는 것입니다.

Docker Compose를 선택하면

구성 요소를 작게 유지하고 기본을 문서화하세요. 최소한 테스트된 백업(데이터베이스, 업로드 파일, 시크릿), 기본 모니터링과 알림(가동 시간, 디스크 공간, CPU/RAM, DB 헬스), 간단한 업데이트 계획(이미지 당겨오기, 서비스 재시작, 롤백), 로그를 가장 먼저 확인할 장소, 문서화된 재해 복구 런북(복구 절차, 접근 권한 보유자, 키 보관 위치)을 마련하세요.

하나만 더 한다면, 프로덕션과 동일한 스테이징 환경을 구축하세요. 많은 "Compose는 신뢰할 수 없다"는 이야기는 사실상 "프로덕션과 테스트가 다르다"는 경우입니다.

Kubernetes를 선택하면

직접 클러스터를 먼저 만들지 마세요. 관리형 Kubernetes를 사용하고 초기 기능 범위를 최소로 유지하세요. 하나의 네임스페이스, 적은 수의 서비스, 명확한 릴리즈 프로세스를 목표로 하세요. 누가 유지보수할지 설명할 수 있을 때만 고급 기능을 추가하세요.

첫 번째 마일스톤은 무상태 서비스에 대한 간단한 롤링 업데이트와 통상적으로 클러스터 외부에 두는 상태 부분에 대한 계획입니다(데이터베이스, 파일).

운영 부담을 초기에 줄이고 싶다면 AppMaster(appmaster.io)은 코드 없이 완전한 앱을 빌드해 AppMaster Cloud에 배포할 수 있는 경로를 제공합니다. 필요 시 소스 코드를 내보내 AWS, Azure, Google Cloud 또는 자체 인프라에서 실행할 수 있는 옵션도 제공합니다.