Наши команды активно используют ansible для создания шаблонов и финальной
конфигурации виртуальных машин. Поэтому перед нами встаёт вопрос обеспечения
работоспособности и корректности сценариев развёртывания.
В этой заметке будет рассказано об имитации systemd внутри docker-контейнера
и валидации финального результата с помощью фреймворка testinfra.
Technical Breadth — определение, которое я впервые услышал в английском
варианте от архитектора Марка Ричардса (Mark Richards). Если грубо переводить
его на русский язык, оно означает “технический кругозор”. Аналогом этого
слова у дизайнеров является “насмотренность”.
Что делать с этим понятием и как расширять свой технический кругозор?
Semantic Workspace — это просто красивое название, которое я придумал полгода
назад для ряда простых принципов организации каталога с проектами на локальной
машине.
Все наши сервисы полностью соответствуют 12 факторам. Но в этой заметке речь
пойдёт только об одном из них — конфигурации через переменные окружения, а точнее про недооцененный инструмент direnv, позволяющий автоматически
загружать переменные окружения при переходе в каталог с проектом.
В этом посте речь пойдёт про организацию очереди отложенных задач в базе данных. На практике выяснилось, что очень большое количество разработчиков эту идею принимают с большим трудом, сразу же выражают обеспокоенность искусственно созданной нагрузкой. С одной стороны, это грамотное замечание. С другой — это тот барьер, через который надо научиться переступать, наблюдать за вашим приложением и грамотно настраивать базу.
В своей работе мы постоянно используем различные инструменты: protoc,
golangci-lint, allure и многие другие.
Чтобы избежать ситуации, в которой версия или конфигурация инструмента у одного
разработчика отличается от того, что уже установлено у другого, или от того, что настроено в CI, наши инструменты “запечены” в контейнеры.
В данной заметке речь пойдёт о “настоящих” виртуальных машинах, и никак не про контейнерную виртуализацию. Поэтому мысль вида “да всё ж можно в докер запихнуть” тут немного неуместна.
Строя облачные сервисы, мы в своей работе постоянно используем виртуальные
машины. В продакшине — гипервизоры первого типа, которые, говоря простым языком,
ставятся на “голое железо”; на своих локальных машинах — второго типа, это привычные нам всем VirtualBox, qemu и, возможно, Parallels Desktop.
К большому сожалению, несмотря на наличие продвинутых систем сборок, нам всё ещё
приходится использовать утилиту make и писать Makefile-ы руками.
Передо мной встала задача по составлению справки по целям сборки в текущем Makefile проекта. Из коробки древняя утилита не позволяет получить
список целей сборки и их описание, которого не предполагалось.
Вся техническая документация наших проектов пишется в формате Markdown.
Это простой и удобный формат, который можно читать даже в сыром виде без
постобработки.
Мне часто приходится экспериментировать с настройками мониторинга, сбором ошибок и метрик в различных окружениях.
Чтобы не выделять отдельный проект в общем Sentry, предпочитаю разворачивать
собственную локальную копию.
Процесс развёртывания занимает некоторое время, для “старого” ноутбука, процедура может занять минут десять.