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

есть реальные проблемы с данными, с контейнерами и без них

А зачем ты это пишешь в треде про контейнеры?

Хотя ладно, я не хочу этого знать.

есть реальные проблемы с данными, с контейнерами и без них

А зачем ты это пишешь в треде про контейнеры?

Затем, что ОП пытается прикрутить контейнеры, которые ему просто НЕ НУЖНЫ. Нынче люди используют контейнеры не для того, чтобы решить задачу, а просто потому что контейнеры используют все — прямо как с вашим дженкинсом.

byko3y, вы разработчик, но суждения в разных тредах весьма РАСПЛЫВЧАТЫ.

Для РАЗРАБОТЧИКА это ПЛОХО.

Учитесь понимать суть, а не НАБРАСЫВАТЬ В ТРЕДАХ!

Скорее всего вы обидитесь, но когда обида поутихнет подумайте о сказанном.
Еще раз

НАБРАСЫВАТЬ и ПОНИМАТЬ это РАЗНОЕ ...

PS: Пост не для того, чтобы вас принизить.
Разработчик вы не плохой, но без понимания СУТИ, толку мало будет …

Владимир

точного воспроизведения можно добиться через логи?

Лечения кариеса тоже можно добиться через анус. Но это не точно.

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

Авось пронесет, ага.

И да, если у тебя этих локалхостов тыщи, они таки да будут дохнуть практически непрерывно.

Учитесь понимать суть, а не НАБРАСЫВАТЬ

Ты шо, ты шо, тише. Последнего контент-криэйтора нам испортишь.

А вольюм на нфсе, ага.

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

Да, где-то так, гигабайты-первые десятки гигабайт в день и получаются. На обычном эластике, в обычном кубернетесе, на вашем любимом AWS.

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

А если ту же нагрузку без докера запускать, вы будете БД по сто раз на дню перезагружать?

При этом важно совершать все действия в инсталляторе и установщике патчей в нужном порядке, выбирая нужные галочки. Шаг в сторону и всё заново (ну первый раз заново, второй раз уже со снапшота).

Можно проделать это один раз, запаковать инсталляцию Оракла в архив, а на новой системе ставить его распаковкой архива с последующим запуском скрипта для клонирования Oracle Home. И это не какой-то хак, а способ, поддерживаемый Oracle. В одном месте Oracle так и ставился запуском одного скрипта.

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

Давно это стало редкостью? Самый нормальный подход, не могу представить, чтобы было по-другому. Или надо устроиться туда, где все копошатся на одном сервере, чтобы ощутить преимущества докера?

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

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

При чем тут он.

haproxy? Как пример понятного тебе (надеюсь) баллансировщика.

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

а бэкап так восстановить, видите ли, нельзя

Ты вообще не представляешь что находится в файле, который генерит твоя команда из кронтаба? Выполни и посмотри.
Через LOAD DATA нельзя загрузить sql команды.

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

Да это ж прямо как дедовский мэйнфрейм.

Если нужна точная синхронизация между логами,

Что такое точная синхронизация? В эластик обычно все пишется, так как он позволяет осуществлять очень удобный поиск.

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

Ты бредишь уже

А вольюм на нфсе, ага

А сервер NFS в KVM, а KVM на 9P...

Один экземпляр мускуля с сетевым накопителем NVMe положит тебе целый InfiniBand на 60 Гбит/с.

Эмммм нет, не положит. Это нужно, чтобы БД непрерывно раздавала какие-то зигабайтные блобы непонятно кому, зачем и главное по какой среде.

скопировать изначально том по сети на тот хост

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

Да это ж прямо как дедовский мэйнфрейм.

Все повторяется. Сейчас пишут плейбуки на Ansible, деды писали плейбуки на JCL :)

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

А куда его деть? Сервер с рейдмассивом и пачкой дисков на замену держать под кроватью? Паппет-мастер разворачивать?

Ему надо 15 гб памяти, диск, веб сервер с поддержкой SSL, логирование в централизованный сервис с возможностью долгосрочного аудита. В openhift у нас это всё настроено из коробки один раз, достаточно запустить контейнер с одним процессом, который пишет лог в stdout и сразу получаешь всё, от https до метрик, мониторинга и логов.

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

У нас вон и дженкинс в openshift выложен.

Не могу оценить, я опеншифт щупал сто лет назад, когда там был free tier или как там оно называлось. Не знаю возможностей.

Сто лет назад Openshift был самостоятельным PaaS, написанным на Ruby и использующим концепцию картриджей.

С тех пор мир сильно изменился и теперь OpenShift - это Kubernetes с несколькими дополнительными операторами, добавляющими пару-тройку полезных абстракций типа Image Stream, Build Configuration и Route

