Container Registry: кому нужен и как использовать готовый реестр контейнеров

Рассказываем о решении, которое ускорит деплой приложений и сделает работу с контейнерами более удобной. 

---

Container Registry — это готовый к работе реестр контейнеров, хранилище образов, где ими можно управлять: добавлять новые, удалять старые, запускать из образов контейнеры.

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

Зачем нужны образы

Образ — базовое понятие, хорошо известное всем, кто имеет дело с контейнерами в разработке. Если вы среди них, смело переходите на блок текста про организацию хранения образов. 

Без образа не запустить новый контейнер. Образ содержит написанное разработчиками приложение (код) и зависимости (софт, библиотеки, исполняемые файлы и т.д.), необходимые для запуска сервиса в контейнере. 

Изолированность — одно из ключевых преимуществ контейнеризации. Разработчик  может локально запустить свое приложение в одном окружении (например, в Ubuntu) — все будет работать. Но, если то же приложение запустить на Debian или Fedora, может произойти конфликт. С приложением в контейнере такое не случится — оно запустится в любой, даже «инородной» среде. 

Для создания нового образа можно использовать специальное ПО — чаще всего используют Docker, а именно — Dockerfile. Этот файл содержит шаги, или инструкции, которые выполнит Docker при собрании образа. Инструкции варьируются: можно добавлять файлы, устанавливать программное обеспечение, выполнять настройки сети и другие действия. В образе инструкции образуют собой слои в формате read-only. 

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

Ни одна компания, работающая с контейнерами, не обходится без хранилища образов. От их правильного хранения и использования зависит беспроблемный ход разработки. Сервисы, где хранят образы, называются реестрами. 

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

Организация хранения образов

Можно выделить три подхода к организации хранения образов. Команда разработки может создать хранилище самостоятельно с помощью инструментов open source, использовать публичный облачный сервис или выбрать готовое решение провайдера инфраструктуры. Рассмотрим преимущества и недостатки каждого из них.

Самостоятельное создание хранилища 

Разработчики арендуют инфраструктуру и настраивают на ней собственное хранилище с помощью одного из бесплатных инструментов. В числе таких — GitLab Container Registry, Harbor, Atomic Registry и другие. Как правило, они распространяются в виде образов виртуальных машин, которые можно скачать и запустить в облаке или на bare metal.

Преимущество подхода в том, что компания может создать более кастомизируемое хранилище, самостоятельно прописать необходимую автоматизацию, полностью контролировать работу с образами. 

Здесь же кроются недостатки: 

1. Для четкой и безошибочной работы хранилища нужны опытные специалисты с опытом работы в построении процессов CI/CD. 
2. Придется арендовать дополнительную инфраструктуру и администрировать ее. Так, GitLab рекомендует использовать сервер с не менее чем 2 vCPU и 4 ГБ оперативной памяти. 
3. Нужно учитывать объем доступных ресурсов (например, памяти диска), если используете инфраструктуру со сложно масштабируемыми параметрами конфигурации. Если не следить за этим, сохранение очередной новой версии образа может пойти не по плану. 

Использование публичного сервиса

Компания использует DockerHub – решение от Docker. Оно предлагает неограниченное количество бесплатных публичных репозиториев, но за частные придется платить. 

Очевидное преимущество решения — в наличии бесплатного тарифа. Также можно выделить развитое комьюнити и большое количество документации по работе с инструментом. 

Но есть и недостатки: 

1. Использование публичного репозитория может быть небезопасно. Так, в 2020 году анализ общедоступных сборок на Docker Hub показал, что 51% из них имеют критические уязвимости, а около 6500 из 4 миллионов последних изображений можно считать вредоносными. Безопасность контейнерной разработки — до сих пор одна из самых обсуждаемых тем. 
2. Реестр находится на стороннем ресурсе, а не рядом с инфраструктурой приложения. Это может влиять на скорость загрузки и скачивания образов. 
3. Большинство провайдеров тарифицирует внешний трафик. А значит, связность стороннего сервиса с инфраструктурой будет платной. 

Решение от провайдера IT-инфраструктуры 

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

Вот почему: 

1. Повышается скорость развертывания контейнеров из-за близкого нахождения инфраструктуры с реестром образов.
2. У провайдера могут быть предусмотрены особые условия для тех, кто пользуется несколькими продуктами в инфраструктуре. Если говорить про Container Registry от Selectel, трафик между услугой Managed Kubernetes, инфраструктурой в облачной платформе и хранилищем образом бесплатный. Важно: это не распространяется на физическую инфраструктуру. Если у вас развернут Kubernetes, Docker, Docker Swarm, Nomad на выделенном сервере, трафик до подключенного Container Registry будет тарифицироваться. 
3. Готовое решение безопаснее публичных сервисов — вы получаете частный репозиторий, который хранится в трех копиях. 

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

Кому подойдет и не подойдет Container Registry

Готовый для работы реестр образов подойдет компаниям, которые поддерживают микросервисную инфраструктуру или разрабатывают приложения в контейнерах. Они могут быть клиентами Managed Kubernetes или развертывать контейнеры на облачных или физических серверах Selectel. Также решение — выбор для тех, кто не хочет заниматься настройкой и администрированием собственного хранилища образов, а также отдает высокий приоритет безопасности. 

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

Container Registry в бете

На время бета-тестирования услугой можно пользоваться бесплатно. Но есть ограничение: в рамках одного проекта в облаке есть лимиты на один реестр в объеме 20 ГБ и 50 репозиториев. 

Весь фидбек по работе с хранилищем можете направлять в тикетах через панель управления.

О выходе услуги в коммерческий релиз мы сообщим отдельно и заранее. 

Подробнее о старте работы с Container Registry читайте в базе знаний. Там — инструкции о том, как создать реестр, авторизоваться в Docker CLI, управлять образами и другие.

Container Registry

Полностью готовый к работе реестр для хранения образов контейнеров.