Тестируйте на конфигурации, приближенной к реальной

На той неделе я ездила к заказчику разворачивать билды. Допустим, я должна была поднять:

• http://testbase.ru/ — сервис testbase
• http://bugred.ru/ — сервис bugred

Тестировщик-внедренец? 

Почему бы и нет

Исходно я знала, что разворачивать буду 6 стендов — по три на каждый сервер (DEV, TEST, UAT). Там будет стоять "голый" линукс, redhat 7, java 8 и «ванильные» wildfly 10 — это те, которые скачаны с официального сайта. Мы их уже сконфигурили под свои сервисы и обычно отдаем уже готовые сборки, но политика безопасности и все такое...

Это немного волнительно — я давно уже не выезжала на внедрение. А тут еще и настройка «ванильного» wildfly, инструкция немного сложнее. Больше возможностей где-то налажать, в общем ))

Разумеется, вначале надо проверить все инструкции на своей стороне. Развернуться на «голых» стендах. Проверить, какие команды на линуксе должны работать, вот это все. Ставлю задачу админу — «сделать стенд dev-testbase, "голый" линукс, java 8 и «ванильный» wildfly 10». Я знала, что у нас будет redhat 7, но не сочла нужным добавлять это в описание задачи. Линукс и линукс, какая разница, какая версия? Наверняка седьмая бай дефолт и ставится... Оказалось, что «бай дефолт» ставится шестая версия, и админ развернул мне стенд с центосью 6 (Redhat — платный дистрибутив, а CentOS — бесплатный аналог). Казалось бы, ну как это повлияет? Wildfly то тот же.. Но вы уже, наверное, догадались об ответе на этот вопрос 😁 Версия линукса — влияет...

См также:

Настройка сервисов wildfly10 для redhat 6, 7 и debian 6 — выписала отличия 6 и 7 версий

На момент развертывания на dev-testbase я, однако, была в счастливом неведении. Я все развернула, хотя не совсем я... Муж-линуксоид помог 👀 Оказалось, что наша инструкция уже не совсем актуальная, вот и проапдейтила заодно! Теперь я была спокойна — на внедрении просто пройдусь по тем же шагам и все будет хорошо. Ага... Конечно...

Среда

Я приехала к заказчику в 10 утра. Меня проводили к рабочему месту:

— Ваш куратор сказала, что ближайшие пару-тройку дней вы посидите здесь.

В ответ я только улыбнулась:

— Пару-тройку?! Да вы что, я надеюсь управиться сегодня!

Мне надо было показать, как это настраивается, поэтому решила так: сначала я настрою один сервер, перепроверю, что инструкция сработает. Потом при коллегах настрою еще один или сразу оба оставшихся.

Сижу себе, настраиваю. Все вроде хорошо. Пока я все не доделала. Запускаю сервер... А в консоли вместо [ok] минута ожидания и... failed!

# service testbase start

... [failed]

А-а-а-а-а-а! Как это failed?! Что делать, что делать..

Все пропало, не работает!

Открываю WSDL сервиса — хммммм... Работает!

Может, просто статус не смог определить? У меня такое было, когда сервер стартовал больше минуты. Статус failed, хотя сам работает. Хммм, ну ладно, разберемся.

Зову коллег, показываю, как настраивается. Ставим сразу на два стенда. Все вроде хорошо. Решаем сразу и bugred поставить. Ставим-ставим-ставим, все по прежнему. Сервер поднимается, хоть и пишет failed.

Тут мы замечаем, что часть функционала не работает, потому что ошиблись в параметре внутри standalone.conf. Исправили, ребутаем сервис

# service bugred restart

Restarting factor (via systemctl):  Job for bugred.service failed because the control process exited with error code. See "systemctl status bugred.service" and "journalctl -xe" for details.
                                                           [FAILED]

Эээээ, как так?? Попробуем еще раз.

# service bugred stop

stop [ok]

А если проверю?

# ps aux | grep java

1024 bugred ...

