
Комментарии 8
Есть же Docker
Контейнеризация не всегда применима в проектах, более того для небольших систем она избыточна, а так же добавляет необходимость дополнительных компетенций у заказчика при передаче систем ему.
И сам по себе Docker не решает задач автоматизаций, для него требуется дополнительная оркестрация, например решения задач деплоя или сбора логов.
Вот насчёт компетенций, кстати, спорный вопрос. Один знает бубунту хорошо, второй привык к Terraform какому-нибудь, третий... И тп. А если у тебя докер, ты любого девопса можешь нанять на пару дней под отдельную задачу (или в принципе в штат) - он разберётся. Хотя, может, я и не прав..
Я как-то проект завязал на Laravel forge - ну все же понятно и для людей. Но, как оказалось, не только лишь все в СНГ с этим привыкли работать. А если вдруг понадобится админ, а не "Laravel artisan" - там ещё на порядок меньшая вероятность что этот человек эту "кузницу" в глаза видел :)
А чем оно будет лучше, чем те же самые ansible playbooks? Если же облако - то cloud-init? А может terraform?
Job security. Работадатель будет сильно стараться что бы найти и обучить инженера готового придти на инфру управляемую через ХКонфиг
Не сказал бы, что он лучше Ansible, Terraform или cloud-init вообще. Он лучше подходит именно под наши задачи.
Нам нужен был свой более узкий инструмент под типовые сценарии и российский стек, которым мы можем полностью управлять и, что особенно важно для работы с госзаказчиками, на который у нас есть права. Там далеко не любую зависимость или компонент можно просто взять и занести в проект.
del
Как мы перестали настраивать Linux-серверы по памяти и открыли HConfig