Comments 27
И мы не можем использовать профессиональные IDE, такие как IntelliJ IDEA, Eclipse или Apache NetBeans IDE
Автор преувеличивает. Почти всегда можно подключиться удаленно. Исключения в моей практике выглядят например так: есть кластер, ну скажем Hadoop, и ваше приложение запускается на неизвестном заранее узле. Вопрос тут не в том, чтобы подключиться из IDEA, а скорее в том, чтобы понять, куда именно из узлов, и какие порты там не заняты. Ну т.е. это скорее неудобно, а не невозможно — причем если вы решите через jdb это проделать, то у вас ровно такие же проблемы будут.
Почти всегда можно подключиться удаленно.
Почти никогда нельзя, если в компании есть ИБ.
И вообще не понимаю, при чем тут пром? Если у вас нет доступа на хост — то запустить там jdb вам точно не дадут, как и подключиться отладчиком. То есть на то о чем автор пишет, это не влияет.
Для приложений Java типичными производственными и тестовыми машинами являются серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки.
Ну т.е. подразумевается, что доступ к среде у вас есть, но UI нет. Вот это на мой взгляд и неправда. Если у вас есть доступ к среде — что вам помешает идею запустить удаленно? У меня всю мою практику работы на компании все тестовые машины были без мониторов, и без графического интерфейса — и это никогда не мешало запустить там скажем firefox, или идею, и отладчиком подключиться. Если вы можете зайти по ssh — почему вы не можете графические приложения запускать, какая тут связь? X server скажем кто-то отменил, который на машине клиента запускается?
А если вам ИБ запрещает доступ к пром среде — так авторская идея использовать там инструмент командной строки тоже выглядит глупо, потому что в пром среде вам не разрешат перезапустить приложение с включенной отладкой. Более того, скорее всего это вовсе даже не ИБ сделает, а просто поддержка.
Ну значит ты везунчик без ИБ или сидишь на микропроекте. К примеру на моём где инфраструктура вся в США даже просто удалённого доступа для простых разрабов нет, чтобы запустить из консоли дебаггер, прямой коннект запрещён не то, что к базе, даже к некоторым серверам. хочешь что-то посмотреть - дуй в удалённый рабочий стол - citrix, от туда кстати и запускают шел для конекта (кому согласовали). со своей тачки у тебя есть прямой доступ только к стейджингу, бамбу, стэшу и спланку, и, кстати, я думаю, что только так и правильно. При этом я не могу сказать, что у нас прям супер продвинутый или защищённый заказчик, скорее люди просто выполняют рекомендации по защите инфраструктуры. Майкрософтовские креды кстати тоже смогли везде интегрировать, куда бы ты не захотел залогиниться - везде будут именно твои стандартные креды. Ну а если у вас не так, значит у вас дыра и проходной двор
Ну да, микропроект — в отделе примерно 750 человек, и еще так было в десяти предыдущих банках :) Если бы вы читали предыдущие комменты, вы бы увидели, что это не одиночный случай.
Нет, я просто сотрудник банка, и ИБ в том числе понимает, что для работы доступ нужен. Это кстати не значит, что он есть вообще у всех — а именно у тех, кому нужно по работе.
Это вполне логично. Но не универсально на 100%.
>Если надо отлаживать на проде, то разработчики и/или QA облажались.
Или безопасники ошиблись в своих оценках. Например, в наших условиях нет возможности сделать тестовые стенды, хотя бы немного похожие на пром — ну или это очень дорого обойдется (даже не считая того, что большую часть времени они будут простаивать). А если даже это и сделать — то для поддержания их в актуальном состоянии придется удвоить размеры команд. Так что некоторые проблемы у нас воспроизводятся строго на проме, потому что только там есть правильные версии всех зависимостей.
>Кроме того, они считают, что чем меньше людей имеет доступ к проду, тем проще предотвратить или хотя бы обнаружить утечку персональных данных клиентов.
Ну и это логично. Поэтому доступ к прому не с рабочих машин, а с виртуалок, где все действия логируются и т.п. Причем я бы сказал, что это тоже всегда так было на практике — т.е. я могу вспомнить такое примерно в 2009.
"Так что некоторые проблемы у нас воспроизводятся строго на проме, потому что только там есть правильные версии всех зависимостей."
ух, по-моему вы сами себя нарочно закапываете, учитывая сколько людей работает я вот никак не поверю, что никого нельзя загрузить в свободное время в конце спринта на приведение инфраструктуры в порядок. хотя вспоминаю как сам короткое время работал над российским банковским проектом и там тоже никто не парился насчёт мок сервисов например. трудозотраты небольшие, а страдали из-за их отсутствия все.
Я даже не могу поставить такую же версию Оракла — потому что текущая поддерживаемая например 12g, а на проме у коллег стоит 11g, и мне ее просто негде взять — так же, как и линуксы идентичной версии, «как на проме». В итоге тестового стенда Оракла 11g нет и не будет.
Я уже не говорю про то, что стенды разработки по железу примерно на порядок меньше промышленных. Вы предлагаете рядом поставить второй идентичный набор стоек? А платить кто будет, вы?
значит в вашем банке огромная дыра в информационной безопасности, вот и всё :) ну и безопасники ваши оказались слишком нежные, раз их получилось прогнуть на такое. есть кстати ещё разные тулы для понимания что как работает в связке, под аббревиатурой APM, у нас к примеру используется dynatrace, хотя опять, доступ по итогу дали только девопсам. в принципе за всё время работы я не могу вспомнить случая, когда мы бы не смогли по коду понять что не так в коде, достаточно логирования sql запросов, чтобы понять какие данные пришли, дальше глянуть по коду что получилось по итогу и почему. в принципе конечно было бы проще сразу дебагером тыкнуть на стейджинг дате и том, что репортали тестеры, но по факту пошевелив мозгами всегда понимали в чём дело ну за день точно. в крайнем случаи просто делали временные комиты в которых было логирование подозрительных участков.
В чём проблема пробросить себе на локальную машину этот самый 5005 порт (например, через ssh туннель) и подключиться любой нормальной ide? Зачем запускать отладчик на самом сервере?
Автор же пишет про то, что «серверы Linux без графического интерфейса, поэтому доступны только инструменты командной строки» — при этом забывая, что для отладки графический интерфейс на той же машине, где работает JVM, вообще говоря не нужен, потому что идея может работать удаленно на другой машине. А если запрещены туннели, или нет доступа — то с большой вероятностью вы не можете сделать и вот это:
java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 Test
Во-первых, потому что никто вам не даст рабочие скрипты запуска менять, даже наличие доступа не означает наличие доступа на запись, и во-вторых, приложение может работать 24х7, а чтобы в командной строке вот это вот задать — нужно рестарт.
может проблема в том, что сервер не в вашей сети, а к вам прокинут тоннель и доступен вам только обычный http/s? обычная ситуация для аутсортса кстати
Отладка Java-приложений из командной строки