Я вот пытаюсь понять, при динамическом inventory файле как люди не раздражаются ограничиваться json выводом?
Я костыле-писатель, формирую файл баш-скриптом и всегда указываю
ansible-playbook example.yml -i `inventory.sh`
Как обходить дупликацию хостов находящихся в разных сущностях, и нужно ли это делать?
И что-то до меня никак не доходит, как засунуть в сущность В все хосты, кроме тех что в сущности А, пробовал так:
Всего год прошёл, спасибо за быстрый ответ. Давно отказались от ваших услуг и никому советовать не будем в дальнейшем. Лучшим ответом с вашей стороны, даже спустя год, были бы извинения за проблемы с сетью(даже если их нет). А доказывать что у вас проблем с сетью нет надо не в комментах, а статьями с графиками(я бы после такой статьи выглядел идиотом), это же маркетинг. Продайте нам ваши услуги, а не критикуйте открытым матом.
Тоже интересует этот вопрос. На работу хожу со своим ноутом у которого 165х162 DPI 13.3 FHD, а подключаю обычный монитор FHD c 92 DPI. Просто поставил более крупный шрифт, потому что не захотел возится.
Мне нравится выражение «несовместимо с существующей инфраструктурой», а может тогда они дадут спецификацию на текущую инфраструктуру и мы поправим? Оборонка сразу пошлёт, а остальные тоже сошлются на какую нибудь гос. тайну. Да и в тендере на гос. закупки все пункты обязаны быть указаны, иначе ссылаться на них неправомерно. Если в тендере есть условия и они все выполнены, то формулировка «не отвечает требованиям» означает ошибку при проведении тендера и требует отмены результатов, и повторного проведения аукциона. Иначе всё это филькина грамота.
Добавить более стойкий хеш кусочков в торренты и добавить поддержку в клиенты. В случае если с sha1 по итогу загрузки есть проблема несовпадения хешей(проверка md5 итогового файла например), то проверять каждый кусочек с более стойким алгоритмом. Обратная совместимость сохраняется, так как есть и использование старых технологий и обход подмены кусочков в новой версии. По истечении некоторого времени поддержку говна мамонта из технологии выпилить и работать только с более стойким алгоритмом. Проблема потокового воспроизведения торрентов решается переключением на новый алгоритм, для потока всё равно нужен комп мощнее калькулятора.
Моё мнение, что есть какой то срок договорённостей 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. Да и логика микросервисов ломается, хотя все её ломают кроме меня. За то что я идейный меня уже пожурили на работе.
Я костыле-писатель, формирую файл баш-скриптом и всегда указываю
Как обходить дупликацию хостов находящихся в разных сущностях, и нужно ли это делать?
И что-то до меня никак не доходит, как засунуть в сущность В все хосты, кроме тех что в сущности А, пробовал так:
Нет, я выдвинул предположение о том что правильней для такого функционала было бы использовать. Все последующие комментарии были только для более полного и подробного описания идеи. Надеюсь вы не серчаете на меня.
Нет, мы через оркестрацию задаём всем физическим машинам настройки докера. А именно удаляем все имеющиеся сети и добавляем 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. Разве не это есть упрощение?
за это руки оторвать.