Да, где-то так, гигабайты-первые десятки гигабайт в день и получаются. На обычном эластике, в обычном кубернетесе, на вашем любимом AWS

А потом начинаются претензии «откуда ты взял, что микросервисы приводят к раздуванию БД на ровном месте». Ты подписался на микросервисы, и сразу же стал бигдатой, и отсюда становится очевидным выбор БД для микросервисов — мускуль такое не вывезет. Собственно, и немускули не особо вывозят такой объем жмыха гонять.

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

А если ту же нагрузку без докера запускать, вы будете БД по сто раз на дню перезагружать?

Нет, я просто не буду логировать БД, потому что у меня будет иной центральный узел обработки информации.

При чем тут он.

haproxy? Как пример понятного тебе (надеюсь) баллансировщика

Это прокси-балансировщик с совершенно иной функцией. Моя претензия была к производительности и отказоустойчивости механизмов коорединации, то есть, БД, а haproxy ничего не координирует.

Если существует подход, позволяющие снизить требования к персоналу, то это просто прекрасно

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

Что такое точная синхронизация? В эластик обычно все пишется, так как он позволяет осуществлять очень удобный поиск

Если чо, это прямо основная беда распределенных систем. Гугл под это дело Spanner с атомными часами и GPS сделал. У вас в датацентре стоит сервер времени с GPS синхронизацией? Если нет, то у меня для вас печальные новости — время в логах будет уезжать на минимум на десятки миллисекунд. За это время сотни запросов могут выполниться.

Эмммм нет, не положит. Это нужно, чтобы БД непрерывно раздавала какие-то зигабайтные блобы непонятно кому, зачем и главное по какой среде

Сам сервис БД читает намного больше данных, чем отдает по сети. Он для того и сделан, если что.

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

Да ты бредовую архитектуру описываешь.

Ему надо 15 гб памяти, диск, веб сервер с поддержкой SSL, логирование в централизованный сервис с возможностью долгосрочного аудита. В openhift у нас это всё настроено из коробки один раз, достаточно запустить контейнер с одним процессом, который пишет лог в stdout и сразу получаешь всё, от https до метрик, мониторинга и логов

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

И да, если у тебя этих локалхостов тыщи, они таки да будут дохнуть практически непрерывно

Гугл в треде — всем укрыться в BigTable.

Блочные устройства через сеть - это реальность, бредовая или нет. Я о реальности говорю.

Через LOAD DATA нельзя загрузить sql команды

А я с этим спорил, что ли? Есть несколько способов вставки данных, в том числе больших объемов — параметры для очень быстрой вставку SQL я писал выше по треду.

А я с этим спорил, что ли?

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

параметры для очень быстрой вставку SQL я писал выше по треду.

прямо «очень быстрой»? это сколько в попугаях?

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

и? если у меня elastic, то я ищу всяко не только по timestamp'у. И вообще логи в современном мире это больше потоки с триггерами когда надо алертить. (посмотри на graylog хотя бы, чтобы дичь не писать) И уже во вторую очередь разбор полетов.

потому что у меня будет иной центральный узел обработки информации.

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

У Васи Пупкина её нету, и потому ваши решения ему не подходят.

и Витьке Кривому тоже, так как он сапожник. Вот если ты не умеешь играть на балалайке, то тебе она тоже не подходит, но ты почему-то не ведешь войну с балалаечниками.
Букварь что ли какой-нибудь прочитай. Хотя бы это https://12factor.net/ru/ для начала.

У Васи Пупкина её нету, и потому ваши решения ему не подходят.

Давай ты откроешь тред на начало и найдёшь где и что я советовала ТСу.

Spoiler: я не предлагала ему развернуть кубернетес.

Разумеется в разных случаях требуются разные решения. Фишка в том что ты не понимаешь и не знаком с «99% процентами» «типовых» случаев, но прибежал в тред рассказывать как все неправы.

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

Открою тайну - докер никому не нужен. Инструмент созданный для снижения требований к квалификации, чтобы в it могли «работать» макаки за банан. Если нужны контейнеры, в их изначальном, не извращённом виде, то есть lxc.

Хотя бы это https://12factor.net/ru/ для начала.

Можешь перевести с рекламно-маркетингового на человеческий?

Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний

Это монорепа или что?

Явно объявляйте и изолируйте зависимости

Это про package.json или .node_modules?

Считайте сторонние службы (backing services) подключаемыми ресурсами

А чем ещё их можно считать?

Запускайте приложение как один или несколько процессов не сохраняющих внутреннее состояние (stateless)

Это запрет писать в базу? В носиквельную базу? А куда данные-то сохранять?

Масштабируйте приложение с помощью процессов

С помощью процессов масштабирования приложения, я надеюсь?

Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы

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

Выполняйте задачи администрирования/управления с помощью разовых процессов

