Cloud Foundry 애플리케이션을 Code Engine으로 마이그레이션 FAQ

Cloud Foundry 애플리케이션을 Code Engine으로 마이그레이션하는 것과 관련된 일반적인 질문에 대한 답변입니다.

Code Engine에서 사용자 정의 URL을 사용할 수 있습니까?

예. Code Engine 콘솔에서 사용자 지정 도메인 매핑을 생성하여 사용자 지정 URL 을 Code Engine 애플리케이션에 매핑할 수 있습니다. 인터넷 서비스 제공업체를 통해 사용자 지정 URL 을 할당할 수도 있습니다 IBM Cloud Internet Services. IBM Cloud Internet Services 을 통해 사용자 지정 도메인으로 앱을 배포하는 방법에 대한 자세한 내용은 고가용성 애플리케이션 구성하기를 참조하세요. 사용자 지정 도메인을 통해 앱을 배포하는 방법에 대한 자세한 내용은 Cloud Internet Services (CIS) 에서 사용자 지정 도메인과 해당 TLS 인증서 및 비공개 키 가져오기를 참조하세요.

내 앱에 특정 라우트가 포함되어 있습니다. 동일한 라우트를 사용할 수 있습니까?

제어하는 한 동일한 사용자 정의 라우트 또는 도메인을 사용할 수 있습니다. 라우트가 다른 소스의 라우트인 경우 (예: IBM제공 라우트 (예: mybluemix.net), Code Engine 에서 제공하는 도메인을 사용하거나 새 사용자 정의 도메인을 앱에 맵핑해야 합니다.

내 앱을 중지할 수 있습니까?

앱을 직접 중지할 수는 없지만 앱의 가시성을 project 로 설정하고 0으로 스케일링을 허용하여 앱이 트래픽을 수신하지 못하도록 할 수 있습니다. 자세한 정보는 내 앱이 트래픽을 수신하는 것을 어떻게 중지할 수 있습니까? 를 참조하십시오.

앱 인스턴스가 너무 많은 이유는 무엇입니까?

앱을 업데이트할 때 Code Engine 는 자동으로 새 개정을 작성합니다. 개정이 사용 가능하면 트래픽이 새 인스턴스로 라우팅됩니다. 개정이 확장되고 트래픽이 전송되는 동안 원래 앱 인스턴스는 계속해서 트래픽을 처리합니다. 개정이 스케일링 업되고 모든 트래픽이 여기로 라우팅되면 원래 앱이 스케일링 다운됩니다. 또한 앱은 트래픽에 따라 자동으로 스케일링 업 및 다운됩니다. 나중에 다시 확인하여 앱이 올바른 수의 인스턴스를 실행 중인지 확인하십시오. 자세한 정보는 애플리케이션 스케일링 구성을 참조하십시오.

내 앱의 응답이 느린 이유는 무엇입니까?

애플리케이션은 기본적으로 0으로 스케일링되므로 스케일업하는 동안 응답 속도가 느려질 수 있습니다. 이 동작은 콘솔 또는 CLI에서 애플리케이션을 업데이트하고 최소 스케일을 1로 설정하여 변경할 수 있습니다.

예를 들어, CLI에서 myapp 애플리케이션의 최소 스케일을 1로 설정하려면 다음 명령을 사용하십시오.

ibmcloud ce app update --name myapp --min-scale 1

애플리케이션이 업데이트되면 항상 단일 인스턴스가 실행됩니다. 요금이 부과될 수 있습니다. 자세한 정보는 Code Engine 가격을 참조하십시오.

요청을 특정 애플리케이션 인스턴스로 라우팅할 수 있습니까?

아니오, 이 기능은 현재 지원되지 않습니다. Knative 트래픽 분할을 사용하여 이 기능을 추정할 수 있습니다. Code Engine 와 함께 Knative를 사용하는 방법에 대한 자세한 내용은 Code Engine 와 함께 Knative 사용을 참조하세요.

내 Cloud Foundry 앱에서 글로벌 로드 밸런서를 사용합니다. Code Engine로 마이그레이션할 수 있습니까?

예, 인증서 체인 및 해당 개인 키에 액세스할 수 있는 경우 Code Engine 앱을 가리키도록 글로벌 로드 밸런서를 업데이트할 수 있습니다. 다음 단계에서는 Cloud Internet Services (CIS)를 사용 중이라고 가정합니다. 그러나 사용자 고유의 글로벌 로드 밸런서에 대해 이 단계를 조정할 수 있습니다.

이 단계에서는 콘솔을 사용합니다.

앱에 대한 도메인 맵핑을 작성하십시오. 도메인 맵핑을 작성할 때 개인 키 및 도메인의 전체 인증서 체인을 제공하십시오. 자세한 정보는 앱에 대한 사용자 정의 도메인 맵핑 구성 을 참조하십시오. 모든 프로젝트의 도메인 맵핑이 Ready 상태를 표시할 때까지 기다리십시오.
각 도메인 맵핑의 세부사항을 열고 CNAME 값을 기록하십시오 (예: custom.<your-random-id>.us-south.codeengine.appdomain.cloud 또는 custom.<your-other-random-id>.us-east.codeengine.appdomain.cloud).
각 애플리케이션의 세부사항 페이지로 이동하여 도메인 맵핑 탭을 선택한 후 시스템 도메인 맵핑 섹션에서 No external system domain mapping 를 선택하십시오. 이 단계를 수행하면 이 프로젝트 외부에서 호출될 때 사용자 정의 도메인을 통해서만 애플리케이션에 액세스할 수 있습니다.
Cloud Internet Services (CIS) 인스턴스에서 신뢰도로 이동하십시오. > 글로벌 로드 밸런서 > 오리진 풀 을 클릭하고 오리진 주소를 이전에 기록한 CNAME 로 변경하여 기존 오리진 풀을 편집하십시오.

이제 글로벌 로드 밸런서가 Code Engine 앱을 가리키고 있습니다.

내 앱이 스펙을 따라야 합니까?

앱은 12요소앱 방법론을 따라야 합니다.

Code Engine에서 사용할 수 있는 워크로드 유형은 무엇입니까?

Code Engine은 두 가지 유형의 워크로드(애플리케이션 및 일괄처리 작업)를 지원합니다.

애플리케이션 또는 앱은 코드를 실행하여 HTTP 요청을 제공합니다. 기존 HTTP 요청 외에 IBM Cloud® Code Engine은 WebSocket을 통신 프로토콜로 사용하는 애플리케이션도 지원합니다. 앱의 실행 중인 인스턴스 수는 수신 요청 및 구성 설정에 따라 자동으로 확장 또는 축소(0으로)됩니다. 앱에는 하나 이상의 개정이 포함되어 있습니다. 개정은 앱 구성 특성의 불변 버전을 나타냅니다. 앱 구성 특성을 업데이트할 때마다 앱 개정이 새로 작성됩니다.

작업은 실행 코드의 인스턴스를 하나 이상 병렬로 실행합니다. HTTP 요청을 처리하는 애플리케이션과 달리 작업이 한 번 실행되고 종료되도록 설계되었습니다. 작업을 작성할 때 작업이 실행될 때마다 사용될 워크로드 구성 정보를 지정할 수 있습니다.

원하는 워크로드 유형 판별

대부분의 Cloud Foundry 애플리케이션은 Code Engine으로 마이그레이션할 수 있습니다. 그러나 Cloud Foundry 애플리케이션에서 수신 HTTP 요청을 기다리지 않는 경우에는 작업을 사용하는 것이 더 나을 수 있습니다. 자세한 설명 및 예는 Code Engine 계획을 참조하십시오.

Manifest 파일을 사용합니다. Code Engine에서 사용할 수 있는 유사한 옵션이 있습니까?

Cloud Foundry 애플리케이션에 Manifest 파일을 사용하는 경우 Manifest 속성을 해당 Code Engine 기능 또는 CLI 옵션에 맵핑하십시오.

테이블용Markdown 코딩
Manifest 속성	`ibmcloud ce app create` 또는 `app update` 명령에 해당하는 Code Engine의 속성
`command`	`--command` 옵션
`disk_quota`	Code Engine에서 내재적으로 설정합니다.
`docker`	Code Engine에 필요하지 않습니다.
`health-check-http-endpoint`	Code Engine에 필요하지 않습니다. 기본적으로 애플리케이션이 정상 상태이고 준비되었는지 확인하는 데 TCP 프로브가 사용됩니다.
`health-check-invocation-timeout`	Code Engine에 필요하지 않습니다.
`instances`	`--min-scale` 및 `--max-scale` 옵션
`memory`	`--memory` 옵션
`metadata`	현재 지원되지 않습니다.
`no-route`	`--cluster-local` 옵션을 사용하면 프로젝트 내의 다른 워크로드에서 애플리케이션에 계속 액세스할 수 있지만 애플리케이션과 연결된 인터넷에 액세스할 수 있는 URL 주소는 포함되지 않습니다.
`path`	현재 적용할 수 없습니다.
`processes`	Code Engine에 필요하지 않습니다. 애플리케이션은 런타임에 추가 프로세스를 생성할 수 있습니다.
`random-route`	Code Engine에 필요하지 않습니다. 각 프로젝트에는 고유한 서브도메인이 있는데, 애플리케이션 이름이 URL의 일부가 되어 URL을 고유하 만듭니다.
`routes`	사용자 정의 라우트는 현재 지원되지 않지만 IBM Cloud Internet Service(CIS)또는 Cloudflare 를 사용하여 사용자 정의 도메인이 있는 프론트 엔드 애플리케이션을 사용할 수 있습니다.
`sidecars`	현재 지원되지 않습니다.
`stack`	Code Engine에서 내재적으로 관리합니다.
`timeout`	Code Engine에 필요하지 않습니다.
환경 변수	`-env` 옵션
서비스	`ibmcloud ce app bind` 명령을 참조하십시오.

Code Engine은 자동 스케일링 관리 방식과 같이 Cloud Foundry에서 사용할 수 없는 많은 옵션을 지원합니다. Code Engine에서 앱 작업 및 애플리케이션 스케일링 구성을 참조하십시오.

Cloud Foundry로 앱을 배치하는 방법을 알고 있습니다. Code Engine에서 앱을 배치할 때 알아야 할 사항은 무엇입니까?

Cloud Foundry로 앱을 배치하는 방법을 알고 있는 경우 Code Engine에서 앱을 배치할 때 알아야 할 사항을 찾아보십시오.

푸시 코드

Code Engine을 사용하면 Git 저장소 또는 로컬 시스템(CLI만 해당)에서 소싱되는 코드를 빌드할 수 있습니다. 또한 Cloud Foundry(cf push)와 마찬가지로 CLI와 Code Engine 콘솔을 모두 사용하여 단일 단계로 앱을 빌드하고 배치할 수 있습니다. 자세한 정보는 코드를 Code Engine 애플리케이션 컴포넌트로 실행하려면 어떻게 해야 합니까?를 참조하십시오.

배치 컨텍스트

Cloud Foundry에서 코드를 애플리케이션에 푸시하려면 Org 및 Space가 필요합니다. 모든 Cloud Foundry 사용자는 기본적으로 자신을 위해 작성된 Org 및 Space를 수신합니다. 그러나 새로 추가하려면 다음 예와 유사한 Org 및 Space 대상을 설정해야 합니다.

ibmcloud cf create-org MyOrg
ibmcloud target -o <ORGNAME>
ibmcloud target -s dev

그런 다음 Cloud Foundry를 사용하여 앱을 배치하면 Org 및 Space가 배치 대상이 됩니다.

Code Engine은 IBM Cloud 리소스 그룹 및 Code Engine 프로젝트의 개념을 사용합니다.

ibmcloud target -g <RESOURCE-GROUP>
ibmcloud ce project create --name <PROJECTNAME>

위 명령은 프로젝트를 작성할 뿐만 아니라 프로젝트를 "대상으로 지정"합니다. 모든 후속 Code Engine 명령은 project select 명령을 사용하여 다른 프로젝트를 대상으로 지정할 때까지 이 프로젝트의 컨텍스트에서 실행됩니다. 자세한 정보는 프로젝트 관리를 참조하십시오.

로그

Code Engine은 앱, 작업 및 빌드에 대한 로그를 제공하여 배치가 올바르게 실행되지 않을 때 발생하는 사항을 판별하는 데 도움을 줍니다. 다음 예와 유사한 명령을 실행하여 로그를 찾을 수 있습니다.

ibmcloud ce app logs -n <APPNAME>
ibmcloud ce jobrun logs -n <JOBRUN-NAME>
ibmcloud ce buildrun logs -n <BUILDRUN_NAME>

로그 메시지를 보다 장기적으로 보존하려면 IBM Cloud Logs 서비스를 사용할 수도 있습니다. 자세한 정보는 로그 보기를 참조하십시오.

서비스 작성

관리형 서비스의 인스턴스를 만드는 방법은 Cloud Foundry 와 Code Engine 에서 비슷합니다.

Cloud Foundry 애플리케이션에서 사용할 서비스를 새로 작성하려면 다음 명령을 사용하십시오.

ibmcloud cf create-service cloudantNoSQLDB lite myNameCloudant

Code Engine 애플리케이션에서 사용할 서비스를 새로 작성하려면 다음 명령을 사용하십시오.

ibmcloud resource service-instance-create myNameCOS cloud-object-storage lite global

서비스 바인딩

애플리케이션을 작성한 후에는 애플리케이션을 서비스에 "바인드"할 수 있습니다.

Cloud Foundry를 사용하는 경우 다음 명령을 실행하십시오.

ibmcloud cf bind-service appName instanceName

Code Engine을 사용하는 경우 다음 명령을 실행하십시오.

ibmcloud ce app bind --name appName --service-instance instanceName

서비스 인스턴스 인증 정보(좌표)는 환경 변수를 사용하여 앱(또는 작업)에 삽입됩니다. Code Engine에서 Cloud Foundry의 VCAP_SERVICES에 해당하는 항목은 CE_SERVICES입니다. 자세한 정보는 서비스 바인딩과 IBM Cloud 통합을 참조하십시오.

앱 또는 작업 업데이트

애플리케이션 또는 작업을 작성한 후에는 업데이트 명령을 사용하여 워크로드의 특성을 업데이트할 수 있습니다. 예를 들어, Code Engine에서 애플리케이션을 업데이트하려면 다음 명령을 사용하십시오.

ibmcloud ce app update --name <APPNAME> ...

애플리케이션 또는 작업을 작성할 때 사용 가능한 특성을 업데이트할 수 있습니다. 자세한 정보는 다음 주제를 참조하십시오.

런타임 지원

Code Engine 는 Cloud Foundry 에서 지원하는 많은 런타임을 지원합니다. Code Engine에서 지원되는 런타임 목록은 Cloud Native 빌드팩 을 참조하십시오. 예를 들어 Swift 또는 Liberty와 같이 지원되지 않는 런타임을 사용하려는 경우 Code Engine 에서 직접 이미지를 빌드하지 않고 앱을 컨테이너 이미지로 직접 패키징하고 해당 이미지를 Code Engine 에 배포할 수 있습니다.

다음 단계

마이그레이션을 시작하는 중입니까? 시작하기를 확인하십시오.
Cloud Foundry 용어를 Code Engine과 비교하십시오.
로컬 빌드 튜토리얼로 Code Engine을 사용해 보십시오.
애플리케이션에서 서비스 바인딩을 사용합니까? 서비스 바인딩 마이그레이션을 확인하십시오.
스케일링 및 트래픽 관리에 대해 알아보십시오.
Cloud Foundry 명령에 해당하는 Code Engine 명령을 찾으십시오.
Cloud Foundry 애플리케이션을 Code Engine으로 마이그레이션(현재 페이지)

기타 정보

Code Engine 가격에 대해 알아보십시오.
다른 Code Engine 튜토리얼을 시도하십시오.
다른 Code Engine 주제를 탐색하십시오.