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 인스턴스 보안

보안은 입사 절차의 중요한 부분입니다. 인스턴스를 안전하게 보호하면 작업 및 조직이 안전해집니다.

이 디렉터리이 모두는 아니지만, 이러한 단계를 따르면 인스턴스를 안전하게 보호할 수 있는 좋은 시작점이 됩니다.

  • 긴 루트 암호를 사용하여 보안 리포지터리에 저장하십시오.
  • 신뢰할 수 있는 SSL 인증서를 설치하고 갱신 및 취소 프로세스를 설정하십시오.
  • 조직 지침에 따라 SSH 키 제한을 구성하십시오.
  • 신규 등록 비활성화.
  • 이메일 확인이 필요합니다.
  • 암호 길이 제한 설정, SSO 또는 SAML 사용자 관리 구성.
  • 가입을 허용하는 경우 이메일 도메인 제한.
  • 이중 인수 인증(2FA)이 필요합니다.
  • HTTPS를 통한 Git의 패스워드 인증 비활성화 비활성화.
  • 알 수없는 로그인에 대한 이메일 알림을 설정하십시오.
  • 사용자 및 IP 속도 제한을 구성하십시오(https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/#user-and-ip-rate-limits).
  • 웹훅 로컬 액세스 제한을 제한하십시오.
  • 보호된 경로의 속도 제한을 설정하십시오.
  • 통신 설정센터의 보안 경보에 등록하십시오.
  • 블로그 페이지에서 보안 모범 사례를 추적하세요.

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 자체에 저장할 수 없습니다.
  • 프로젝트 내보내기 옵션을 사용하여 다음을 내보낼 수 있습니다:
  • 파일 내보내기를 업로드하여 그룹 내보내기 해당 그룹 내의 프로젝트는 내보내지 않으나 다음을 내보냅니다:
    • Epic
    • 마일스톤
    • 보드
    • 레이블
    • 추가 항목

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

대안적인 백업 전략

어떤 상황에서는 백업을 위한 Rake 작업이 가장 최적의 해결책이 아닐 수 있습니다. 여기에는 여러 가지 대안이 있습니다.

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

GitLab 서버에 대량의 Git 리포지터리 데이터가 있는 경우, GitLab 백업 스크립트가 너무 느리다고 느낄 수 있습니다. 특히, 비즈니스용 장소에 백업하는 경우에는 특히 느릴 수 있습니다.

이러한 느린 성능은 보통 Git 리포지터리 데이터 크기가 약 200GB인 경우부터 시작됩니다. 이런 경우에는 백업 전략의 일환으로 파일 시스템 스냅샷을 사용하는 것을 고려할 수 있습니다. 예를 들어, 다음 컴포넌트를 갖춘 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 리포지터리 및 다른 몇 가지 자산을 복제합니다. 복제 제한 사항에 대해 자세히 알아보세요.

Self-Managed형 GitLab 지원

GitLab은 Self-Managed형 GitLab을 위한 다양한 채널을 통해 지원을 제공합니다.

  • 우선 지원: Premium 및 Ultimate Self-Managed형 고객은 계층화된 응답 시간과 함께 우선 지원을 받습니다. 우선 지원으로 업그레이드에 대해 자세히 알아보세요.
  • 실시간 업그레이드 지원: 프로덕션 업그레이드 중에 전문가의 일대일 지침을 제공받으세요. 우선 지원 계획으로, 지원팀 구성원과의 실시간 예약된 화면 공유 세션을 예약할 수 있습니다.

Self-Managed형 GitLab을 위해 지원을 받으려면:

  • GitLab 설명서를 참조하여 자체 서비스 지원을 이용하세요.
  • 커뮤니티 지원을 위해 GitLab 포럼에 가입하세요.
  • 티켓을 제출하기 전에 구독 정보를 수집하세요.
  • 지원 티켓 제출을 합니다.

GitLab SaaS 지원

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

  • 우선 지원: 골드 및 실버 GitLab SaaS 고객은 계층화된 응답 시간과 함께 우선 지원을 받습니다. 우선 지원으로 업그레이드에 대해 자세히 알아보세요.
  • GitLab SaaS 24/7 모니터링: 전체 사이트 안정성 및 프로덕션 엔지니어 팀이 항상 대기 중입니다. 문제를 인지한 시점에는 이미 누군가가 조치에 착수하고 있을 수 있습니다.

GitLab SaaS를 위해 지원을 받으려면:

Self-Managed형 GitLab API 및 요청 제한

요청 제한은 서비스 거부 공격 또는 브루트 포스 공격을 방지합니다. 대부분의 경우, 단일 IP 주소에서의 요청 속도를 제한하여 응용프로그램 및 인프라에 걸리는 부하를 줄일 수 있습니다.

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

Self-Managed형 GitLab의 요청 제한 구성

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

API 및 요청 제한에 대한 자세한 정보는 API 페이지에서 확인하세요.

GitLab SaaS의 API 및 요율 제한

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

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

GitLab SaaS의 요율 제한 구성

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

  • 요율 제한 페이지 검토
  • API 및 요율 제한에 대한 자세한 정보는 API 페이지를 참조하십시오.

GitLab SaaS별 블록 및 오류 응답

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

GitLab 교육 자료

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

  • GitLab 포럼에 참여하여 우리의 유능한 커뮤니티와 지식을 공유하세요.
  • 계속해서 업데이트되는 우리 블로그에서 확인:
    • 릴리스
    • 응용프로그램
    • 기여
    • 뉴스
    • 이벤트

유료 GitLab 교육

  • GitLab 교육 서비스: 전문적인 교육 과정을 통해 GitLab 및 DevOps 최상의 실천 방법에 대해 자세히 알아보세요. 전체 과정 카탈로그를 확인하세요.
  • GitLab 기술 인증: 주요 GitLab 및 DevOps 기술에 중점을 둔 인증 옵션을 탐색하세요.

무료 GitLab 교육

  • GitLab 기초: Git 및 GitLab 기초에 대한 자체 서비스 가이드를 찾아보세요.
  • GitLab 대학: GitLab 대학에서 구조화된 과정으로 새로운 GitLab 기술을 배우세요.

제3자 교육