На периодической основе, я наедаюсь?

Как этот маркетоидный бессвязный бред капитана очевидность можно соотнести с реальностью?

Это монорепа или что?

Просто репозиторий.

Это про package.json или .node_modules?

Скорее package.json

Это запрет писать в базу? В носиквельную базу? А куда данные-то сохранять?

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

С помощью процессов масштабирования приложения, я надеюсь?

Нет. С помощью параллельно выполняемых процессов

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

Нет. Тут о том, что простой из-за сбоя минимальный был. И при деплое новая версия должна быстро подниматься.

А чем ещё их можно считать?

Зависимостями например.

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

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

Это борьба с утечками памяти, штоле?

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

Да. Это же всё какие-то бессмысленные выкрики из серии «пишите хорошие приложения, не пишите плохие!!»

Без конкретики - это какая-то бессмысленная вода уровня аджайл-манифеста.

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

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

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

прямо «очень быстрой»? это сколько в попугаях?

Порядка сотни тыщ строк записей в секунду.

И вообще логи в современном мире это больше потоки с триггерами когда надо алертить. (посмотри на graylog хотя бы, чтобы дичь не писать) И уже во вторую очередь разбор полетов

Я сразу написал по поводу отладки. Отладка распределенной системы — это чудовищно сложная штука. Настолько сложная, что наша уважаемая хайлоад-бигдата просто ничего про эту отладку не знает. Точные объемные логи — это один из немногих способов посмотреть, что реально происходит на системе. А чтобы логи эти были полезными. они должны обладать двумя свойствами: быть синхронизированными-сериализованными, и минимально вмешиваться в работу системы, то есть, система работает будто логирования нет.

потому что у меня будет иной центральный узел обработки информации

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

Питон, гошечка.

и Витьке Кривому тоже, так как он сапожник. Вот если ты не умеешь играть на балалайке, то тебе она тоже не подходит, но ты почему-то не ведешь войну с балалаечниками.
Букварь что ли какой-нибудь прочитай. Хотя бы это https://12factor.net/ru/ для начала

Я бы хотел начать и закончить на «И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки» — потому что не могут. Все эти ваши best practice и готовые решение по итогу упираются в одну и ту же БД. Потом начинаются кэши, потому начинаются проблемы с когерентностью, потом ни один человек в команде не знает, как система на самом деле работает и в какой момент испортит данные. Это всё традиционные проблемы распределенных системы, которые нынче принятой примитивной готовой инфраструктурой логирования и оркестрации не решаются никак.

Давай ты откроешь тред на начало и найдёшь где и что я советовала ТСу

К тебе претензий нет, извиняюсь, если намекнул на что-то такое. Претензии есть к соседним ораторам.

Фишка в том что ты не понимаешь и не знаком с «99% процентами» «типовых» случаев, но прибежал в тред рассказывать как все неправы

Понимаю, но лично не участвовал. Я вот лично не проверял, но у меня есть сведения, что у 99% мужчин есть член. Как я смог это узнать?

Открою тайну - докер никому не нужен. Инструмент созданный для снижения требований к квалификации, чтобы в it могли «работать» макаки за банан. Если нужны контейнеры, в их изначальном, не извращённом виде, то есть lxc

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

Как этот маркетоидный бессвязный бред капитана очевидность можно соотнести с реальностью?

Я уже заметил систему. Возникает чередная хайповая технология. Возникают хомяки-утята с позицией «до нас ничего не было», когда начинают описывать технологию так, будто с нее зародилось IT. ООП/класс-ориентированное программирование, реактивное программирование — это прямо-таки самые яркие примеры. Самое жопораздирающее в сем явлении то, что чудовищные проколы и антипаттерны преподносятся как данность, мол «смотрите, как это можно еще улучшить», а не «что мы натворили, конечно, часть из привнесенных проблем можно исправить...».

Без конкретики - это какая-то бессмысленная вода уровня аджайл-манифеста

Конкретика — это описания традиционной современной архитектуры микросервисов. То есть, читай заголовок «Как делать микросервисы на докере». В индустрии есть конкретные популярные готовые решения и приемы, эти приемы авторы сайта превратили в более абстрактные методики, и всё это объединили в идеологию с таким пафосом, будто сначала разработали идеологию, а потом следуя ей уже пришли к остроумным хитростям конкретных реализаций. А не как в реальности: херак-херак и в прод... не работает? Лепим костыль... падает? Перезапускаем по таймауту.

Что плохого в том, что рутинная работа должна быть полавтоматизирована

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

Это борьба с утечками памяти, штоле?

С неконтролируемым раздуванием пространства состояний. Которое мешает пониманию происходящего и воспроизводимости поведения.

Гугл в треде — всем укрыться в BigTable

Манявр защитан.