d-stream

Рекомендую заглянуть в config.toml раннера и почитать доки.
Всего этого при наличии ресурсов достаточно чтобы сделать и 2 и 10 и даже разных раннеров на одной машине.

Не стоят ли какие-либо имитаторы GPS? Mosck*, fakeGPS и т.п.?

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

Ну roadmap - известен. И там в общем случае php уже нет)

Ну а "пакет-инсталлятор-обновлятор" и CI/CDL/CDP - это слегка перпендикулярные понятия.

p.s. применительно к описанному - малая автоматизация рутинных действий и их выполнение потом средствами gitlab раннеров (тут по вкусу - ps, sh, и даже dos-cmd). Мало будет шеллскриптинга - тут по вкусу - хоть на питоне, хоть на php. Можно и на go, но в силу его компилируемости - придётся построить пайпы для этого - "сборка и деплой средств сборки")

Собственно процесс размагничивания непрерывен. Даже если hdd работает. Так что если хочется надёжности - можно раз в год-два подключать диск и прогонять например длинный S.M.A.R.T тест

И если что-то пошло не так - раздеплой на 100500 серверов положит их все...
По-моему вариант индивидуального certbot на каждом сервере будет несколько получше

var cert = new X509Certificate2(путь_до_файла_серта, "пароль_серта");
    var handler = new HttpClientHandler();
    handler.ClientCertificates.Add(cert);

подробности

Саму графану надо научить что у нее base path /server/grafana/ и тогда для логина она будет редиректить на /server/grafana/login

Подводный камень один: запрет для РФ. Соответственно все шустрости и "химия" - до поры до времени. Выгнали в дверь. Так не надо лезть в окно. Ибо совершенно обоснованно можно получить ссаной тряпкой в морду.

А точно это ssh гита, а не ssh машины?
По-умолчанию на 22 порту слушает ssh хостмашины, а ssh гита - живёт вроде бы на 2222 порту

Естественно лучше это поменять:
https://docs.gitlab.com/ee/administration/operatio...
https://about.gitlab.com/blog/2016/02/18/gitlab-do...

Что мешает в батнике старта зукипера убрать явный путь до java и пользовать ту что доступна по path ?

В приведённом варианте openssl создаёт самоподписанный сертификат. На что и будут регулярные жалобы.
Прямой вариант - выпустить нормальный сертификат например на letsencrypt с цепочкой удостоверяющих центров и т.п.
Ну или как минимум имитировать подобное создав свой псевдоудостоверяющий центр:
ca сертификат и им подписать серт для гитлаба, но тогда придётся ca прописывать всем клиентам как trusted ca

Kiosk mode хватит?

Скорее всего малинка начнёт захлёбываться на работе с дисками. По крайней мере если будет сверх хранения версий ещё и ci/cd.
Ну а скармливать логи и артефакты сборки на быстрое хранилище S3 - а чего бы тогда не подсадить туда и сам gitlab? )

Из моей практики на x86 - 4..8vCPU и 7..8Гб ОЗУ и в силу специфики (огромные артефакты) - быстрые диски.

Ну и да - "диски" - это надёжная дисковая полка + регулярные бэкапы. Ибо система контроля версий - это сердце разработки.

Возможно это вначале покажется чутка избыточным, но по размышлению - нет:

master == прод
dev == ветка стабильной разработки, где живут более-менее целостные фичи
feature_xx == опять же целостная, самостоятельная фича, привносящая осмысленный функционал и состоящая возможно из множества задач

фичи отращиваются и возвращаются в ветку dev и их можно даже на уровне ветки протестировать
в какой-то момент от ветки dev отращивается ветка release (по-сути релиз-кандидат) и потом по выпуску (релизу) вливается в master и dev
go to 1

при таком подходе в dev живёт достаточно стабильное решение, а ветках feature - конкретные фичи, которые к моменту влития в dev - в общем-то тоже стабильны и функциональны.

ну и собственно релизный цикл получает некую "асинхронность" относительно цикла разработки:
- захотел релиз-менеджер к юбилею фирмы выпустить релиз - пожалуйста - в dev есть пачка фич
- накопилось осмысленное кол-во фич - вперёд в релиз
- оттестирована конкретная ожидаемая фича - в релиз (ну и попутно менее значимые)

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