Моё мнение, что есть какой то срок договорённостей 7 или 90 дней, после которого если компания производитель не закрыла баг\уязвимость она подвергает опасности своих пользователей, а не гугл или другой публикатор информации. Тебе по тихому сказали где проблема? Ты болт забил? Ты и виноват.
Как можно проследить появление такого функционала как параллельная обработка действий? На митапе было обсуждение что alerter однопоточен и при большом количестве уведомлений он не успевает своевременно прогнать все уведомления.
Вы можете показать практически работающее решение, на основании того, как вы его описываете?
Нет, я выдвинул предположение о том что правильней для такого функционала было бы использовать. Все последующие комментарии были только для более полного и подробного описания идеи. Надеюсь вы не серчаете на меня.
Нет, мы через оркестрацию задаём всем физическим машинам настройки докера. А именно удаляем все имеющиеся сети и добавляем macvlan. И к контейнеру привязывается единственная наша сеть через macvlan.
Для какой системы мониторинга?
Вы в badoo используете заббикс с LLD на основе хостнеймов. Читал с митапа заббикса ваш доклад.
мы меняем default gw, который мы проставляли при создании MACVLAN сети на .254, что сделать без NET_ADMIN не получится
Через dhcp вы так же можете получить маршруты, в том числе и default gw.
эта запись будет разной, в зависимости от хоста, на котором запускам контейнер. Да, тоже самое значение я передаю позже в -e HOST_IP=1.1.1.17, его можно использовать. Но т.к. сущности разные, то и указываю отдельно там и там.
это я не совсем понимаю, плодить сущности конечно не хорошо, но если это обход Ограничения технологии by design: доступность контейнера с хоста и доступность хоста из контейнера отсутствует. То думаю это самое простое решение.
нет, нельзя это указывать в Dockerfile, т.к. там мы можем указать какие директории будем экспортировать, а нам нужен еще и импорт.
Я каждый убранный пункт прокомментировал, всё что мы не указали подтягивается либо из дефолтных настроек докера, либо из dhcp, либо из dns. Так как у вас в любом случае есть свои dns и dhcp сервера и выносить с них этот функционал не было никакого смысла. Что же касается дефолтных настроек докера то у вас физические машины и сами контейнеры управляются через оркестрацию вашу. Так что я просто использовал то что у вас есть для упрощения нового.
Вот такое docker run -d \
// здесь мы выбираем тип сети для контейнера, выдаем ему ip-адрес:
// Этого можно было бы не делать будь у вас DHCP
--net=c_services --ip=1.1.2.17 \
// указываем имя, т.к. просто удобнее смотреть потом на docker ps. Можно не указывать.
// Это необходимо для создания фильтрации в централизованном лог сервере
--name=$VARIABLE \
// это опять же приятнее рандомайза, т.е. дело эстетики. Можно не указывать.
// Это необходимо для системы мониторинга, но можно через dhcp проставлять
-h $VARIABLE.local \
// да, тут чуть сложнее и мне это нужно:
// это так же решается dhcp сервером
--cap-add=NET_ADMIN \
// добавить запись в /etc/hosts. Можно сделать иначе, но так оно прозрачнее.
// если у нас есть dhcp значит и dns можно поставить и управлять этим можно будет централизованно
--add-host='nginx.localhost:1.1.1.17' \
// переменные окружения. То, что вы говорили про порт для приложения:
// этого тоже можно избежать забирая $VARIABLE из хостнейма и присвоенный адрес из системы
-e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 \
// чтобы не указывать вереницу служебных директорий, которые нам нужны в определенных контейнерах.
// Это сугубо специфичное и должно указываться в dockerfile
--volumes-from=badoo_loop \
// имя образа:
dockerio.badoo.com/cteam/$VARIABLE:2.30.0_994
Можно с лёгкостью уменьшить до VARIABLE=SERVICE;docker run -d \
// Это необходимо для создания фильтрации в централизованном лог сервере, можно наверно не указывать
--name=$VARIABLE \
// имя образа:
cteam/$VARIABLE:2.30.0_994
Итого наш контейнер запускается и работает независимо от ключей, требуется только указать имя образа в registry. Разве не это есть упрощение?
В любом случае по моему проще добавить DHCP в этот отдельный VLAN, а условие отдачи маршрутов натянуть через типовой ключ(hostname или ip адрес, да любой который подходит). Ну а про докеры я просто поплакался.
А почему вы не рассмотрели получение маршрутов от DHCP в зависимости от хостнейма? И огород городить бы не пришлось с Linux capabilities. Да и логика микросервисов ломается, хотя все её ломают кроме меня. За то что я идейный меня уже пожурили на работе.
Судо критично необходимо если админов больше 1. А перевешивание на другой порт помогает от китайских ботов, хотя я уже даже на домашнем роутере перестал перевешивать порт. Трафик от ботов не такой чтобы с этим гемороится. А так считаю что опытный админ закрывает вход под рутом и прописывает судо баш в башрс, просто потому что это въедается в голову из компаний где больше 1 админа. Закрывать доступ по айпи это супер если у тебя единственная точка входа со статическим айпи, к которой ты подключаешься с помощью сертификатов. И вводить пароли по факту не надо и удобно и безопасно. А чтобы не боятся потерять ключи хранить их надо только в 1 месте на зашифрованном диске(и распечатка в сейфе).
Увы, смарт-карты не понимает. Но настроив как написано в инструкции 1 раз только для работы в ГУИ. Всё будет работать. На любой ОС бывают задачи которые надо выполнять через системный/сервисный функционал(консоль).
Потом в апплете НМ — сетевые соединения — добавить — openconnect — заполняем шлюз, путь к СА файлу и в поле сертификат пользователя (или личный ключ) указываем как в скрипте pkcs11:model=eToken;id=%XX%XX
Возможно придётся через CLI networkmanager добавить этот параметр, но зато всё в гуи.
Нет, я выдвинул предположение о том что правильней для такого функционала было бы использовать. Все последующие комментарии были только для более полного и подробного описания идеи. Надеюсь вы не серчаете на меня.
Нет, мы через оркестрацию задаём всем физическим машинам настройки докера. А именно удаляем все имеющиеся сети и добавляем macvlan. И к контейнеру привязывается единственная наша сеть через macvlan.
Вы в badoo используете заббикс с LLD на основе хостнеймов. Читал с митапа заббикса ваш доклад.
Через dhcp вы так же можете получить маршруты, в том числе и default gw.
это я не совсем понимаю, плодить сущности конечно не хорошо, но если это обход Ограничения технологии by design: доступность контейнера с хоста и доступность хоста из контейнера отсутствует. То думаю это самое простое решение. Здесь я наверно не прав.
docker run -d \
// здесь мы выбираем тип сети для контейнера, выдаем ему ip-адрес:
// Этого можно было бы не делать будь у вас DHCP
--net=c_services --ip=1.1.2.17 \
// указываем имя, т.к. просто удобнее смотреть потом на docker ps. Можно не указывать.
// Это необходимо для создания фильтрации в централизованном лог сервере
--name=$VARIABLE \
// это опять же приятнее рандомайза, т.е. дело эстетики. Можно не указывать.
// Это необходимо для системы мониторинга, но можно через dhcp проставлять
-h $VARIABLE.local \
// да, тут чуть сложнее и мне это нужно:
// это так же решается dhcp сервером
--cap-add=NET_ADMIN \
// добавить запись в /etc/hosts. Можно сделать иначе, но так оно прозрачнее.
// если у нас есть dhcp значит и dns можно поставить и управлять этим можно будет централизованно
--add-host='nginx.localhost:1.1.1.17' \
// переменные окружения. То, что вы говорили про порт для приложения:
// этого тоже можно избежать забирая $VARIABLE из хостнейма и присвоенный адрес из системы
-e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 \
// чтобы не указывать вереницу служебных директорий, которые нам нужны в определенных контейнерах.
// Это сугубо специфичное и должно указываться в dockerfile
--volumes-from=badoo_loop \
// имя образа:
dockerio.badoo.com/cteam/$VARIABLE:2.30.0_994
Можно с лёгкостью уменьшить до
VARIABLE=SERVICE;docker run -d \
// Это необходимо для создания фильтрации в централизованном лог сервере, можно наверно не указывать
--name=$VARIABLE \
// имя образа:
cteam/$VARIABLE:2.30.0_994
Итого наш контейнер запускается и работает независимо от ключей, требуется только указать имя образа в registry. Разве не это есть упрощение?
за это руки оторвать.
dnf install -y gnome-networkmanager-openconnect networkmanager-openconnect openssl gnutls
Потом в апплете НМ — сетевые соединения — добавить — openconnect — заполняем шлюз, путь к СА файлу и в поле сертификат пользователя (или личный ключ) указываем как в скрипте pkcs11:model=eToken;id=%XX%XX
Возможно придётся через CLI networkmanager добавить этот параметр, но зато всё в гуи.