а нужны ли мне эти ваши docker-контейнеры?

В смысле? Кому дорого? Ты платишь за расстояния в интернете?

Не за расстояние, а за регион. Например:

https://aws.amazon.com/ec2/pricing/on-demand/?#Data_Transfer

Как правило, хостеры упрощают этот подсчет, вроде «внутри датацентра/к партнерам, по стране, по миру». Я вот плачу те же деньги за трафика как по городу, так и по миру, но фактически я получаю заметно меньшую пропускную способность по миру.

«Программистов» не смущает, что их «проще» почему-то представляет из себя «в пять раз дольше сроки»?

В смысле? Не понял этого момента

а нужны ли мне эти ваши docker-контейнеры? (комментарий)
«Я как-то участвовал в проекте (меня заставили!), в котором 5 человек с кубренетесом, эластиксёрчем и самописным аналогом кафки два месяца ваяли проект, который моя мама сделалабы за неделю не выходя из экселя.»

Я подчеркиваю — это не мои слова, так что не «я один это выдумал». Я сам этой участи избежал, но слышал очень много страшилок от тех, кто непосредственно в таких проектах участвовал.

поскольку перекинуть пол-системы на новую архитектуру чудовищно долго и сложно

Какую новую архитектуру? Ты о чем?

Да хотя бы упомянутый JSON->Protobuf. Какой оцениваешь сложность перехода? Я уверен, что для достаточно сложной и долго разрабаытваемой системы ответ будет «это нереально», потому что отдельные сервисы написаны людьми, который уже не работают в компании, на языках, на которых никто в компании писать уже не умеет.

Расскажите случай из личного опыта

Я не крутил мускуль на AWS, но мои сетапы туда бы и не налезли.

Бэкапы для мускуля — это наименее проблемная штука,

Пока у вас база в пару десятков гигабайт укладывается, так и есть

Ты забываешь, что безудержный рост объема БД — это следствие архитектуры микросервисов, но совсем не обязательный результат для монолитов, у которых объем БД даже может уменьшаться со временем. Для средней системы в вакууме терабайты ACID-ных данных нужно хранить только если в вашей фирме миллион сотрудников или сотни миллионов пользователей.

Перезапустив целый монолит. Похрену на бедных клиентов

Нет. Это же не микросервис, он поддерживает горячее обновление конфигурации.

Но ты не ответил про правильную архитектуру и использования. Ты на сервере логи собираешься что-ли хранить? И смысл тогда в них?

Например:

а нужны ли мне эти ваши docker-контейнеры? (комментарий)

Кстати, хранение логов на локалхосте — не такая уж и плохая задумка, поскольку не забивает сетку без толку.

Судя по остальным комментариям, правильная архитектура логгирования это класть логи в /var/log/service_name и ротировать их логротэйтом

Например, софтина похожая на разрабатываюмую мной:

https://varnish-cache.org/docs/trunk/users-guide/operation-logging.html

То есть ты вообще не представляешь как системы проектируют

У меня есть наглядное пособие:

https://cs5.pikabu.ru/images/big_size_comm/2015-10_5/144562825015356133.png

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

Да как ты не можешь понять, постгрес/мускуль — это примерно как FTP сервер. Какой смысл запускать FTP сервер на дрогой машине? Чтобы по сети смонтировать ФС и отдать с нее FTP сервером файлы по той же сети? Хотя, адепты микросервисов даже тут скажут «ну файлы и сервис же в разных сегментах, для безопасности хорошо, да и FTP сервисов ты можешь запускать сколько хочешь и где хочешь, а с файлами пусть DBA морочится, это не наша проблема, сетка тоже у нас как данность, ее пропускная способность безгранична».

являются лохами в той или иной степени, даже если по итогу выходят в плюсе

Любопытный стиль мышления, где-то я его уже видел

Это когда ты работаешь 40 лет на заводе, чтобы потом получить 10 тыр пенсию после 65 лет. В плюсе же? В плюсе. Но есть ньюанс.

Правильно и залочить на запись всю базу. Отличное решение. И на тот же сервер, где база

InnoDB не лочит базу.

И восстановление из бэкапа 1Gb базы - сутки

SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;

Не благодари.

если sql-proxy или proxysql, то он еще и кэшировать будет.

