DaaS - "devops as a service" - это такой преднастроенный (но конфигурируемый если надо) набор компонентов, позволяющих быстро организовать "devops".

Задача

Создать преднастроенную систему взаимодествующих между собой компонентов для организации тестирования (CI) в небольшой по размеру команде разработчиков. Компоненты должны сами запускаться, конфигурироваться, мониториться, и по возможности легко переезжать на новое железо. Должны быть предусмотрены backup-ы критичных данных и возможность восстановления. Тестовые стенды под тот или иной проект должны разворачиваться "по нажатию одной кнопки", должна быть предусмотрена возможность запустить столько тестовых стендов одного проекта, сколько понадобится.

Архитектура

Компоненты:

Gitlab
ВМ c docker (для развёртывания виртуальных тестовых стендов в замкнутой сети)
ansible
vagrant для управления Virtualbox-ами
мониторинг (grafana + netdata)
service discovery (dns и не только) внутри ВМ (consul, registrator, consul-template)
хранение приватной информации (vault и/или локально ansible vault)
"api-server" - REST API. Единая точка входа для взаимодействия между компонентами.

а может просто надо использовать k8s в minukube? https://habr.com/company/flant/blog/333470/

Концепция:

Для того, чтобы обеспечить наличие независимой сети для каждого тестового стенда (разные проекты могут иметь одинаковые ip), стенды запускаются внутри ВМ (virtualbox) с виртуальной сетью. При этом чтобы обеспечить лёгкость запуска и сопровождения самих узлов используется docker. Поэтому основная идея: docker запускается внутри ВМ, при этом тестовый стенд работает с виртуальной сетью внутри ВМ (сеть наружу не выходит).

Имеется базовый преднастроенный vagrant box для тестового стенда. Для создания нового тестового стенда под конкретный проект используется ansible и vagrant, которые на основе этого образа ВМ преднастраивают компоненты и всё необходимое под конкретный проект. Gitlab является центральным элементом, вокруг которого строится процесс (используются его механизмы CI/CD, issue, code review, MR и т.п.).

api-server (необходимость под вопросом)

Это сервис с REST API, позволяющий единообразно общаться между разными компонентами. Например запустить задачу в jenkins, поменять статус задачи или создать новую в youtrack, gitlab, bugzilla и т.п. Его цель предоставить единый интерфейс к "разношёрстным" сервисам. Т.к. многие продукты и так умеют работать между собой (gitlab + jenkins, jenkins + youtrack), то возможно этот слой "абстракции является лишним", с другой стороны если есть единый неизменный интерфейс и все работают только через него, то это приводит к единообразию работы с разношёрстными сервисами, позволяет легко их обновлять или добавлять не затрагивая основной процесс (т.к. при изменении в API сторонних компонентов будет корректироваться только внутренняя реализация общения с ними). Минусом является поддержка всего этого.

Документация