P
Size: a a a
2019 September 22
ЕО
Stanislav
Сейчас есть ci/cd и в облаке это все работает и с другим облачным мониторингом, но после последних проблем с облаком и то как мы это перенесли хочется перестроить (на мое мнение, правильно, но оно обсуждаемо)
Он говорит, что у него уже всё есть, только не работает
P
Он говорит, что у него уже всё есть, только не работает
Эмммм
S
Он говорит, что у него уже всё есть, только не работает
Работает, только все в облаке и без ad и на другом мониторинге
ЕО
И зачем вы хотите на железо тащить?
ЕО
Чтобы двухфазный коммит ставил колом придожение? :)
ЕО
Таск звучит как возвращение на 10 лет назад, есть облачное приложение без завязки на вендостек, а его хотят затащить в онпрем с active directory
S
И зачем вы хотите на железо тащить?
Потому что с облаком уже были проблемы, после которых надо было переразворачивать дроплет,
ЕО
Вы понимаете, что гибридная архитектура требует во много раз больших сил + постоянного админа?
S
Вы понимаете, что гибридная архитектура требует во много раз больших сил + постоянного админа?
Да
ЕО
Есть причины адекватные для использования гибридной архитектуры: например накопленная экспертиза по эксплуатации онпрема или сложности с PCI/DSS в облаке. Но обычно у таких товарищей всё всерьёз: прямой BGP пиринг с облаком, разделение по зонам ответственности (например онпрем для хранения финансовой информации, а в клауде бекенды сайтов и приложений).
Но факап в облаке это не причина создавать архитектуру, которая и работать-то не будет без переписывания приложения и адаптации его к гибридности. Вы не сможете гарантировать консистентность данных с таким пингом (без атомных часов), расширится с железа на облако бесшовно и быстро -- задача практически нерешаемая, вы в эти переходные моменты больше простоя получите чем от падения самого облака
Но факап в облаке это не причина создавать архитектуру, которая и работать-то не будет без переписывания приложения и адаптации его к гибридности. Вы не сможете гарантировать консистентность данных с таким пингом (без атомных часов), расширится с железа на облако бесшовно и быстро -- задача практически нерешаемая, вы в эти переходные моменты больше простоя получите чем от падения самого облака
S
Есть причины адекватные для использования гибридной архитектуры: например накопленная экспертиза по эксплуатации онпрема или сложности с PCI/DSS в облаке. Но обычно у таких товарищей всё всерьёз: прямой BGP пиринг с облаком, разделение по зонам ответственности (например онпрем для хранения финансовой информации, а в клауде бекенды сайтов и приложений).
Но факап в облаке это не причина создавать архитектуру, которая и работать-то не будет без переписывания приложения и адаптации его к гибридности. Вы не сможете гарантировать консистентность данных с таким пингом (без атомных часов), расширится с железа на облако бесшовно и быстро -- задача практически нерешаемая, вы в эти переходные моменты больше простоя получите чем от падения самого облака
Но факап в облаке это не причина создавать архитектуру, которая и работать-то не будет без переписывания приложения и адаптации его к гибридности. Вы не сможете гарантировать консистентность данных с таким пингом (без атомных часов), расширится с железа на облако бесшовно и быстро -- задача практически нерешаемая, вы в эти переходные моменты больше простоя получите чем от падения самого облака
Вот на уровне простоя, хотелосьбы разобраться какие варианты переходов возможны и что они за собой влекут
ЕО
Давайте так, я перескажу своими словами вашу задачу, как я её понял, а вы поправите.
У вас сейчас есть вся инфраструктура в облаке, вы хотите перетащить всё на физически доступное железо. При этом для нагрузок, которые превышают определенный порог, перебрасывать нагрузку на клауд? При этом ваше приложение -- монолит на джанге
У вас сейчас есть вся инфраструктура в облаке, вы хотите перетащить всё на физически доступное железо. При этом для нагрузок, которые превышают определенный порог, перебрасывать нагрузку на клауд? При этом ваше приложение -- монолит на джанге
A
Stanislav
Гитлаб платный
А можете привести пример сложностей разворачивания такого инстанса?
А можете привести пример сложностей разворачивания такого инстанса?
Если собираетесь юзать Gitlab Geo из Premium или Platinum редакций, то, наверное, не будет (их щупать не доводилось). А вот со всеми более дешевыми редакциями будет вагон костылей.
A
Впрочем, Gitlab Geo, на самом деле, сам по себе тоже выглядит как костыль с кучей ограничений.
https://docs.gitlab.com/ee/administration/geo/replication/index.html#current-limitations
Зато официальный :)
https://docs.gitlab.com/ee/administration/geo/replication/index.html#current-limitations
Зато официальный :)
N
Stanislav
За месяц, согласен, но тут вопрос на пару дней, может быть четыре максимум, вот прям с головой, что бы еще два дня отдохнуть
Я бы разбил тз на конкретные таски и примерно прикинул за скок эти таски можнл выполнить. Чтобы хотя бы иметь представление в часовом эквиваленте по задачам. Да и чтото типа тз уже будет
S
Давайте так, я перескажу своими словами вашу задачу, как я её понял, а вы поправите.
У вас сейчас есть вся инфраструктура в облаке, вы хотите перетащить всё на физически доступное железо. При этом для нагрузок, которые превышают определенный порог, перебрасывать нагрузку на клауд? При этом ваше приложение -- монолит на джанге
У вас сейчас есть вся инфраструктура в облаке, вы хотите перетащить всё на физически доступное железо. При этом для нагрузок, которые превышают определенный порог, перебрасывать нагрузку на клауд? При этом ваше приложение -- монолит на джанге
Да