в идеале да

Оу

для каждой команды своё окружение

раз им треба разные версии

Этож шибанешься

Для каждого набора городить энв

дефайн энв )

я думал о стандартных дев, тест, стэдж, прод

У меня есть приложения аля админка, она ходит в пяток других сервисов которые представляют собой апишки предоставляющие данные

Все это девелопятся разными командами

И для тестирования нужно запускать этот набор из разных версий разных сервисов

вооо отдельное ci для каждой команды тогда а дальше тогда на выходе, то что получилось на конкретный релиз собираешь всё в одну кучу в тимсити например можно это подключением разных VCS Roots организовать, а если пупетом, то можно puppet+r10k+git, где новый энв паппета будет новой веткой в гите (по номеру релиза, напимер) и уже тестить на тестовой ноде админки

ну как вариант )

а версии кто и когда менять будет ?

руками в паппете ? после того как билд прошёл ?

подразумевал, это уже было сделано в пункте: "отдельное ci для каждой команды тогда"

у меня вот вопрос другой, кто какой модуль фаера может посоветовать, окромя паппетлабсовского

чот меня достала уже его ограниченность

или у всех самонапиленные?

речь о iptables само собой

а что там ограниченно ?

А здесь ведь есть те кто паппет для деплоя через CI юзают да ?

А что такого? Я, честно говоря, не вижу особенной разницы с ансиблом (в другом проекте с ним, в обоих случаях гитлаб)

версия пакета хранится в хиере и меняется скриптом деплоя, никакого latest

У меня в докер файле

Т.е. докер файл потом создаёт факт внутри контейнера,

Факты точнее

Для того, что бы быстрее выкатывалось, мы деплоим на версию контейнера от последнего ci,

Именно это запускается по коммиту, но ночью запускается полный деплой на чистое окружение

а что там ограниченно ?

сейчас уперся в то что кастомные полиси не могет

или я херово почитал доку?

или у всех самонапиленные?

У нас самописный, по тому что своя специфика со сложной (наверное) сетью

сейчас уперся в то что кастомные полиси не могет

Поточнее

Поточнее

можно задавать policy только для встроенных цепочек, для своих нельзя

э ?

firewallchain ?

у него есть аттрибут полиси

а гоню

It can only be set on inbuilt chains ('INPUT', 'FORWARD', 'OUTPUT', 'PREROUTING', 'POSTROUTING')

yep

ещё была лажа с указанием наскольких source массивом

бралось последнее значение

пришлось доп. модуль поставить

concat::fragment { target => 'iptables.rules', ... }

Азазаз

если в депенденсях указан то нарм

сейчас уперся в то что кастомные полиси не могет

а что хочется в конечном итоге?

а что хочется в конечном итоге?

хочется разбить input на 3 кастомные цепочки и сделать по умолчанию политику drop в первой будут правила разрешающие то, что трогать не нужно dns, puppet server, zabbix, ssh итд во второй - изменяемые правила, которые будут генериться отдельным софтом от ИБ и посылаемые в гит в виде ямлов для хиеры и тут есть момент, что unmanaged правила надо purge'ить, т.к. софт сам это не умеет. Модуль фаера умеет, но если правила переименовать, например (сменить нумерацию), то они все спуржатся и мы терям коннекты, что не айс, а если оставить как есть, то агент почему-то хранит стейт и ничего не меняет/меняет но не сразу. Поэтому хочется просто каждый раз переименовывать цепочку, дабы гарантированно применять новый набор правил. в третей будет логирование и в случае если с политикой по умолчанию будет слишком жестко, оставим акцепт и последним правилом дроп all to all 1 и 3 цепочки при этом будет удобно пихнуть в common.yaml а вторую генерить посервисно

итить. простыня

многа букаф, скип )

можно конечно проще - версионировать имена правил типа 010 allow some service port 80 ver.1 и каждый раз инкрементить

но чот не красиво кажется

хочется разбить input на 3 кастомные цепочки и сделать по умолчанию политику drop в первой будут правила разрешающие то, что трогать не нужно dns, puppet server, zabbix, ssh итд во второй - изменяемые правила, которые будут генериться отдельным софтом от ИБ и посылаемые в гит в виде ямлов для хиеры и тут есть момент, что unmanaged правила надо purge'ить, т.к. софт сам это не умеет. Модуль фаера умеет, но если правила переименовать, например (сменить нумерацию), то они все спуржатся и мы терям коннекты, что не айс, а если оставить как есть, то агент почему-то хранит стейт и ничего не меняет/меняет но не сразу. Поэтому хочется просто каждый раз переименовывать цепочку, дабы гарантированно применять новый набор правил. в третей будет логирование и в случае если с политикой по умолчанию будет слишком жестко, оставим акцепт и последним правилом дроп all to all 1 и 3 цепочки при этом будет удобно пихнуть в common.yaml а вторую генерить посервисно

