pritchin Oct 9 2019 at 18:05

Infrastructure as Code: как побороть проблемы с помощью XP

11 min

9.7K

Dodo Engineering corporate blogDevOps*IT Infrastructure*Development Management*

+21

Comments 4

Tzimie Oct 9 2019 at 20:45

Не отчаивайтесь, всегда есть где хуже!
Расскажу вам быль из нашего devops. Читаю письмо от DBA

Ребята! У меня нет доступа к вашему nexus. Вы лучше оттуда из артефакта скрипты вычлените и пришлите письмом, а я пришлю вам результат выполнения. Да, и какое имя сервера?

Так что у нас полуавтоматизация: робот держит станину, а рабочий по ней лупит кувалдой

pritchin Oct 9 2019 at 20:55

Спасибо. Но отчаяния-то и нет. То, что описано выше работает и помогает. А дальше только пробовать еще и еще

Fedcomp Oct 10 2019 at 16:12

Не смог понять из статьи что не так с unit тестами, там только безапеляционное утверждение. Не занимался infrastructure as code, но в обычной разработке юниты наоборот лично мне экономят время если хорошо написаны. Плюс это готовая документация как этот юнит вообще использовать.
Почему у вас они не прижились?

pritchin Oct 10 2019 at 18:02

Получается хорошо юнит-тестировать при использовании высокоуровневых языков. И та часть инфраструктуры, которая сервисы имеет такие тесты. Но большая часть есть конфигурация или ее разновидности(DSL, templaters), а это не удается проверить качественно тестами. Мы не особо пробовали, но выглядит как много работы при малом выхлопе.
Например, нам надо иметь кол на jsonnet, который генерит терраформ-конфигурацию. Это для поддержки параметров и множества окружений. Там поднимается машинка, в ней при старте выполняется скрипт, который подтягивает скрипты инициализации(скрипт протестирован). И еще при старте начинают работать демоны на машине.
Вот это все проверяется поднятием реального ресурса. Т.е. это интеграционный тест.