앱 및 버전

버전 관리 및 애플리케이션에 대해 알아보세요 - 개념과 모범 사례로 더 깊이 이해하기.

📦 애플리케이션

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

  • 여러 게임 또는 비게임 프로젝트를 작업할 때(통합 청구),

  • 공동 개발자로서 외부 프로젝트에 참여할 때(나중에 소유권 이전),

  • 다양한 확장 패턴이나 요구사항을 가진 느슨하게 결합된 여러 서버 유형에 의존할 때.

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

🏷️ 앱 버전

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

  • 호환성 유지 클라이언트와 서버 간의,

  • 여러 측면을 비교하기 위해 증분 릴리스 (성능, 사용자 반응),

  • 테스트 여러 앱 버전을 동시에 (개발, 품질 보증, 스테이징, 베타).

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

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

각 버전은 상위 애플리케이션 내에서 고유하게 식별되며 그 기준은 앱 버전 이름입니다. 자신만의 명명 규칙을 자유롭게 정할 수 있습니다. 선택에 영감을 줄 몇 가지 인기 있는 예시는 다음과 같습니다:

  • 2024.01.30-16.23.00-UTC - 타임스탬프는 과거의 많은 버전을 투명하게 보관하는 데 유용합니다,

  • 1.1.0 - 시맨틱 버전 관리 - 변경 범위를 전달하는 데 훌륭한 선택입니다,

  • dev , staging, qa, prod - 환경별로 최신 버전만 유지하는 것이 매우 쉽습니다,

  • blue, green - 버전은 롤링 업데이트 릴리스 전략의 별칭으로 사용할 수 있습니다.

애플리케이션이나 버전은 우리의 대시보드 에서 비활성화할 수 있으며, 사람(개발자)의 실수로부터 보호하기 위해.

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

버전 관리 전략 결합하기

대부분의 경우 최상의 솔루션은 버전 관리 전략의 혼합입니다. 예를 들면:

🧱 필수 매개변수

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

리소스 요구사항

다음과 더불어, 버전의 이름외에도 새 버전을 생성하려면 몇 가지 매개변수가 필요합니다:

  • vCPU - 앱이 실행되기 위해 필요한 가상 CPU 단위 수(1024 단위 = 1 vCPU),

    • 허용되는 최소 vCPU 양은 0.25 vCPU(256 단위)입니다,

    • 이 설정은 기존 앱 버전에서 편집할 수 없으며, 새 버전을 만들어야 합니다.

  • 메모리 - 앱이 실행되기 위해 필요한 RAM 메가바이트 수(1024MB = 1GB),

    • 이 설정은 기존 앱 버전에서 편집할 수 없으며, 새 버전을 만들어야 합니다.

  • GPU - 앱이 실행되기 위해 필요한 그래픽 처리 장치 수,

    • 이 기능은 아직 제공되지 않으며, 관심이 있으시면 문의해 주세요.

우리의 서버 머신은 위치에 따라 클럭 속도가 2.4 - 3.2 GHz인 AMD/Intel CPU를 사용합니다. 서버에 충분한 리소스가 있는지 확인하려면 커뮤니티 디스코드.

이미지 세부정보

이러한 매개변수는 나중에 어떤 서버 빌드를 시작할지 시스템이 결정하는 데 도움이 됩니다:

  • 레지스트리 - registry.edgegap.com 만약 우리의 컨테이너 레지스트리,

    • 를 사용 중이라면, 타사 레지스트리를 사용하려면 타사 레지스트리 도커 자격증명을 입력하세요,

    • 레지스트리는 귀하와 다른 사용자의 리포지토리를 위한 공유 저장소 서비스로 작동합니다.

  • 이미지 리포지토리 - 애플리케이션의 전용 리포지토리를 의미합니다,

  • 태그 - 서버 이미지의 특정 빌드 아티팩트(버전)를 의미합니다,

    • 우리의 플러그인은 기본적으로 앱 버전 이름에서 태그 값을 복사합니다,

    • 로컬에 저장된 태그는 Docker Desktop의 이미지 또는 docker CLI로 확인할 수 있습니다.

  • 프라이빗 레지스트리 - 리포지토리 접근이 보호(비공개 리포지토리)되는 경우, 우리는 또한 다음이 필요합니다:

고급 사용자는 다음에 관심이 있을 수 있습니다: 유니티.

문제 해결 및 FAQ

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

  • 이는 컨테이너 레지스트리에 로그인하지 않았음을 의미합니다. Edgegap 컨테이너 레지스트리에 대한 Edgegap 컨테이너 레지스트리 지침, 또는 해당 레지스트리 제공자에 대한 동등한 지침을 참조하세요. 마지막 작업을 반복해도 오류가 해결되지 않습니다.


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

  • 이는 현재 로그인한 레지스트리 사용자가 충분한 권한(일반적으로 새 이미지를 푸시할 권한)을 가지고 있지 않거나 잘못된 레지스트리 제공자에 로그인한 경우를 의미합니다. 로그아웃한 다음 올바른 제공자 및 충분한 권한을 가진 사용자로 다시 로그인해 보세요. 마지막 작업을 반복해도 오류가 해결되지 않습니다.


