유료 소프트웨어 업데이트에 Apt 리포지토리 사용

주별 및 / 또는 월별 업데이트가있을 수있는 호스팅 / 사이트 웹 응용 프로그램에 소프트웨어 업데이트를 배포하는 방법을 결정하려고합니다. 온 사이트 제품을 사용하는 고객이 수동으로 업데이트하는 것에 대해 걱정할 필요가 없도록하기 위해 Chrome에서 자동으로 다운로드하여 설치하기를 원합니다. Ubuntu와 함께 소프트웨어를 설치하고 구성한 OVF 파일을 제공 할 계획입니다.

소프트웨어를 배포하는 방법에 대한 첫 번째 생각은 키를 사용하여 SSH를 통해 액세스 할 6 개의 Apt 저장소 / 채널 (이 시점에서 어떤 것이 더 좋을지 확실하지 않음)을 만드는 것이므로 고객이 구독을 갱신하지 않으면 계정을 비활성화 할 수 있습니다 :

1. 베타-테스트 데이터에 내부적으로 사용되어 패키지에 중대한 결함이 있는지 확인합니다.
2. 내부-라이브 데이터에서 내부적으로 사용되어 패키지 결함 여부를 확인합니다 (개 먹이 단계).
3. 외부 1-결함을 확인하기 위해 사용자 기반의 1 % (임의로 선택됨)에 배포합니다.
4. 외부 9-결함을 확인하기 위해 사용자 기반의 9 % (임의로 선택됨)에 배포합니다.
5. 외부 90-나머지 90 %의 사용자에게 배포됩니다.
6. 호스팅 됨-호스팅 된 환경에 배포됩니다.

문제가보고 될 경우 각 단계에서 다음 저장소로 이동하려면 사인 오프해야합니다.

커뮤니티에 대한 나의 질문은 :

1. 아무도 전에 이런 식으로 시도한 적이 있습니까?
2. 누구나 이런 유형의 절차에 대한 단점을 볼 수 있습니까?
3. 더 좋은 방법이 있습니까?

전반적으로, 나는 그 접근법을 좋아합니다. 불법 복제 문제는 전통적인 배포 방식이든 자동화 된 방식이든 관계없이 반박 할 수 없으며 라이센스 체계의 불편 함을 피할 수 있습니다.

무작위 선택에 문제가있을 수 있습니다. 비즈니스 관계의 전체 기간 동안 고객이 얼리 어답터로 선정 되었습니까? 그렇지 않다면 어떻게 외부 1에서 외부 9로 다운 그레이드를 실현할 수 있습니까?

소프트웨어의 일반 라이센스 및 전화 홈 유형 보호에 대해 생각해 보셨습니까?

여기에서 (라이센스없이) 보이는 문제는 한 달 동안 비용을 지불하고 중지 한 다음이 버전에서 계속 실행할 수 있다는 것입니다. 오래되었지만 무료입니다. 이 허점은 적어도 일부 사람들에 의해 악용 될 것입니다

라이센스가 이미있는 경우 실행하기 전에 라이센스를 확인해야하는 소프트웨어를 사용하여 간단한 보호되지 않은 리포지토리 만 있으면됩니다.

소프트웨어 및 / 또는 고객의 특성에 대해 잘 모르지만 테스트를 거치지 않고 업데이트가 설치되지 않는 곳이 많습니다. 많은 회사에서 시간이 초과되는 라이센스 키를 사용합니다. 업데이트를 다운로드하고 수동으로 시작하도록 허용하십시오. 자동 업데이트는 편리하지만 때로는 사용자가 놀라움을 좋아하지 않습니다.

OS X 용 Sparkle 프레임 워크를 살펴보면 Chrome 업데이트 메커니즘과 매우 유사하지만 사용자 의견을 제공하므로 업데이트를 건너 뛰거나 나중에 수행 할 수 있습니다. 나는 적어도 사용자에게 물어 보는 것이 가장 좋습니다.

나는 적절한 아이디어를 좋아하지만 그렇게하는 것이 합리적입니다.이 시점에서 간단하고 실제로 테스트가 잘되었습니다.

나는 당신이 묘사 한 것을 거의 정확하게하고있는 회사를 알고 있습니다. (당신이 묘사 한 것보다 더 적은 계층이며, 그들이 어떻게 인증하는지 모르겠습니다.)

그들이 가진 가장 큰 문제는 일부 고객이 어플라이언스에서 인터넷 액세스를 차단한다는 것입니다. 즉, 해당 고객은 설치 한 버전으로 고정되어 있습니다. 아마도 괜찮을 것입니다. 그들은 그 고객들과 방화벽 규칙을 개방하는 것에 대해 논의했다고 생각합니다. 다른 사람들은 방금 수동으로 업그레이드했습니다.

내가해야한다면 IP 주소를 기반으로 할 것입니다. 따라서 다운로드 할 때 해당 서버에 연결하려면 IP 주소가 허용 목록에 있어야합니다. 그렇지 않으면 다운로드 할 수 없습니다. 그들이 전용 IP를 가지고 있지 않으면 짜증 나지만 워크 스테이션을위한 서버 기반이라면 서버에서 이야기하고있는 것처럼 들리지 않을 것입니다. 내부에서 적절한 서버를 설치 한 다음 다운로드를 사용하는 것이 좋습니다 일주일에 한 번 cron 작업 또는 ftp를 통한 복사 등을 통해 복사 한 다음 워크 스테이션을 실제로 다운로드하십시오.

이것은 좋은 노련한 접근 방식입니다.

고려해야 할 몇 가지 함정 :

• 항상 1 %, 9 %, 90 %로 가고 싶지는 않을 것입니다. 고객이 동 질적이지 않을 수 있습니다. 즉, 지역, 장치 유형 등으로 전문화를 시작하려는 경우 전 세계적으로 1, 9, 90 %의 배포가 더 이상 의미가 없습니다.

• 90 %의 사용자를위한 단일 리포지토리를 사용하면 핫스팟 이 발생합니다. 즉, 서버는 대량의 요청을 겪게되므로 트래픽 급증시 가장 먼저 사망하여 90 %의 사용자가 중단됩니다. 물론 중복성이 도움이되지만 전체적으로 더 많은 비용이 발생합니다.

• 특정 기능을 모든 사용자의 90 %에게 배포 할 준비가 된 워크 플로가있을 수 있지만 전역 업데이트로 인해 90 % 채택 준비가되지 않은 기능이 프로덕션 환경에 적용되어 개발 워크 플로에 병목 현상이 발생합니다. 고정 배포에서는 이러한 문제를 효과적으로 처리 할 수 ​​없으므로 응용 프로그램 수준에서이를 처리해야합니다.

이를 해결하는 방법은 여러 서버에 프로덕션 저장소의 여러 사본을 유지 하고 구성 가능한로드 밸런서를 앞에 배치 한 다음 롤 단위로 프로덕션 저장소를 점진적으로 업데이트하는 것입니다. 다시 말해, 모든 리포지토리는 결국 동일하게 원하는 것으로 취급하지만 서버에서 읽는 사용자의 비율을 변경할 수 있도록 트래픽을 구성하십시오.

이점은로드 밸런서를 사용하여 원하는대로 요청 배포를 구성 할 수 있고 수평 적으로 확장 할 수 있다는 것입니다 (모든 기능이 100 % 채택 될 준비가되면 모든 서버가 동일한 리포지토리에 비례 적으로 서비스를 시작할 수 있음). 팀의 워크 플로 및 지역별 업데이트가 필요한 경우 다른 기능에 대해 걱정하지 않고 특정 기능을 즉시 사용할 수 있습니다.