Debian 패키지를 사용하여 Debian 기반 서버에 소프트웨어(웹 애플리케이션)를 배포하고 싶습니다. 이 질문의 범위를 벗어나는 이유로 인해 Docker(또는 Heroku와 같은 PaaS)를 사용하면 이 문제를 완전히 피할 수 없습니다.
설정은 매우 간단합니다. 일부 소스 코드가 포함된 Git 저장소가 있습니다. 우리는 브랜치에서 작업하고 코드를 로컬에서 실행합니다(여기에는 Debian 관련 항목이 없습니다. 실제로 개발은 다양한 운영 체제에서 수행됩니다). 브랜치에 만족스럽게 커밋하고 CI 테스트가 실행되고 검토되고 마스터에 병합될 때까지 기다립니다. .
마스터로 병합한 후 데비안 서버에 배포하려고 합니다. 현재 이 작업은 파일을 올바른 위치로 이동하고 올바른 서비스를 다시 시작하는 셸 스크립트를 통해 "수동으로" 수행됩니다. 이는 여러 가지 이유로 취약하며(스크립트가 중간에 실패하여 프로덕션 서버가 일관되지 않은 상태로 남을 수 있음) 더 나은 것을 원합니다.
데비안 패키지는 좋은 솔루션처럼 들립니다. 여기에는 파일 복사, systemd 서비스 (다시) 시작 등과 같이 배포 스크립트를 통해 현재 수동으로 수행하는 많은 작업에 대한 처리 기능이 내장되어 있습니다. 또한 CI/CD 시스템(Azure DevOps)에는 다음과 같은 개념이 있습니다.문화 유물저장되고 언제든지 수동으로 재배포할 수 있으므로 .deb전체 애플리케이션을 포함하는 아이디어에 적합합니다.
내가 본 문제:
- 데비안은 배포판과 버전의 개념을 고수합니다. 우리의 경우에는 버전이 없고 필요하지 않습니다. 우리가 관심을 갖는 것은
master현재 브랜치에서 무엇이든 배포할 수 있다는 것입니다..deb파일 자체는 SSH를 통해 쉘 스크립트를 통해 복사되고 편집되므로 다음 과 같은dpkg작업에 사용됩니다. APT 저장소의 버전 제어를 유지하는 것은 관련이 없습니다. - 데비안은 변경 로그를 관리합니다. 우리는 이를 수동으로 유지하고 싶지 않습니다.
gbp dch --ignore-branch -S하나는 우리를 위해 생성되지만 모든 커밋을 하나의 "변경"으로 압축하고 여전히 버전 문제를 해결하지 못합니다. - 대부분의 도구와 문서에서는 "데비안" 부분이 자체 저장소인 버전이 지정된 소스 타르볼이 있다고 가정합니다. 버전에 대한 개념이 없었을 뿐만 아니라 애플리케이션의 소스 코드와 데비안 패키징 도구가 모두 동일한 저장소에 있었습니다.
질문:
- 처음에는 이게 좋은 생각이었나요?
- 버전 및 변경 로그 개념을 어떻게 완전히 무시/해결할 수 있습니까?
- 패키지 설치와 업그레이드 간의 차이를 계속 유지할 수 있습니까? 내 응용 프로그램에는 다른 설치를 업그레이드할지 아니면 처음부터 새 설치를 시작할지에 대한 논리가 다릅니다(예: 새 설치에서 응용 프로그램은 수동으로 생성해야 하는 구성 파일에 의존하므로 systemd 서비스를 자동으로 시작하는 것은 옵션이 아닙니다. 그러나 업그레이드 중에는 구성 파일이 이미 존재한다고 가정하므로 서비스가 이미 시작된 경우 다시 시작해야 합니다.