GitLab 관리 시작하기

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 관리를 시작하세요. 조직과 인증을 구성한 다음 GitLab을 보호하고 모니터링하고 백업하세요.

인증

인증은 설치를 안전하게 만드는 첫 번째 단계입니다.

  • 모든 사용자에 대한 이중 인증(2FA)을 강제로 적용. Self-managed 인스턴스에 대해 2FA를 강력히 추천합니다.
  • 사용자가 다음을 수행했는지 확인하세요:
    • 강력하고 안전한 암호를 선택하세요. 가능하다면 비밀번호 관리 시스템에 저장하세요.
    • 모든 사람을 위해 구성되지 않은 경우, 계정용 이중 인증(2FA)을 활성화하세요. 이 일회용 비밀 코드는 비밀번호를 가진 사람들조차도 침입자를 제외하도록 하는 추가적인 안전장치입니다.
    • 백업 이메일을 추가하세요. 계정에 액세스를 잃을 경우, GitLab 지원 팀이 보다 신속하게 도와드릴 수 있습니다.
    • 복구 코드를 저장하거나 인쇄하세요. 인증 장치에 액세스할 수 없는 경우, 이러한 복구 코드를 사용하여 GitLab 계정에 로그인할 수 있습니다.
    • 프로필에 SSH 키를 추가하세요. SSH로 필요한 경우 새로운 복구 코드를 생성할 수 있습니다.
    • 개인 접근 토큰을 활성화하세요. 2FA를 사용할 때, 이러한 토큰을 사용하여 GitLab API에 액세스할 수 있습니다.

프로젝트 및 그룹

그룹과 프로젝트를 구성하여 환경을 조직하세요.

  • 프로젝트: 파일 및 코드를 저장할 곳을 지정하거나 비즈니스 범주에서 문제를 추적하고 구성하세요.
  • 그룹: 사용자 또는 프로젝트 모음을 구성하세요. 이러한 그룹을 사용하여 빠르게 사람 및 프로젝트를 할당하세요.
  • 역할: 프로젝트 및 그룹에 대한 사용자 액세스 및 가시성을 정의하세요.

그룹 및 프로젝트의 개요를 시청하세요.

시작하기:

추가 리소스

프로젝트 가져오기

GitHub, Bitbucket 또는 다른 GitLab 인스턴스와 같은 외부 원본에서 프로젝트를 가져와야 할 수 있습니다. 많은 외부 원본을 GitLab로 가져올 수 있습니다.

인기 있는 프로젝트 가져오기

이러한 데이터 유형과 관련하여 도움이 필요한 경우 GitLab 계정 담당자나 전문적인 이주 서비스에 대해 GitLab 지원팀에 문의하세요.

GitLab 인스턴스 보안

보안은 온보딩 프로세스의 중요한 부분입니다. 인스턴스를 보호하면 작업과 조직이 보호됩니다.

이것이 전부가 아니지만, 이러한 단계를 따르면 인스턴스를 안전하게 보호하기 위한 견고한 시작을 할 수 있습니다.

GitLab 성능 모니터링

기본 설정을 마친 후 GitLab 모니터링 서비스를 검토할 준비가 되었습니다. Prometheus는 핵심 성능 모니터링 도구입니다. 다른 모니터링 솔루션(Zabbix 또는 New Relic과 같은)과 달리 Prometheus는 GitLab과 긴밀하게 통합되어 있으며 광범위한 커뮤니티 지원을 받고 있습니다.

모니터링 컴포넌트

  • 웹 서버: 서버 요청을 처리하고 다른 백엔드 서비스 거래를 용이하게 합니다. 이 노드의 건강 상태를 추적하기 위해 CPU, 메모리 및 네트워크 IO 트래픽을 모니터링합니다.
  • Workhorse: 본 서버에서 웹 트래픽 혼잡을 완화합니다. 이 노드의 건강 상태를 추적하기 위해 지연 시간 증가를 모니터링합니다.
  • Sidekiq: GitLab이 원활하게 실행되도록 하는 백그라운드 작업을 처리합니다. 이 노드의 건강 상태를 추적하기 위해 긴 대기 중인 작업 대기열을 모니터링합니다.

GitLab 데이터 백업