Хмммммм... Сервис НЕ останавливается! Хотя и пишет ok... Попробовали так-сяк потыкать, не срослось. Ладно, говорю, пока прибьем (kill, куда без него), проверим работоспособность при правильной настройке, а потом я буду разбираться с сервисами.

Убили процесс, донастроили, запустили — все ок! Только разобраться бы, что с сервисами не так. Коллеги разошлись по своим местам, а я стала искать причину ошибки. Написала в общий чатик нашего проекта, вдруг кто сталкивался?

Выполнили эти команды

systemctl status bugred.service

journalctl -xe

Обнаружили, что он не там ищет PID

systemd[1]: PID file /var/run/wildfly/wildfly.pid not readable (y...rt.

systemd[1]: bugred.service start operation timed out. Terminating.

Да, /var/run/wildfly не существует. Потому что есть /var/run/bugred/wildfly.pid. Залезла в  init.d скрипты, но нет, там указано через переменную

# Load JBoss AS init.d configuration.

if [ -z "$JBOSS_CONF" ]; then

JBOSS_CONF="/etc/default/${WILDFLY_NAME}.conf"

fi

Переменная верная. Попробовала заменить на жесткое условие

# Load JBoss AS init.d configuration.

if [ -z "$JBOSS_CONF" ]; then

JBOSS_CONF="/etc/default/bugred.conf"

fi

Не помогло 😕

В итоге коллеги как раз и подсказали, что проблема в версии ОС. Что у нас в офисе стоит центось 6 и "видимо, она отличается от 7". Решили поэкспериментировать позже у нас или спросить у здешних админов. Но время рабочего дня подходило к концу, а в тот день я не могла больше задерживаться, поэтому уехала, оставив развернутыми только 4 из 6 серверов.

Четверг

На следующий день я приехала пораньше в гордой уверенности, что "щас вот в 8 приеду и до 10 все закончу". Ага... Там нашлись потом другие баги, которые я фиксила до вечера. Но на третий день уже не осталась! К моменту моего ухода все шесть серверов работали как часы 😀

Ближе к обеду я закончила с основными проблемами и наконец обратилась к местым админам. Вдруг они знают, как настраивать редхат 7? Оказалось, знают :-) Админ показал мне разницу  что скрипты берутся из разных мест:

• redhat 6 - JBOSS_HOME/docs/contrib/scripts/init.d
• redhat 7 - JBOSS_HOME/docs/contrib/scripts/systemd

В папке systemd лежал Readme, так что выполнить его было довольно легко. Правда, вначале пришлось подчистить за собой и удалить все, что было сделано по инструкции для 6 оси — init.d скрипты.

К этому моменту я уже подняла все 6 серверов, так что подчищать пришлось все... Но ничего, зато запомнилось! Как оказалось позднее, я и в скайпе не в тот чатик писала, в нашем чатике админа то нет. А наш админ тоже знал, что в семерке все немного по другому. Эх! Знал бы прикуп... Все равно бы приехал в четверг ))) Потому что помимо настройки сервисов были и другие проблемы. 

Но зато запомнилось! И это мне помогло чуть позже)) Буквально через пару дней уже другой заказчик переезжал на линукс. И вот он начал мне описывать проблемы — сервис стартуем, а статус failed, пытаешься остановить, а он продолжает работать... Если бы не мое внедрение в среду и четверг, я бы не знала, что ответить. А без доступа еще и консультировать тяжело. Искали бы по всему офису линуксоидов-вангователей, «найду проблему по скрину». А так я уже знала ответ, едва услышав о симптомах! Так что все быстренько настроили ))) Нет худа без добра! 

Выводы

Всегда тестируйте на конфигурации, приближенной к реальной. Если линукс, то какой версии? С какими правами? Оракл? А оракл какой версии? А java? А что исходно на машине установлено? А какие у тебя права?

Ведь как оно обычно бывает — у разработчика все работает, а у пользователя на немного другом стенде косяк! Чтобы выявить его заранее, надо проверять на тех же условиях. В рамках разумного, конечно, повторить боевой сервер, на котором развернуты дорогие платные дистрибутивы, не получится. Но все, что можно настроить — настройте так, как оно будет потом работать.