Электронная почта, подборка
По почте у нас написано довольно много, кроме того много было дописано недавно. И если недавние статьи больше практические, то более ранние важны с точки зрения теории, несмотря на их возраст. Почта - еще более старая технология с годами там менялось мало. особенно в фундаментальном плане.
🔶 Теория
🔹 Почтовый сервер для начинающих. Структура и принцип работы
🔹 Почтовый сервер для начинающих. Настраиваем 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
👍30❤2
И снова про ремесла
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
Прошлая наша заметка про ремесло и магию получила достаточно откликов, но далеко не всем стало понятно, почему в качестве аналогии мы выбрали средневековые цеха ремесленников.
Поэтому раскроем эту мысль подробнее. Ремесло – это прежде всего ручное производство с использованием ручных орудий труда. И это в нашем случае очень важно. Фактически ремесло строится вокруг фигуры мастера и его знаний, и умений.
Развитие средств производства и промышленная революция во многом положили конец ремесленничеству, и на смену ремесленникам пришли просто рабочие, которые отличались в рамках своей профессии взамозаменяемостью.
Это сделало возможным массовое производство, унификацию и удешевление продукции. Также создало рынок труда, где работники одной специальности спокойно могли перемещаться между различными производствами.
Например, тот же токарь сегодня может работать на автомобильном производстве, а завтра перейти в судостроение. Смысл его работы был и остается один, разве что вытачиваемые детали будут иными.
Среди ремесленников такой унификации не было и быть не могло. У каждого цеха был свой, говоря современным языком, стек технологий и подмастерье стеклодув без переобучения не смог бы пойти в цех гончаров.
Но не все ремесло было повержено промышленностью, были есть и продолжают оставаться профессии, которые очень хорошо подходят под понятие ремесла. Где все решает уровень знаний и умений одного человека – мастера и работа носит преимущественно ручной характер.
При этом мы не можем заменить одного мастера некоторым количеством линейного персонала и технологией, следуя которой они будут выпускать продукт устойчивого качества.
Наиболее типичным ремеслом современности является медицина и отношения там недалеко ушли от цеховых, с поправкой на современные реалии, разумеется.
Это по-прежнему закрытая система с достаточно высоким порогом входа и классической цеховой системой уровней.
Нельзя просто так прийти в больницу и сказать: а возьмите меня врачом? Также нельзя стать врачом пройдя какие-либо короткие курсы подготовки, в то же время как на рабочие специальности вас обучат в сжатые сроки.
Чтобы стать врачом нужно будет вступить в соответствующий цех и пройти в нем весь пусть снизу доверху. Студент – интерн – врач, чем не классическое ученик – подмастерье – мастер?
И просто так перейти в другой цех не получится, ну не сможет хирург взять и пойти работать офтальмологом. как и наоборот. Потребуется снова пройти всю цепочку, только уже в новом цеху.
IT, как ни странно, при всей молодости и современности данной отрасли, тоже фактически является ремесленничеством. Здесь также все завязано на свои цеха и даже существует своя трехуровневая система: джун – мидл – сеньор.
И каждый раз вам придется проходить весь путь сначала, снизу доверху. Даже если вы были до невозможности крутым сетевым инженером, то сменив специализацию, скажем на программирование вам придется начать с позиции джуна, несмотря на былые заслуги и наоборот.
Универсального специалиста в отрасли нет, не считая самого нижнего уровня, на нашем жаргоне «эникеи». Там вполне промышленный подход и это фактически рабочие специальности с унификацией и взаимозаменяемостью.
А вот уровнем выше уже все завязано на конкретных специалистов. Такие специалисты дороги и, что более важно, обладают всем необходимым объемом знаний, которые могут позволить им воспроизвести свое ремесло в другом месте.
Грубо говоря, рабочий на заводе делает какое-то свое действие и как это действие превращается в конечный продукт знает очень узкий круг лиц, тот же технолог и ряд менеджеров того же уровня. И с завода рабочий может пойти только на другой завод.
А вот специалист (мастер) может полностью воспроизвести весь опыт у конкурента или вообще начать работать самостоятельно. Поэтому специалист дорог не только в плане оплаты труда, но и как носитель знаний и умений.
И поэтому не стоит поддаваться соблазну облегчить себе жизнь и превратиться из ремесленника в рабочего, просто запускающего контейнеры.
🔥13👍9❤3👌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 видится именно в атомарности, нравится нам это или нет. А что думаете вы?
👍6❤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, где контейнеры отделены как от базовой системы, так и от пользовательских данных. Сломался контейнер? Убей, запусти новый.
С одной стороны дико, но с другой – это время, а время деньги. Бизнес не погладит вас по головке из-за того, что вы несколько часов решали проблему и таки решили ее. Бизнес за это время потерял деньги.
Поэтому схема решения проблемы запуском заведомо исправной системы имеет место быть. А если она начинает регулярно выходить из строя – то есть тестовый стенд, разбирайся, никуда не спеши. Бизнес при этом будет продолжать работать.
Таким образом роль серверной ОС также сводится до фактически ограниченного набора ролей: гипервизор, роутер, хранилище и никто не мешает сделать их атомарными. И большинство админов будут только рады.
Нажал – апдейт. Перезагрузился. Все. Не понравилось – откатился назад. Тоже абсолютно ни за что не опасаясь.
👍11🤡2👌1