У меня только один вопрос - а вы серьезно пишете про защиту от DDoS уже на клиентском порту в 2022 году? Даже не смешно, вы вроде как компания авторитетная...
А где вы тут переход на личности? Я дал вам какую-то характеристику как человеку или специалисту?
Вы написали пост, прочитав который у меня осталось впечатление, что это "крик души" и "исповедь выжившего". У меня у самого есть огромное количество претензий к 1С, я вообще инфраструктурщик, но я же не пытаюсь сравнивать 1С с vmware-ей, где и логи клевые, и интерфейс удобный. И вообще есть крутой API по созданию виртуальных машин.
Мне кажется что вам нужно поискать причину не в окружающих, а в себе.
Мне интересно, когда люди перестанут сравнивать длинное и кислое? Почему вдруг все решили что 1С - это язык программирования? Вы сравнивайте 1С с SAP/Navision/Axapta/Парус/Галактика - это хотя бы продукты одного класса. Я еще под постом выдры хотел написать что это больше смахивает на стенограмму у психолога, но воздержался. А тут уже нет ) А Андрею Овсянику - респект!
P.S. А еще хочется спросить - а что ж вы у БД не предъявляете такие же претензии? Там тоже для получения снаружи json-а надо пилить костыли ))))
Оставляя за скобками вообще бредовость рациональность того, что вы делаете, хотел бы вам помочь советом:
Есть уже готовые решения по учету ip-адерсов в сети. Возьмите хотя бы phpipam - там у вас все будет из коробки, с нормальным api, web-интерфейсом и сканером сети.
Для большинства известных dhcp-серверов с очень большой вероятностью есть готовые модули работы с ними - просто погуглите. Если нет - найдите тот, у которого есть. В вашей ситуации это более выгодный вариант.
В итоге вы получите более адекватное решение, которое сможет поддерживать не то только создатель, но и человек, пришедший на его место
Они просто начнут меньше производить и продавать дороже. Будет не 20 моделей, а 3 и не по 100$ а по 200$. Все равно купят, ибо современный мир без смартфона невозможен, а прибыль будет увеличиваться. Ну или хотя бы не уменьшаться. Наверное )
Судя по всему мы по-разному понимаем термин "локальная установка". В моем понимании это вариант, когда все манипуляции с данными происходят в контуре заказчика.
По поводу нагрузки на продуктовые сервера - полностью согласен. Поэтому в нашем случае никаких агентов не ставится, а данные ТЖ И ЖР забираются по обычной smb/nfs шаре.
По поводу Postgres. Вы берете всю информацию из ТЖ. Наша система собирает данные еще и из самой БД.
По поводу "локальной установки". Я не смог найти информацию на вашем сайте о том, как установить серверную часть вашего комплекса в локальном окружении. Поделитесь, пожалуйста если вас не затруднит. Возможно действительно тогда не пришлось бы ничего изобретать.
Да, с ЗУП или Бухгалтерией никто не спорит. Но другие конфигурации, особенно самописные или сильно кастомизированные обновляются как правило через боль и страдания, поэтому делается это когда уже совсем припечет.
Во-первых, я бы хотел обратить ваше внимание на мое сообщение буквально сразу же над вашим. Там описан как сделано у нас.
Во-вторых, далеко не всем нужен такой инструмент как Ansible. Есть достаточное количество компаний где в принципе 1-2 БД развернуто. Они потратят на порядок больше времени на освоение инструмента, который им нужен будет один раз в год, а то меньше.
В-третьих, хочу обратить ваше внимание, что ваша последняя статья тоже рассказывает про достаточно базовые вещи и там тоже нет упоминания про Ansible. Мне кажется что не совсем красиво упрекать других в том, что делаешь сам.
Хорошо, это технический сайт. Я переформулирую - по моему личному опыту в проде все еще много старых платформ.
По поводу вашего аргумента - на мой взгляд он не показательный, так как эти базы часто обновляются из-за изменений в форме отчетности, а 1С принудительно заставляет обновлять вместе с ними и платформу.
Я лично не знаю надежных источников, где бы можно было посмотреть статистику по используемым платформам.
У себя в компании мы собираем собственный deb-пакет, кладем его в локальную репу и катим ансиблом. Но тут была задача рассказать как это можно сделать в базовом варианте. Мануалов как это сделать мы так и не нашли (под наш набор утилит)
Я не очень понял вопрос если честно, но попытаюсь ответить. Основная решаемая задача - это высокодоступное решение. Соответственно, если мастер-нода падает - ее подменяет слейв-нода, на время пока чиним старую мастер-ноду. Тут все стандартно.
Возможность долго хранить логи - кликхаус их очень хорошо сжимает.
Более комплексный взгляд на вопрос производительности (на мой взгляд).
Поддержка не только mssql, но postgres.
И самое главное (опять же, на мой взгляд) - это желание развивать продукт. Из моего опыта общения с конкурентами у них нет какого четкого понимания куда дальше двигаться.
Цены космос? А у каких аналогов цены «не космос»?
У меня только один вопрос - а вы серьезно пишете про защиту от DDoS уже на клиентском порту в 2022 году? Даже не смешно, вы вроде как компания авторитетная...
вы забыли еще про такой продукт как https://express.ms/
у нас в компании развернут - весьма хорошая альтернатива
А где вы тут переход на личности? Я дал вам какую-то характеристику как человеку или специалисту?
Вы написали пост, прочитав который у меня осталось впечатление, что это "крик души" и "исповедь выжившего". У меня у самого есть огромное количество претензий к 1С, я вообще инфраструктурщик, но я же не пытаюсь сравнивать 1С с vmware-ей, где и логи клевые, и интерфейс удобный. И вообще есть крутой API по созданию виртуальных машин.
Мне кажется что вам нужно поискать причину не в окружающих, а в себе.
Мне интересно, когда люди перестанут сравнивать длинное и кислое? Почему вдруг все решили что 1С - это язык программирования? Вы сравнивайте 1С с SAP/Navision/Axapta/Парус/Галактика - это хотя бы продукты одного класса.
Я еще под постом выдры хотел написать что это больше смахивает на стенограмму у психолога, но воздержался. А тут уже нет )
А Андрею Овсянику - респект!
P.S. А еще хочется спросить - а что ж вы у БД не предъявляете такие же претензии? Там тоже для получения снаружи json-а надо пилить костыли ))))
Статья из разряда "вредных советов" Остера
Оставляя за скобками вообще
бредовостьрациональность того, что вы делаете, хотел бы вам помочь советом:Есть уже готовые решения по учету ip-адерсов в сети. Возьмите хотя бы phpipam - там у вас все будет из коробки, с нормальным api, web-интерфейсом и сканером сети.
Для большинства известных dhcp-серверов с очень большой вероятностью есть готовые модули работы с ними - просто погуглите. Если нет - найдите тот, у которого есть. В вашей ситуации это более выгодный вариант.
В итоге вы получите более адекватное решение, которое сможет поддерживать не то только создатель, но и человек, пришедший на его место
Они просто начнут меньше производить и продавать дороже. Будет не 20 моделей, а 3 и не по 100$ а по 200$. Все равно купят, ибо современный мир без смартфона невозможен, а прибыль будет увеличиваться. Ну или хотя бы не уменьшаться. Наверное )
Судя по всему мы по-разному понимаем термин "локальная установка". В моем понимании это вариант, когда все манипуляции с данными происходят в контуре заказчика.
По поводу нагрузки на продуктовые сервера - полностью согласен. Поэтому в нашем случае никаких агентов не ставится, а данные ТЖ И ЖР забираются по обычной smb/nfs шаре.
Мне кажется что "яростно" это очень громкий эпитет. Я просто рассказываю как делали мы, не более того.
Спасибо за ваш отзыв.
По поводу Postgres. Вы берете всю информацию из ТЖ. Наша система собирает данные еще и из самой БД.
По поводу "локальной установки". Я не смог найти информацию на вашем сайте о том, как установить серверную часть вашего комплекса в локальном окружении. Поделитесь, пожалуйста если вас не затруднит. Возможно действительно тогда не пришлось бы ничего изобретать.
Да, с ЗУП или Бухгалтерией никто не спорит. Но другие конфигурации, особенно самописные или сильно кастомизированные обновляются как правило через боль и страдания, поэтому делается это когда уже совсем припечет.
А их, по моему мнению, сильно больше чем ЗУП/Бух
Во-первых, я бы хотел обратить ваше внимание на мое сообщение буквально сразу же над вашим. Там описан как сделано у нас.
Во-вторых, далеко не всем нужен такой инструмент как Ansible. Есть достаточное количество компаний где в принципе 1-2 БД развернуто. Они потратят на порядок больше времени на освоение инструмента, который им нужен будет один раз в год, а то меньше.
В-третьих, хочу обратить ваше внимание, что ваша последняя статья тоже рассказывает про достаточно базовые вещи и там тоже нет упоминания про Ansible. Мне кажется что не совсем красиво упрекать других в том, что делаешь сам.
Хорошо, это технический сайт. Я переформулирую - по моему личному опыту в проде все еще много старых платформ.
По поводу вашего аргумента - на мой взгляд он не показательный, так как эти базы часто обновляются из-за изменений в форме отчетности, а 1С принудительно заставляет обновлять вместе с ними и платформу.
Я лично не знаю надежных источников, где бы можно было посмотреть статистику по используемым платформам.
У себя в компании мы собираем собственный deb-пакет, кладем его в локальную репу и катим ансиблом. Но тут была задача рассказать как это можно сделать в базовом варианте. Мануалов как это сделать мы так и не нашли (под наш набор утилит)
Да, но огромное количество компаний работают на далеко не самых новых версиях платформы, так что этот совет будет актуален еще 3-5 лет думаю
насколько я знаю в Selectel сделали такую историю. не смотрели у них?
Я не очень понял вопрос если честно, но попытаюсь ответить. Основная решаемая задача - это высокодоступное решение. Соответственно, если мастер-нода падает - ее подменяет слейв-нода, на время пока чиним старую мастер-ноду. Тут все стандартно.
Немного юмора никогда еще не вредило )
Внедряется он реально очень просто:
включается ТЖ
Включается ЖР в файлах
Расширвается папка с ТЖ и ЖР
Ставится хранимка на скуль
Ставится расширение в конфигурацию (для структуры базы и для Апдекса)
На Ubuntu генерируется специальной софтиной compose файл
Дальше все это стартуется и все - все готово для работы и данные собираются
У меня запуск занял с нуля занял 2 часа
контакты ушли в личку
Возможность долго хранить логи - кликхаус их очень хорошо сжимает.
Более комплексный взгляд на вопрос производительности (на мой взгляд).
Поддержка не только mssql, но postgres.
И самое главное (опять же, на мой взгляд) - это желание развивать продукт. Из моего опыта общения с конкурентами у них нет какого четкого понимания куда дальше двигаться.