Використання Apt-сховища для оновлених платних програм

Я намагаюся визначити спосіб розповсюдження оновлень програмного забезпечення для розміщеного веб-додатку, розміщеного на сайті, який може мати оновлення щотижня та / або щомісяця. Я не хочу, щоб клієнти, які використовують продукт на місці, турбувалися про оновлення вручну, просто хочу, щоб він автоматично завантажував та встановлював ala Google Chrome. Я планую надати файл OVF з Ubuntu та встановленим та налаштованим програмним забезпеченням.

Моя перша думка про те, як розподілити програмне забезпечення - це створити шість сховищ / каналів Apt (не впевнений, що було б краще в цей момент), до яких можна отримати доступ через SSH за допомогою клавіш, тому, якщо клієнт не поновить свою підписку, ми можемо вимкнути його рахунок :

1. Бета-версія - використовується внутрішньо на тестових даних для перевірки пакета на наявність основних дефектів.
2. Внутрішній - Використовується всередині даних живих даних для перевірки пакета на наявність дефектів (етап харчування собак).
3. Зовнішній 1 - Використовується до 1% нашої бази користувачів (вибрано випадковим чином) для перевірки на наявність дефектів.
4. Зовнішній 9 - Використовується до 9% нашої бази користувачів (вибрано випадковим чином), щоб перевірити наявність дефектів.
5. Зовнішні 90 - Застосовуються для решти 90% користувачів.
6. Розміщено - розміщено в розміщеному середовищі.

Буде відмінятися на кожному етапі, щоб перейти до наступного сховища, якщо буде повідомлено про проблеми.

Мої запитання до громади:

1. Хтось раніше пробував щось подібне?
2. Чи може хтось бачити недолік цього виду процедури?
3. Чи є кращий спосіб?

Загалом, я люблю підхід. Питання піратства ні в якому разі не можна протидіяти традиційному розповсюдженню чи автоматизованому, і ви можете уникнути незручностей у схемі ліцензування.

У вас можуть виникнути проблеми з випадковими виділеннями. Чи вирішив клієнт бути достроковим приймачем протягом усього періоду ділових відносин? Якщо ні, то як можна здійснити перехід від зовнішнього 1 до зовнішнього 9?

Чи задумалися ви про загальне ліцензування та захист домашнього типу для свого програмного забезпечення?

Проблема, яку я бачу тут (без жодного ліцензування), полягає в тому, що я можу заплатити протягом місяця, зупинити, а потім просто продовжувати працювати на цій версії. Впевнений, його старий, але безкоштовний. Цю лазівку будуть експлуатувати принаймні деякі люди

Якщо у вас вже є ліцензування, просто створіть прості незахищені сховища з програмним забезпеченням, яке вимагає перевірити ліцензію перед запуском

Я недостатньо знаю про ваше програмне забезпечення та / або характер ваших клієнтів, але в багатьох місцях оновлення не встановлюються без тестування. Багато компаній використовують ліцензійний ключ, який закінчиться. Дозвольте їм завантажити оновлення та розпочати вручну. Автоматичні оновлення зручні, але іноді користувачі не люблять сюрпризів.

Погляньте на рамку Sparkle для OS X, вона дуже схожа на механізм оновлення Chrome, але надає відгуки користувачів, щоб вони могли пропустити оновлення або зробити це пізніше. У мене було оновлення програм і я міняв функціонал, який мені потрібен, як завжди, завжди краще, принаймні, запитати користувача.

Мені подобається влучна ідея, хоча є сенс зробити це саме так, це просто і справді, дуже добре перевірено на цьому етапі.

Я знаю про компанію, яка робить майже точно те, що ви описали. (Менше ярусів, ніж ви описали, і я не знаю, як вони підтверджують автентичність.)

Найбільша проблема у них полягала в тому, що деякі клієнти блокують доступ до Інтернету зі свого пристрою. Це означає, що ці клієнти просто заблоковані до встановленої ними версії. Можливо, це добре. Я думаю, що вони обговорювали відкриття правил брандмауера з деякими з цих клієнтів. Інші просто модернізували вручну.

Якби я це зробив, я би робив це на основі IP-адреси. Отже, коли вони завантажуються, їх ip-адреса повинна знаходитись у списку дозволених для підключення до цього сервера, інакше вони не можуть завантажити. Це відстійно, якщо вони не мають виділеного ip, але навряд чи з того, що це звучить, як ви говорите, якщо це сервер, якщо він працює для робочих станцій, то вам може бути краще налаштувати їх там, де є власний підходящий серверний будинок, а потім завантаження копія через роботу в Cron або щось понад ftp тощо. раз на тиждень, а потім завантажуйте робочі станції звідси.

Це хороший витриманий підхід.

Деякі підводні камені, які слід врахувати:

• Ви не завжди можете піти на 1%, 9%, 90%. Ваші клієнти можуть бути не однорідними, тобто ви можете почати спеціалізуватися, скажімо, за регіонами, за типом пристрою тощо. У цьому випадку розподіл на 1, 9, 90 відсотків у всьому світі вже не має сенсу.

• Маючи єдине сховище для 90 відсотків ваших користувачів, вводиться гаряча точка - цей сервер відчує більшу частину запитів, а це означає, що він першим загине у випадку збільшення трафіку, що спричинить аварію для 90 відсотків ваших користувачів. Скороченість допомагає, звичайно, але це загалом збільшує витрати.

• У вас може бути робочий процес, коли певні функції готові до розповсюдження до 90 відсотків усіх користувачів, але глобальне оновлення призведе до того, що функції, не готові до 90-відсоткового прийняття, потраплять у виробництво, вводячи вузькі місця у робочий процес розробника. Фіксований дистрибутив не зможе ефективно впоратися з цими проблемами, змусивши вас це впоратися на рівні програми.

Спосіб виправити це - збереження декількох копій виробничих репостів на різних серверах, розмістіть перед ним настроюваний балансир навантаження , а потім ретельно оновлюйте виробничі репозиції поступово на постійній основі. Іншими словами, ставитесь до всіх репостів як до того, що вони хочуть бути однаковими, але конфігуруйте трафік, щоб відсоток користувачів, які читали з сервера, мінявся.

Перевага полягає в тому, що ви можете налаштувати розподіл запитів за бажанням, використовуючи балансир завантаження, ви можете масштабувати горизонтально краще (всі ваші сервери можуть почати пропонувати пропорції пропорційно пропорційно, якщо всі функції готові до 100-відсоткового прийняття), і, залежно від того, як ваш Робочий процес роботи команди та ваша потреба в оновленнях, що стосуються конкретних регіонів, ви можете з часом дозволити доступ до певних функцій, не турбуючись про інші функції.