컨테이너 안에 서버가 있습니다. Go 서비스, Rails 앱, Spring Boot API, 또는 nginx 뒤에 있는 웹 서버일 수도 있습니다. 이 서버는 HTTP를 사용하며, 특정 포트에서 대기(listen)합니다. 그저 실행될 장소만 필요할 뿐입니다.

프로젝트에 파일을 추가하면, Vercel이 이미지를 빌드, 저장, 배포 및 Fluid compute 상에서 오토스케일링(autoscales)합니다. 따라서 코드가 사용하는 CPU만큼만 비용을 지불하면 됩니다. 로컬에서 실행할 데몬(daemon)이나 설정할 레지스트리(registry), 관리할 클러스터(cluster)도 필요 없습니다. Dockerfile.vercel

다음은 $PORT에서 대기하는 Go 언어로 작성된 작은 HTTP 서버입니다.

이를 작은 이미지로 빌드하고 실행하는 파일을 추가합니다: Dockerfile.vercel

그런 다음 배포합니다:

git push 또는 커밋 없이 vercel 명령어를 실행하여 배포합니다.

끝입니다. 단 두 개의 파일로 라이브 상태가 됩니다. git push를 할 때마다 이미지를 다시 빌드하고 새로운 프리뷰 URL(preview URL)을 제공합니다. 또는 커밋 없이 vercel 명령어를 실행하여 배포할 수도 있습니다.

이 예제에서는 Go를 사용했지만, 어떤 스택이든 작동합니다. Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, 그리고 nginx 뒤의 웹 서버 모두 동일한 방식으로 배포됩니다. 유일한 규칙은 서버가 $PORT(기본값은 80)에서 대기해야 한다는 것입니다. HTTP를 사용한다면 배포됩니다. 네, Java도 가능합니다. PHP도 가능합니다.

Vercel의 컨테이너는 퍼스트 클래스 시민(first-class citizen)입니다. 프론트엔드 및 Vercel의 다른 services on Vercel과 동일한 플랫폼 및 동일한 컴퓨팅 자원 위에서 실행됩니다.

컨테이너의 성능은 첫 번째 요청에 응답하는 데 걸리는 시간에 달려 있습니다.

Vercel이 이미지를 빌드할 때, 이를 optimized boot image인 레이어(layer) 형태로 저장합니다. 이는 빠른 시작을 위해 최적화된 컨테이너 디스크의 압축된 스냅샷(snapshot)입니다.

컨테이너가 부팅될 때, 우리는 무언가가 실행되기 전에 전체 이미지를 다운로드하는 대신, 해당 스냅샷을 스트리밍하고 필요에 따라 압축을 해제합니다. 따라서 전체 이미지가 준비되기 전이라도 서버가 요청을 처리하기 시작할 수 있으므로, 이미지가 크더라도 다운로드가 완료될 때까지 기다릴 필요가 없습니다.

인스턴스가 실행되면, Fluid compute는 매 요청마다 새로운 복사본을 시작하는 대신 인스턴스를 따뜻한 상태(warm)로 유지하며 많은 요청을 처리합니다. 이를 통해 따뜻한 상태의 서버가 제공하는 응답성(responsiveness)과 유휴 상태일 때 잠드는 서버의 비용 효율성을 동시에 얻을 수 있습니다.

각 컨테이너는 상태가 없는 프로세스(stateless process)입니다. 요청을 받고, 응답을 반환하며, 그 사이에는 아무것도 유지하지 않습니다. 영구적인 상태(Persistent state)는 Vercel Marketplace의 데이터베이스나 캐시와 같이 연결된 백엔드 서비스(backing service)에 저장됩니다. 인스턴스가 유지되어야 할 어떠한 데이터도 보유하지 않기 때문에, Vercel은 트래픽이 들어올 때 인스턴스를 추가하고 트래픽이 멈추면 인스턴스를 제거할 수 있습니다. 또한 컨테이너에 연결된 내구성이 있는 스토리지(durable storage)를 곧 출시하기 위해 작업 중입니다.

