Я ищу способы доставки нашего серверного решения заказчику. Чтобы клиент мог легко установить и испытать наше решение.
Наш набор серверных решений включает tomcat + webapp, memcached, db solution и так далее. Какой предпочтительный способ доставки серверного решения заказчику?
Я думаю о следующем.
Интересно, какое еще решение существует и в чем будет проблема среди трех вышеупомянутых вариантов.
Это немного зависит от целевой аудитории, но в большинстве случаев вам нужно решение, которое требует очень мало усилий для настройки и стабильно работает.
Чаще всего, когда поставщики предоставляют нам тестовые версии, они предоставляют нам полные образы дисков VMWare (vmdk файлы).
Они совместимы с VMWare и VirtualBox.
Это имеет большое преимущество в том, что вы в основном контролируете среду и можете хорошо ее протестировать, прежде чем передать ее.
Недостатком является то, что это не обязательно похоже на производственную среду или процесс установки (если вы не продаете бытовую технику).
Я не видел ни одного (коммерческого) поставщика, поставляющего коробки Vagrant.
Лично я бы не стал только предоставить коробки Vagrant, я бы опасался, что это напугает потенциальных клиентов, которые еще не используют Vagrant.
Я бы подумал о предоставлении как Vagrant и vmdk файлы.
Предоставление RPM - это здорово если это то, что вы в конечном итоге продадите покупателю.
Это позволяет группе администрирования также оценить процесс установки.
Конечно, для этого требуется очень хорошая документация с вашей стороны (требования, параметры конфигурации, ...).
Но я бы все равно предоставил vmdk образ.
Для быстрой оценки это просто самый беспроблемный способ (как для заказчика, так и для поставщика).
Amazon Cloud. Создайте свои серверы в облаке, после чего вы сможете создать образ с помощью Amazon Machine Images. Создайте дубликат, создайте для них учетную запись для входа и отправьте им учетные данные по электронной почте. Конечно, это работает, только если они довольны тестированием в облаке, а не на собственном оборудовании, но для вашего клиента это будет легко.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html
Учитывая ваши три варианта, я бы лично выбрал ваш вариант 2 и создал развертываемый пакет. Преимущество пакета здесь в том, что вам нужно будет отправлять только зависимости вашего приложения, а не всю ОС.
Обычно я использую системы на базе Ubuntu, поэтому я обычно создаю DEB, а не RPM. Учитывая, что вы упомянули RPM, я предполагаю, что ваш клиент использует разновидность Linux, которая может устанавливать пакеты RPM, но если вы не знаете целевую архитектуру, распространение tarball может иметь больше смысла. Поскольку вы используете Apache Tomcat, вы можете рассматривать эти архивы как хорошие примеры простой упаковки.
Подход с предварительно запеченными изображениями в принципе звучит очень хорошо, особенно если вы пытаетесь создать простую демонстрацию, с которой клиент мог бы поиграть. Несколько лет назад я рассматривал возможность поставки решения в качестве Виртуальное устройство но в конце концов решил, что лицензионная головная боль, связанная с упаковкой всей ОС, - больше хлопот, чем пользы. Например, вы можете столкнуться с проблемой лицензирования, поскольку одна из интерпретаций GPL будет заключаться в том, что для распространения Live CD Linux или образа Vagrant вам потребуется выпустить весь свой код под GPL (что, я полагаю, вы бы не хотели делать). Кроме того, вы не захотите нести ответственность за то, чтобы системные библиотеки на вашем образе диска были обновлены всеми соответствующими исправлениями безопасности. В идеале за безопасность сервера времени выполнения должен отвечать ваш клиент, а не вы.
Если вы решите создавать RPM и строить с Maven, я могу порекомендовать JDeb и RVM плагины maven, они великолепны. FPM также удобный инструмент для работы с менеджерами пакетов.