Snowpark Container Services 문제 해결¶

공용 서비스 엔드포인트에 액세스할 때 “invalid consent request” 오류가 수신되었습니다.

현재 구현에서 Snowflake는 기본 역할을 사용하여 현재 사용자를 인증합니다. 이 오류는 아마 사용자가 ACCOUNTADMIN 또는 SECURITYADMIN 과 같이 권한 있는 역할 중 하나를 기본 역할로 사용하고 있기 때문에 발생하는 것 같습니다(통합 사용에서 특정 역할 차단하기 참조). ALTER USER 명령을 사용하여 사용자의 기본 역할을 변경하고 다시 시도하십시오.

docker login 인증 실패.

docker login 명령에 대문자 호스트 이름을 사용하지 말고 docker push, docker pull 명령에 소문자 호스트 이름을 사용하십시오. Docker CLI는 대/소문자 키와 함께 자격 증명을 저장합니다. 관련 Docker CLI 문제.

docker push 오류: 요청 URL에 호스트가 없습니다.

Docker CLI와 상호 작용할 때 항상 URL에 있는 계정 이름의 밑줄을 하이픈으로 바꾸십시오. Docker CLI는 호스트 이름에 밑줄이 있으면 (cURL이 작동하더라도) 오류를 반환합니다. 예를 들어 다음 Docker 푸시는 “my_acct”를 계정 이름으로 지정합니다.

docker push myorg-my_acct.registry.snowflakecomputing.com/tutorial_db/data_schema/tutorial_repository/service_to_service

Docker는 다음 오류를 반환합니다.

Get "https:/v2/": http: no Host in request URL.

또한 SHOW IMAGE REPOSITORIES 명령을 사용하여 유효한 리포지토리 URL을 가져올 수도 있습니다.

일시 중단된 컴퓨팅 풀이 STOPPING 상태로 고착되었습니다.

서비스를 실행하면 컴퓨팅 풀이 중지되지 않습니다. ALTER COMPUTE POOL 명령을 사용하여 컴퓨팅 풀에 남아 있는 모든 활성 서비스를 일시 중단합니다.

ALTER COMPUTE POOL <pool_name> STOP ALL

실행 중인 서비스가 더 이상 (서비스 함수 또는 공용 엔드포인트의) 요청에 응답하지 않습니다. 서비스 상태가 실행 중에서 보류 중으로 변경되었습니다.

이는 컴퓨팅 풀 노드의 리소스 부족을 나타낼 수 있습니다. 컨테이너가 리소스(CPU/메모리) 집약적인 경우 너무 많은 서비스가 단일 노드에 배치되지 않도록 서비스(작업 서비스 포함)에 리소스 요청을 명시적으로 지정해야 합니다.

현재 구현에서는 메모리 요청만 지정할 수 있습니다.

예를 들어 컴퓨팅 풀의 노드에 64GB의 RAM이 있는 경우 서비스(또는 작업 서비스)에 대해 32GB 이상을 요청하면 한 번에 한 노드에서 하나의 서비스 또는 작업 서비스만 노드에서 실행할 수 있도록 보장하게 됩니다. 각 인스턴스 유형의 기능에 대한 자세한 내용은 CREATE COMPUTE POOL 섹션을 참조하십시오.

서비스에 대한 공용 엔드포인트에 요청을 제출하는 경우 HTTP 인증 헤더에 큰따옴표를 사용하지 마십시오.

서비스 함수 시간 초과 및 중복 실행 문제.

단일 서비스 함수 호출이 30초보다 오래 걸리는 경우 Snowflake는 함수를 다시 시도하고, 몇 번 다시 시도한 후에는 시간 초과 오류로 인해 함수가 실패합니다. 컨테이너의 함수 구현이 idempotent가 아닌 경우 예기치 않은 결과가 발생할 수 있습니다. 더 긴 시간 제한을 허용하는 다른 HTTP 코드(202)를 반환하여 비동기 실행을 사용해 보십시오. 자세한 내용은 비동기 원격 서비스 섹션을 참조하십시오.

인증에 실패하는 경우 사용자 또는 계정과 관련된 네트워크 정책 때문일 수 있습니다.

인터넷에서 공용 엔드포인트에 액세스할 때 사용자 이름/비밀번호 인증은 작동하지만 SSO 페이지가 빈 페이지로 표시되거나 “OAuth client integration with the given client ID is not found.” 오류가 발생할 수 있습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 수신 및 SSO 고려 사항 섹션을 참조하십시오.

클라이언트가 수신 엔드포인트(500/503/504)에서 5XX 오류를 수신하면 클라이언트는 약간의 백오프를 두고 재시도해야 합니다. 바인딩된 지수 백오프 를 권장합니다.

CORS 비행 전 요청은 “status 404-Endpoint does not exist:”를 반환합니다.

SHOW ENDPOINTS 명령을 실행하여 엔드포인트가 존재하는지 확인합니다.

CORS 비행 전 요청은 상태 302를 반환합니다.

CORS 요청에는 어떤 형태의 인증도 없었습니다. CORS 요청과 리디렉션/앵커 태그를 구분할 수 없기 때문에 리디렉션/앵커 태그 케이스라고 가정하고 302를 반환해야 합니다.

응답 상태 403 “Rejecting a CORS request since cookie was present, and request does not have an auth header”.

이는 교차 출처가 GET 이 아니고 HEAD 도 아닌 요청이 인증 방법으로 쿠키를 사용하려고 할 때 발생합니다. 인증 헤더는 이러한 교차 출처 요청에 필요합니다. 이 오류는 요청에 쿠키가 있고 인증 헤더가 없을 때 발생합니다.

오류 메시지 “Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at …”.

서비스가 요청된 교차 출처 액세스를 지원하지 않는다고 표시하면 브라우저에서 이 오류를 반환합니다. 이는 일반적으로 브라우저에서 제공하는 Origin 이 엔드포인트에 대한 서비스 사양의 Access-Control-Allow-Origin 에 지정된 출처 중 하나와 일치하지 않기 때문에 발생합니다. 이들을 일치시키려면 스키마(HTTP/HTTPS)와 호스트 이름이 모두 일치해야 합니다.