앱 및 버전

버전 관리와 애플리케이션에 대해 알아보세요 - 더 깊이 이해하기 위한 개념과 모범 사례입니다.

📦 애플리케이션

애플리케이션은 서버 프로젝트를 캡슐화합니다. 이러한 문맥 분리는 특히 다음과 같은 경우에 유용합니다:

여러 게임 또는 비게임 프로젝트를 작업하는 경우(통합 청구),
외부 프로젝트에 공동 개발자로 참여하는 경우(나중에 소유권 이전),
서로 다른 확장 패턴이나 요구 사항을 가진 여러 개의 느슨하게 결합된 서버 유형에 의존하는 경우.

플러그인, 대시보드또는 API를 사용하여 Edgegap에서 애플리케이션을 관리할 수 있습니다.

다음을 살펴보세요 애플리케이션 API 레퍼런스또는 다음에 대해 더 읽어보세요 관리 API.

🏷️ 앱 버전

애플리케이션을 개발하고 새로운 빌드를 지속적으로 생성하면, 각 빌드를 별도의 버전으로 저장해야 합니다. 그 이유는 다음과 같습니다:

호환성 유지 클라이언트와 서버 간의
다양한 측면 비교 점진적 릴리스의 (성능, 사용자 반응),
테스트 여러 앱 버전을 동시에 (개발, 품질 보증, 스테이징, 베타).

각 앱 버전은 선택한 하나의 빌드 아티팩트를 가리킵니다. 여러 버전이 동일한 빌드를 가리킬 수도 있습니다.

다음을 사용하여 Edgegap에서 앱 버전을 관리할 수 있습니다 대시보드또는 API를 사용하여 Edgegap에서 애플리케이션을 관리할 수 있습니다.

다음을 살펴보세요 앱 버전 API 레퍼런스또는 다음에 대해 더 읽어보세요 API.

각 버전은 상위 애플리케이션 내에서 다음에 의해 고유하게 식별됩니다 앱 버전 이름. 원하는 명명 규칙을 자유롭게 정할 수 있습니다. 선택에 도움이 되도록 몇 가지 인기 있는 예시를 소개합니다:

2024.01.30-16.23.00-UTC - 타임스탬프는 많은 과거 버전을 보관하는 데 투명합니다,
1.1.0 - 의미 기반 버전 관리 는 변경 범위를 전달하기 위한 훌륭한 선택입니다,
dev , staging, qa, prod - 환경별로 최신 버전만 유지하는 것이 매우 쉽습니다,
blue, green - 버전은 롤링 업데이트 릴리스 전략의 별칭으로 사용할 수 있습니다.

클라이언트/서버 호환성을 유지하는 한 언제든지 접근 방식을 변경할 수 있습니다.

다음에서 모든 앱 또는 버전을 비활성화할 수 있습니다 대시보드 에서 인적(dev) 오류를 방지하기 위해.

무료 요금제는 애플리케이션 2개, 버전 2개, 그리고 컨테이너 레지스트리 저장공간 5GB로 제한됩니다.

버전 관리 전략 결합

대개 가장 좋은 해결책은 버전 관리 전략을 혼합하는 것입니다. 예를 들면:

dev 빌드에 타임스탬프 또는 의미 기반 버전 관리를 사용하여 더 세밀하게 추적하기;
유지하기 staging, qa 및 prod 환경별 매개변수를 가진 버전;
번갈아 사용하는 blue 및 green 버전을 다음의 별칭으로 무중단 매치메이킹 업데이트.

🧱 필수 매개변수

이 기본 매개변수는 항상 정의되어 있어야 합니다.

리소스 요구 사항

다음 외에도 버전 이름, 새 버전을 만들기 위해 몇 가지 매개변수가 필요합니다:

vCPU - 앱을 실행하는 데 필요한 가상 CPU 단위 수(1024단위 = 1 vCPU),
- 허용되는 최소 vCPU는 0.25 vCPU(256단위)입니다,

배포당 0.25 vCPU보다 적게 필요하신가요? 최적화 옵션을 검토하려면 문의해 주세요.

메모리 - 앱을 실행하는 데 필요한 RAM 용량(1024MB = 1GB),
GPU - 앱을 실행하는 데 필요한 그래픽 처리 장치 수,
- 이 기능은 아직 사용할 수 없습니다. 관심이 있으시면 문의해 주세요.

버전에는 자동으로 2:1 RAM-vCPU 비율의 RAM이 포함되며, 0.25 vCPU에 512MB RAM 제공.

