https://www.opennet.ru/openforum/vsluhforumID3/136942.html Представлен релиз дистрибутива NixOS 25.05, основанного на пакетном менеджере Nix и предоставляющего собственные разработки для упрощения настройки и сопровождения системы. В NixOS вся настройка системы осуществляется через единый файл системной конфигурации configuration.nix. Предоставляются возможности для быстрого отката системы на предыдущую версию конфигурации и переключения между различными состояниями системы. Поддерживается установка индивидуальных пакетов отдельными пользователями и возможность одновременного использования нескольких версий одной программы. Обеспечены воспроизводимые сборки. Для архитектур x86_64 и ARM64 подготовлен установочный образ с графическим окружением (3.7 ГБ) и сокращённый консольный вариант (1.4 ГБ)...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63296<br> https://www.opennet.ru/openforum/vsluhforumID3/136942.html#100 Sun, 01 Jun 2025 09:04:26 GMT Фанаты уже вроде все подуспокоились. Не кричат. С аргументами так и подавно давно не кричат. Всем влом.<br> https://www.opennet.ru/openforum/vsluhforumID3/136942.html#99 Sun, 01 Jun 2025 06:34:09 GMT &gt;Да оно понятно, что проект авторский. Единственная претензия к автору заключается в том, что он не имеет ответа на главный вопрос: какую проблему это решает? Фичи Nix, безусловно, интересны. Однако необходимость в них в реальном бою близка к нулю. Раз так, то у дистрибутива никогда не будет пользовательской базы и инвесторов. А на одних энтузиастах далеко не уедешь.<br><br>Убирает docker и контейнеризацию, добавляя что-то позабористее и посложнее. При этом сложность довольно искусственна и смысла копаться в этой сложности нет. <br>Тебе могут прямо положить сломанные пакеты в репу, могут сломать совместимость в конфиге, чтобы переназвать опцию, не понятно зачем. Тебе придется лазить по гиту чтобы понять куда в опции положили определенный конфиг, при этом его могли вообще не положить и опять надо идти собирать свой nix package.<br>В общем для домашнего сервера или vps может и сойдет, но надо учитывать что придется тратить на него время, у меня пару vps живет на нем нормально.<br>В продакшене - учитывая политику разработч https://www.opennet.ru/openforum/vsluhforumID3/136942.html#98 Thu, 29 May 2025 15:09:20 GMT &gt;&gt; Тем, что terraform apply гарантировано полностью синхронизирует состояние кластера с кодом в репозитории, и точно не возникнет ситуации, когда что-то в коде есть, но "забыли накатить". А если у тебя пачка kubectl apply и helm upgrade -- запросто.<br>&gt; Это всегда зависит от логики CI/CD, но может в вашем случае это <br>&gt; обосновано. Просто в фоне terraform точно также использует helm upgrade и <br>&gt; kubectl apply команды, а значит этого можно добиться без terraform.<br><br>Какова бы ни была логика, надо учитывать человеческий фактор.<br>Вот добавит человек манифест/чарт, а команду накатки в CI/CD забудет, и у нас IaC не консистентный получится.<br>Не страшно, конечно, но зачем вообще допускать возможность подобного.<br><br>&gt;&gt; Конечно стоит: он собирает метрики с экспортеров кластера (и скрейпит бизнес-метрики пейлоада, узнавая о них по лейблам), а затем пушит их в центральный прометей для хранения, анализа и алёртинга.<br>&gt; Прометей даже в агент-режиме жирноват<br><br>С mvagent я не работал. А prometheus -- проверенный и надёжный ин https://www.opennet.ru/openforum/vsluhforumID3/136942.html#97 Thu, 29 May 2025 08:34:07 GMT &gt; Тем, что terraform apply гарантировано полностью синхронизирует состояние кластера с кодом в репозитории, и точно не возникнет ситуации, когда что-то в коде есть, но "забыли накатить". А если у тебя пачка kubectl apply и helm upgrade -- запросто.<br><br>Это всегда зависит от логики CI/CD, но может в вашем случае это обосновано. Просто в фоне terraform точно также использует helm upgrade и kubectl apply команды, а значит этого можно добиться без terraform.<br><br>&gt; Конечно стоит: он собирает метрики с экспортеров кластера (и скрейпит бизнес-метрики пейлоада, узнавая о них по лейблам), а затем пушит их в центральный прометей для хранения, анализа и алёртинга.<br><br>Прометей даже в агент-режиме жирноват, есть mvagent от VictorialMetrics, который точно также умеет скрейпить метрики и пушить и в централизованый Прометей и в VictorialMetrics.<br><br>&gt; Простота реализации -- залог того, что ничто не сломается.<br><br>Я как раз сталкивался с поломками, я бы не назвал это простотой реализации, он зачем то подтягивает helper образ постоян https://www.opennet.ru/openforum/vsluhforumID3/136942.html#96 Wed, 28 May 2025 22:19:58 GMT &gt;&gt; В основном потому, что такой подход позволяет удобно из единого места конфигурировать общие ассеты куба.<br>&gt; И чем это отличается от простого использования kubectl или helm?<br><br>Тем, что terraform apply гарантировано полностью синхронизирует состояние кластера с кодом в репозитории, и точно не возникнет ситуации, когда что-то в коде есть, но "забыли накатить". А если у тебя пачка kubectl apply и helm upgrade -- запросто.<br><br>&gt;&gt; прометей <br>&gt; не стоит размещать в кластере<br><br>Конечно стоит: он собирает метрики с экспортеров кластера (и скрейпит бизнес-метрики пейлоада, узнавая о них по лейблам), а затем пушит их в центральный прометей для хранения, анализа и алёртинга.<br><br>&gt;&gt; - а при определённых архитектурах CD -- мб ещё gitlab-runner <br>&gt; Ой не стоит. При сборках gitlab-runner может отъесть всю память у сервисов, <br>&gt; в K8s нет swap, соответственно он питается только оперативкой. При тяжелых <br>&gt; сборках, как раз swap на обычной Linux ноде может выручить.<br><br>Ну так я ж написал CD, а не CI. Естественно это только для https://www.opennet.ru/openforum/vsluhforumID3/136942.html#95 Wed, 28 May 2025 21:06:52 GMT &gt; В основном потому, что такой подход позволяет удобно из единого места конфигурировать <br>&gt; общие ассеты куба.<br><br>И чем это отличается от простого использования kubectl или helm? <br><br>&gt; Это полезно, поскольку помимо собственно пейлоада кластер должен иметь ещё как минимум: <br>&gt; - пару ингресс-контроллеров <br>&gt; - cert-manager c одним или несколькими ClusterIssuer-ами <br>&gt; - ksm <br>&gt; - promtail <br>&gt; - volume provisioner (опционально) <br><br>эти must have<br><br>&gt; прометей<br><br>не стоит размещать в кластере, K8s вообще не очень хорошо подходит для любого рода стейтфулсетов, а для нормальной работы Prometheus в кластаре он должен быть настроен определенным образом, как минимум, должен быть включён CPU Manager с политикой Static и многое зависит от платформы на которых узлы K8s разположены, желательно, чтобы на ней не происходила постоянная миграция RAM и CPU, как встречается в облаке на VMWare например.<br><br>И кстати VictoriaMetrics менее прожорливая и совместима с форматом Prometheus, при этом я бы тоже не размещал её в K8s. Одно д https://www.opennet.ru/openforum/vsluhforumID3/136942.html#94 Wed, 28 May 2025 17:27:53 GMT &gt; YAML-ики кубера и хелм-чаты - уже сами по себе IaC, зачем им обёртка в виде TF?<br><br>В основном потому, что такой подход позволяет удобно из единого места конфигурировать общие ассеты куба.<br>Это полезно, поскольку помимо собственно пейлоада кластер должен иметь ещё как минимум:<br>- пару ингресс-контроллеров<br>- cert-manager c одним или несколькими ClusterIssuer-ами<br>- прометей/ksm<br>- promtail<br>- volume provisioner (опционально)<br>- а при определённых архитектурах CD -- мб ещё gitlab-runner <br><br>плюс бывает такое, что нужно некоторые манифесты накатывать пачками по шаблону, тут пригождаются terraform-модули<br><br>&gt; Это же двойная работа по конвертации.<br><br>вот как раз чтобы не заниматься перегонкой всего в HCL при использовании hashicorp/kubernetes, есть gavinbunney/kubectl<br><br>Например:<br><br>[code]<br>resource "kubectl_manifest" "my-cluster-issuer" {<br> yaml_body = &lt;&lt;EOF<br>apiVersion: cert-manager.io/v1<br>kind: ClusterIssuer<br>spec:<br> acme:<br>&lt;...&gt;<br>EOF<br>}<br>[/code]<br><br>&gt; Или для систем с разрозненными конфигами, чтобы объединит https://www.opennet.ru/openforum/vsluhforumID3/136942.html#93 Wed, 28 May 2025 17:09:25 GMT &gt; Из необлачных самые любимчики -- hashicorp/kubernetes, hashicorp/helm, gavinbunney/kubectl. <br><br>если еще не сильно в этом увязли, крайне не рекомендую такой подход. YAML-ики кубера и хелм-чаты - уже сами по себе IaC, зачем им обёртка в виде TF? Это же двойная работа по конвертации. Может ради TF стейта? А нужен ли он тут, если сами YAML конфиги это и есть стейт по сути?<br><br>Terraform хорош для управления системами с избыточным GUI, в котором легко допустить ошибки и запутаться от обилия опций и где нужно часами всё настраивать, а потом сам забудешь, что ты настраивал. Или для систем с разрозненными конфигами, чтобы объединить их в единый модуль. А когда у нас в распоряжении система такая же удобная, как и сам Terraform (kubectl/helm), нам Terraform уже так не нужен, это как "масло масленное", ИМХО.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/136942.html#92 Tue, 27 May 2025 19:14:02 GMT &gt; У NixOS много проблем, и в основные проблемы это внезапно не проблемы технические по большему счёту.<br><br>Как девопс со стажем скажу так: на любом, абсолютно любом действующем производстве (и не только техническом), основные проблемы -- не технические.<br><br>В общем, это -- нормально.<br>