мне кажется, лучше свой модуль написать

ну, может, я не права

или вообще не паппетом решать, ага

да можно и паппетом

склоняюсь уже к выбору других решений

можно конечно проще - версионировать имена правил типа 010 allow some service port 80 ver.1 и каждый раз инкрементить

я бы такое писала как раз на паппете или ансибле. Версии в гите, если нужны

мне кажется, можно форкнуть какой-нибудь имеющийся, наиболее похожий модуль, и самостоятельно мантайнить его дальше

я не думаю, что это прям сложно-сложно дописать, что вам нужно

ну дк, я с чего вопрос и начал )

у меня вот вопрос другой, кто какой модуль фаера может посоветовать, окромя паппетлабсовского

^^

для задачи форка модуля стоит не только интерфейсы смотреть, но и исходники

если кто стоковый юзает не форкая, может и не знать особенно что там внутри (ну так, бегло просмотрели с точки зрения ИБ, и всё)

у нас совсем самописный модуль. По тому, что vswitch и много tagged трафика, в том числе tagged vxlan

и там в одном модуле функционал и iptables,

и фильтрации на L2 уровне

ну у нас никто особо не хочет уметь в ruby

хоть оно и не сложно

а вы на питоне напишите, можно exec сделать :)

надо что-то побыстрее

ы

не показывайте просто никому

тогда уж проще iptabels-save iptables-restore генерить каждый раз новые

по секрету скажу, что так многие делают. Потом, когда решают загрузить в паппетфордж, переписывают экзеки на плагины на руби

тоже варик кстати

тогда уж проще iptabels-save iptables-restore генерить каждый раз новые

это нельзя мантайнить, и что бы в гите лежало

можно на мастере через generate

менять строки, а файлики сами в гите

решений то всегда полно

но на сильно красиво надо время, да

Кто-нибудь пробовал настраивать работу кастомных бекендов с использованием скомпиленных переменных?

defaults: lookup_key: eyaml_lookup_key hierarchy: path: "nodes/%{::trusted.certname}.yaml" .. mapped_path[includes, inc, "includes/{%inc}.yaml" glob: "includes/{%{includes_str}}.yaml" .. path: common.yaml site.pp: $includes = lookup('includes', Array[String], 'unique', []) $includes_str = join($includes, ',')

Тут eyaml нормально дешифрует значения из common.yaml и nodes/certname.yaml

Но несмотря на то, что из includes/ нужные ямлы забираются, еямл из них не дешифруется

а datadir как задана? мож она ./includes не включает?

Включает

Дело в том, что оно-таки инклюдится из инклюдов

Но ENC[...] не расшифровываются

я про место где сам бэкенд описан :eyaml:

В defaults

Хм, странно, притащил параметры eyaml'а из puppet/hiera.yaml в директорию с окружением и заработало

policy для пользовательских цепочек не поддерживается самим iptables, модуль паппета тут ни при чем

policy для пользовательских цепочек не поддерживается самим iptables, модуль паппета тут ни при чем

а ведь и правда

подскажите как правильно реализовать остановку сервиса в случая добавления пользователя в систему? в таком варианте ругается что сервис лишний раз описан service { 'sssd-stop': ensure => 'stopped', } service { 'sssd-start': ensure => 'running', } user { 'user.name': ensure => 'present', notify => Service['sssd-stop'] ... ssh_authorized_key { 'user.name_ssh': require => User['user.name], notify => Service['sssd-start'], }

именно остановку? не рестарт?

подскажите как правильно реализовать остановку сервиса в случая добавления пользователя в систему? в таком варианте ругается что сервис лишний раз описан service { 'sssd-stop': ensure => 'stopped', } service { 'sssd-start': ensure => 'running', } user { 'user.name': ensure => 'present', notify => Service['sssd-stop'] ... ssh_authorized_key { 'user.name_ssh': require => User['user.name], notify => Service['sssd-start'], }

name => 'sshd'

если указать дважды один name ругается