Привет!
Решили познакомиться с новыми CI/CD инструментами (не Jenkins’om единым!) и наткнулся на интересную статью про … Docker!!! А именно – antipatterns и как можно их избежать.
У автора интересная подача, которая начинается с простого – «Не путайте виртуальные машины и контейнеры. Контейнеры – не виртуальные машины!». Не с точки зрения техники, скорее с точки зрения восприятия. Это важно, потому как это подводит к таким советам, как:
🍭 Образ контейнера – новая «единица обмена» информацией. Dev больше не дает код/приложение Ops и не просит его «развернуть». Он дает Dockerfile!
🍭Образы должны быть максимально простыми. И даже образы контейнеров можно «дробить» (есть интересный подход через multistage build, где результирующий Dockerfile не содержит «лишней» информации, что делает его легче, менее многослойным)
🍭 Не «вшивайте» конфигурационную информацию ИТ-окружения в Dockerfile – это подводит нас к тому, что Dockerfile в Dev, Test, QA, Cert, Pre-prod и Prod – это один и тот же образ!
🍭 А как тогда передать конфигурацию?.. В run-time, например, в качестве переменных окружения - в статье есть отличные примеры и инструменты, которые позволяют это делать!
И это далеко не все (согласно рекомендациям, статья занимает 19 минут)!
Решили познакомиться с новыми CI/CD инструментами (не Jenkins’om единым!) и наткнулся на интересную статью про … Docker!!! А именно – antipatterns и как можно их избежать.
У автора интересная подача, которая начинается с простого – «Не путайте виртуальные машины и контейнеры. Контейнеры – не виртуальные машины!». Не с точки зрения техники, скорее с точки зрения восприятия. Это важно, потому как это подводит к таким советам, как:
🍭 Образ контейнера – новая «единица обмена» информацией. Dev больше не дает код/приложение Ops и не просит его «развернуть». Он дает Dockerfile!
🍭Образы должны быть максимально простыми. И даже образы контейнеров можно «дробить» (есть интересный подход через multistage build, где результирующий Dockerfile не содержит «лишней» информации, что делает его легче, менее многослойным)
🍭 Не «вшивайте» конфигурационную информацию ИТ-окружения в Dockerfile – это подводит нас к тому, что Dockerfile в Dev, Test, QA, Cert, Pre-prod и Prod – это один и тот же образ!
🍭 А как тогда передать конфигурацию?.. В run-time, например, в качестве переменных окружения - в статье есть отличные примеры и инструменты, которые позволяют это делать!
И это далеко не все (согласно рекомендациям, статья занимает 19 минут)!