당사의 서버 머신은 위치에 따라 2.4 - 3.2GHz의 AMD/Intel CPU를 사용합니다. 서버에 충분한 리소스가 있는지 확인하려면 다음에서 문의하세요 커뮤니티 Discord.

이미지 세부 정보

이 매개변수는 시스템이 이후에 서버의 어느 빌드를 시작해야 할지 결정하는 데 도움이 됩니다:

레지스트리 - registry.edgegap.com 당사의 컨테이너 레지스트리,
- 를 사용하는 경우, 타사 레지스트리의 Docker 자격 증명을 입력하세요,
- 레지스트리는 귀하와 다른 사용자의 저장소를 위한 공유 저장 서비스 역할을 합니다.
이미지 저장소 - 애플리케이션 전용 저장소를 의미합니다,
- 모든 저장소는 다음에서 찾을 수 있습니다 대시보드의 컨테이너 레지스트리 페이지,
- 각 저장소에는 서버 이미지의 여러 태그가 포함될 수 있습니다.
태그 - 서버 이미지의 특정 빌드 아티팩트(버전)를 의미합니다,
- 당사 플러그인은 기본적으로 앱 버전 이름에서 태그 값을 복사합니다,
- Docker Desktop Images 또는 docker CLI를 사용해 로컬에 저장된 태그를 볼 수 있습니다.

❌ 하지 마세요 - 기존 태그를 덮어쓰거나 latest 태그 를 사용하여 오래된 빌드가 배포되지 않도록 하세요. ✅ 해야 합니다 - 버전 태그를 항상 증가시키고 새 빌드를 배포하여 오래된 캐시를 피하세요.

개인 레지스트리 - 저장소 접근이 보호되는 경우(비공개 저장소), 다음도 필요합니다:
- 사용자 이름 토큰 - 레지스트리의 프로그래밍 방식 접근용 사용자 이름,
- 비밀번호 토큰 - 레지스트리의 프로그래밍 방식 접근용 비밀번호,
- Edgegap의 경우 컨테이너 레지스트리, 다음을 할 수 있습니다 대시보드에서 이 값들을 복사,
- 이 값들은 공개 저장소에는 필요하지 않습니다.

문제 해결 및 FAQ

다음 오류를 받았습니다 401 Unauthorized 서버 이미지를 푸시할 때.

이는 컨테이너 레지스트리에 로그인하지 않았음을 의미합니다. 자세한 내용은 다음을 참조하세요 Edgegap 컨테이너 레지스트리 안내또는 사용 중인 레지스트리 제공업체의 동일한 안내를 참조하세요. 마지막 작업을 다시 실행해도 오류는 해결되지 않습니다.

다음 오류를 받았습니다 403 Forbidden 서버 이미지를 푸시할 때.

이는 현재 로그인한 레지스트리 사용자의 권한이 충분하지 않거나(보통 새 이미지를 푸시할 권한), 잘못된 레지스트리 제공업체에 로그인했음을 의미합니다. 올바른 제공업체와 충분한 권한이 있는 사용자로 로그아웃했다가 다시 로그인해 보세요. 마지막 작업을 다시 실행해도 오류는 해결되지 않습니다.

레지스트리, 저장소, 프로젝트의 차이점은 무엇인가요?

레지스트리를 저장 시설, 저장소를 보관함, 프로젝트를 보관함 번호라고 생각하면 됩니다. 각 레지스트리에는 일반적으로 많은 저장소가 포함되며, 일부는 공개이고 일부는 조직과 사용자에게 비공개입니다.
예시 레지스트리: registry.edgegap.com .
예시 저장소: registry.edgegap.com/my-edgegap-org/my-game-server.
예시 프로젝트 이름: my-game-server .

새 이미지 태그 / 빌드를 푸시할 때 변경 사항이 제대로 다시 로드되지 않습니다.

빌드를 다시 만들 때마다 새 이미지 태그로 푸시해야 합니다. Edgegap의 내부 캐싱 시스템은 태그 이름을 사용하며, 태그 값을 덮어쓰면(예: latest) 새 빌드를 감지하지 못합니다.

같은 빌드 아티팩트에 여러 번 태그를 붙일 수 있나요?

예, 같은 아티팩트에 여러 번 태그를 붙여도 문제 없으며, 동일한 빌드의 여러 별칭으로 사용할 수 있습니다. 나중에 태그를 제거하는 방법은 계속 읽어보세요.