레지스트리, 리포지토리 및 프로젝트의 차이점은 무엇인가요?

  • 레지스트리는 저장 시설, 리포지토리는 저장 유닛, 프로젝트는 저장 유닛 번호로 생각하세요. 각 레지스트리에는 일반적으로 여러 리포지토리가 포함되며, 일부는 공개이고 일부는 조직 및 사용자에게 비공개입니다.

  • 예시 레지스트리: registry.edgegap.com .

  • 예시 리포지토리: registry.edgegap.com/my-edgegap-org/my-game-server.

  • 예시 프로젝트 이름: my-game-server .


새 이미지 태그/빌드를 푸시할 때 변경 사항이 올바르게 반영되지 않습니다.

  • 빌드를 다시 생성할 때마다 새 이미지 태그로 푸시했는지 확인하세요. Edgegap의 내부 캐싱 시스템은 태그 이름을 사용하며 태그 값을 덮어쓰는 경우(예: latest) 새 빌드를 감지하지 못합니다.


동일한 빌드 아티팩트에 여러 태그를 붙일 수 있나요?

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


태그를 삭제하면 무슨 일이 발생하나요? 해시를 사용해 특정 아티팩트를 삭제할 수 없는 이유는 무엇인가요?

  • 태그를 삭제하면 해당 빌드 아티팩트에 다른 태그가 연결되어 있지 않은 경우 해당 빌드 아티팩트도 삭제됩니다. 이는 API 요청.

  • 도커 API 표준과 최상의 사용자 경험을 보장하기 위해 우리는 태그 삭제를 위한 인터페이스만 제공합니다. 빌드 아티팩트 삭제에 관해서는 위의 항목을 참조하세요.

⚙️ 선택적 매개변수

이러한 매개변수는 배포를 추가로 맞춤화하기 위해 구성할 수 있습니다.

주입 변수

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

  • 일반적인 예로는 엔진 인수, 타사 비밀 및 엔드포인트 등이 포함됩니다,

  • 참조: 주입된 변수 배포 컨텍스트에 따라 환경 변수를 주입하는 다양한 방법을 이해하려면, 앱 버전 변수 외에도,

  • 각 환경 변수는 최대 4KB(킬로바이트)의 문자열 데이터를 포함할 수 있습니다.

활성 캐싱

🌟 종량제(Pay as You Go) 요금제로 업그레이드 전 세계적으로 0.5초 배포 시간을 잠금 해제하려면!

배포 속도를 높이고 서버를 몇 초 내에 시작하세요, 대기 서버가 필요하지 않습니다. 이 앱 버전에 연결된 서버 이미지는 전 세계 모든 위치에 자동으로 사전 로드됩니다.

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

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

포트 매핑

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

  • 포트 값은 내부 포트 값을 의미하며, 일반적으로 네트코드 통합에서 사용됩니다,

  • 프로토콜 은 네트코드 통합의 전송 방식에 따라 달라집니다,

  • 이름 은 사용자의 필요를 위한 사람이 읽을 수 있는 식별자이며 포트와 동일할 수 있습니다,

  • 검증 은 컨테이너가 READY로 표시되기 전에 초기화되었는지 확인하기 위해 활성화할 수 있습니다.

서버 프로세스의 내부 포트는 앱 버전의 일부로 정의되는 반면, 외부 포트는 배포가 생성되면 무작위로 할당됩니다잠재적 악의적 행위자(해커)가 피해를 주기 전에 늦춰지거나 감지되도록 하기 위해서입니다.

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

안전 보호 장치

이러한 매개변수는 다양한 경계 사례 및 일반적인 서버 문제 해결에 도움이 됩니다:

  • 시간 제약 - 이러한 기능은 배포의 리소스 수명 주기를 관리하는 데 도움이 될 수 있습니다:

    • 게임 최대 지속 시간 은 주어진 기간 후 서버를 정상 종료하도록 설정하거나 다음으로 설정할 수 있습니다, -1 와 함께 앱 버전 API 생성/편집 다음에 대해: 지속성 와 함께 프라이빗 플릿.

    • 배포의 최대 시간 시작하는 데 너무 오래 걸리는 배포를 정리하는 데 도움이 될 수 있습니다.

  • 컨테이너 로그 저장소 - 배포가 중지된 후 서버 로그를 내보내려면 사전 구성된 S3 호환 버킷을 지정하여 컨테이너 로그를 내보내세요,

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

⏩ 업데이트 일관성

우리의 대시보드을 통해 새 앱 버전을 생성할 때 어떤 매개변수도 변경되지 않도록 하려면, 우리는 중복 기능을 이전 앱 버전의 대시보드 페이지 오른쪽 상단에서 사용하는 것을 권장합니다. 중복할 때 저장하기 전에 모든 매개변수를 편집할 수 있습니다.

참조: 매치메이커 롤링 업데이트 추가적인 릴리스 자동화.

Last updated

Was this helpful?