아티팩트 기반 빌드 시스템

이 페이지에서는 아티팩트 기반 빌드 시스템과 제작 철학을 다룹니다. Bazel은 아티팩트 기반 빌드 시스템입니다. 작업 기반 빌드 시스템은 빌드 스크립트보다 낫지만 개별 엔지니어가 자신의 작업을 정의하도록 하면 과도한 전력을 쏟을 수 있습니다.

아티팩트 기반 빌드 시스템에는 엔지니어가 제한된 방식으로 구성할 수 있는 소수의 태스크가 시스템에 의해 정의되어 있습니다. 엔지니어는 여전히 시스템에 무엇을 빌드해야 하는지 알려주지만 빌드 시스템은 빌드 방법을 결정합니다. 작업 기반 빌드 시스템과 마찬가지로 Bazel과 같은 아티팩트 기반 빌드 시스템에도 빌드 파일이 있지만 이러한 빌드 파일의 콘텐츠는 매우 다릅니다. 출력 생성 방법을 설명하는 Turing-complete 스크립팅 언어에서 필수적인 명령어 집합이 아닌 Bazel의 빌드 파일은 빌드할 아티팩트 세트, 종속 항목, 빌드 방식에 영향을 주는 제한된 옵션 집합을 설명하는 선언적 매니페스트입니다. 엔지니어는 명령줄에서 bazel을 실행할 때 빌드할 대상 집합 (대상)을 지정하며 Bazel은 컴파일 단계 구성, 실행, 예약 (방법)을 담당합니다. 이제 빌드 시스템이 실행할 도구를 완전히 제어할 수 있기 때문에 정확성을 보장하면서도 훨씬 효율적으로 보장할 수 있습니다.

기능적인 관점

아티팩트 기반 빌드 시스템과 기능 프로그래밍을 비유하는 것은 쉽습니다. 기존의 명령형 프로그래밍 언어 (예: 자바, C, Python)는 작업 기반 빌드 시스템에서 프로그래머가 일련의 단계를 정의할 수 있는 것과 같은 방식으로 실행할 문 목록을 차례로 지정합니다. 반면 기능적 프로그래밍 언어 (예: Haskell 및 ML)는 일련의 수학 방정식과 유사하게 구성됩니다. 기능적 언어에서는 프로그래머가 실행할 계산을 설명하지만 계산이 언제 어떻게 정확히 컴파일되는지에 대한 세부정보는 컴파일러에 남겨둡니다.

이는 아티팩트 기반 빌드 시스템에서 매니페스트를 선언하고 시스템이 빌드 실행 방법을 알아내도록 하는 개념에 대응됩니다. 기능적 프로그래밍을 사용하여 쉽게 표현할 수 없는 경우가 많지만 이를 통해 많은 이점을 얻는 것은 프로그래밍을 통해 이러한 프로그램을 쉽게 병렬 처리할 수 있고 명령형으로는 불가능한 정확성을 강력하게 보장할 수 있습니다. 함수 프로그래밍을 사용하여 표현하는 가장 쉬운 문제는 단순히 일련의 규칙 또는 함수를 사용하여 한 데이터를 다른 데이터로 변환하는 것입니다. 빌드 시스템은 정확히 다음과 같습니다. 전체 시스템은 소스 파일 (및 컴파일러와 같은 도구)을 입력으로 사용하고 바이너리를 출력으로 생성하는 수학적 함수입니다. 따라서 함수 프로그래밍의 원리를 기반으로 빌드 시스템을 기반으로 하는 것이 잘 작동하는 것은 그리 놀라운 일이 아닙니다.

아티팩트 기반 빌드 시스템 이해

Google의 빌드 시스템인 Blaze는 최초의 아티팩트 기반 빌드 시스템이었습니다. Bazel은 오픈소스 버전의 Blaze입니다.

Bazel에서 빌드파일 (일반적으로 BUILD)은 다음과 같습니다.

