일반적인 Linux 배포판을 새로 설치한다고 가정해 보겠습니다. 구축하고 호스팅하려는 웹 애플리케이션의 소스 코드가 포함된 tarball을 다운로드했습니다. 이 프로젝트는 약간 현대적이어서 Node.js/npm 및 Ruby/gem용 시스템 패키지를 설치해야 했습니다. 모든 전제 조건이 충족되면 웹 서버에서 제공할 수 있는 파일을 생성하는 애플리케이션을 구축할 수 있도록 npm install -g몇 가지 다른 작업을 수행해야 합니다 .gem install.js.css
이제 앱을 빌드했으므로 이를 달성하기 위해 설치해야 했던 모든 것을 제거하고 싶습니다. 원본 소스 코드, JS/CSS 컴파일러 또는 지금 컴파일하는 종속성 빌드 아티팩트가 필요하지 않습니다. 어떤 경우에는 Node.js/Ruby를 더 이상 설치할 필요조차 없습니다. 조만간 코드를 다시 컴파일할 계획은 없습니다. 그날이 오면 전제 조건만 다시 설치하겠습니다.
저는 애플리케이션을 구축하기 위해 시스템에 적용해야 하는 모든 변경 사항을 "해체"하는 쉬운 방법을 찾고 있습니다. 즉, 시스템을 타르볼을 다운로드하기 전의 상태로 되돌리되 최종 빌드 결과물은 유지하세요. (공유 라이브러리 문제에도 불구하고 C/C++ 컴파일에 대해 유사한 작업 흐름을 허용할 만큼 프로세스가 충분히 일반적이었다면 좋았을 것입니다.)
나는 chroot를 조사했고 그것이 계산서에 맞을 수도 있지만 과잉처럼 보입니다. 또한 가상 머신에서 빌드하고, 빌드 아티팩트를 추출하고, 단순히 머신을 삭제하는 것도 고려했지만 이 역시 비효율적이라고 생각됩니다. 이 사용 사례에 적합한 일종의 파일 시스템 "스냅샷" 기능이 있습니까? 아니면 다양한 패키지 관리자에게 전용 일회용 임시 디렉토리에서 특별히 작업하도록 지시하는 방법이 있습니까?
답변1
몇 가지 옵션이 있습니다.
전통적인 접근 방식은 소스 코드의 모든 항목을 홈 디렉터리에 수동으로 설치한 다음 완료되면 콘텐츠를 삭제하는 것입니다. 이것의 장점은 모든 배포판에서 실행되고 일부 종속성이 설치된 경우 시스템 라이브러리를 활용할 수 있다는 것입니다. 그러나 단점은 무언가를 올바르게 빌드하는 것이 종종 까다롭다는 것입니다.
대부분의 패키지 관리자는 일반적으로 명령줄 옵션이나 환경 변수를 통해 설정되는 특정 경로에 설치할 수도 있습니다. 나는 Emergency, pacman 및 DNF가 이것을 지원할 것이라고 확신하며 Zypper도 이를 지원할 것이라고 확신합니다. dpkg 기반 시스템을 다룰 때 debootstrap프로그램을 사용하여 chroot를 생성하도록 선택할 수도 있습니다(이 프로그램을 사용하여 초기화한 다음 chroot하고 거기에 설치된 패키지 관리자를 사용하여 필요한 패키지를 추가할 수 있습니다).
배포판별 옵션도 몇 가지 있는데, 그 중 가장 중요한 두 가지는 다음과 같습니다.
- BTRFS<에 설치하면 SUSE는 패키지 관리자 트랜잭션 전후에 시스템의 스냅샷을 찍을 수 있습니다. 나는 SUSE를 자주 사용하지 않기 때문에 정확히 어떻게 설명할 수는 없지만 약간의 노력을 기울이면 원하는 것을 달성할 수 있습니다.
- NixOS에서 사용되는 Nix 패키지 관리자는 기본적으로 사용자 정의 가능한 설치된 패키지 세트인 사용자별 "프로필"을 허용합니다. 이는 연결된 사용자가 마음대로 생성, 수정, 전환 및 삭제할 수 있으며(사용하기 위해 루트 권한이 필요하지 않음) 이를 수행하기 위한 또 다른 빠른 옵션을 제공합니다.
답변2
간단한 chroot, 컨테이너 및 가상 머신은 "과잉"이 아닙니다. 이러한 작업은 그 용도 중 하나입니다. 실제로 시스템에 되돌릴 수 없는 변경이 발생하는 것을 방지하려는 경우 필수적입니다. 요즘 컨테이너와 가상머신은 사용하기 너무 쉬워서 사용하지 않을 이유가 없습니다. 즉, 시스템의 나머지 부분과 완전히 격리된 빌드 환경을 제공합니다.
실제로 파일 시스템 스냅샷을 사용하여 메인 시스템의 항목을 업그레이드/설치하고 소프트웨어를 구축한 다음 이전 스냅샷으로 되돌리는 것은 중복됩니다. 또한 너무 조잡하고 작업에 잠재적으로 위험할 수 있습니다... 컴파일된 프로그램(예: 다양한 백그라운드 작업, 데몬, 크론 작업 등)뿐만 아니라 주어진 시간에 시스템에서 많은 일이 일어나고 있습니다. 메일을 다운로드하여 pop/imap 서버에서 삭제했거나, 이 프로그램 구축과 전혀 관련 없는 파일을 생성/편집한 경우) -모두이전 스냅샷으로 되돌리면 해당 내용이 복원됩니다. Fileystem 스냅샷은 좋은 아이디어이자 유용한 도구이지만, 서로 다른 운영 환경 간에 동적으로 전환하는 방법보다는 좋은 백업 및/또는 간단한 복구 전략의 일부로 사용하는 것이 더 좋습니다.
대부분의 컨테이너 및 가상 머신 관리 시스템(예: docker, , , lxc, 등 virsh) virt-manager은 새로운 상태에서 각 실행을 쉽게 다시 시작할 수 있으므로 매번 정확히 동일한 원래 빌드 환경으로 시작할 수 있습니다. VM 디스크 이미지는 일반적으로 스냅샷을 생성하고 복제할 수 있는 형식으로 저장됩니다(예: qcow2ZFS zvol. 원본 디스크 이미지 파일도 복사하고 선택적으로 압축할 수 있음). chroot로 동일한 작업을 수행할 수 있지만 chroot를 삭제하고 직접 다시 만들어야 합니다(예: chroot의 .tar.gz 아카이브 사용).
상당히 기본적인 설정 및 빌드 프로세스는 chroot, 컨테이너 또는 가상 머신을 시작합니다. 이는 각 빌드 작업의 요구 사항에 따라 구성하는 일반 빌드 환경일 수도 있고, 하나의 특정 프로그램만 빌드하도록 사전 구성된 환경일 수도 있습니다. 그런 다음 이를 사용하여 소프트웨어를 구축하고 마지막으로 실행될 위치에 복사합니다(및/또는 배포용 패키지를 구축합니다. 작업이 너무 많은 것 같으면 시도해 보세요.설치 확인).
docker특히 완벽한 빌드 컨테이너를 자동으로 생성하거나 공통 컨테이너를 기반으로 특정 빌드 컨테이너를 사용자 정의할 수 있는 몇 가지 훌륭한 도구가 있습니다.
또한 가상 머신이나 컨테이너를 시작하고, 여기에 작업을 보내 컴파일한 후 다시 해체하는 전체 프로세스를 자동화할 수도 있습니다. 이 아이디어를 구현한 기존 구현이 많이 있습니다.로봇 만들기(인기있는 GPL Python 프로그램이 있습니다.buildbot, 그러나 그 이름, 아이디어 및 작업 구현은 2003년 처음 작성되기 훨씬 전부터 존재했습니다. 봇 구축이 핵심 부분입니다지속적 통합(CI). 그런데 CI라고 하면 오픈소스GitLab자동화된 빌드, 테스트 및 배포와 같은 다양한 CI 관련 작업과 결합하여 자신만의 Github와 같은 소스 코드 저장소 및 문제 추적기를 실행할 수 있는 훌륭한 도구입니다.
요약하자면create a completely discardable build environment, 그리고 귀하의 질문에 대답하십시오. 원하는 것을 수행하는 방법은 아주 많습니다. 그 중 다수는 다양한 Linux 배포판용으로 사전 패키지되어 제공됩니다(그러나 여전히 작동 방식과 구성 방식을 이해해야 합니다). 어려운 부분은 의미하는 바가 무엇인지, 필요한 기능이 무엇인지, 자동화하려는 기능의 정도를 정확히 파악하는 것입니다.
물론 또 다른 중요한 요소는 여기에 얼마나 많은 시간/노력을 투자할 가치가 있는지입니다. 예를 들어 홈 소프트웨어 연구실, 소규모 회사 또는 스타트업의 경우 이 도구는 업무 수행에 도움이 되지만 고용주는 그렇지 않습니다. 필요하다고 생각하시나요? 아니면 전체 개발팀이 필요하다고 생각하시나요? 아니면 회사 전체를 위한 대규모 프로젝트인가요?
추신: 제가 제공한 모든 링크가 특정 소프트웨어 프로젝트나 회사 페이지로 직접 연결되지 않고 Wikipedia에 대한 링크인 이유가 궁금하시다면, 이는 이 답변이 특정 소프트웨어에 대한 권장 사항이라기보다는 개념적 개요에 가깝기 때문입니다. Wikipedia 페이지에는 직접 링크가 있으며, 더 중요한 것은 유사한 소프트웨어, 소프트웨어 비교 페이지 및 상호 관련된 많은 개념에 대한 링크가 있다는 것입니다. 이것은 배우기 쉬운 답이 하나만 있는 쉬운 주제가 아닙니다. 더 많이 알수록 특정 요구 사항에 맞는 올바른 결정을 내리는 것이 더 쉬워집니다.