А куда он денется? Конечно будет, потому что без кэша всё это встанет колом. Только ты забываешь, что при прямом доступе к серверу БД ты кэши получаешь на самом этом сервере, из коробки. То есть, проблему сначала нужно грамотно создать, а потом уже придумывать, как ее решать кэшами.

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

Вообще-то именно PHP является отдаленным прототипом модели микросервисов. На меня звания ЛАМПокрута вешают, но я совсем не ЛАМПер, скорее питонист с большим натягом. Причем, что характерно, даже сам пых отходит от синхронной stateless модели.

Посоветуйте сервис под бэкапы, для личного использования (немного баз, немного файлов, гигабайт на 50-100 в сумме).
Отстал от жизни, не знаю что используют кроме своих серверов - backblaze, crashplan?

Один поехавший почти полгода заливал 80 Тб данных на Backblaze. Но для твоих масштабов такой скорости более чем достаточно, что-то вроде $5 в месяц это стоит.

Потому что dump - это куча insert'ов, а они очень медленные, особенно если в таблице есть индексы

Интересно, что ты будешь делать, если тебе нужно будет по задаче от заказчика/шефа вставить сколько-то миллионов записей в БД. Xtrabackup прикольна, но с этой задачей не справится.

восстановление из бэкапа 1Gb базы - сутки.

По моему перебор

Я наблюдал сравнимые скорости, так что охотно верю.

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

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

Самое дешёвое это https://aws.amazon.com/s3/glacier/pricing/ но там, говорят, опухнешь ждать, пока обратно свои файлы выкачаешь

Ну это на самых халявных уровнях, и то хотят $2.5 за терабайт, а Backblaze дает безлимит за $5. Так-то за $30 можно оперативно выкачать свой терабайт на несколько минут, но я боюсь, что это будет не «самое дешевое».

что безудержный рост объема БД — это следствие архитектуры микросервисов, но совсем не обязательный результат для монолитов

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

InnoDB не лочит базу.

Базу нет, а таблицы лочит.

Не благодари

У меня нет mysql-а в продакшне вообще.

Конечно будет, потому что без кэша всё это встанет колом.

Слушай, ну блин. Ну посмотри на haproxy. Почему через него колом все встанет, а без него будет работать?

Интересно, что ты будешь делать, если тебе нужно будет по задаче от заказчика/шефа вставить сколько-то миллионов записей в БД.

Как это связано с бэкапом? Но наверное привел бы к csv/tsv и загрузил бы через LOAD DATA.

временно подключить логирование

Что? Вы там в своём уме? У нормальных людей логи пишутся всегда

Как залогировать некий …

Точно так же, как и без докера.

Если вы там расходов на $200к насчитали, значит AWS используется на полную катушку. Значит повторить всё это с нуля понадобится много работы крупного отдела админов. 10 человек, год работы, средняя зарплата в $100k, вот мы и попали на лям баксов. И, что ещё хуже, попали на годовую задержку в развитии проекта.

Это когда ты работаешь 40 лет на заводе, чтобы потом получить 10 тыр пенсию после 65 лет. В плюсе же? В плюсе.

Зависит от наличия альтернатив.

Но есть ньюанс.

Вот это он и есть. Лохом ты являешься, если этому плюсу есть более выгодные реальные альтернативы.

горячее обновление конфигурации

О да, детка, давай подкручивай конфигурацию на лету. Чтобы потом никто не смог ее воспроизвести.

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

• Локалхост помер — и все логи с ним.
• Надо отследить какой-то запрос по логам нескольких локалхостов. Сегодня будет напряженный день.

после остановки сервиса хоть солнце не свети

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

Да как ты не можешь понять(с), я говорю не о «зачем», а о случае, если это уже сделано. Если нашлись причины пускать БД в контейнере или без него на VPS. Не бывает созданных лично для тебя шаблонных ВМ с терабайтными хранилищами, поэтому ты выбираешь ВМ по процу/памяти, а хранилище докупаешь отдельно, и лежит оно тоже отдельно, и поэтому переживает смерть ВМ.
И поэтому - в стотыщный раз - копировать данные при пересоздании ноды в пределах ДЦ не требуется.

Какой смысл запускать FTP сервер на дрогой машине? Чтобы по сети смонтировать ФС и отдать с нее FTP сервером файлы по той же сети?

Да не «смонтировать ФС по сети», а «провайдер мне подоткнет в ВМ сетевое хранилище, видимое мной как блочное устройство».

