Насколько болезненной может быть миграция с Linux на OpenSolaris?

Question

У нас есть бизнес-приложение, которое в основном работает в независимом от ОС стеке (tomcat + java + mysql), но мы всегда запускаем его redhat или centos.

Есть клиент, который настаивает на том, чтобы запускать его на opensolaris по своим собственным причинам (дорогостоящее соглашение Sun с поддержкой «все включено»).

Насколько болезненной может быть такая миграция? У нас есть много конфигурационных файлов и сценариев поддержки, таких как:

• апач
• Разъем apache / tomcat
• взаимодействие с почтой с постфиксом
• индивидуальный запуск / остановка обслуживания
• пара заданий cron (резервное копирование, мониторинг)
• разные пользователи и разрешения (java, mysql, электронная почта, резервное копирование ...)

Наш процесс сборки выводит файл .tar.gz с нашим бизнес-кодом + некоторые сценарии оболочки, которые редактируют все файлы конфигурации os.

Любой предыдущий опыт по этому вопросу.

Answer 1

Мы запускаем оба, хотя мы не используем OpenSolaris в качестве веб-серверов.

Хорошее:

• OpenSolaris поставляется с инструментами gnu, так что сделайте правильный путь, и все в порядке.

• Большинство вещей просто создаются и работают просто отлично.

Не очень хорошо:

• Убедитесь, что вы установили и используете bash. В противном случае все те удары, которые вы используете, которые, как вы думали, вы не используете, будут кусать вас.

• Убедитесь, что вы не используете жестко закодированные пути к / usr / bin или / bin. Эти инструменты не являются GNU и поэтому имеют разные опции. Используйте / usr / gnu, как указано выше.

• У вас нет огромного количества пакетов, которые вы можете установить сразу, как вы делаете это с помощью yum или apt. Да, у вас есть менеджер пакетов, просто он не так хорошо заполнен. В результате вы, вероятно, будете устанавливать пакеты вручную. Они должны установить, это просто немного больше работы для системных администраторов.

• Вы уверены, что OpenSolaris хорошо работает на вашем оборудовании? Это стоит проверить. Вы можете обнаружить, что некоторые драйверы оборудования не так хорошо протестированы.

В противном случае мы находим OpenSolaris хорошим. У него много хороших идей.

Вы смотрели на Nexenta - http://www.nexenta.org/os Это ядро ​​OpenSolaris с пользовательским пространством Ubuntu.

Answer 2

Самые большие проблемы будут с нестандартными (нестандартными) параметрами, которые вы использовали для инструментов GNU, предоставляемых в Linux, которые не входят в стандартные команды Solaris. Вы можете решить, что портировать соответствующие инструменты из набора GNU проще, чем модифицировать вашу систему. Если вы добавили в код абсолютные пути к командам (/usr/bin/ls), но решили вместо этого использовать версии GNU, вам нужно найти способ исправить их. Я был бы крайне осторожен с заменой версий OpenSolaris на версии GNU; Вы не знаете, когда вы сломаете что-то, на что опирается система. Таким образом, вы бы поместили команды GNU в отдельный каталог - вероятно, не /usr/local, потому что это должны заполнять владельцы компьютеров, а не вы как поставщик приложений, - и организовали бы их использование вместо системных команд. (Примечание: в Solaris /bin является символической ссылкой на /usr/bin; я предполагаю, что то же самое относится и к OpenSolaris.) AFAIK, Postfix не является стандартным для OpenSolaris, поэтому вам также необходимо убедиться, что он установлен.

Все это выполнимо - нет ничего непреодолимого. Но многое зависит от вашей кодовой базы.

Answer 3

OpenSolaris уже включает все утилиты GNU, просто укажите ваши сценарии на / usr / gnu / bin

Установка Postfix не должна представлять никаких проблем, и Apache / MySQL присутствуют в базовой установке OpenSolaris (на самом деле, материал Cool Web Stack делает его таким же простым в администрировании, как WAMP / Instant Rails). Помимо этого, проявляется SMF (SMF является заменой для сценариев rc, вроде как launchd OSX, хотя вы все еще можете использовать обычные сценарии инициализации), что может упростить вашу жизнь, поскольку указание зависимостей и порядка выполнения несколько лучше (рекурсивно запускается остановите также все зависимые службы).

Tomcat определенно работает, хотя все, кого я знаю по OpenSolaris, используют GlassFish. YMMV, но развертывание .war практически одинаково везде.

Это может быть неплохим первым шагом для развертывания в зоне под брендом LX (для сравнения рассмотрим тюрьмы FreeBSD или Linux vServer), поскольку зоны под брендом LX могут запускать двоичные файлы Linux и явно основаны на CentOS / RHEL. *

Кроме этого, OpenSolaris - это Xen dom0, начиная с b77 или чего-то подобного, и поместить CentOS / RHEL в domU очень просто, если это вариант.

Вы также получаете все полезные свойства Solaris (DTrace, ZFS, виртуализация сети [через CrossBow] и т. Д.). Кто знает? Вам может даже понравиться это! Java - это Java, так что это не должно вызывать проблем.

Answer 4

Помимо того, что вы тролль, кто-то только что сказал выше, что (Open) Solaris имеет: - ZFS - DTrace

Мы можем понять, что вы боитесь не потерять работу в RHCE, но вы просто еще раз доказали мне, что мое решение как работодателя игнорировать все сертификаты при опросе людей было хорошим. Кажется, что большой процент таких людей (особенно в мире Microsoft) не настолько ... непредвзято, мягко говоря.

С уважением, Alex

Answer 5

• вам, вероятно, придется переписать большую часть ваших сценариев (создание пользователей, запуск службы), поскольку она, вероятно, отличается в CentOS и OpenSolaris.

• как написано ранее, попросите вашего клиента установить инструменты GNU, чтобы у вас было меньше работы по переписыванию ваших сценариев.

• Файлы конфигурации os также могут быть не в том же формате, вам нужно проверить.

• Ваш файл tar.gz должен быть извлечен без проблем, но опять же у вас будет меньше сюрпризов, если вы используете инструменты GNU. некоторые ОС Unix имеют tar с некоторыми ограничениями

Любой предыдущий опыт по этому вопросу.

(возможно, немного оффтоп)

мы упаковываем и распространяем наше приложение java / tomcat / postgresql / unix со всеми двоичными файлами, указанными в наших скриптах. это подразумевает наличие 1 системы сборки для каждой поддерживаемой нами ОС, это подразумевает, что мы поддерживаем наше приложение, но также и внешние двоичные файлы, но, в конце концов, у нас нет неприятных сюрпризов для клиентов.

мы также просим их выполнить все корневые операции (создание пользователя, создание каталога, настройка sendmail, настройка системы) перед установкой приложения. мы написали сценарии выключения / запуска для всех поддерживаемых ОС, и их установка - единственное, что мы делаем в root на компьютере клиента.