GitLab은 데이터를 안전하게 보관하고 복구하기 위한 백업 방법을 제공합니다. Self-managed이나 GitLab SaaS 데이터베이스를 사용하더라도 데이터를 정기적으로 백업하는 것이 중요합니다.

  • 백업 전략을 결정합니다.
  • 매일 백업을 생성하기 위해 cron 작업을 작성하는 것을 고려합니다.
  • 구성 파일을 별도로 백업합니다.
  • 백업에서 제외할 대상을 결정합니다.
  • 백업을 업로드할 위치를 결정합니다.
  • 백업 보존 기간을 제한합니다.
  • 테스트 백업 및 복원을 실행합니다.
  • 주기적으로 백업을 확인할 방법을 설정합니다.

GitLab Self-managed 인스턴스 백업

일상적인 백업은 리눅스 패키지 또는 Helm 차트 중 어느 것으로 배포했느냐에 따라 다릅니다.

리눅스 패키지를 사용하여 설치한 (단일 노드) GitLab 서버를 백업할 때는 단일 Rake 작업을 사용할 수 있습니다.

리눅스 패키지 또는 Helm 변형 백업에 대해 알아보기. 이 프로세스는 전체 인스턴스를 백업하지만 구성 파일은 백업하지 않습니다. 이들은 별도로 백업하는 것이 중요합니다. 암호화 키는 암호화된 데이터와 함께 보관되지 않도록 별도의 위치에 구성 파일과 백업 아카이브를 보관합니다.

백업 복원

백업은 동일한 버전 및 유형 (커뮤니티 에디션/엔터프라이즈 에디션)의 GitLab에만 복원할 수 있습니다.

GitLab SaaS 백업

GitLab 데이터베이스 및 파일 시스템은 매일 24시간마다 백업되며 누적 일정에 따라 2주간 유지됩니다. 모든 백업은 암호화됩니다.

  • GitLab SaaS는 데이터를 안전하게 유지하기 위해 백업을 생성하지만 이러한 방법을 사용하여 데이터를 내보내거나 백업할 수는 없습니다.
  • 이슈는 데이터베이스에 저장됩니다. Git 자체에는 저장할 수 없습니다.
  • 다음 위치에서 프로젝트 내보내기 옵션을 사용할 수 있습니다:
  • 파일 내보내기를 통한 그룹 내보내기 업로드 해당 그룹의 프로젝트를 내보내지 않지만 다음을 내보냅니다:
    • 에픽
    • 마일스톤
    • 보드
    • 라벨
    • 기타 항목

GitLab SaaS 백업에 대한 자세한 정보는 백업 FAQ 페이지를 참조하세요.

대체 백업 전략

일부 상황에서는 백업을 위한 Rake 작업이 가장 최적의 솔루션이 아닐 수 있습니다. 여기에는 고려해야 할 몇 가지 대안이 있습니다.

옵션 1: 파일 시스템 스냅숏

GitLab 서버에 많은 Git 리포지터리 데이터가 포함된 경우 GitLab 백업 스크립트가 너무 느리다고 생각할 수 있습니다. 특히 오프사이트 위치에 백업을 수행할 때 특히 느릴 수 있습니다.

일반적으로 Git 리포지터리 데이터 크기가 약 200GB가 되면 느림 현상이 시작됩니다. 이 경우 백업 전략의 일환으로 파일 시스템 스냅숏 사용을 고려할 수 있습니다. 예를 들어, 다음 컴포넌트를 포함하는 GitLab 서버를 고려해보십시오:

  • 리눅스 패키지 사용.
  • /var/opt/gitlab에 마운트된 ext4 파일 시스템을 포함하는 AWS에 호스팅.

EBS 스냅숏을 가져와서 애플리케이션 데이터 백업 요구 사항을 충족하는 EC2 인스턴스입니다. 이 백업에는 모든 리포지터리, 업로드 및 PostgreSQL 데이터가 포함됩니다.

일반적으로 가상화된 서버에서 GitLab을 실행하는 경우 전체 GitLab 서버의 VM 스냅숏을 만들 수 있습니다. VM 스냅숏을 작성하려면 서버를 종료해야 하는 경우가 일반적입니다.

옵션 2: GitLab Geo

Tier: Premium, Ultimate Offering: Self-managed

Geo는 GitLab 인스턴스의 로컬 읽기 전용 인스턴스를 제공합니다.

GitLab Geo는 원격 팀이 로컬 GitLab 노드를 사용하여 더 효율적으로 작업할 수 있게 하지만 재해 복구 솔루션으로 사용할 수도 있습니다. 재해 복구 솔루션으로서의 Geo 사용에 대해 자세히 알아보세요.

Geo는 데이터베이스, Git 리포지터리 및 기타 몇 가지 자산을 복제합니다. 복제 제한 사항에 대해 자세히 알아보세요.

Self-managed GitLab 지원

