Спасибо за инфу, но мы не рулим дженкинсом через XML.) Так наверное можно было подумать, когда я упомянул IaC, но IaC дженкинса не касается. В заметке приведен просто частный случай динамического изменения значения параметров задания.
Если Вам известен другой способ динамического заполнения Choice parameter значениями из внешнего источника — поделитесь, пожалуйста. Заранее спасибо.
— При миграции на новую версию ESXI, обязательно надо сделать Upgrade Hardware и обновить vmware tools, такие же непонятные зависания были вплоть до розового экрана.
Миграции не было. Была чистая установка ESXi, создавалась с нуля машина и в нее ставилась чистая винда.
Переход от сетевки E1000 на VMXNET3, сразу глюки прекратились.
Неа. После запуска машина повисла через 15 минут. После чего виртуалка была перенесена в ту самую времянку, которую раскатал для просмотра мастера.
На новом месте пока полет нормальный.
Но это еще ничего ни о чем не говорит.
Ну, как-то «получилось запустить» — это громко сказано… Установил и запустил без всякого конфигурирования, оптимизаций и прочего. Все шаги, что я выполнял — в статье. Никаких дополнительных действий не выполнял.
Правда, это не полноценный ELK, ибо Logstash отсутствует, Filebeat отдает данные напрямую в ES.
При этом типичное потребление ресурсов вот такое:
Вы имеете в виду virtual appliance? Если его, то нет.
Если имеете в виду готовое решение, то оно есть, но у меня не заработало по причине, указанной в комментарии выше:
трафр не идет на той сборке debian из за отсутствия архитектуры и библиотек (после доставления хорошо работает<...>)
Вы меня заинтриговали). В чем выражается плохая работа ES, если он один? И что именно нужно подкрутить у джавы, и что будет, если этого не сделать?
Касаемо второго пункта — это прекрасно, но чтобы создать пакет развертывания, сначала нужно, чтобы оно хотя бы заработало после установки ручками, и именно этот процесс я описал).
IDS/NMS это только обнаружение и мониторинг.
IPS это тема для отдельного разговора. И в этом разговоре, разумеется, не будет размахивания шашкой на каждый алерт.
ESXi и есть. Если бы они были на одном хосте, то задача зеркалирования порта была бы решена силами vSwitch'а, да… Вообще, я сторонник принципа keep it simple, и если задачу можно решить минимумом привлеченных ресурсов, значит так ее и надо решать).
Да, я просмотрел это видео. Мне оно показалось несколько поверхностным, оно скорее как источник вдохновения для реализации такой связки на базе готового решения SELKS. У меня SELKS5 тоже участвовал в ходе поиска решения, но мне его не удалось завести с trafr, видимо, потому что плохо старался). В итоге описанное в моей статье решение лично для меня оказалось более простым и понятным, хотя, как я отметил в заключении, и не лишенным недостатков.
Есть доля истины в ваших словах). Но лично для меня так сложилось, что ковырнув конфиг, раскиданный по таблицам, именованным по выполняемому функционалу, картинка в голове сложилась быстрее и воспринимается более слитной. При этом и понимание сделанных ранее конфигов в XML улучшилось, нашел косяки. И в целом, база данных лучше располагает к массовым правкам благодаря SQL-запросам. Мне пока что нравится больше.
И коллегам, которые на подхвате, и которые по сравнению со мной много дальше от консоли и XML, веб-морда заходит лучше. В свете необходимости делегировать им админские функции это несомненный плюс.
В подобных авралах заставляю себя и руководство компании остановить и не делать поспешных «хоп, хоп и в продакшен», 1-2 дня все таки лучше затестить и выяснить чего на самом деле надо сделать и чего хочется.
Вы немножко превратно истолковали слово «продакшн». Речь шла о другом: бывают ситуации, когда надо просто дать ответ «да» или «нет», и дать его очень быстро. Именно тот факт, что FS заработал и обеспечил тот же функционал, что и существующая телефония, и стал критерием того, что именно FS пошел в продакшн, а не Asterisk. Не было никакого резона домучивать Asterisk до работоспособного состояния, когда изначально FS буквально взлетел. А собственно нюансы конфига будут уже вдумчиво допиливаться уже когда телефония будет поднята на новом месте и в масштабах хотя бы 100 абонентов.
Консоль это конечно хорошо, но ведь будут новые сотрудники которые будут админить и через gui легче показать, как создать учетку, поменять аудиозапись на ivr или приветствие.
Позволю себе не согласиться. Через консоль это показать легче, чем через гуи. Когда приходишь на новое место, чисто физически невозможно запомнить вообще все новое. Лично я записываю. И если буду обучать кого-то, то тоже заставлю записывать, если начнут переспрашивать. И писать конспекты о том, какую закладку открыть, какую кнопку нажать и какую галку поставить менее эффективны, чем консольные команды.
У вас же не вызвало сожаления (наверное) что я конфиг микротика привел именно в консольных командах, а не сериями скриншотов окон WinBox'а. Скриншоты требуют и вглядываться в себя, и не дай бог галочку не ту или не там поставил, и требуют понимания логики действий в не меньшей мере. Консоль же требует только понимания и все.
Не говоря уже о том, что консольные команды можно копипастить, меняя лишь малую толику значений параметров, и это значительно быстрее, чем наматывать километры курсором мыши, и значительно точнее, чем играть в «найди 10 отличий». Все сказанное имхо.)
Я, признаться, не великий фанат графических интерфейсов, когда речь идет о всяких пакетных типовых операциях, типа заведения сотен абонентских номеров в PBX. А поднятие с нуля телефонии это в первую очередь такие операции.
Гуи хорош, когда визуальное представление повышает информативность и эффективность операций. В случае с телефонией гуи скорее зло. Ну, это мое имхо.
И CRMка нам не грозит) У нас такая специфика работы, что она совершенно не оправдана. И в целом уровень автоматизации бизнес-процессов у нас очень приличный, давно электронный документооборот с контролями исполнения и прочи, и бумага используется только при сдаче проектной документации, и аж цельный отдел автоматизацией занимается. Так что стадия подобных интеграций была пройдена довольно давно. Хотя, канеш, не зарекаюсь.
The task was from customer. I don't know why do they need that. They asked, I implemented, all's simple))
Если Вам известен другой способ динамического заполнения Choice parameter значениями из внешнего источника — поделитесь, пожалуйста. Заранее спасибо.
Миграции не было. Была чистая установка ESXi, создавалась с нуля машина и в нее ставилась чистая винда.
Спасибо! Попробую.
На новом месте пока полет нормальный.
Но это еще ничего ни о чем не говорит.
Правда, это не полноценный ELK, ибо Logstash отсутствует, Filebeat отдает данные напрямую в ES.
При этом типичное потребление ресурсов вот такое:
Если имеете в виду готовое решение, то оно есть, но у меня не заработало по причине, указанной в комментарии выше:
Я говорю о SELKS.
Касаемо второго пункта — это прекрасно, но чтобы создать пакет развертывания, сначала нужно, чтобы оно хотя бы заработало после установки ручками, и именно этот процесс я описал).
IPS это тема для отдельного разговора. И в этом разговоре, разумеется, не будет размахивания шашкой на каждый алерт.
ESXi и есть. Если бы они были на одном хосте, то задача зеркалирования порта была бы решена силами vSwitch'а, да… Вообще, я сторонник принципа keep it simple, и если задачу можно решить минимумом привлеченных ресурсов, значит так ее и надо решать).
И коллегам, которые на подхвате, и которые по сравнению со мной много дальше от консоли и XML, веб-морда заходит лучше. В свете необходимости делегировать им админские функции это несомненный плюс.
И да, если не сложно, поделитесь результатом. На сколько успешным был запуск.
Вы немножко превратно истолковали слово «продакшн». Речь шла о другом: бывают ситуации, когда надо просто дать ответ «да» или «нет», и дать его очень быстро. Именно тот факт, что FS заработал и обеспечил тот же функционал, что и существующая телефония, и стал критерием того, что именно FS пошел в продакшн, а не Asterisk. Не было никакого резона домучивать Asterisk до работоспособного состояния, когда изначально FS буквально взлетел. А собственно нюансы конфига будут уже вдумчиво допиливаться уже когда телефония будет поднята на новом месте и в масштабах хотя бы 100 абонентов.
Позволю себе не согласиться. Через консоль это показать легче, чем через гуи. Когда приходишь на новое место, чисто физически невозможно запомнить вообще все новое. Лично я записываю. И если буду обучать кого-то, то тоже заставлю записывать, если начнут переспрашивать. И писать конспекты о том, какую закладку открыть, какую кнопку нажать и какую галку поставить менее эффективны, чем консольные команды.
У вас же не вызвало сожаления (наверное) что я конфиг микротика привел именно в консольных командах, а не сериями скриншотов окон WinBox'а. Скриншоты требуют и вглядываться в себя, и не дай бог галочку не ту или не там поставил, и требуют понимания логики действий в не меньшей мере. Консоль же требует только понимания и все.
Не говоря уже о том, что консольные команды можно копипастить, меняя лишь малую толику значений параметров, и это значительно быстрее, чем наматывать километры курсором мыши, и значительно точнее, чем играть в «найди 10 отличий». Все сказанное имхо.)
Гуи хорош, когда визуальное представление повышает информативность и эффективность операций. В случае с телефонией гуи скорее зло. Ну, это мое имхо.
И CRMка нам не грозит) У нас такая специфика работы, что она совершенно не оправдана. И в целом уровень автоматизации бизнес-процессов у нас очень приличный, давно электронный документооборот с контролями исполнения и прочи, и бумага используется только при сдаче проектной документации, и аж цельный отдел автоматизацией занимается. Так что стадия подобных интеграций была пройдена довольно давно. Хотя, канеш, не зарекаюсь.
Да, действительно.
Благодарю.