Почему я стараюсь вести разработку в Docker-контейнерах

Есть немало программистов, которые неоднократно слышали про всякие докеры и прочие инструменты контейнеризаций но для себя так и не нашли им применение в разработке. Это вполне нормально, поскольку контейнеризация является не какой-то волшебной палочкой разработчика, а всего-лишь специфичным инструментом, который надо использовать там, где это уместно.

Например, я использую Docker и Docker Compose в первую очередь для изоляции процессов друг от друга, что позволяет ограничить выполняемый код от каких-либо деструктивных действий.

Я давно заметил, что большинство разработчиков мало заботятся за организацию безопасности в момент разработки. И частым аргументом этого является отсутствие времени на это. Особенно жестят этим именно в среде веб-разработки.

При этот таких разработчиков никак не волнует, что они скачивают какой-то скрипт через тот же NPM и скорее всего автоматически его запускают под своей учётной, которая нередко у таких разработчиков имеет привилегированные права в своей системе. У таких разработчиков могут быть открыты доступы по SSH-ключам к различным системам, адреса которых можно найти в .known-hosts. Думаю сами понимаете, какие последствия может принести какой-нить зловредный скрипт, который может быть скрыт в зависимостях скачиваемой вами библиотеки и который активизируется по какому-нибудь триггеру (геолокация, таймеры, сторонние запросы и пр.).

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

Лично я по возможности стараюсь вести любую разработку в нескольких отдельных контейнерах. Код, который я пишу, хранится вне контейнера в отдельной директории, которая монтируется к контейнерам через Volumes. При этом в одном контейнере ведется разработка, а в другом работа с репозиторием и т.д.

Самым главным отличием этих контейнеров является то, что первый контейнер служит только для работы с кодом, включая его запуск и отладку и только для этого, т.е. этот контейнер не имеет доступа куда-то ещё. Второй контейнер имеет необходимый доступ к git-репозиторию, но не имеет возможности запускать этот код. Т.е. фактически, мы изолировали возможный нежелательный код от деструктивных действий в своем любимом репозиторчике.

Заключение

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

Я прекрасно понимаю, что такие инструменты, как Docker не всегда легко осваиваются и местами сложны для понимания. Я сам долго вникал в эту тему и уже потом, когда упорно разобрался во всем, я по-настоящему оценил преимущества контейнеризации и с того момента Docker стал одним из тех инструментов, который я стал постоянно использовать в разработке.