다음은 GitLab 이 의존성을 함께 묶은 패키지와 Docker 이미지를 제공하는 이유에 대한 기본 정보입니다.

이 방식은 물리 머신과 가상 머신 설치, 그리고 단순한 Docker 설치에 적합합니다.

목표#

이 패키지의 핵심 목표는 다음과 같습니다.

1. 설치, 업그레이드, 유지 관리가 매우 쉬움.
2. 다양한 운영 체제 지원
3. 폭넓은 클라우드 서비스 공급자 지원

Linux 패키지 아키텍처#

GitLab의 핵심은 Ruby on Rails 프로젝트입니다. 그러나 애플리케이션 전체로서의 GitLab은 더 복잡하며 여러 구성 요소로 이루어져 있습니다. 이 구성 요소가 없거나 잘못 구성되면 GitLab 이 동작하지 않거나 예측할 수 없게 동작합니다.

GitLab 개발 문서의 GitLab 아키텍처 개요에서는 이러한 구성 요소 일부와 이들이 상호 작용하는 방식을 보여 줍니다. 각 구성 요소는 구성이 필요하고 최신 상태로 유지해야 합니다.

대부분의 구성 요소에는 외부 의존성도 있습니다. 예를 들어 Rails 애플리케이션은 여러 Ruby gem에 의존합니다. 이러한 의존성 중 일부는 다시 자체 외부 의존성을 가지며, 해당 의존성이 올바르게 동작하려면 운영 체제에 그 의존성이 있어야 합니다.

또한 GitLab은 월간 릴리스 주기를 따르므로 최신 상태를 유지하려면 자주 유지 관리해야 합니다.

앞서 언급한 모든 사항은 GitLab 설치를 유지 관리하는 사용자에게 부담이 됩니다.

외부 소프트웨어 의존성#

GitLab과 같은 애플리케이션에서 외부 의존성은 대개 다음과 같은 어려움을 가져옵니다.

• 직접 의존성과 간접 의존성 간 버전 동기화 유지
• 특정 운영 체제에서 해당 버전의 제공 여부
• 버전이 바뀌면서 기존에 사용하던 구성이 추가되거나 제거될 수 있음
• 라이브러리가 취약한 것으로 표시되었지만 아직 새 버전이 릴리스되지 않았을 때의 보안 문제

사용 중인 운영 체제에 의존성이 존재하더라도 지원되는 다른 운영 체제에는 존재하지 않을 수 있다는 점에 유의합니다.

이점#

의존성을 함께 묶은 패키지의 이점은 다음과 같습니다.

1. GitLab 설치에 드는 수고가 최소화됩니다.
2. GitLab을 실행하는 데 필요한 구성이 최소화됩니다.
3. GitLab 버전 간 업그레이드에 드는 수고가 최소화됩니다.
4. 여러 플랫폼을 지원합니다.
5. 구버전 플랫폼의 유지 관리가 크게 단순해집니다.
6. 잠재적 문제를 지원하는 데 드는 수고가 줄어듭니다.

단점#

의존성을 함께 묶은 패키지의 단점은 다음과 같습니다.

1. 이미 설치된 소프트웨어와 중복될 수 있습니다.
2. 구성의 유연성이 낮습니다.

시스템 패키지를 사용할 수 있는데 Linux 패키지에서 패키지를 설치하는 이유#

간단히 말하면 유지 관리 부담이 줄어들기 때문입니다. 버전이 호환되지 않으면 기존 기능을 망가뜨릴 수 있는 여러 패키지를 관리하는 대신, 하나만 관리하면 됩니다.

패키지가 여러 개이면 여러 위치에서 구성을 올바르게 유지해야 합니다. 구성을 동기화된 상태로 유지하는 일은 오류가 발생하기 쉽습니다.

현재의 모든 의존성을 유지 관리할 역량이 있고 앞으로 추가될 수 있는 의존성을 처리할 시간이 충분하다면, 앞서 설명한 이유만으로는 Linux 패키지의 패키지를 사용하지 않을 근거가 되지 않을 수 있습니다.

이 방식을 택하기 전에 유의할 점이 두 가지 있습니다.

1. 대다수 사용자가 테스트하지 않은 라이브러리 버전을 사용하면 가능한 경우의 수가 많아지므로, 발생한 문제에 대한 지원을 받기가 더 어려울 수 있습니다.
2. Linux 패키지의 패키지도 구성 요소를 독립적으로 실행해야 하는 경우에는 필요 없는 서비스를 끌 수 있습니다. 예를 들어 Linux 패키지 설치에서 번들에 포함되지 않은 PostgreSQL 데이터베이스를 사용할 수 있습니다.

애플리케이션에 구성 요소가 많을 때는 Linux 패키지와 같은 비표준 방식이 더 적합할 수 있다는 점에 유의합니다.

여러 서비스가 포함된 Docker 이미지#

GitLab Docker 이미지는 Linux 패키지를 기반으로 합니다.

이 이미지에서 생성된 컨테이너에는 여러 프로세스가 포함되므로, 이러한 유형의 컨테이너를 'fat container' 라고도 부릅니다.

이런 이미지에는 장점과 단점이 모두 있으며, 앞서 언급한 내용과 비슷합니다.

1. 시작하기가 매우 간단합니다.
2. 최신 버전으로 업그레이드하기가 매우 간단합니다.
3. 여러 컨테이너에서 개별 서비스를 실행하고 계속 동작하게 유지하는 일은 더 복잡할 수 있으며, 특정 설치에는 필요하지 않을 수 있습니다.

이 방식은 컨테이너와 스케줄러를 이제 막 도입하기 시작해 더 복잡한 설치를 감당하기 어려운 조직에 유용합니다. 입문 방식으로 적합하며 규모가 작은 조직에서 잘 동작합니다.