Концепция: IaC

Для начала, дабы не оставлять пробелов в теме поставки решений на сервер, одним предложением скажу, что происходит.

Для удобства ведения повествования представим, что мы пишем java-проект, на микросервисной архитектуре и хотим его положить в Kubernetes.

Зачастую DevOps пишет пайплайн, в котором сначала ваш код билдится в исполняемый файл, потом оборачивается в Docker image и сохраняется в registry. (Это классический пайплайн, но, естестественно, в зависимости от разных факторов он может выглядеть совершенно иначе)

Что же происходит после всего этого?

🧳 Есть разные решения этого способа поставки, но я хочу остановиться на концепции IaC (Infrastructure-as-Code).

Из названия понятно только то, что мы можем как-то кодом описать инфраструктуру. По факту это и есть самое большое преимущество данной концепции:
🧦 описывая инфраструктуру кодом, мы можем заливать этот код в репозитории и иметь версионирование всей инфраструктуры;
🧤 т.к. это код, мы можем выделить повторяющиеся участки кода и переиспользовать их, кастомизируя параметрами;
🧣 будучи разработчиком, научиться подобному языку не составит большого труда.

Следующим постом я хочу познакомить вас с одной из реализаций данного подхода — Terraform. А еще рассказать о самом большом преимуществе концепции IaC
#rdclr_DevOps