java_binary(
    name = "MyBinary",
    srcs = ["MyBinary.java"],
    deps = [
        ":mylib",
    ],
)
java_library(
    name = "mylib",
    srcs = ["MyLibrary.java", "MyHelper.java"],
    visibility = ["//java/com/example/myproduct:__subpackages__"],
    deps = [
        "//java/com/example/common",
        "//java/com/example/myproduct/otherlib",
    ],
)

Bazel에서 BUILD 파일은 대상을 정의합니다. 여기서 두 가지 유형의 대상은 java_binary 및 java_library입니다. 모든 타겟은 시스템에서 생성할 수 있는 아티팩트에 대응됩니다. 바이너리 타겟은 직접 실행될 수 있는 바이너리를 생성하며, 라이브러리 타겟은 바이너리 또는 다른 라이브러리에서 사용될 수 있는 라이브러리를 생성합니다. 모든 타겟에 적용되는 사항

name: 명령줄 및 기타 대상에서 대상을 참조하는 방법
srcs: 대상의 아티팩트를 만들기 위해 컴파일한 소스 파일입니다.
deps: 이 타겟 전에 빌드하고 그 타겟에 연결해야 하는 다른 타겟

종속 항목은 동일한 패키지 내에 있거나 (예: MyBinary의 :mylib 종속 항목) 동일한 소스 계층 구조의 다른 패키지(예: mylib의 //java/com/example/common 종속 항목)에 있을 수 있습니다.

작업 기반 빌드 시스템과 마찬가지로 Bazel의 명령줄 도구를 사용하여 빌드를 수행합니다. MyBinary 대상을 빌드하려면 bazel build :MyBinary를 실행합니다. 클린 저장소에 해당 명령어를 처음 입력하면 Bazel이 다음을 수행합니다.

작업공간의 모든 BUILD 파일을 파싱하여 아티팩트 간의 종속 항목 그래프를 만듭니다.
그래프를 사용하여 MyBinary의 전이 종속 항목을 확인합니다. 즉, MyBinary가 종속되는 모든 타겟과 이러한 대상이 종속되는 모든 타겟을 재귀적으로 결정합니다.
이러한 각 종속 항목을 순서대로 빌드합니다. Bazel은 다른 종속 항목이 없는 각 대상을 빌드하는 것으로 시작하고 각 대상에 대해 여전히 빌드해야 하는 종속 항목을 추적합니다. 대상의 모든 종속 항목이 빌드되면 Bazel이 해당 대상을 빌드하기 시작합니다. 이 프로세스는 모든 MyBinary의 전이 종속 항목이 빌드될 때까지 계속됩니다.
3단계에서 빌드된 모든 종속 항목에 연결되는 최종 실행 바이너리를 생성하도록 MyBinary를 빌드합니다.

기본적으로는 여기서 발생하는 작업이 작업 기반 빌드 시스템을 사용할 때와 크게 다르지 않을 수도 있습니다. 실제로 최종 결과는 동일한 바이너리이며, 이를 생성하기 위한 프로세스에는 여러 단계를 분석하여 종속 항목 간의 종속 항목을 찾은 후 이러한 단계를 순서대로 실행하는 작업이 포함됩니다. 하지만 중요한 차이가 있습니다. 첫 번째 단계는 3단계에서 나타납니다. Bazel은 각 대상이 자바 라이브러리만 생성한다는 것을 알고 있기 때문에 임의의 사용자 정의 스크립트가 아닌 자바 컴파일러만 실행하면 된다는 사실을 알고 있으므로 이러한 단계를 동시에 실행하는 것이 안전합니다. 이렇게 하면 대상을 멀티코어 머신에서 한 번에 하나씩 빌드하는 것보다 성능이 크게 향상될 수 있으며, 이것이 가능한 이유는 아티팩트 기반 방식이 빌드 시스템을 자체 실행 전략으로 유지하여 동시 로드에 대해 더 강력한 보장을 제공하기 때문입니다.

하지만 이점은 병렬 처리 이상의 성능입니다. 이 접근 방식을 사용하면 개발자가 아무것도 변경하지 않고 bazel build :MyBinary을 두 번째로 입력할 때 Bazel이 대상이 최신 상태라는 메시지와 함께 1초 이내에 종료됩니다. 이는 앞서 설명한 기능적 프로그래밍 패러다임으로 인해 가능합니다. Bazel은 각 타겟이 자바 컴파일러의 실행 결과라는 것을 알고 있으며 자바 컴파일러의 출력은 입력에만 종속된다는 것을 알고 있습니다. 따라서 입력이 변경되지 않았다면 출력을 재사용할 수 있습니다. 이 분석은 모든 수준에서 작동합니다. MyBinary.java이 변경되면 Bazel은 MyBinary를 다시 빌드하지만 mylib를 재사용하는 것을 인식합니다. //java/com/example/common의 소스 파일이 변경되면 Bazel은 라이브러리, mylib, MyBinary를 다시 빌드하지만 //java/com/example/myproduct/otherlib는 재사용합니다. Bazel은 모든 단계에서 실행하는 도구의 속성에 대해 알고 있으므로 매번 최소한의 아티팩트 세트만 다시 빌드할 수 있으며, 오래된 빌드가 생성되지 않도록 보장합니다.

작업이 아닌 아티팩트 측면에서 빌드 프로세스를 재구성하는 것은 미묘하지만 강력합니다. 프로그래머에 노출되는 유연성을 줄이면 빌드 시스템이 빌드의 모든 단계에서 수행되는 작업에 관해 더 잘 알 수 있습니다. 이 지식을 사용하여 빌드 프로세스를 병렬화하고 출력을 재사용하여 빌드의 효율성을 높일 수 있습니다. 하지만 이는 실제로 첫 번째 단계에 불과합니다. 이러한 병렬 처리 및 재사용의 기본 구성요소는 고도로 확장 가능한 분산형 빌드 시스템의 기반이 됩니다.

기타 Bazel의 멋진 기술

아티팩트 기반 빌드 시스템은 작업 기반 빌드 시스템에 고유한 병렬 처리 및 재사용 문제를 근본적으로 해결합니다. 하지만 아직까지 Google에서 해결하지 못한 문제들이 몇 가지 있습니다. Bazel은 이러한 문제를 해결하는 기발한 방법이 있기 때문에 계속 진행하기 전에 논의해야 합니다.

종속 항목으로 사용되는 도구

이전에 한 가지 문제는 빌드가 머신에 설치된 도구에 종속되었고 다양한 도구 버전이나 위치로 인해 시스템 간 빌드를 재현하기가 어려울 수 있다는 문제가 있었습니다. 프로젝트에서 빌드하거나 컴파일하는 플랫폼 (예: Windows 또는 Linux)에 따라 다른 도구가 필요한 언어를 사용하는 경우 이러한 문제는 더 어려워집니다. 이러한 각 플랫폼에는 동일한 작업을 하기 위해 약간 다른 도구 세트가 필요합니다.

Bazel은 도구를 각 대상에 대한 종속 항목으로 취급하여 이러한 문제의 첫 번째 부분을 해결합니다. 작업공간의 모든 java_library는 잘 알려진 컴파일러를 기본값으로 설정하는 자바 컴파일러에 암시적으로 종속됩니다. Bazel은 java_library를 빌드할 때마다 지정된 컴파일러를 알려진 위치에서 사용할 수 있는지 확인합니다. 다른 종속 항목과 마찬가지로 자바 컴파일러가 변경되면 종속된 모든 아티팩트가 다시 빌드됩니다.

Bazel은 빌드 구성을 설정하여 문제의 두 번째 부분인 플랫폼 독립성을 해결합니다. 이러한 도구는 도구에 직접 의존하는 대신 구성 유형에 따라 달라집니다.

호스트 구성: 빌드 중에 실행되는 빌드 도구
대상 구성: 최종적으로 요청한 바이너리 빌드

빌드 시스템 확장

Bazel은 널리 사용되는 몇 가지 프로그래밍 언어의 대상과 함께 기본적으로 제공되지만, 엔지니어는 항상 더 많은 작업을 수행하기를 원합니다. 작업 기반 시스템의 이점은 모든 빌드 프로세스를 지원할 수 있는 유연성에 있으므로 아티팩트 기반 빌드 시스템에서는 포기하지 않는 것이 좋습니다. 다행히 Bazel은 커스텀 규칙을 추가하여 지원되는 대상 유형을 확장할 수 있습니다.

Bazel에서 규칙을 정의하기 위해 규칙 작성자는 규칙에 필요한 입력 (BUILD 파일에 전달된 속성 형식)과 규칙이 생성하는 고정 출력 집합을 선언합니다. 또한 작성자는 해당 규칙에 의해 생성될 작업을 정의합니다. 각 작업은 입력과 출력을 선언하고, 특정 실행 파일을 실행하거나, 파일에 특정 문자열을 작성하며, 입력과 출력을 통해 다른 작업에 연결할 수 있습니다. 즉, 작업은 빌드 시스템에서 가장 낮은 수준의 구성 가능한 단위입니다. 작업은 선언된 입력과 출력만 사용하는 한 원하는 것은 무엇이든 할 수 있으며 Bazel은 작업을 예약하고 결과를 적절하게 캐시합니다.

시스템은 개발자가 확정되지 않은 프로세스를 작업의 일부로 도입하는 등의 작업을 막을 방법이 없으므로 완벽한 시스템은 아닙니다. 하지만 이러한 경우는 드물게 발생하며 악용 가능성 가능성을 작업 수준까지 아래로 내리면 오류 가능성이 크게 줄어듭니다. 많은 공통 언어 및 도구를 지원하는 규칙이 온라인에서 널리 사용되고 있으며 대부분의 프로젝트에서 자체 규칙을 정의할 필요가 없습니다. 이러한 규칙도 저장소의 한 곳에서만 정의하면 되므로 대부분의 엔지니어는 구현에 대해 걱정할 필요 없이 이러한 규칙을 사용할 수 있습니다.

환경 격리

작업은 다른 시스템의 작업과 동일한 문제가 발생할 수 있는 것처럼 보입니다. 같은 파일에 쓰는 작업을 서로 작성하게 되는 작업을 작성하는 것은 여전히 가능하지 않나요? 실제로 Bazel은 샌드박스를 사용하여 이러한 충돌을 방지합니다. 지원되는 시스템에서 모든 작업은 파일 시스템 샌드박스를 통해 다른 모든 작업과 격리됩니다. 실제로 각 작업은 선언된 입력과 생성된 출력을 포함하는 파일 시스템의 제한된 뷰만 볼 수 있습니다. 이는 Docker의 기반 기술인 Linux의 LXC와 같은 시스템에 의해 적용됩니다. 즉, 선언하지 않은 파일은 읽을 수 없고, 작성은 했지만 선언하지 않은 파일은 작업이 끝나면 서로 버려지기 때문에 작업이 서로 충돌할 수 없습니다. 또한 Bazel은 샌드박스를 사용하여 작업이 네트워크를 통해 통신하는 것을 제한합니다.

외부 종속 항목을 확정적으로 설정

여전히 한 가지 문제가 남아 있습니다. 빌드 시스템은 종속 항목을 직접 빌드하지 않고 외부 소스에서 도구 (라이브러리 또는 라이브러리)를 다운로드해야 하는 경우가 많습니다. 이 예는 Maven에서 JAR 파일을 다운로드하는 @com_google_common_guava_guava//jar 종속 항목을 통해 확인할 수 있습니다.

현재 작업공간 외부의 파일에 따라 위험할 수 있습니다. 이러한 파일은 언제든지 변경될 수 있으므로 빌드 시스템에서 파일이 최신 상태인지 지속적으로 확인해야 할 수 있습니다. 작업공간 소스 코드에서 해당하는 변경 없이 원격 파일이 변경되면 재현 불가능한 빌드로 이어질 수도 있습니다. 빌드가 언젠가는 작동할 수 있지만, 알 수 없는 종속 항목 변경으로 인해 뚜렷한 이유 없이 빌드가 실패할 수 있습니다. 마지막으로 외부 종속 항목이 타사 소유일 경우 큰 보안 위험이 발생할 수 있습니다. 공격자가 타사 서버에 침투할 수 있는 경우 종속 항목 파일을 자체 디자인으로 대체하여 빌드 환경과 출력을 완전히 제어할 수 있습니다.

근본적인 문제는 빌드 시스템이 이러한 파일을 소스 제어에 체크인하지 않고도 인식할 수 있도록 하는 것입니다. 종속 항목 업데이트는 의식적인 선택이어야 하지만, 개별 엔지니어가 관리하는 것이 아니라 시스템에서 한 번만 선택해야 하며 시스템에서 자동으로 수행해야 합니다. 이는 'Live at Head' 모델을 사용하더라도 여전히 빌드가 확정적이어야 합니다. 즉, 지난주의 커밋을 체크아웃하면 종속 항목이 현재와 같이 그대로 표시되어야 합니다.

Bazel 및 일부 빌드 시스템에서는 작업공간의 모든 외부 종속 항목에 대한 암호화 해시를 나열하는 작업공간 전체 매니페스트 파일을 요구하여 이 문제를 해결합니다. 해시는 전체 파일을 소스 제어에 체크인하지 않고 파일을 고유하게 나타내는 간결한 방법입니다. 작업공간에서 새 외부 종속 항목을 참조할 때마다 해당 종속 항목의 해시가 수동 또는 자동으로 매니페스트에 추가됩니다. Bazel은 빌드를 실행할 때 캐시된 종속 항목의 실제 해시를 매니페스트에 정의된 예상 해시와 비교하여 해시가 다른 경우에만 파일을 다시 다운로드합니다.

다운로드한 아티팩트에 매니페스트에서 선언된 것과 다른 해시가 있는 경우 매니페스트의 해시가 업데이트되지 않으면 빌드가 실패합니다. 이 작업은 자동으로 실행할 수 있지만 빌드가 새 종속 항목을 수락하기 전에 승인을 받고 소스 제어에 체크인해야 합니다. 즉, 종속 항목이 업데이트된 시기에 관한 기록이 항상 있으며 작업공간 소스에서 이에 상응하는 변경 없이는 외부 종속 항목을 변경할 수 없습니다. 또한 이전 버전의 소스 코드를 체크아웃할 때 빌드는 해당 버전이 체크인된 시점에 사용된 것과 동일한 종속 항목을 사용하도록 보장됩니다. 그러지 않으면 이러한 종속 항목을 더 이상 사용할 수 없게 되면 빌드가 실패합니다.

물론 원격 서버를 사용할 수 없게 되거나 손상된 데이터를 제공하기 시작한 경우에도 문제가 될 수 있습니다. 이 경우, 종속 항목의 다른 사본을 사용할 수 없는 경우 모든 빌드가 실패할 수 있습니다. 이 문제를 방지하려면 중요한 프로젝트의 경우 신뢰할 수 있고 제어하는 서버 또는 서비스에 모든 종속 항목을 미러링하는 것이 좋습니다. 그러지 않으면 체크인 해시가 보안을 보장하더라도 빌드 시스템의 가용성을 항상 서드 파티가 고려해야 합니다.