Я ему третий день об этом толкую. Но он, видимо, слишком занят войной на несколько фронтов, поэтому ниасиливаю донести.

Я не крутил мускуль на AWS,

Вас не смущает, что вы, не имея никакого опыта в теме, спорите со специалистом?

безудержный рост объема БД — это следствие архитектуры микросервисов

А на следующем круге мы узнаем, что микросервисы придумал Гитлер.

Во-первых, маргинальщина, наверное имеющая свою область применения, но не очень широкую. Во-вторых, вам докер запрещает «logs to a shared memory segment, called the VSL - the Varnish Shared Log. When the end of the segment is reached we start over, overwriting old data»?

Backblaze дает безлимит за $5.

А в чём подстава?

Мне кажется он просто в глаза не видел ни одного контейнера. Поэтому он судит о них по названию.

Отсюда какие-то странные вопросы про репликацию, логи, данные и т.п.

Ну то есть он просто не знает, что контейнер может писать данные на диск, логи в /var/log, запускаться по юниту systemd и т.д. и т.п.

По-моему, здесь давно не про контейнеры, а про микросервисную архитектуру и вообще всё.

Ну это отдельная проблема, осознать что контейнер, микросервис и облачная оркестрация - это три разных человека.

Да даже и облачная окрестрация бывает сильно разной. У нас вон и дженкинс в openshift выложен. Понятно что никто не настраивает ему автоскейлинг и green-blue deployment, он просто тихо сидит себе и раз в полгода обновляется.

InnoDB не лочит базу.

Базу нет, а таблицы лочит.

Нет, не лочит.

Слушай, ну блин. Ну посмотри на haproxy. Почему через него колом все встанет, а без него будет работать?

При чем тут он. Мы говорили про БД. Когерентные кэши в принципе не могут работать быстрее прямого доступа к БД, потому что прямой доступ к БД — это и есть тот самый когерентный кэш.

Как это связано с бэкапом? Но наверное привел бы к csv/tsv и загрузил бы через LOAD DATA

Вот, то есть, вставку ты будешь делать одной операцией, а бэкап так восстановить, видите ли, нельзя, только insert-ом по одной строчке.

Что? Вы там в своём уме? У нормальных людей логи пишутся всегда

Петабайт уже набрали в своей системе?

Точно так же, как и без докера

Ну и зачем тогда играться в 24/7? Я сомневаюсь, что ваши сервисы умеют в горячую перезагрузку конфигов — вместо этого их нужно убивать и поднимать заново.

Если вы там расходов на $200к насчитали, значит AWS используется на полную катушку

На полную катушку — не значит «эффективно». Достаточно нанять рукожопов, для которых вычислительные мощности и сеть безграничны, и амазон тебе любезно «смасштабирует» систему до сотен тысяч под нагрузкой.

Значит повторить всё это с нуля понадобится много работы крупного отдела админов. 10 человек, год работы, средняя зарплата в $100k, вот мы и попали на лям баксов

Чиво? Почему не сто админов? Как там, «сколько админов нужно, чтобы вкрутить mysql...».

О да, детка, давай подкручивай конфигурацию на лету. Чтобы потом никто не смог ее воспроизвести

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

Локалхост помер — и все логи с ним

Будто у тебя каждый день локалхосты дохнут как мухи.

Надо отследить какой-то запрос по логам нескольких локалхостов. Сегодня будет напряженный день

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

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

Дальнейшее обсуждение вопроса читайте в ветке:

а нужны ли мне эти ваши docker-контейнеры? (комментарий)
а нужны ли мне эти ваши docker-контейнеры? (комментарий)

Петабайт уже набрали в своей системе?

Вы там в церн играете?

Ну и зачем тогда играться в 24/7?

Вопрос не понят.

вместо этого их нужно убивать и поднимать заново.

Как будто что-то плохое.

Да как ты не можешь понять(с), я говорю не о «зачем», а о случае, если это уже сделано. Если нашлись причины пускать БД в контейнере или без него на VPS. Не бывает созданных лично для тебя шаблонных ВМ с терабайтными хранилищами, поэтому ты выбираешь ВМ по процу/памяти, а хранилище докупаешь отдельно, и лежит оно тоже отдельно, и поэтому переживает смерть ВМ.
И поэтому - в стотыщный раз - копировать данные при пересоздании ноды в пределах ДЦ не требуется

