Я календарь переверну…
Сегодня многие отмечают известный день, в который надо переворачивать календари и жечь костры из рябин. Не меньшее количество товарищей настроены к этим многим негативно и с самого утра подвергают их обструкции.
Но мы не будем касаться этих народных развлечений и поговорим о вещах более серьезных.
Не так давно один наш коллега спросил, а как можно изменить триггер Zabbix, чтобы он срабатывал только в рабочее время.
На самом деле очень просто, добавляем к условию срабатывания:
В данном случае триггер будет срабатывать между 09:45 и 22:15, в остальное время тревожить он вас не будет.
Но оказалось, что триггер работает неправильно.
Первое, о чем тут хочется спросить – часовой пояс.
Да, с часовым поясом все нормально, Zabbix показывает события точно по времени, а вот триггер по времени работать не хочет.
А теперь вспоминаем, что веб-интерфейс Zabbix – это отдельное приложение, которое имеет собственные настройки часового пояса, в то время как сама система хранит все события с временной меткой UTC.
И вот здесь важно понимать, что аппаратные часы Linux идут в UTC, а уже потом система или отдельные приложения делают поправку на свой часовой пояс.
Что касается веб-интерфейса Zabbix, то там у каждого пользователя есть свои настройки часового пояса, так как пользователей у системы мониторинга может быть много и собирать события она может из разных часовых поясов.
Сам же сервер Zabbix работает в часовом поясе операционной системы на которой запущен и что там установлено в веб-интерфейсе его волнует мало.
Таким образом у нашего коллеги оказалось, что веб-интерфейс Zabbix имел правильные настройки пояса – MSK (UTC +3), а вот сам сервер работал, как и был из коробки – т.е. в UTC.
Поэтому события в интерфейсе показывались с правильным временем, а вот триггеры срабатывали с отставанием на 3 часа, потому как считали, что сервер находится в часовом поясе UTC (Гринвич).
Ошибка эта распространенная, можно сказать – типовая. Поэтому никогда не забывайте настраивать правильный часовой пояс в самой ОС, причем сразу после установки. Также как и рабочую локаль. Избежите многих потенциальных сложностей.
Сегодня многие отмечают известный день, в который надо переворачивать календари и жечь костры из рябин. Не меньшее количество товарищей настроены к этим многим негативно и с самого утра подвергают их обструкции.
Но мы не будем касаться этих народных развлечений и поговорим о вещах более серьезных.
Не так давно один наш коллега спросил, а как можно изменить триггер Zabbix, чтобы он срабатывал только в рабочее время.
На самом деле очень просто, добавляем к условию срабатывания:
and time()>=094500 and time()<=221500
В данном случае триггер будет срабатывать между 09:45 и 22:15, в остальное время тревожить он вас не будет.
Но оказалось, что триггер работает неправильно.
Первое, о чем тут хочется спросить – часовой пояс.
Да, с часовым поясом все нормально, Zabbix показывает события точно по времени, а вот триггер по времени работать не хочет.
А теперь вспоминаем, что веб-интерфейс Zabbix – это отдельное приложение, которое имеет собственные настройки часового пояса, в то время как сама система хранит все события с временной меткой UTC.
И вот здесь важно понимать, что аппаратные часы Linux идут в UTC, а уже потом система или отдельные приложения делают поправку на свой часовой пояс.
Что касается веб-интерфейса Zabbix, то там у каждого пользователя есть свои настройки часового пояса, так как пользователей у системы мониторинга может быть много и собирать события она может из разных часовых поясов.
Сам же сервер Zabbix работает в часовом поясе операционной системы на которой запущен и что там установлено в веб-интерфейсе его волнует мало.
Таким образом у нашего коллеги оказалось, что веб-интерфейс Zabbix имел правильные настройки пояса – MSK (UTC +3), а вот сам сервер работал, как и был из коробки – т.е. в UTC.
Поэтому события в интерфейсе показывались с правильным временем, а вот триггеры срабатывали с отставанием на 3 часа, потому как считали, что сервер находится в часовом поясе UTC (Гринвич).
Ошибка эта распространенная, можно сказать – типовая. Поэтому никогда не забывайте настраивать правильный часовой пояс в самой ОС, причем сразу после установки. Также как и рабочую локаль. Избежите многих потенциальных сложностей.
👍25🤮4👀2🤔1👌1
Как на самом деле работает KSM sharing, ожидание и реальность.
Сегодня с коллегой решали одну задачу, а именно уплотнение количества виртуальных машин на нодах. Временно понадобилось увеличить количество работающих виртуалок практически на половину, при условии использования наличных ресурсов.
Такая задача поставлена была не спроста, потому как уплотнение нужно на небольшой переходный период по переносу рабочей нагрузки со старых виртуалок на новые с последующим выводом старых из эксплуатации. После чего свободных ресурсов окажется снова более чем достаточно.
При расчетах исходили из того, что в среднем одна нода имеет 16 ГБ оперативной памяти и 6 виртуальных машин с потреблением ОЗУ примерно на уровне 10 ГБ. Все виртуальные машины однотипны.
Таким образом максимально мы можем поместить на ноду 9 виртуальных машин и память закончится, но у нас есть KSM sharing, и мы на него рассчитывали.
Сразу скажем – он не подвел и при запущенных 9 виртуальных машинах потребление памяти не превысило 12 ГБ при уплотненном объеме в районе 3 ГБ.
Результат неплохой, полностью соответствующий ожиданиям, но наш коллега остался несколько разочарованным. О чем мы его прямо и спросили.
Как выяснилось, он ожидал, что KSM sharing как сейчас все оптимизирует, да как все освободит, ну даром что ли у нас 9 одинаковых виртуалок. А он всего лишь поджал память к лимитам.
И это достаточно распространенные ожидания, которые не оправдываются реальной работой технологии. Но на самом деле все работает именно так, как задумывается.
Начнем с того, что свободная память – это не самоцель, а ресурс, который мы должны использовать наиболее выгодно. Уплотненная память ресурс гораздо более дорогой, чем обычная и если можно память не уплотнять, то уплотнять ее не нужно. ‼️
Поэтому KSM включается по умолчанию достаточно поздно, при превышении порога занятой памяти в 80%. Это некоторый критический порог, за которым начнется конкуренция за свободную память между приложениями и буферами / кешем, что ни к чему хорошему с точки зрения производительности и стабильности не приведет.
Поэтому система начинает уплотнять память, но делать это грамотно, стараясь использовать уплотненную память по минимуму.
При превышении заданного порога система добавляет к уплотнению некоторое количество страниц, добиваясь возвращения потребления памяти к заданному порогу. Если после этого свободной памяти окажется больше, то из уплотнения будет вычтено некоторое количество страниц.
При повторном превышении снова будут добавлены страницы, при понижении вычтены и через некоторое время система придет в некоторое положение равновесия, когда уплотнено будет ровно столько страниц, сколько нужно для удержания количества свободной памяти рядом с установленным порогом или чуть ниже.
Потому как нет смысла загонять процессы в уплотненную и дорогую память ради выделения неиспользуемой дешевой. Это глупое разбазаривание ценного ресурса, память должна работать.
И настройки KSM по умолчанию неплохо соответствуют этой парадигме. При желании изменить такое поведение и покрутить руками можете воспользоваться нашими рекомендациями из статьи:
https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
Но будьте благоразумны и не один раз подумайте, а для чего вам свободная оперативная память.
А реальную работу KSM sharing можно посмотреть на скриншоте ниже, где видно как по мере ввода новой рабочей нагрузки производилась оптимизация и подбор количества уплотняемых страниц и как этот процесс стабилизировался на отметке близкой к порогу.
Сегодня с коллегой решали одну задачу, а именно уплотнение количества виртуальных машин на нодах. Временно понадобилось увеличить количество работающих виртуалок практически на половину, при условии использования наличных ресурсов.
Такая задача поставлена была не спроста, потому как уплотнение нужно на небольшой переходный период по переносу рабочей нагрузки со старых виртуалок на новые с последующим выводом старых из эксплуатации. После чего свободных ресурсов окажется снова более чем достаточно.
При расчетах исходили из того, что в среднем одна нода имеет 16 ГБ оперативной памяти и 6 виртуальных машин с потреблением ОЗУ примерно на уровне 10 ГБ. Все виртуальные машины однотипны.
Таким образом максимально мы можем поместить на ноду 9 виртуальных машин и память закончится, но у нас есть KSM sharing, и мы на него рассчитывали.
Сразу скажем – он не подвел и при запущенных 9 виртуальных машинах потребление памяти не превысило 12 ГБ при уплотненном объеме в районе 3 ГБ.
Результат неплохой, полностью соответствующий ожиданиям, но наш коллега остался несколько разочарованным. О чем мы его прямо и спросили.
Как выяснилось, он ожидал, что KSM sharing как сейчас все оптимизирует, да как все освободит, ну даром что ли у нас 9 одинаковых виртуалок. А он всего лишь поджал память к лимитам.
И это достаточно распространенные ожидания, которые не оправдываются реальной работой технологии. Но на самом деле все работает именно так, как задумывается.
Начнем с того, что свободная память – это не самоцель, а ресурс, который мы должны использовать наиболее выгодно. Уплотненная память ресурс гораздо более дорогой, чем обычная и если можно память не уплотнять, то уплотнять ее не нужно. ‼️
Поэтому KSM включается по умолчанию достаточно поздно, при превышении порога занятой памяти в 80%. Это некоторый критический порог, за которым начнется конкуренция за свободную память между приложениями и буферами / кешем, что ни к чему хорошему с точки зрения производительности и стабильности не приведет.
Поэтому система начинает уплотнять память, но делать это грамотно, стараясь использовать уплотненную память по минимуму.
При превышении заданного порога система добавляет к уплотнению некоторое количество страниц, добиваясь возвращения потребления памяти к заданному порогу. Если после этого свободной памяти окажется больше, то из уплотнения будет вычтено некоторое количество страниц.
При повторном превышении снова будут добавлены страницы, при понижении вычтены и через некоторое время система придет в некоторое положение равновесия, когда уплотнено будет ровно столько страниц, сколько нужно для удержания количества свободной памяти рядом с установленным порогом или чуть ниже.
Потому как нет смысла загонять процессы в уплотненную и дорогую память ради выделения неиспользуемой дешевой. Это глупое разбазаривание ценного ресурса, память должна работать.
И настройки KSM по умолчанию неплохо соответствуют этой парадигме. При желании изменить такое поведение и покрутить руками можете воспользоваться нашими рекомендациями из статьи:
https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
Но будьте благоразумны и не один раз подумайте, а для чего вам свободная оперативная память.
А реальную работу KSM sharing можно посмотреть на скриншоте ниже, где видно как по мере ввода новой рабочей нагрузки производилась оптимизация и подбор количества уплотняемых страниц и как этот процесс стабилизировался на отметке близкой к порогу.
👍12❤2🤝2
Закат 32-битной эпохи
Вышедший в августе Debian 13 расстроил ретроградов, один из последних оплотов 32-битной архитектуры отказался от ее полноценной поддержки и не выпустил 32-разрядной версии дистрибутива.
При этом сама архитектура остается доступной в целях обратной совместимости, т.е. вы можете подключить 32-битные репозитории к своей 32-битной системе и получить оттуда необходимые пакеты. Это может потребоваться для запуска устаревшего ПО, которое не имеет 64-битной версии.
Напомним, что до этого практически все ведущие дистрибутивы прекратили поддержку 32-битной архитектуры гораздо ранее, так для Ubuntu последним выпуском с поддержкой 32-бит был выпуск 18.04 LTS, а Fedora прекратила сборку 32-битных дистрибутивов начиная с выпуска 31 в 2019 году.
FreeBSD тоже решило нанести «удар в спину» и также отказывается от поддержки 32-битного дистрибутива начиная с 15 выпуска запланированного на конец этого года.
И это, в общем и целом, правильно. Сегодня уже практически не осталось адекватного современным требованиям железа, не поддерживающего 32-битные инструкции. Сегодня запускать 64-битный код может практически каждый чайник и утюг, особенно если мы говорим об архитектуре x86.
При этом полностью от поддержки 32-битных приложений пока никто не отказывается, вы можете их спокойно запускать на своих 64-битных системах и даже подключать репозитории с 32-битными пакетами.
Но они, честно говоря, не являются «настоящими» 32-битными, если мы подразумеваем под этим классические архитектуры i586/686. Данные пакеты собраны в среде современных ОС и требуют поддержки инструкций присутствующих в современных процессорах.
Но это, как раз понятно, потому как их цель не поддержка устаревших процессоров, а продление жизни старого ПО, не имеющего 64-битных версий при обеспечении для него нормального быстродействия и максимального использования всех преимуществ современных платформ.
И тем удивительнее сегодня слышать просьбы найти именно 32-битный пакет для того или иного ПО. Потому как никакого практического смысла сегодня это не имеет. Платформ не поддерживающих 64-бита (не считая какой-нибудь экзотики или промышленного оборудования) в широкой эксплуатации нет. Поэтому и нет смысла держаться за старое. Ведь никто же сегодня не сетует на отсутствие поддержки 16-бит?
Вышедший в августе Debian 13 расстроил ретроградов, один из последних оплотов 32-битной архитектуры отказался от ее полноценной поддержки и не выпустил 32-разрядной версии дистрибутива.
При этом сама архитектура остается доступной в целях обратной совместимости, т.е. вы можете подключить 32-битные репозитории к своей 32-битной системе и получить оттуда необходимые пакеты. Это может потребоваться для запуска устаревшего ПО, которое не имеет 64-битной версии.
Напомним, что до этого практически все ведущие дистрибутивы прекратили поддержку 32-битной архитектуры гораздо ранее, так для Ubuntu последним выпуском с поддержкой 32-бит был выпуск 18.04 LTS, а Fedora прекратила сборку 32-битных дистрибутивов начиная с выпуска 31 в 2019 году.
FreeBSD тоже решило нанести «удар в спину» и также отказывается от поддержки 32-битного дистрибутива начиная с 15 выпуска запланированного на конец этого года.
И это, в общем и целом, правильно. Сегодня уже практически не осталось адекватного современным требованиям железа, не поддерживающего 32-битные инструкции. Сегодня запускать 64-битный код может практически каждый чайник и утюг, особенно если мы говорим об архитектуре x86.
При этом полностью от поддержки 32-битных приложений пока никто не отказывается, вы можете их спокойно запускать на своих 64-битных системах и даже подключать репозитории с 32-битными пакетами.
Но они, честно говоря, не являются «настоящими» 32-битными, если мы подразумеваем под этим классические архитектуры i586/686. Данные пакеты собраны в среде современных ОС и требуют поддержки инструкций присутствующих в современных процессорах.
Но это, как раз понятно, потому как их цель не поддержка устаревших процессоров, а продление жизни старого ПО, не имеющего 64-битных версий при обеспечении для него нормального быстродействия и максимального использования всех преимуществ современных платформ.
И тем удивительнее сегодня слышать просьбы найти именно 32-битный пакет для того или иного ПО. Потому как никакого практического смысла сегодня это не имеет. Платформ не поддерживающих 64-бита (не считая какой-нибудь экзотики или промышленного оборудования) в широкой эксплуатации нет. Поэтому и нет смысла держаться за старое. Ведь никто же сегодня не сетует на отсутствие поддержки 16-бит?
👍35
Zabbix get – получаем информацию от Zabbix через CLI
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
Или аптайм:
А вот при попытке получить утилизацию памяти в % получим ошибку:
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
Многие администраторы воспринимают Zabbix как некоторую цельную и закрытую систему, все данные в которой собираются сервером Zabbix и концентрируются в одном месте.
Однако это не так, Zabbix достаточно открытая и универсальная система, которая может предоставлять различные сценарии использования. Так для получения данных от агентов вам не обязательно нужен сервер или прокси, вы можете использовать для этого отдельную утилиту командной строки - Zabbix get.
Вы можете установить ее как на хост с Zabbix, так и на любую иную систему, для которой есть соответствующие пакеты. Для этого нужно подключить репозитории Zabbix и выполнить команду (для DEB-систем):
apt install zabbix-get
Если данный узел не является сервером Zabbix, то нужно добавить его адрес в опцию
Server агента, в противном случае вы получите ошибку:Check access restrictions in Zabbix agent configuration
После чего можете начать общаться со своим агентом при помощи командной строки, общий синтаксис такой:
zabbix_get -s host-name-or-IP [-p port-number] -k item-key
Вам нужно указать адрес агента после ключа -s и ключ элемента данных (item) после ключа -k, ключ -p – порт не является обязательным, если он не указан, то будет использоваться стандартный 10050.
Где взять ключи? Их можно посмотреть в самом Zabbix, например, открыв нужный шаблон.
Проверим доступность агента:
zabbix_get -s 192.168.101.198 -p 10050 -k agent.ping
Если агент доступен получим значение 1, иначе 0.
Проверим утилизацию процессора:
zabbix_get -s 192.168.101.198 -p 10050 -k system.cpu.util
Или аптайм:
zabbix_get -s 192.168.101.198 -p 10050 -k system.uptime
А вот при попытке получить утилизацию памяти в % получим ошибку:
zabbix_get -s 192.168.101.198 -k vm.memory.util
ZBX_NOTSUPPORTED: Unknown metric vm.memory.util
Неизвестная метрика… Но почему, ведь в шаблоне такой ключ есть?
Но все правильно, вспомним, что есть вычисляемые элементы данных, которые не собираются с узлов, а вычисляются сервером на основе иных полученных значений, указанный ключ принадлежит именно вычисляемому элементу, в чем также несложно убедиться, посмотрев колонку Тип, а открыв сам элемент мы можем увидеть на основании каких элементов и как он вычисляется.
Данную утилиту удобно использовать в первую очередь для диагностики и отладки агентов, но никто не мешает получать с ее помощью нужные данные для сторонних систем, отчетов или средств автоматизации.
👍22🔥3👀2❤1
Профессия – программист
Сегодня пятница, поэтому, как это уже принято, поговорим на околотехнические темы. Тем более что есть определенная фактура, как говорится, из первых рук.
В этом году мой сын закончил 9 классов и успешно поступил в Колледж высоких технологий местного Университета на программирование. Но поступление было далеко не простым.
Дело в том, что наш регион как приграничный и прифронтовой (Белгородская область) выпускались по упрощенной схеме – без ЕГЭ и ОГЭ, по среднему баллу, а поступление осуществлялось на основе «конкурса аттестатов».
Что это значит? А это значит, что при поступлении имеет значение только средний балл аттестата. При этом если на программирование поступает ребенок, у которого пятерки по математике и информатике, но посредственные оценки по литературе, русскому, химии, географии и т.д., а вместе с ним подал документы троечник по математике/информатике, но отличник по гуманитарным наукам, то пройдет гуманитарий, так как балл его аттестата выше.
Добавляем туда любимчиков, активистов, личные приятственные или неприязненные отношения учителей и многое другое. Тем более что из школ в колледжи побежало в этом году практически 90-95% детей. Потому как потенциальное ЕГЭ через два года мало кого прельщает.
В итоге такой конкурс аттестатов мог спокойно перекрыть дорогу на «престижные» специальности действительно увлеченным детям, вместо которых возьмут тех, у кого аттестат лучше.
К счастью, наш колледж основан на базе Университета, который обладает определенной автономией, поэтому при приеме учитывали не только средний балл аттестата, но и реальные заслуги на профессиональном поприще.
А так как у сына были грамоты и дипломы от разных городских конкурсов по IT, программированию и робототехнике, в т.ч. и проводимых Университетом, то он уверенно прошел, несмотря на достаточно низкий балл аттестата (потому что забивал в школе на гуманитарку).
После поступления сходили познакомились с куратором, преподавателями и узнали много интересного. Но ничего нового я не услышал. История повторяется.
Сегодня на IT-специальности в целом и программирование в частности конкурс очень дикий. В сознании родителей эта сфера представляется некоторой синекурой, где достаточно иметь нужный диплом, и легкая обеспеченная жизнь гарантируется по умолчанию.
Кстати, наш куратор была в приемной комиссии и побеседовав с сыном тет-а-тет сказала: этого беру к себе и пофиг на балл в аттестате. Потому что опять наберем больше половины идиотов.
И это не фигура речи, потому что как можно поступать на программирование не умея сканировать и присылая фото с мобилы в документе Word?
Посему к Университету и его преподавателям поклон и уважение, что они стараются отбирать действительно увлеченных ребят и давать им возможность получить образование по выбранному профилю.
А остальные? Тут я хочу вернуться на 25-30 лет назад, в далекие и светлые, для кого-то «святые». Тогда было очень популярно учиться на юриста.
Юристов готовили юридические ВУЗы, гуманитарные, технические и даже сельскохозяйственные.
Для самой профессии пророчили упадок и замещение дешевыми кадрами, ну все это мы слышим и сейчас.
И что изменилось? Хорошие юристы как были поштучно, так и остались. Доходы их как были высокими, так и остались. Их как искали днем с огнем, так и ищут.
А куда делись все эти стада с «юридическим» образованием? Осели по «Пятерочкам» того времени и тому подобным организациям. Максимум в ИП Джамшут юристом, чисто потешить этого самого Джамшута эго, на зарплате продавца из «Пятерочки».
Точно также будет и с «программистами», жаль только тех ребят, которые действительно хотят, горят и желают, но не смогут пройти по чистой формальности, наподобие конкурса аттестатов.
Ну и родителям тоже надо задуматься. Хороший сантехник сегодня тоже на вес золота и зарабатывает не хуже, чем программист.
Сегодня пятница, поэтому, как это уже принято, поговорим на околотехнические темы. Тем более что есть определенная фактура, как говорится, из первых рук.
В этом году мой сын закончил 9 классов и успешно поступил в Колледж высоких технологий местного Университета на программирование. Но поступление было далеко не простым.
Дело в том, что наш регион как приграничный и прифронтовой (Белгородская область) выпускались по упрощенной схеме – без ЕГЭ и ОГЭ, по среднему баллу, а поступление осуществлялось на основе «конкурса аттестатов».
Что это значит? А это значит, что при поступлении имеет значение только средний балл аттестата. При этом если на программирование поступает ребенок, у которого пятерки по математике и информатике, но посредственные оценки по литературе, русскому, химии, географии и т.д., а вместе с ним подал документы троечник по математике/информатике, но отличник по гуманитарным наукам, то пройдет гуманитарий, так как балл его аттестата выше.
Добавляем туда любимчиков, активистов, личные приятственные или неприязненные отношения учителей и многое другое. Тем более что из школ в колледжи побежало в этом году практически 90-95% детей. Потому как потенциальное ЕГЭ через два года мало кого прельщает.
В итоге такой конкурс аттестатов мог спокойно перекрыть дорогу на «престижные» специальности действительно увлеченным детям, вместо которых возьмут тех, у кого аттестат лучше.
К счастью, наш колледж основан на базе Университета, который обладает определенной автономией, поэтому при приеме учитывали не только средний балл аттестата, но и реальные заслуги на профессиональном поприще.
А так как у сына были грамоты и дипломы от разных городских конкурсов по IT, программированию и робототехнике, в т.ч. и проводимых Университетом, то он уверенно прошел, несмотря на достаточно низкий балл аттестата (потому что забивал в школе на гуманитарку).
После поступления сходили познакомились с куратором, преподавателями и узнали много интересного. Но ничего нового я не услышал. История повторяется.
Сегодня на IT-специальности в целом и программирование в частности конкурс очень дикий. В сознании родителей эта сфера представляется некоторой синекурой, где достаточно иметь нужный диплом, и легкая обеспеченная жизнь гарантируется по умолчанию.
Кстати, наш куратор была в приемной комиссии и побеседовав с сыном тет-а-тет сказала: этого беру к себе и пофиг на балл в аттестате. Потому что опять наберем больше половины идиотов.
И это не фигура речи, потому что как можно поступать на программирование не умея сканировать и присылая фото с мобилы в документе Word?
Посему к Университету и его преподавателям поклон и уважение, что они стараются отбирать действительно увлеченных ребят и давать им возможность получить образование по выбранному профилю.
А остальные? Тут я хочу вернуться на 25-30 лет назад, в далекие и светлые, для кого-то «святые». Тогда было очень популярно учиться на юриста.
Юристов готовили юридические ВУЗы, гуманитарные, технические и даже сельскохозяйственные.
Для самой профессии пророчили упадок и замещение дешевыми кадрами, ну все это мы слышим и сейчас.
И что изменилось? Хорошие юристы как были поштучно, так и остались. Доходы их как были высокими, так и остались. Их как искали днем с огнем, так и ищут.
А куда делись все эти стада с «юридическим» образованием? Осели по «Пятерочкам» того времени и тому подобным организациям. Максимум в ИП Джамшут юристом, чисто потешить этого самого Джамшута эго, на зарплате продавца из «Пятерочки».
Точно также будет и с «программистами», жаль только тех ребят, которые действительно хотят, горят и желают, но не смогут пройти по чистой формальности, наподобие конкурса аттестатов.
Ну и родителям тоже надо задуматься. Хороший сантехник сегодня тоже на вес золота и зарабатывает не хуже, чем программист.
💯37❤6👍6🥱2🤣2
Электронная почта, подборка
По почте у нас написано довольно много, кроме того много было дописано недавно. И если недавние статьи больше практические, то более ранние важны с точки зрения теории, несмотря на их возраст. Почта - еще более старая технология с годами там менялось мало. особенно в фундаментальном плане.
🔶 Теория
🔹 Почтовый сервер для начинающих. Структура и принцип работы
🔹 Почтовый сервер для начинающих. Настраиваем DNS зону
🔹 Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом
🔹 Настраиваем свой почтовый сервер. Что нужно знать. Ликбез
🔹 Какие порты и для чего использует почтовый сервер. Ликбез
🔹 Как правильно настроить DNS-записи для мультидоменного почтового сервера
🔶 Практика. Почтовые сервера
🔹 Установка и настройка почтового сервера iRedMail с веб-клиентом SOGo и сертификатами Let's Encrypt
🔹 Установка и настройка почтового сервера Modoboa в Debian или Ubuntu
🔹 Установка и настройка почтового сервера Mail-in-a-Box в Ubuntu 22.04
🔶 Практика. Антиспам
🔹 Proxmox Mail Gateway - настраиваем пограничный почтовый шлюз
🔹 Используем API для автоматизации работы с Proxmox Mail Gateway
🔹 Обновляем Proxmox Mail Gateway с версии 7 до 8
🔶 Полезные инструменты
🔹 Онлайн инструменты для проверки почтового сервера
🔹 Проверка связи по протоколу SMTP с помощью Telnet
🔹 Перенос почтовых ящиков между серверами при помощи imapsync
По почте у нас написано довольно много, кроме того много было дописано недавно. И если недавние статьи больше практические, то более ранние важны с точки зрения теории, несмотря на их возраст. Почта - еще более старая технология с годами там менялось мало. особенно в фундаментальном плане.
🔶 Теория
🔹 Почтовый сервер для начинающих. Структура и принцип работы
🔹 Почтовый сервер для начинающих. Настраиваем DNS зону
🔹 Почтовый сервер для начинающих. PTR и SPF записи как средство борьбы со спамом
🔹 Настраиваем свой почтовый сервер. Что нужно знать. Ликбез
🔹 Какие порты и для чего использует почтовый сервер. Ликбез
🔹 Как правильно настроить DNS-записи для мультидоменного почтового сервера
🔶 Практика. Почтовые сервера
🔹 Установка и настройка почтового сервера iRedMail с веб-клиентом SOGo и сертификатами Let's Encrypt
🔹 Установка и настройка почтового сервера Modoboa в Debian или Ubuntu
🔹 Установка и настройка почтового сервера Mail-in-a-Box в Ubuntu 22.04
🔶 Практика. Антиспам
🔹 Proxmox Mail Gateway - настраиваем пограничный почтовый шлюз
🔹 Используем API для автоматизации работы с Proxmox Mail Gateway
🔹 Обновляем Proxmox Mail Gateway с версии 7 до 8
🔶 Полезные инструменты
🔹 Онлайн инструменты для проверки почтового сервера
🔹 Проверка связи по протоколу SMTP с помощью Telnet
🔹 Перенос почтовых ящиков между серверами при помощи imapsync
👍33❤2
И снова про ремесла
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
🔥14👍11❤3👌1🥱1
Атомарность – будущее Linux
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
Читал сегодня новость про выпуск альфа-версии KDE Linux, сразу обратил внимание на себя следующий момент:
Дистрибутив основан на пакетной базе Arch Linux, но оформлен в форме неделимого образа, не применяющего разбивку на отдельные пакеты, монтируемого в режиме только для чтения и обновляемого атомарно. Компоненты, помимо базового системного окружения, собраны из исходного кода при помощи kde-builder или поставляются в форме пакетов Flatpak.
И это не только особенность именно этого дистрибутива, к идее атомарности пользовательские дистрибутивы идут уже давно, благо он уже откатан на мобильных ОС.
Атомарность дает большое преимущество – стабильную и предсказуемую среду, не зависящую от действия или бездействия пользователя. Это хорошо разработчику и это хорошо пользователю, каждый из них знает, что это просто работает, без 100500 условий…
Сегодня пакетные дистрибутивы неизбежно скатываются в атомизацию (не путать с атомарностью) – страшный сон любого разработчика и администратора. Потому как обновляясь (или не обновляясь) с произвольной частотой мы получаем бесконечно большое множество самых разных сочетаний пакетов.
Дополнительно ситуация усугубляется сторонними репозиториями, пакетами, установленными вручную, заморозкой и прикреплением пакетов, это мы уже промолчим про самостоятельную сборку.
И что мы получаем? Правильно, неуправляемый хаос. В итоге один и тот же пакет, на одной и той же системе отлично работает у Пети, не совсем хорошо у Васи и совсем не работает у Димы. А ты пойди – разберись.
Да и Пете, Васе и Диме, как пользователям, тоже от этого не легче. Они хотят просто скачать пакет и работать, становиться администраторами Linux у них нет ни времени, ни желания.
Еще одна известная ложка дегтя – это наличие целого зоопарка дистрибутивов, под каждый из которых нужно собирать свой пакет. И хорошо, если это будет делать мейнтейнер и это не будет противоречить политике дистрибутива.
Но попробуйте в том же Debian, где пакетная база замораживается на этапе подготовки к релизу, поддерживать пять лет тот же Telegram? Ну вот то-то же…
Разработчик? А оно ему надо? Ну вот возьмем один тот же Debian, как минимум надо поддерживать три версии: stable, oldstable и oldoldstable. Такая же ситуация практически с любым дистрибутивом и даже если взять только дистрибутивы первого эшелона список уже окажется огромным.
А ведь это не просто собрать пакет. Его нужно тестировать, сопровождать, устранять баги и т.д. и т.п. Не говоря уже о том, что возможности у дистрибутивов разные и если в последних версиях есть какая-то библиотека, предоставляющая новые функции, то в старых ее может не быть, со всеми вытекающими.
Чтобы избежать этих сложностей придумали универсальные пакеты: Flatpak, Snap, AppImage. По сути, это ничто иное, как контейнеризация приложений, позволяющая обеспечить единую среду выполнения вне зависимости от версии и типа ОС.
А если мы отвязали пользовательские приложение от системы, то кто нам мешает отвязать систему от пользователя? Тем более что мобильные платформы все это давно реализовали и обкатали.
Собираем атомарный, неизменяемый образ и поставляем его пользователю как есть, обновления поставляем в виде нового, неизменяемого образа, у которого есть только одно, строго определенное состояние, которое заранее известно.
В результате получаем небольшой набор возможных состояний, что сильно облегчает разработку и сопровождение.
Пользователю тоже хорошо, он знает, что если приложение А заработало у Пети, то будет работать и у него. А для возможных багов есть общие универсальные решения. Без оглядки на то, что если у вас Debian, то… а если Fedora – тогда…
А как быть с патчами? Вот нашли уязвимость в библиотеке, пересобирать образ? Вовсе нет, уже давно есть утилита systemd-sysext, которая позволяет устанавливать расширения атомарных образов, накладывая их сверху на иерархию файловой системы через OverlayFS.
Таким образом будущее настольного Linux видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍11🤔4❤1👎1
Атомарность на серверах Linux. Да или нет?
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
Обсуждая с коллегами атомарные дистрибутивы очень часто можно услышать мнение, что мол да, десктопные туда уверенно идут и скоро придут, но вот серверные…
Серверные системы представляются как надежный оплот пакетной базы, где каждый админ, как тот суслик, сам себе агроном и сам себе собирает по кирпичикам нужную систему.
На самом деле это давно не так, ну разве только вы админ локалхоста. В корпоративных средах давно важна унификация и поддержка. Точнее снижение затрат на последнюю.
Любая собранная руками система накладывает дополнительные требования по своей поддержке и увеличивает суммарную стоимость владения.
К тому же сервер сегодня – это не сервер вчера, времена, когда одна система выполняла кучу различных ролей, канули в прошлое. Сегодня ведущую роль играет виртуализация и контейнеризация. И неписанным стандартом стало правило: одна роль – одна виртуалка (контейнер).
Таким образом типичный современный железный сервер будет с большой вероятностью иметь роль гипервизора. Либо еще что-то нишевое и специфическое: роутер, дисковое хранилище и т.д. со своей нишевой сборкой: OPNsense, TrueNAS и т.д. и т.п.
А все остальное – виртуалки или контейнеры, скорее всего последнее. Контейнеры экономичны, производительны, удобны и не несут ничего лишнего, тогда как виртуалка – это полноценная ОС со всем «фаршем».
Но так или иначе мы приходим к тому, что базовая система на физическом сервере должна обеспечить нам возможность запуска KVM, LXC, Docker. А остальное нас сильно не волнует. Точнее даже будет лучше, если вообще не будет волновать.
И мы снова приходим к атомарной системе. Чем плох атомарный гипервизор? Да ничем, наоборот даже лучше, что никакие шаловливые ручки не наставят в него левых пакетов и он не «скопытится» на очередном обновлении.
Тоже самое давно напрашивается в отношении OPNsense, TrueNAS и подобных, там давно никто не лазит под капот. Скажем та же RouterOS давно себе является атомарной. Мы просто загружаем новый образ системы и никого это не напрягает и не ущемляет.
Если завтра атомарным станет Proxmox – кому станет от этого хуже? Да никому, кроме полутора землекопов, которые пытаются из пакетов натянуть сову на глобус, типа установки на mdadm или еще чего-нибудь разработчиками нерекомендуемого и неподдерживаемого.
А так вышло обновление, прочитали отзывы, если все хорошо – обновляемся, нет – ждем следующего релиза.
И нет никаких конфликтов зависимостей, левых репозиториев и установленных через make install непотребств, которые могут взять и сломать все на ровном месте.
Вы всегда знаете, что у вас под капотом образ 123.45.6 и он работает именно так, как написано. Еще есть образ 123.45.7, но там есть траблы, поэтому подождем 123.46.0 где их не только исправят, но и новых «ништияков» подкинут.
А как же то, что мое приложение требует… Как-как? Берем контейнер с нужным окружением и пусть дальше требует, получите и распишитесь. Работаем, радуемся, никому не мешаем. Надо обновить? Просто заменили контейнер. Проблемы? Убили контейнер, создали новый из шаблона.
Это прекрасно представлено в парадигме Docker, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍24🤡3👌2❤1🤔1
Oracle Cloud - всё?
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
Сдается мне, что Oracle Cloud – всё.
Зоркий глаз, в лице известного ведомства из трех букв увидел таки сего провайдера и решил сделать то, что Oracle Cloud так до конца и не сделал сам.
Проблемы начались еще с пятницы, а сегодня со второй половины дня ресурсы Oracle Cloud недоступны через проводной интернет Мегафон. Бегают только пинги, и то, непонятно, надолго-ли.
Внешний зарубежный мониторинг показывает, что с ресурсами все в порядке. С территории РФ доступа нет.
Возможно – это временные трудности или что-то куда-то попало по ошибке.
Но скажем честно, верится слабо. Поэтому будем исходить из того, что одна из последних доступных бесплатных площадок – всё…
😱3🔥2
А у вас есть доступ к Oracle Cloud? (доступно несколько ответов)
Anonymous Poll
6%
Да, проводной провайдер
1%
Да, мобильный провайдер
3%
Нет, проводной провайдер
2%
Нет, мобильный провайдер
19%
Меня там забанили еще в 2022
17%
Принципиально не использую западные сервисы
9%
Так вам и надо!
51%
Ничего не понятно, но очень интересно
🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Екатеринбурге и поборись за призовой фонд 600 000 рублей!
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
📅 Когда: 30 сентября–3 октября
🌐 Формат: онлайн + финал на площадке
Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности;
🔹развиваешься в направлении разработки, аналитики, информационной безопасности или DevOp;
🔹сможешь быть в Екатеринбурге 3 октября.
Выбери свой кейс:
🔸 Terraform LogViewer: от хаоса к порядку. Разработай инструмент, который автоматизирует визуализацию и поиск проблем при развертывании и использовании инфраструктуры.
🔸 Обход защиты Web Application Firewall. Найди уязвимости, замаскируй атаки и попытайся «обойти» инструменты защиты ИБ.
Почему стоит участвовать:
🔻Кейс в портфолио и полезная обратная связь от менторов Т1;
🔻Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний;
🔻Реальный опыт командной работы;
🔻Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.
Регистрация открыта!
➡️ Успей до 28 сентября по ссылке.
Ты не из Екатеринбурга, но хочешь принять участие? Смотри расписание хакатонов в других городах.
#реклама
О рекламодателе
⚡2❤1