Vitaly Karasik

На мой взгляд, если уже смотреть на смежные области, то на DevOps или AWS.

CI работает и с монолитом, и с микросервисами.

И второе, это автоматический запуск тестов, при определенных действиях, например принятие merge-request с мастером.
Что мне непонятно:
Чаще всего, в обучающих материалов пишут, что перед запуском тестов Создается Сборка и уже в ней запускаются тесты.

Начните с простого: напишите последовательность шагов, которые вы сегодня запускаете вручную, чтобы собрать приложение. И задеплоить (хотя формально это уже CD).
А потом думайте-проверяйте, как перенести этот сценарий в выбранный сервис CI.

Конкретно насчет тестов - о каких тестов идет речь? Unit? Integration? End-to-end?

Полное обследование действительно стоит немало.
Если хочется просто бесплатно получить красивый PDF, то
1. https://sonarcloud.io/code-security
2. https://www.indusface.com/web-application-scanning.php
3. app.k6.io , blazemeter.com

Если хотите использовать прямые ссылки, то надо активизировать s3 website hosting https://docs.aws.amazon.com/AmazonS3/latest/usergu...,
там и получите URL.

1. ИМХО, 90% зависит от задач и от организации. То есть есть смысл в сотнях сервисах для громадной фирмы, но мне трудно представить чтобы это имело смысл для группы из трех разработчиков
2. Как уже сказали, если не тормозит то потому что сервисы очень близко друг к другу. Но скорость - не единственная проблема. Мониторинг, дебаггинг - все выглядит совсем не так как раньше.
3. Насколько понимаю тут идет серьезный спор - одна база на всех или база для микросервиса.

Disclaimer - я DevOps, не архитект.

См.
https://world.hey.com/joaoqalves/disasters-i-ve-se...
https://medium.com/microservices-in-practice/micro...
https://k8s.af/ - Kubernetes Failure Stories
highscalability.com/blog/category/example - Real Life Architectures

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

Насколько помню, это действительно так.

даже если у меня root

Речь об учетке AWS

Я бы пошел по первому пути. Или вообще использовал метрики (megabytes/sec), не логи.

Согласен с BorLaze - используйте что-то готовое. Например https://www.liquibase.org/.

посмотрите в /var/log/syslog - может памяти нехватает и система убивает elastic.

Т.е образ контейнера один и тот же но может поменяться только аргумент для запуска.

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

В Kubernetes можно использовать horizontal autoscaling.

Есть много, когда пару лет назад проверял, то наиболее щедрые бесплатные планы были у
blazemeter.com
https://k6.io/

Сам не пробовал, но пишут что так

https://hevodata.com/learn/integrating-elasticsear...

https://medium.com/@rajkumar012786/how-to-setup-mo...

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

free -m

апустить под Ubuntu, какую нибудь виртуальную машину,

Запустить MacOs в виртуалке нельзя, максимум https://hackintosh.com/

Наверно, зависит от вложений - PDF можно парсить и искать по нему, картинки и т.п. - нет.
Посмотрите на https://www.elastic.co/guide/en/elasticsearch/plug....
https://discuss.elastic.co/t/how-to-index-and-stor...