Лучшие практики контейнерной разработки

В какой-то момент времени ваша разработка должна перейти от традиционных монолитных приложений к микросервисам. Это означает появление контейнеров. Мир контейнерной разработки значительно отличается от того, к которому вы привыкли, что означает, что многие старые лучшие практики больше не применимы.
Поэтому, если вы хотите отойти от стандартной разработки приложений, что делать? Учиться как можно быстрее. А учитывая, как быстро развивается мир разработки в наши дни, этот темп достиг бешеной скорости. Поэтому приходится быстро осваивать лучшие практики, иначе есть риск либо быть вытесненным из игры, либо постоянно развертывать приложения, которые либо не работают, либо ненадежны, либо не могут масштабироваться, либо слишком небезопасны для использования в корпоративной среде.

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

Использование стабильных изображений от известных организаций

Этот пункт занимает первое место в списке просто потому, что он стал одним из самых важных вопросов, связанных с безопасностью контейнеров. Все, что вы разрабатываете в контейнерном мире, начинается с образа. Вы можете создать свой собственный образ с нуля или пойти по быстрому пути и взять образ, например, из Docker Hub. Если вы идете по пути сторонних разработчиков, то всегда должны использовать только стабильные образы от известных организаций.
Например, вы хотите развернуть контейнер на основе последнего образа Python. Если выполнить поиск на Docker Hub, то можно найти множество образов для Python, но только один официальный образ от настоящих разработчиков Python. Именно его и следует использовать. Каждый образ, полученный от официальной организации, будет помечен как таковой. Важно, чтобы вы использовали только эти изображения. Не стоит брать изображение из неизвестного источника, поскольку никогда не знаешь, что оно может содержать. 

Сохраняйте небольшие размеры изображений

У вас может возникнуть соблазн сформировать свои контейнеры на основе изображения, включающего в себя несколько колокольчиков и свистков. Помните об этом: Чем больше образ, тем больше контейнер. Если при развертывании приложения, включающего множество подвижных частей, все контейнеры будут основаны на более крупных образах, то это не только приведет к появлению ненужных служб, но и к значительному увеличению расходов на облачный хостинг.
Помните, что идея контейнеризации заключается в достижении огромной масштабируемости при снижении цены. Поэтому развертывание контейнеров на основе больших образов противоречит этой цели.
Не делайте этого. Всегда используйте самый маленький (официальный) образ, который только можно найти. А если не удается найти официальный образ достаточно маленького размера, создайте свой собственный. Кроме того, при использовании более крупного образа план атаки может расти в геометрической прогрессии.

Используйте постоянные данные

Не следует хранить данные в слое хранения контейнера. Почему? По двум причинам: Хранение и доступность. Подумайте вот о чем: Если хранить данные в слое хранения контейнера, то этот контейнер будет расти в геометрической прогрессии. Но и это еще не все. Если контейнер выйдет из строя, то доступ к данным будет невозможен. Вместо этого следует хранить данные в постоянных томах.
Использование томов гарантирует, что размер контейнеров не будет расти по мере накопления данных, а доступ к хранимым данным будет возможен для множества контейнеров. 

Использование CI/CD для тестирования и развертывания

Вам потребуется много тестирования. А развертывание будет происходить постоянно. Помните, что при контейнеризации приложения целью является автоматизация. Вы не хотите замедлять время развертывания из-за необходимости вручную все тестировать и переразвертывать. Вместо этого следует использовать подход Continuous Integration/Continuous Deployment (CI/CD).
Цель CI/CD - автоматизировать как можно больше. Если вы используете CI/CD для тестирования и развертывания, вы увидите, что все работает гораздо эффективнее.

Умело маркируйте образы контейнеров

По мере создания собственных образов (или модификации полученных) их необходимо помечать, прежде чем они будут отправлены в репозитории. Когда вы помечаете эти изображения, убедитесь, что вы делаете это грамотно. Не стоит просто помечать изображение словом "latest" или датой. Возможно, вы добавили в изображение какую-то специфическую функцию или создали изображение для определенной цели.
Убедитесь, что вы пометили эти изображения таким образом, что вы всегда будете знать их назначение.

Обеспечение безопасности на каждом этапе

При разработке контейнеров обеспечение безопасности начинается с первого шага и никогда не прекращается. Это особенно актуально, когда целью является автоматизация. В этом случае безопасность следует рассматривать как круг, который проходит по всем аспектам развертывания. 
Безопасность начинается с базовых образов, проходит через манифесты контейнеров, проверяет DevOps, GitOps и средства автоматизации, следует за развертыванием и возвращается в репозитории, где хранится ваш код. Если рассматривать безопасность как бесконечный компонент, который должен следовать за контейнером от начала до конца, то можно убедиться, что такие развертывания стоит использовать.
Просто помните, что безопасность при разработке контейнеров никогда не успокаивается.

Одно приложение в контейнере

Хотя можно развернуть один контейнер, в котором будут находиться все приложения, необходимые для работы сервиса, этого делать не следует. Почему? Самая главная причина заключается в том, что контейнеры с одним приложением легче масштабировать. А поскольку масштабируемость является одной из основных целей контейнеризации, это не вызывает сомнений.
Масштабируемость становится возможной благодаря тому, что менеджер кластера может развернуть больше контейнеров, когда это необходимо. Например, если для масштабирования вашего приложения требуется только увеличение количества экземпляров базы данных, то если вы развернули эту базу данных в контейнере с другими приложениями, то масштабирование будет включать и эти приложения, что неэффективно. 
Кроме того, контейнеры для одного приложения гораздо проще создавать и тестировать. 

Заключение

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