Comments 10
Спасибо за пост. Как связано понимание этих концепции и что любой инструмент может перестать быть опенсорсом? Скорее эти фразу стоило разделить на 2 предложения.
Отсутствие документации версий инфраструктуры, трудно отследить проблемы, которые могли возникнуть из-за выкатки новой версии.
Это применимо как изменяемой так и к неизменяемой инфраструктуре.
1. Возможность версионирования.
a. Можно отследить, в каком из обновлений возникла ошибка.
2. Конфигурационные файлы выступают в качестве документации состояния инфраструктуры.
Вы это можете делать и с изменяемой инфраструктурой.
3. Упрощение конфигурации. Не нужно помнить, что и на какой машине установлено, если есть готовый образ, из которого она создана, со своим описанием в виде файла конфигурации.
4. Благодаря согласованной конфигурации машин проще выкатывать обновления и тестировать новые версии.
5. Инстансы с одним и тем же приложением одинаковы.
Если использовать практики infrastructure as a code и идемпотентность, то эти пункты можно реализовать на изменяемой инфраструктуре.
1. Более медленный деплой новых версий по сравнению с Mutable-инфраструктурой, так как поднимаются новые машины.
Наоборот, более быстрый деплой по сравнению с Mutable инфраструктурой. Вы просто указываете новый образ, в котором уже был деплой приложений и библиотек когда вы его паковали, например, с помощью packer.
Виды инструментов Immutable infrastructure
1. Инструменты доставки конфигурации
Стартовым можно считать использование инструментов вроде Ansible, Puppet, Chef, Saltstack и др.
Наоборот. Ansible, Puppet, Chef, Saltstack это инструменты для mutable инфраструктуры. Они подключаются к серверу и настраивают его.
Только в связке с packer это инструменты immutable инфраструктуры. Но в этом пункте вы это не упомянули.
Стартовым можно считать использование инструментов вроде Ansible, Puppet, Chef, Saltstack и др. Стоит помнить, что, как и в остальных инструментах Immutable, хранилище стейта должно быть отделено от виртуальной машины
У Ansible, Puppet, Chef, Saltstack нет state, а у terraform есть. Но в пункте ничего про terraform не написано.
Собираем образ, проставляем метаданные в зависимости от приложения
Собираем образ с помощью packer, проставляем метаданные в зависимости от приложения
Pulumni
Pulumi
Продолжая подход Service Mesh, для сборки логов и метрик можно установить на инстанс приложения агент мониторинга (Telegraf, Fluentbit, Node Exporter и другие).
Продолжая подход Service Mesh, для сборки логов (Fluentbit) и метрик можно установить на инстанс приложения агент мониторинга (Telegraf, Node Exporter и другие).
Immutable-инфраструктура и ее преимущества