우리는 단 한 번의 명령으로 Dockerfile을 배포할 수 있게 해주는 기능을 제공했습니다. 그것은 10년 전의 일이었고, 그 아이디어는 옳았지만, 이를 훌륭하게 구현할 인프라(infrastructure)는 아직 존재하지 않았습니다. first platform

그 이후 수년 동안 우리는 이를 잘 처리할 수 있는 기본 요소(primitives)를 구축하는 데 시간을 보냈습니다. 이 요소들은 Vercel에서 실행되는 모든 것, 즉 빌드(Builds), 함수(Functions), 샌드박스(Sandboxes), 그리고 이제는 컨테이너(containers)를 구동합니다. 이 모든 것은 트래픽에 따라 확장(scale)되며, 사용한 CPU에 대해서만 비용을 지불합니다. 이제 컨테이너는 다른 모든 것과 동일한 시스템에서 실행되는 일등 시민(first-class citizen)입니다.

프레임워크 감지(Framework detection)는 우리의 관문입니다. 프레임워크를 인식하면 코드를 읽고 앱에 필요한 인프라를 도출합니다, 왜냐하면 코드가 이미 무엇을 해야 하는지를 설명하고 있기 때문입니다. 대부분의 앱에 있어 이것이 가장 빠르게 배포하는 방법입니다. Dockerfile은 그 외의 모든 것을 위한 것입니다. FFmpeg나 Chromium 같은 시스템 라이브러리가 필요한 서비스, 우리가 아직 자동으로 감지하지 못하는 프레임워크, 또는 현재 실행되는 방식 그대로 가져오고 싶은 앱 등이 해당됩니다. Dockerfile은 프로그램이 어떻게 빌드되어야 하는지를 말하는 보편적인 방법이므로, 읽을 수 있는 프레임워크가 없을 때 우리는 Dockerfile을 직접 마주하게 됩니다.

Dockerfile을 둘러싼 모든 것은 설정이 필요 없는 제로 구성(zero configuration)입니다. 이미지를 지정하기만 하면 빌드, 레지스트리(registry), 롤아웃(rollout), 확장(scaling), 그리고 URL이 모두 자동으로 이루어집니다.

이제 여러분의 백엔드도 프론트엔드와 동일한 방식으로 배포됩니다: 한 번의 푸시(push), 하나의 프리뷰(preview), 하나의 플랫폼. 여러분이 무엇을 만들어낼지 정말 기대됩니다.

또는 시작하려면 문서 읽기 예제 배포하기

더 읽어보기

작동 방식

얻을 수 있는 것

빠른 시작을 위한 설계

왜 지금인가?

백엔드의 귀환

• 모든 커밋은 열람, 공유 및 롤백(roll back)이 가능한 고유한 불변(immutable) URL을 가집니다. 모든 푸시에 대한 프리뷰 배포:

• 트래픽이 들어오면 확장(scale out)하고, 트래픽이 멈추면 인스턴스가 종료됩니다. 플릿(fleet)의 크기를 정하거나 동시성(concurrency) 수치를 추측할 필요가 없습니다. 양방향 오토스케일링 (Autoscaling):

• 코드가 실제로 실행되는 시간에 대해 유동적인 컴퓨팅(fluid compute) 비용이 청구되므로, 느린 쿼리나 상위 API(upstream API)를 기다리며 유휴(idle) 상태인 서버가 CPU를 소모하지 않습니다. 실제 경과 시간(wall time)이 아닌 실행 시간(execution time)에 대해 비용을 지불합니다. 활성 CPU 가격 책정 (Active CPU pricing)

• 컨테이너를 위한 로그(logs), 트레이스(traces), 메트릭(metrics)이 여러분이 배포하는 다른 모든 요소와 동일한 대시보드에 존재합니다. 관측성 (Observability) 포함:

• 컨테이너는 프론트엔드 및 다른 서비스와 나란히 위치하며, Vercel 네트워크를 통해 비공개로 통신합니다. 전체 스택이 하나의 배포로 이루어집니다. 하나의 프로젝트, 하나의 도메인: