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은 데이터를 안전하게 보관하고 복구할 수 있는 백업 방법을 제공합니다. 자체 관리형이나 GitLab SaaS 데이터베이스를 사용하더라도 데이터를 정기적으로 백업하는 것이 중요합니다.

  • 백업 전략을 결정하세요.
  • 매일 백업을 생성하기 위해 cron 작업을 작성하는 것을 고려하세요.
  • 구성 파일을 따로 백업하세요.
  • 백업에서 제외해야 할 사항을 결정하세요.
  • 백업을 업로드할 위치를 결정하세요.
  • 백업 수명을 제한하세요.
  • 테스트 백업 및 복구를 실행하세요.
  • 주기적으로 백업을 확인할 수 있는 방법을 설정하세요.

GitLab 자체 관리형 인스턴스 백업

일반 리눅스 패키지 또는 Helm 차트를 사용하여 배포했는지에 따라 절차가 다릅니다.

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

리눅스 패키지 또는 Helm의 다양성에 대한 백업 참조를 확인하세요. 이 절차는 전체 인스턴스를 백업하지만 구성 파일은 백업하지 않습니다. 이는 구성 파일이 따로 백업되도록 해야 함을 의미합니다. 암호화 키가 암호화된 데이터와 함께 보관되지 않도록 구성 파일 및 백업 아카이브를 별도의 위치에 유지하세요.

백업 복원

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

GitLab SaaS 백업

생산 데이터베이스의 백업은 디스크 스냅숏을 통해 매시간, wal-g 기본 백업을 통해 24시간마다, 연속 아카이빙 또는 WAL 트랜잭션 로그 파일은 GCS로 스트리밍하여 시점 복구에 활용됩니다.

모든 백업은 암호화됩니다. 90일 후에는 백업이 삭제됩니다.

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

자세한 정보는 GitLab SaaS 백업 FAQ 페이지를 참조하세요(https://handbook.gitlab.com/handbook/engineering/infrastructure/faq/#gitlabcom-backups).

대체 백업 전략

일부 상황에서 백업을 위한 Rake 작업이 가장 최적의 솔루션이 아닐 수 있습니다. Rake 작업이 작동하지 않는 경우 고려해야 할 몇 가지 대안을 살펴보겠습니다.

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

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

이러한 느림현상은 일반적으로 약 200GB의 Git 리포지토리 데이터 크기에서 시작됩니다. 이 경우 백업 전략의 일환으로 파일 시스템 스냅숏 사용을 고려할 수 있습니다. 예를 들어 다음과 같은 구성 요소를 포함한 GitLab 서버가 있다고 가정해 봅시다:

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

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

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

옵션 2: GitLab Geo

Tier: Premium, Ultimate Offering: Self-managed

Geo는 GitLab 인스턴스의 지역 복사본(읽기 전용)을 제공합니다.

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

Geo는 데이터베이스, Git 리포지토리 및 일부 기타 에셋을 복제합니다. Geo가 복제하는 데이터 유형에 대해 자세히 알아보세요.

자체 관리형 GitLab 지원

GitLab은 자체 관리형 GitLab에 대한 지원을 다양한 채널을 통해 제공합니다.

  • 우선 순위 지원: 프리미엄 및 얼티메이트 자체 관리형 고객은 계층별 응답 시간을 가진 우선 순위 지원을 받습니다. 우선 순위 지원으로 업그레이드하는 방법에 대해 자세히 알아보세요.
  • 라이브 업그레이드 지원: 우선 순위 지원 플랜으로, 프로덕션 업그레이드 중에 1:1 전문 지침을 받을 수 있습니다. 지원팀의 구성원과 일정된 화면 공유 세션을 통해 전문가 지도를 받을 수 있습니다.

자체 관리형 GitLab의 지원을 받으려면:

GitLab SaaS 지원

GitLab SaaS를 사용하는 경우 지원을 받고 답변을 찾을 수 있는 여러 채널이 있습니다.

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

GitLab SaaS를 위한 도움을 받으려면:

자체 관리형 GitLab의 API 및 속도 제한

속도 제한은 서비스 거부 또는 무차별 공격을 방지합니다. 대부분의 경우, 단일 IP 주소에서의 요청 속도를 제한함으로써 응용 프로그램 및 인프라의 부하를 줄일 수 있습니다.

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

자체 관리형 GitLab의 속도 제한 구성

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

API 및 속도 제한에 대한 자세한 내용은 API 페이지를 참조하세요.

GitLab SaaS의 API 및 속도 제한

속도 제한은 서비스 거부 또는 무차별 공격을 방지합니다. IP 차단은 보통 GitLab.com이 단일 IP 주소로부터 이상한 트래픽을 받았을 때 발생합니다. 시스템은 속도 제한 설정을 기반으로 이상한 트래픽을 잠재적으로 악의적으로 간주합니다.

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

GitLab SaaS의 속도 제한 구성

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

  • 속도 제한 페이지를 확인하세요.
  • 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 및 컨테이너 레지스트리 인증 실패 금지: 단일 IP 주소로부터 3분 내에 30회의 인증 실패 요청을 받은 경우 GitLab SaaS는 1시간 동안 HTTP 상태 코드 403으로 응답합니다.