태그를 삭제하면 어떻게 되나요? 해시를 사용해 특정 아티팩트를 삭제할 수 없는 이유는 무엇인가요?

레지스트리의 공간을 확보하려면 특정 아티팩트와 연결된 모든 태그를 삭제해야 합니다.
Docker API 표준과 최상의 사용자 경험을 보장하기 위해, 당사는 태그 삭제용 인터페이스만 제공합니다. 빌드 아티팩트 삭제에 대해서는 위 항목을 참조하세요.

⚙️ 선택적 매개변수

이 매개변수는 배포를 더 세부적으로 사용자 지정하는 데 사용할 수 있습니다.

주입된 변수

이 버전의 모든 배포에 사용자 지정 환경 변수가 주입됩니다:

일반적인 예: 엔진 인수, 타사 시크릿 및 엔드포인트,
참조 삽입된 변수 앱 버전 변수 외에도, 배포 문맥에 따라 환경 변수가 주입될 수 있는 다양한 방법을 이해하려면
각 환경 변수에는 최대 4KB(킬로바이트)의 문자열 데이터를 포함할 수 있습니다.

반드시 민감한 변수(시크릿, 토큰)는 숨김으로 설정하세요 추가 보안을 위해!

활성 캐싱

🌟 종량제 요금제로 업그레이드하여 전 세계 배포 시간을 0.5초로 단축하세요!

배포를 가속화하고 몇 초 안에 서버를 시작하세요. 대기 서버는 필요 없습니다. 이 앱 버전과 연결된 서버 이미지는 전 세계 모든 지역에 자동으로 미리 로드됩니다.

앱 버전의 캐싱 수준이 🟢 좋음에 도달하면 캐싱이 완전히 적용됩니다.

여러 앱 버전이 동일한 이미지 태그를 재사용할 수 있습니다. 한 버전에 대해 캐시를 활성화하면 동일한 이미지 태그에 연결된 모든 버전에 자동으로 활성화됩니다파라미터화된 배포를 쉽게 만듭니다.

이미지는 배포 시에도 수동적으로 캐시되며, 배포된 호스트 머신에서만 캐시됩니다.

이미지는 72시간 연속으로 배포되지 않으면 캐시에서 제거됩니다.

포트 매핑

각 서버는 들어오는 클라이언트 연결을 수락하기 위해 최소 하나의 포트가 필요합니다:

포트 값은 내부 포트 값을 의미하며, 보통 netcode 통합에서 가져옵니다,
프로토콜 는 netcode 통합 전송 방식에 따라 달라집니다,
이름 은 사용자의 필요에 맞는 사람이 읽을 수 있는 식별자이며, 포트와 같을 수도 있습니다,
검증 를 활성화하여 컨테이너가 READY로 표시되기 전에 초기화되었는지 확인할 수 있습니다.

대부분의 게임은 포트 7777.

에 대한 단일 UDP 포트 매핑 추가만 필요합니다. 서버 프로세스의 내부 포트는 앱 버전의 일부로 정의되지만, 외부 포트는 배포가 생성되면 무작위로 할당됩니다잠재적인 악의적 행위자(해커)가 피해를 주기 전에 속도가 늦춰지고 탐지되도록 하기 위해서입니다.

서버가 여러 프로토콜을 통해 통신하는 경우 포트 매핑에 더 많은 포트를 추가하세요.

안전 가드레일

이 매개변수는 다양한 예외 상황과 일반적인 서버 문제 해결에 도움이 됩니다:

시간 제약 - 이 기능은 배포의 리소스 수명 주기를 관리하는 데 도움이 됩니다:
- 게임 최대 지속 시간 를 설정하여 일정 시간이 지나면 서버를 정상 종료하거나, 다음으로 설정할 수 있습니다 -1 와 앱 버전 API 생성/수정 에 대해 영속성 와 프라이빗 플릿.
- 배포 최대 시간 배포 시작이 너무 오래 걸리는 경우 정리하는 데 도움이 됩니다.
프로세스 재시작 정책 - 서버 프로세스가 중지될 때의 배포 동작을 제어합니다.
- 항상 재시작(기본값) - 정상 종료 코드(0) 및 모든 오류 종료 시 재시작합니다.
- 재시작 안 함(권장) - 성공 및 오류 종료 코드에서 배포가 중지됩니다.
- 충돌 시 재시작 - 오류 종료 코드에서만 재시작하며, 영구 서버에 유용합니다.