и есть ли у них площадки кроме парижа и амстердама

не могу найти у них цену за гигабайт на сайте

за гигабайт чего?

и есть ли у них площадки кроме парижа и амстердама

нет. А где тебе надо?

восточное побережье США

амазон очень дорого, да?

~50 белых айпи, ~50 сетевых интерфейсов, ~24 Тб трафика в месяц в одну и столько же в другую сторону. да, дорого.

амазон дорого для всех так то

я вот чешу репу и чую что надо было заказчику брать колокейшн

~50 белых айпи, ~50 сетевых интерфейсов, ~24 Тб трафика в месяц в одну и столько же в другую сторону. да, дорого.

lowendbox.com но там такие варианты...

https://www.packet.net/ вот эти выглядят ничего

амазон дорого для всех так то

ну, по разному, насколько я знаю

https://www.packet.net/ вот эти выглядят ничего

там такой прайсинг...

ну, по разному, насколько я знаю

да не, амазон норм если ты совсем стартап или когда ты как бы не хочешь связываться с поддержкой инфраструктуры, но денег у тебя много. А так нерельно выходит

там такой прайсинг...

ну у меня самый упор по цене как раз в трафик идет. текущие сервера простаивают по-большому счету.

ну у меня самый упор по цене как раз в трафик идет. текущие сервера простаивают по-большому счету.

майни, чтобы не стояли

ха

хм.

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

ну и возможность заюзать всяческий реди по щелчку пальцев без необходимости его накатывать конфигурять и тому подобное...

это расхалаживает.

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

Можешь рассказать, чем именно плохим оборачивается такое удобство?

Можешь рассказать, чем именно плохим оборачивается такое удобство?

написал же

ну и возможность заюзать всяческий реди по щелчку пальцев без необходимости его накатывать конфигурять и тому подобное...

написали себе такое же с ансиблом и докером

Можешь рассказать, чем именно плохим оборачивается такое удобство?

ну вот еще куда ни шло когда у тебя постгре там в rds а не динамо или автора какая нибудь.

написали себе такое же с ансиблом и докером

а на железо одно и тоже раскатываешь? и наверное и стедж и дев и прод все в одном месте?

написал же

Что в твоём понимании сервис? Почему ты не считаешь его частью инфраструктуры? Что плохого в том чтобы думать о базе как о сервисе, а не как “части инфраструтуры”?

а на железо одно и тоже раскатываешь? и наверное и стедж и дев и прод все в одном месте?

сейчас 4 разных стенда, виртуализация разная, схд разные. Максимум абстракции от железа.

Извини что так много вопросов, просто мне на самом деле не понятно.

Что в твоём понимании сервис? Почему ты не считаешь его частью инфраструктуры? Что плохого в том чтобы думать о базе как о сервисе, а не как “части инфраструтуры”?

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

а так то всё круто

Что в твоём понимании сервис? Почему ты не считаешь его частью инфраструктуры? Что плохого в том чтобы думать о базе как о сервисе, а не как “части инфраструтуры”?

потому что когда думаешь о базе как о сервисе тебе не звонят в три часа ночи что у тебя мастер разъехался, например. тебе не надо смотреть за latency между тачками ну и голова у тебя не болит что у тебя сейчас шпиндели в одном раке колом встанут

ну типа да, неистово плюсую

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

сейчас 4 разных стенда, виртуализация разная, схд разные. Максимум абстракции от железа.

ну вот у тебя закончилась емкость на железках, не можешь ты больше напихать виртуалок в одну тачку(нет смысла) и все, весь ансибл с докерами оказывается не нужен, так ведь?

ну вот у тебя закончилась емкость на железках, не можешь ты больше напихать виртуалок в одну тачку(нет смысла) и все, весь ансибл с докерами оказывается не нужен, так ведь?

ставишь еще одну тачку и скейлишь

не понял вопрос

ставишь еще одну тачку и скейлишь

иногда тачку надо заказывать и ждать...

и вот иногда ждешь ее и ждешь а потом опа а она уже и не нужна

ну так заказываешь когда у тебя кончилось 70% ну 80 т.е. как бы это не внезапно

я говорю про инфраструткуру не из 3 серверов

все так, короче, больше всего расслабляет отсутствие необходимости планировать ресурсы

да, само собой

я о чем и говорю, надо реально сидеть считать емкость схд планировать тачки думать о eol ну и всяком таком, гарантии поддержка, баги в процах интела как заплатки накладывать чтобы оно не поломало тебе прод.

это все то о чем ты не задумываешься когда ты сидишь в уютненьком амазоне

на практике если ты пользуешься виртуальным дц в россии, а не на амазоне то всё равно все это делаешь :D

в основнм всегда упираешься в схд

просто 11 проблем из 10

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

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

Народ, как указать перезапуск контейнеров при перезагрузки хост машины в docker_service? Это же не дело что они живут до первого ребута..

restart policy always

В доках к docker_service такой опции нет

это в compose file указывается

это в compose file указывается

А если у меня compose пишется сразу в playbooks? Или нужно отдельно создать compose и тянуть его через docker_service?

А если у меня compose пишется сразу в playbooks? Или нужно отдельно создать compose и тянуть его через docker_service?

если inline сервисы определяются, то туда добавить

если inline сервисы определяются, то туда добавить

Не совсем понял. Я прописываю все настройке напрямую в таске. Подскажите плз куда добавить restart policy?

на телефоне сложновато

redis: image: redis:alpine restart: always

В секции definition ?

да

да

Спасибо) Уже пробую

Привет, подскажите. Стоит задача, чтоб в качестве зависимости для роли предварительно отработал плейбук. Соответственно не хочется руками снгачала запускать плейбук, а потом роль. Хотелось бы сразу запустить роль и получить конечный результат. Подскажиет куда копнуть. Как сделать наиболее правильно ?

Привет, подскажите. Стоит задача, чтоб в качестве зависимости для роли предварительно отработал плейбук. Соответственно не хочется руками снгачала запускать плейбук, а потом роль. Хотелось бы сразу запустить роль и получить конечный результат. Подскажиет куда копнуть. Как сделать наиболее правильно ?

Если верить документации...

Которую нужно читать

То meta

Ток зависимости должны быть от роли всё таки

Или у тебя плейбук другой хост настраивает?

Или у тебя плейбук другой хост настраивает?

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

Впихнуть таски в отдельную роль не?

Впихнуть таски в отдельную роль не?

таски и так в качестве роли... остался отдельный плейбук... вообще возможно отключить сбор фактов для одного таск и включить для последующих в одной роли? в иделе конечно было бы сделать это в одной роли.. но пока не понимаю как

Можно отключить для роли, на сколько я помню

Зависимости ролей пишутся в meta

Правда есть легенда о некошерности смены дефолтных портов ssh на хосте

Зависимости ролей пишутся в meta

Понял, ну тогда получается верным решением будет создание отдельной роли для смены дефолтного порта с отключением сбора фактов и подключением его в качестве зависимости для роли new_server через meta

Да

Но я не понимаю зачем менять порт

зависимости через мета работают не так как ожидается

В зависимости от случая же

например если вызывающий плейбук имеет become то вызываемый тоже получает бекам

У меня все работает так как ожидалось например