Cloud Foundry to Cloud Run 마이그레이션 가이드에서는 Cloud Foundry 서비스와 Cloud Run 서비스 간의 차이점에 대한 배경 정보를 제공하며 Cloud Run의 컨테이너에서 실행하기 위해 Cloud Foundry 애플리케이션을 마이그레이션하는 데 필요한 사항을 보여줍니다. 이 마이그레이션 페이지에서 데이터 마이그레이션은 다루지 않습니다.
마이그레이션할 수 있는 Cloud Foundry 애플리케이션
Cloud Run은 스테이트리스(Stateless) HTTP 또는 HTTP/2 애플리케이션을 실행하도록 설계되었습니다. 다음 조건을 충족하지 않으면 Cloud Foundry 애플리케이션을 마이그레이션할 수 없습니다.
- HTTP 또는 HTTP/2를 사용합니다(gRPC 포함).
PORT
환경 변수를 기반으로 트래픽을 수신 대기합니다.- 다른 애플리케이션으로 다른 경로에 라우팅할 필요가 없습니다.
- 트래픽 프록시를 위해 기존 Cloud Foundry "경로 서비스"를 필요로 하지 않습니다.
- 인스턴스 ID 또는 특정 시작 순서가 필요하지 않습니다.
- 개별 인스턴스에 고유한 주소를 지정할 필요가 없습니다.
- 데이터베이스 마이그레이션 시작과 같이 의도하지 않은 환경 변화 없이 시작할 수 있습니다.
Cloud Foundry와 Cloud Run의 차이점 이해
Cloud Foundry와 Cloud Run 모두 소스 배포 시 비슷한 경험을 공유하지만 워크로드 컨테이너화, 애플리케이션 구성, 서비스 정의에 대한 플랫폼 접근 방식이 크게 다릅니다. 다음 표에서는 Cloud Foundry와 Cloud Run의 차이점을 요약해서 보여줍니다.
앱 구성요소 | Cloud Foundry | Cloud Run 컨테이너 이미지 배포 |
Cloud Run 소스 배포 Dockerfile |
Cloud Run 소스 배포 빌드팩 |
---|---|---|---|---|
컨테이너화 | CF 빌드팩 v2 | 해당 사항 없음 | Cloud Build | Cloud Build |
기본 이미지 |
cflinuxfs3(Ubuntu 18.04) cflinuxfs4(Ubuntu 22.04) |
자체 컨테이너 이미지 가져오기 | 지정된 Dockerfile | Ubuntu 18.04 또는 Ubuntu 22.04 |
서비스 정의 | manifest.yaml |
service.yaml |
||
무시 목록 | .cfignore |
.gcloudignore |
||
서비스 메타데이터 | VCAP_* 환경 변수 |
워크로드 아이덴티티, 클라우드 보안 비밀 | ||
지원되는 컨테이너 형식 | Droplet | Docker 이미지 Manifest V2, 스키마 1, 스키마 2, OCI 형식 |
마이그레이션 방법
Cloud Foundry 애플리케이션을 마이그레이션하려면 다음 단계를 따르세요.
샘플 마이그레이션
Spring Music 예시에서는 Cloud Foundry의 핵심 구성요소를 사용하여 Spring Music을 OCI 호환 이미지로 다시 빌드하고 이를 Cloud Run에 배포합니다. 이 샘플은 리프트 앤 시프트 OCI 규정 준수 전략을 따릅니다.