Sandbox.
Спроектировал, разработал систему “Sandbox”, которая предназначена для создания и управления изолированными средами в помощь тестировщикам и разработчикам.
Исходная проблема заключалась в том, что команд и людей было очень много, а тестовых стендов на всех не хватало и люди часто мешали друг другу, ломая стенды, после чего тратили огромное время на поиск и решение проблем с ними.
Возникла необходимость в инструменте, который позволит создавать изолированные тестовые среды по требованию, повторяя реальную production-инфраструктуру.
В результате чего проблемы на одном стенде не будут затрагивать другие и тестировщики смогут параллельно тестировать задачи на собственных стендах, не блокируя друг друга.
Это был совершенно новый проект в компании. Мне выпал хороший случай оказаться первым, кто начал над ним работать, имея полную свободу действий и возможностей в выборе инструментов.
Что было реализовано:
1.
Сборка на лету в отдельной виртуальной машине разворачиваются на лету в отдельной виртуальной машине во внешнем облаке по требованию. Как только сборка становится не нужна, виртуальная машина вместе со всеми контейнерами уничтожается.
2.
Конструктор микросервиса. С его помощью разработчик мог создать свой микросервис через веб-интерфейс, указав из каких компонентов он состоит. Например, за несколько минут можно было набросать конфигурацию простейшего микросервиса, состоящего из контейнера с приложением, контейнера с базой данных и контейнера с брокером очередей сообщений. Система уже содержала дефолтные часто используемые компоненты, которые можно просто выбирать из списка. Если нужного компонента нет, разработчик может подключить свой docker-образ, размещенный во внутреннем хранилище docker-образов
3.
Собственное хранилище docker-образов. Docker-образы компонентов микросервисов собираются командами самостоятельно с помощью CI и размещаться в общем хранилище образов Registry на наших мощностях (для понимания картины, суммарный объем всех образов был >5TB)
4.
Маппинг портов приложений. В интерфейсе управления компонентами микросервиса можно настраивать публикацию портов, которые маппятся на хост-машину, после чего компонент микросервиса становится доступен извне.
5.
Возможность управлять переменными окружения на уровне компонентов микросервиса. Переменные окружения могут быть переопределены перед началом сборки (для каждого компонента выбранного микросервиса)
6.
Кастомизация образов компонентов перед сборкой. Перед началом сборки можно выбирать, какой образ использовать при сборке. Например, можно запустить свой микросервис и протестировать его на другой версии Postgres, отличной от той, которая используется в данный момент, просто выбрав нужную версию компонента в списке. Удобно, когда хочется посмотреть, как ведет себя приложение на новой версии БД
7.
Изоляция на уровне виртуальных машин и контейнеров. Под каждую сборку создается отдельная виртуальная машина, в которой поднимаются сотни контейнеров, под каждый компонент микросервисов. Разработчики и тестировщики могут создавать любое число таких сборок для любых целей и не мешать друг другу.
8.
Кастомные облачные провайдеры и поставщики услуг. На уровне архитектуры приложения, была возможность интегрировать любой облачный провайдер, имеющий внешний API
9.
Интерактивный процесс создания сборки. Разработчик может видеть процесс сборки выбранного набора микросервисов, видеть логи сборки в веб-интерфейсе.
10.
Различные тарифные планы. При создании сборки можно выбрать тарифный план виртуальной машины, что дает возможность подбирать оптимальную мощность создаваемой виртуальной машины для требуемых нужд при разработке или проведения нагрузочного тестирования, вплоть до самых заряженных машин с 32 ядрами, 128 гигами оперативы и 512 SSD с возможностью подключать дополнительные разделы под сторадж)
11.
Удаленный доступ к сборкам по SSH. Для каждой сборки у разрабов/тестеров был доступ по SSH, что позволяло управлять хостом и существенно упрощало процесс отладки.
На каком-то этапе я понял, что бизнесовая разработка мне интересна больше, чем инфровая, после чего перешел в другую команду.
Вокруг этой системы образовалась новая команда, в задачи которой входило создание инструментов для собственной инфраструктуры разработки, деплоймента и управления серверами компании.
Сама же система в последствии обросла большим числом новых возможностей, была переписана на другом языке и ушла далеко вперед, что очень радует.
Своя CI/CD платформаРазработал прототип своей CI/CD-системы. В серию не пошло, поскольку затащить в одно лицо сразу два инфровых проекта я просто был не в состоянии и переключился на более приоритетный, а этот по моей инициативе мы закрыли. Но был вполне рабочий прототип на Ruby on Rails, который даже варил билды и в риалтайме стримил терминал каждой отдельной билдежки на свою страницу билда (причем православно, корректно отображая все спецсимволы), под капотом прятался RabbitMQ.
Технологии: Ruby on Rails, PHP/Symfony 3, RabbitMQ, Postgres, Docker, Ansible, Puppet, Angular, Bash, Consul, Redis, Gitlab, Jenkins, Nginx, Nodejs