Здравствуйте, kaa.python, Вы писали:
KP>И в целом я бы сказал что это оправданная стратегия.
+1
IAAS (Infrastructure as a Service) это одно из наиболее важных изменений в IT за последние 10 лет.
Здравствуйте, Тёмчик, Вы писали:
Тё>О, это тема! А как оно выглядит- микросервисы инкапсклируют монолит?
Я тебе прямо завидую, если ты не знаешь как такое выглядит! И желаю никогда не узнавать ))
Представь себе обычный такой монолит, со временем превратившийся в классический big ball of mud
А теперь представь, что его порезали на несколько частей, которые шарят одно и то же состояние, и вместо обычных вызовов между компонентами монолита мы теперь имеем удаленные вызовы.
Сразу огребаем массу плюшек: падает один сервис — падает вся система. Состояние-то у них расшаренное ))
все сервисы надо деплоить одновременно. Только теперь это занимает больше времени.
сервисы связаны друг с другом 1-1, т.е. ни о каком горизонтальном масштабировании речи не идет. Мы же помним, что у них общее состояние ))
Очень весело, когда повреждается состояние одного из сервисов. Это сразу аффектит все остальные.
Разумеется, выявлять проблемы стало много сложнее. Надо теперь ковырять логи нескольких сервисов. При том трафик между сервисами такой, что его не залогировать в принципе.
Ну и само собой это все работать стало значительно медленнее. Потмоу что гигансткий трафик — это же какие-то объекты, которые надо сериализовать, передать, десериалзовать. На сериализации идет потеря не только времени, но и памяти. Это колоссальное выделение больших объектов. Которое приводит к надрывной работе сборшика мусора. Который в свою очередь еще больше все тормозит.
Дебажить тоже весело. Надо запускать все это барахло вместе.
Короче, представь что ко всем минусам монолита добавили все минусы распределенной архитектуры. А плюсы при этом убрали.
Здравствуйте, Gradiens, Вы писали:
G>А теперь представь, что его порезали на несколько частей, которые шарят одно и то же состояние, и вместо обычных вызовов между компонентами монолита мы теперь имеем удаленные вызовы. G>Сразу огребаем массу плюшек: падает один сервис — падает вся система. Состояние-то у них расшаренное ))
А почему кстати, падает? Тут есть спрос на микро фронт, оно именно так и задумывается (одно состояние у Statechart), сшитое из разрезанных кусков франкенштейна.
Здравствуйте, kaa.python, Вы писали:
KP>>>По современным веяниям Докер — контейнера для сборки на машине разработчика Тё>>Собирай наздоровье, только дебажиться — боль.
KP>Если уж прям трындец как надо глянуть отладчиком (что должно быть раз в пол года при правильном процессе разработки), то GDB запускается и работает. И вроде в IDE от JB есть удалённая отладка по ssh, но я не пробовал
Я недавно имел счастье попробовать докер на новом Apple M1. Нужно было собрать C++ проект, который по последней моде лежит в контейнере у разработчиков.
Знакомство не задалось с самого начала: сборка шла медленнее обычного. Я решил, что маловато ресурсов и отдал докеру максимальное количество ресурсов — все 10 ядер и почти всю память. Докер так обрадовался свалившемуся богатству, что ушел в бесконечный рестарт, не давая поменять настройки через GUI. Пришлось вручную править конфиг и откатывать количество ядер к 6 (внезапно, есть разница между быстрыми и медленными).
Выяснилось, что виртуальная машина, в которой работает x86_64 образ, плохо виртуализирует ввод/вывод, и рецепты в интернете сводятся к тому, что это ничего страшного, когда-нибудь исправят, ведь железо новое. А пока попробуйте использовать одно ядро
Отказаться от готового образа x64 нельзя, потому что там вся нужная инфраструктура для сборки и перевести ее на arm64 быстро не получится (но видимо все равно это надо делать).
Далее уже чисто из интереса, после получасовой сборки C++ проекта выяснилось, что gdb в в qemu на Apple M1 не работает:
Starting program: /bin/echo
warning: Could not trace the inferior process.
warning: ptrace: Function not implemented
During startup program exited with code 127.
В лучших традициях agile разработки, ошибка закрыта, потому что идите нафиг, вот почему:
docker-desktop-robot commented on 11 Jun 2021
Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked
Хэппи-энд таков: собрать за пару дней Mini-ITX ящик с Ryzen 5950x и 64Gb RAM обошлось в 2 раза дешевле , чем макбук про макс м1 (или как его там, в максимальной комплектации). Само собой, тот С++ проект собирается на AMD за 5 минут.
Вывод: смузизхлебыкреативные личности и фронтендеры, не сталкиваются с отличиями в архитектуре, у них все работает, о чем они радостно вещают в видеообзорах. Но к ARM на северах надо уже быть готовыми.
Перечитал и заметил, что сообщение получилось в тему раздела, как пример ответа на вопрос о какой-нибудь трудности в работе
Здравствуйте, PM, Вы писали:
PM>докер на новом Apple M1. PM>сборка шла медленнее обычного. PM>виртуальная машина, в которой работает x86_64 образ PM>qemu
Ну т.е. ты гоняешь полную эмуляцию x86-64 операционки вместе с её кернелом через qemu на ARM и при этом удивляешься что это работает медленнее чем x86-64 на x86-64?
Здравствуйте, PM, Вы писали:
PM>Хэппи-энд таков: собрать за пару дней Mini-ITX ящик с Ryzen 5950x и 64Gb RAM
Ну т.е. amd64- докер образ оказался непригодным на arm64. Нужно править докер, чтобы был arm64- образ, чтобы его крутить на arm64. Про отладчиком подключиться "удаленно" в докер- ожидаемо геморрой либо совсем не работает.
Здравствуйте, CreatorCray, Вы писали:
PM>>докер на новом Apple M1. PM>>сборка шла медленнее обычного. PM>>виртуальная машина, в которой работает x86_64 образ PM>>qemu
CC>Ну т.е. ты гоняешь полную эмуляцию x86-64 операционки вместе с её кернелом через qemu на ARM и при этом удивляешься что это работает медленнее чем x86-64 на x86-64? CC>
Я не удивляюсь, морально был готов к просадке из-за виртуализации. Но глюки докера (или qemu, или их наложение) показали, что это решение для меня не подходит.
Здравствуйте, Тёмчик, Вы писали:
PM>>Хэппи-энд таков: собрать за пару дней Mini-ITX ящик с Ryzen 5950x и 64Gb RAM
Тё>Ну т.е. amd64- докер образ оказался непригодным на arm64. Нужно править докер, чтобы был arm64- образ, чтобы его крутить на arm64.
Да, но пересобрать образ под arm64 то еще приключение. В нем используются разные библиотеки, которые на arm64 еще не пробовали.
Тё>Про отладчиком подключиться "удаленно" в докер- ожидаемо геморрой либо совсем не работает.
Отладчик нормально работает в x86_64 контейнере на x86_64 системе. Просто qemu не реализует ptrace. Вроде бы есть как раз путь с запуском gdb внутри qemu и подключением к нему. Но мне хватило красноглазия на полдня, чтобы вовремя остановиться.
Насколько я понимаю, тот же Visual Studio Code, когда открывает проект в контейнере использует ssh внутрь образа, чтобы запускать и отлаживать файлы там. Все отлично работает на обычном x86_64 линуксе без виртуализации.
Здравствуйте, PM, Вы писали:
PM>Я не удивляюсь, морально был готов к просадке из-за виртуализации.
Гонять x86 на ARM через qemu это не столько виртуализация сколько эмуляция железа, а это всегда капец как медленно.
Увы, но лучших решений для запуска полноценной OS на другой платформе пока нет, да и вряд ли будет.
Если хочешь гонять x86 аппы на ARM быстро — гоняй их именно как аппы, без виртуалки. Это будет куда быстрее. Но докер под такое не заточен.
Здравствуйте, CreatorCray, Вы писали:
PM>>Я не удивляюсь, морально был готов к просадке из-за виртуализации. CC>Гонять x86 на ARM через qemu это не столько виртуализация сколько эмуляция железа, а это всегда капец как медленно. CC>Увы, но лучших решений для запуска полноценной OS на другой платформе пока нет, да и вряд ли будет. CC>Если хочешь гонять x86 аппы на ARM быстро — гоняй их именно как аппы, без виртуалки. Это будет куда быстрее. Но докер под такое не заточен.
Да, спасибо, x86 на arm это действительно эмуляция, и докер кое-как это делает. Если бы в самом начале процесса он выдал хотя бы предупреждение типа, "так, падажжи емана, ты тут фигню собираешься делать с образом для другой аппаратной платформы", то коллеги может быть бы и задумались. А так один попробовал — у меня все работает, node.js запускается, сервис что-то отвечает. Ну а С++ компиляция, gdb какой-то, кому оно сейчас интересно, это дедовское кряхтенье.