GitLab은 Self-managed GitLab을 다양한 채널을 통해 지원합니다.

Self-managed GitLab 지원을 받으려면:

GitLab SaaS 지원

만약 GitLab SaaS를 사용 중이라면, 지원을 받고 답변을 찾을 수 있는 여러 채널이 있습니다.

  • 우선 지원: Gold 및 Silver GitLab SaaS 고객은 계층별 응답 시간으로 우선 지원을 받습니다. 우선 지원으로 업그레이드하는 방법에 대해 자세히 알아보세요.
  • GitLab SaaS 24/7 모니터링: 저희의 완전한 사이트 안정성 및 제조 엔지니어 팀은 항상 대기 중입니다. 문제를 인지하는 시점에는 누군가가 이미 조사 중인 경우가 많습니다.

GitLab SaaS의 지원을 받으려면:

오픈 소스 GitLab의 API 및 속도 제한

손님문자 (DoS) 또는 브루트 포스 공격을 방지하기 위한 속도 제한입니다. 대부분의 경우, 하나의 IP 주소에서의 요청 속도를 제한함으로써 응용 프로그램 및 인프라의 부하를 줄일 수 있습니다.

속도 제한은 또한 응용프로그램의 보안성을 향상시킵니다.

오픈 소스 GitLab을 위한 속도 제한 구성

기본 속도 제한을 Admin 영역에서 변경할 수 있습니다. 구성에 대한 자세한 정보는 관리자 영역 페이지를 참조하세요.

API 및 속도 제한에 대한 자세한 정보는 API 페이지를 참조하세요.

GitLab SaaS의 API 및 속도 제한

속도 제한은 거부-서비스 또는 브루트 포스 공격을 방지합니다. GitLab.com이 하나의 IP 주소에서 비정상적인 트래픽을 받으면 IP 블록이 발생합니다. 시스템은 속도 제한 설정에 따라 비정상적인 트래픽을 잠재적으로 악의적으로 간주합니다.

속도 제한은 또한 응용 프로그램의 보안성을 향상시킵니다.

GitLab SaaS의 속도 제한 구성

기본 속도 제한을 Admin 영역에서 변경할 수 있습니다. 구성에 대한 자세한 정보는 관리자 영역 페이지를 참조하세요.

  • 속도 제한 페이지를 검토하세요.
  • API 및 속도 제한에 대한 자세한 정보는 API 페이지를 참조하세요.

GitLab SaaS별 차단 및 오류 응답

  • 403 금지 오류: 만약 이러한 오류가 모든 GitLab SaaS 요청에 대해 발생하면, 블록을 유발시킬 수 있는 자동화된 프로세스를 찾아보세요. 자세한 지원은 영향받은 IP 주소를 포함한 오류 세부사항과 함께 GitLab 지원팀에 문의하세요.
  • HAProxy API 쓰로틀: GitLab SaaS는 IP 주소 당 초당 10개 이상의 API 요청에 응답하면 HTTP 상태 코드 429로 응답합니다.
  • 보호된 경로 쓰로틀: GitLab SaaS는 IP 주소 당 분당 10개 이상의 POST 요청에 응답하여 HTTP 상태 코드 429로 응답합니다.
  • Git와 컨테이너 레지스트리 인증 실패 차단: GitLab SaaS는 하나의 IP 주소에서 3분 내에 30건의 인증 실패 요청을 받으면 1시간 동안 HTTP 상태 코드 403으로 응답합니다.

GitLab 교육 자료

GitLab를 관리하는 방법에 대해 자세히 알아볼 수 있습니다.

  • 우리의 재능 있는 커뮤니티와 지식을 공유하기 위해 GitLab 포럼에 참여하세요.
  • 계속해서 업데이트되는 우리의 블로그를 확인하세요:
    • 릴리스
    • 애플리케이션
    • 기여사항
    • 뉴스
    • 이벤트

유료 GitLab 교육

  • GitLab 교육 서비스: 우리의 특별한 교육 과정을 통해 GitLab 및 DevOps 최고의 현업 실무를 배우세요. 전체 과정 카탈로그도 확인하세요.
  • GitLab 기술 인증: 핵심 GitLab 및 DevOps 기술에 중점을 둔 인증 옵션을 탐색하세요.

무료 GitLab 교육

  • GitLab 기본: Git 및 GitLab 기초에 대한 자가 서비스 가이드를 확인하세요.
  • GitLab 대학: 체계적인 강의에서 새로운 GitLab 기술을 GitLab 대학에서 배워보세요.

타사 교육