Один экземпляр мускуля с сетевым накопителем NVMe положит тебе целый InfiniBand на 60 Гбит/с. Один! По этой причине единственный адекватный подход — это скопировать изначально том по сети на тот хост, где будет выполняться сервис БД.

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

Попробуйте не нанимать рукожопов. Это и без AWS хороший совет.

Чиво?

Таво.

Вас не смущает, что вы, не имея никакого опыта в теме, спорите со специалистом?

Не смущает. Меня смущает весьма специфический опыт этого специалиста.

безудержный рост объема БД — это следствие архитектуры микросервисов

А на следующем круге мы узнаем, что микросервисы придумал Гитлер

Я уже отвечал, что архитектура микросервисов подразумевает «тянуть старые API и форматы данных до скончания веков», а это значит, что БД мы оптимизировать-реструктурировать не можем, значит, что мы будем сохранять сырые бессхемовые данные и парсить их на лету — этот подход и приводит к тому, что данных у БД становится больше, больше, еще больше, только больше.

Во-первых, маргинальщина, наверное имеющая свою область применения, но не очень широкую. Во-вторых, вам докер запрещает «logs to a shared memory segment, called the VSL - the Varnish Shared Log. When the end of the segment is reached we start over, overwriting old data»?

В какой эластик ты будешь это совать дальше? У варниша эту штука из коробки как бы позволяет реализовывать произвольный уровень логирования, и при этом не захламлять сетку.

А в чём подстава?

Есть упомянутые выше ограничение на примерно 2 ТБ трафика в день. И всё. У них очень дешевое дисковое пространство, даже в тёпленькой вариации B2 загрузка и скачивание терабайта данных каждый месяц обойдется в $15. Конечно, это в основном канал, но я думаю, что на бэкапы у них являются низкоприоритетным трафиком.

архитектура микросервисов подразумевает «тянуть старые API и форматы данных до скончания веков», а это значит, что БД мы оптимизировать-реструктурировать не можем,

– Вы стоите на самой низшей ступени развития, – перекричал Филипп Филиппович, – вы ещё только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости о том, как всё поделить… А в то же время вы наглотались зубного порошку…

У варниша эту штука из коробки как бы позволяет реализовывать произвольный уровень логирования, и при этом не захламлять сетку.

Ну, подключайте эту вашу игрушку к контейнеру, я вам не запрещаю.

Ну то есть он просто не знает, что контейнер может писать данные на диск, логи в /var/log, запускаться по юниту systemd и т.д. и т.п

Конечно может, но если бы всё было так просто, то контейнер бы не применяли — не находишь? Контейнер нужен чтобы обрезать лишнюю руку-ногу сервису. Я пишу о том, что есть реальные проблемы с данными, с контейнерами и без них, и контейнеры никак эти проблемы не решают, а могут еще собственного геморроя докинуть в кучу.

Ну это отдельная проблема, осознать что контейнер, микросервис и облачная оркестрация - это три разных человека

Я сразу могу написать — я фанат распределенных систем, и да, грамотные распределенные системы вполне себе пишут без контейнеров и микросервисов. Друго дело — зачем нужен контейнер? Запускать постгрес можно и нужно без контейнера. Монолиты с состояниями тоже немного смысла крутить в контейнерах, поскольку кроме них на машине, обычно, ничего нет. Контейнера нужны, чтобы расплодить много-много похожих конфигураций одного и того же — а это очевидные микросервисы. А зачем микросервисы нужны, если не для того, чтобы поиграться в гугл?

У нас вон и дженкинс в openshift выложен. Понятно что никто не настраивает ему автоскейлинг и green-blue deployment, он просто тихо сидит себе и раз в полгода обновляется

И зачем ему быть в openshift?

Вы там в церн играете?

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

Ну и зачем тогда играться в 24/7?

Вопрос не понят

вместо этого их нужно убивать и поднимать заново.

Как будто что-то плохое

Хорошо, я не догадался сразу — всю нагрузку и всё состояние у вас держит кэш и БД, потому сервисы можно убивать хоть пять раз в секунду. Тогда настоящим вопросом становится логирование операций в БД — её точно по первой хотелке не перезапустишь.

Попробуйте не нанимать рукожопов. Это и без AWS хороший совет

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