Docker registry что это
Быстрый запуск и использование своего открытого docker-registry
Docker – это программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации (см. Википедию).
Подробные инструкции по установке есть на официальном сайте: https://docs.docker.com/engine/installation/
Если вы читаете эту статью, то вероятно уже знакомы с докером и готовы сделать следующий шаг — поднять свой собственный регистр для удобной доставки приложений на продакшен-сервера.
Когда я начал делать новый проект — решил попробовать использовать докер. Получилось четыре контейнера, которые надо как-то доставлять на сервер. Далее последует рассказ о том, что у меня из этого получилось.
Что имеется на входе:
Другой вариант использования регистра — поднятие собственного.
Докер предоставляет официальный образ с сервером регистра, кроме того есть документация с инструкциями по запуску.
Регистр докера способен работать как по http, так и по https. При использовании защищённого соединения возможна так же авторизация отдельных пользователей. Но нужен сертификат, который можно купить только для доменного имени. Самоподписанный сертификат у меня так и не получилось заставить работать (читал в интернетах, что с этим есть проблемы). Ввиду того, что у меня нет доменного имени — мы рассмотрим открытый регистр с доступом по http. Это значит, что если кто-то узнает адрес вашего регистра — он сможет свободно им пользоваться.
Запуск регистра
Настройка на сервере
Регистр представляет из себя докер-контейнер, который запускается одной командой:
Готово, но для того, чтобы клиент докера на этом сервере мог обращаться к регистру по открытом соединению без авторизации — нужно добавить строчку в конфигурационный файл /etc/default/docker:
После чего нужно перезапустить докер:
Настройки на клиенте
У меня на компьютере для работы докера используется система виртуализации VirtualBox, в которой запускается boot2docker (минимальный образ Linux с докером), который в свою очередь работает с контейнерами. Виртуальных машин, работающих под VirtualBox на компьютере может быть несколько, для управления ими используется docker-machine.
Для того, чтобы можно было обращаться к регистру по открытому соединению без авторизации — нужно добавить опцию в конфигурационный файл, который лежит внутри виртуальной машины, под которой работают контейнеры.
Посмотрим список виртуальных машин:
Подключимся к нашей виртуальной машине:
В ней есть файл /var/lib/boot2docker/profile, в котором присутствует такой фрагмент:
Открываем его на редактирование с sudo, чтобы получилось так:
Использование регистра
Формирование и отправка образа с рабочего компьютера
Представим, что у вас в текущей директории уже есть Dockerfile и мы можем просто собрать новый образ с именем my-image:
Теперь можно добавить образу тег и отправить его в регистр:
Получение образа на сервере
Сейчас образ в регистре, мы можем получить его на сервере и запустить:
Изучаем Docker, часть 2: термины и концепции
В первой части перевода серии материалов, посвящённых Docker, мы сделали общий обзор этой системы. В частности, мы говорили о том, почему технологии контейнеризации важны в наше время, о том, что такое контейнеры Docker, и о том, с чем их можно сравнить. Сегодня мы поговорим об экосистеме Docker и рассмотрим важные термины, с которыми вы можете столкнуться на пути изучения и использования Docker. Продолжив аналогию с разными вкусностями, представим, что наши термины — это пончики. Дюжина пончиков.
Термины экосистемы Docker
Я разбил термины, с которыми вы можете столкнуться в ходе работы с Docker, на две части. Думаю, это облегчит их запоминание. Первый блок терминов будет относиться к механизмам Docker. Второй — к средствам масштабирования решений, основанных на контейнерах.
Механизмы Docker
▍Платформа Docker
Платформа Docker (Docker Platform) — это программа, которая даёт нам возможность упаковывать приложения в контейнеры и запускать их на серверах. Платформа Docker позволяет помещать в контейнеры код и его зависимости. Как результат, системы, основанные на контейнерах, легко масштабировать, так как контейнеры можно переносить и воспроизводить.
▍Движок Docker
Движок Docker (Docker Engine) — это клиент-серверное приложение. Компания Docker разделила движок Docker на два продукта. Docker Community Edition (CE) — это бесплатное ПО, во многом основанное на опенсорсных инструментах.
Вероятно, вы будете пользоваться именно этой версией Docker. Docker Enterprise — это платная версия системы, дающая пользователям дополнительные возможности в области поддержки систем, управления ими и безопасности. Платная версия Docker даёт компании средства, необходимые для её существования.
▍Клиент Docker
Клиент Docker и другие механизмы экосистемы (взято из документации)
▍Демон Docker
Демон Docker (Docker Daemon) — это сервер Docker, который ожидает запросов к API Docker. Демон Docker управляет образами, контейнерами, сетями и томами.
▍Тома Docker
Тома Docker (Docker Volumes) представляют собой наиболее предпочтительный механизм постоянного хранения данных, потребляемых или производимых приложениями.
▍Реестр Docker
Реестр Docker (Docker Registry) представляет собой удалённую платформу, используемую для хранения образов Docker. В ходе работы с Docker образы отправляют в реестр и загружают из него. Подобный реестр может быть организован тем, кто пользуется Docker. Кроме того, поставщики облачных услуг могут поддерживать и собственные реестры. Например, это касается AWS и Google Cloud.
▍Хаб Docker
Хаб Docker (Docker Hub) — это самый крупный реестр образов Docker. Кроме того, именно этот реестр используется при работе с Docker по умолчанию. Пользоваться хабом Docker можно бесплатно.
▍Репозиторий Docker
Репозиторием Docker (Docker Repository) называют набор образов Docker, обладающих одинаковыми именами и разными тегами. Теги — это идентификаторы образов.
Обычно в репозиториях хранятся разные версии одних и тех же образов. Например, Python — это имя популярнейшего официального репозитория Docker на хабе Docker. А вот Python:3.7-slim — это версия образа с тегом 3.7-slim в репозитории Python. В реестр можно отправить как целый репозиторий, так и отдельный образ.
Теперь поговорим о терминах экосистемы Docker, имеющих отношение к масштабированию.
Масштабирование решений, основанных на контейнерах
Следующие четыре термина имеют отношение к одновременному использованию нескольких контейнеров.
▍Сеть Docker
Сетевые механизмы Docker (Docker Networking) позволяют организовывать связь между контейнерами Docker. Соединённые с помощью сети контейнеры могут выполняться на одном и том же хосте или на разных хостах. Подробности о сетевой подсистеме Docker можно почитать здесь.
▍Docker Compose
▍Docker Swarm
Docker Swarm — это решение, предназначенное для управления контейнерными развёртываниями (то есть, как говорят, для оркестрации контейнеров). В этом материале из официального учебного курса по Docker можно найти сведения о Docker Swarm. Мне хотелось бы порекомендовать вам не тратить время на изучение Docker Swarm в том случае, если у вас нет на то веской причины.
▍Сервисы Docker
Сервисы Docker (Docker Services) — это различные части распределённого приложения. Вот что о них говорится в документации:
Сервисы — это всего лишь «контейнеры в продакшне». В пределах сервиса выполняется лишь один образ, но сервис определяет то, как именно выполняется образ. В частности, речь идёт о том, какие порты должны использоваться, сколько реплик контейнера должно выполняться для того, чтобы сервис обеспечивал бы необходимую вычислительную мощность, и так далее. Масштабирование сервисов предусматривает изменение количества экземпляров контейнера, в которых работает некая программа, благодаря чему сервису выделяется столько системных ресурсов, сколько ему требуется для решения некоей задачи.
Сервисы Docker позволяют масштабировать контейнеры в пределах нескольких демонов Docker, благодаря им существует и технология Docker Swarm.
Краткий перечень терминов
Давайте, буквально в двух словах, повторим только что представленные вам термины:
Вот, на всякий случай, ещё один пончик
Этот термин относится не к самой платформе Docker, а к технологии, которая очень часто используется совместно с Docker.
Kubernetes
Kubernetes — это технология, которая позволяет автоматизировать развёртывание и масштабирование контейнеризированных приложений, а также управление ими. Это — бесспорный лидер рынка средств для оркестрации контейнеров. Если вам нужен инструмент для работы с группами контейнеров, для масштабирования решений, основанных на них, используйте не Docker Swarm, а Kubernetes. Kubernetes не является частью Docker. Они с Docker, скорее, похожи на лучших друзей.
Теперь, когда вы ознакомились с общими понятиями Docker и с терминологией, вы можете приступить к практическим экспериментам.
Итоги: печём пончики с Docker
Помните, как в прошлый раз мы сравнивали платформу Docker с духовкой, которую устанавливают в кухне? Сейчас самое время установить Docker на вашей «кухне» и что-нибудь приготовить.
Docker можно запускать локально на Linux, Mac и Windows. Если вы пользуетесь Mac или Windows, вы можете установить свежую версию Docker Desktop отсюда. Вместе с этой программой, кстати, устанавливается и Kubernetes. Если вы устанавливаете Docker на другой платформе, то загляните сюда для того, чтобы найти подходящую версию.
После установки Docker взгляните на первые две части официального руководства.
В следующий раз мы продолжим разговор о Docker. В частности, поговорим о файлах Dockerfile.
Уважаемые читатели! Если, читая материалы этой серии, вы открываете для себя Docker, просим рассказать о том, как вы планируете использовать технологии контейнеризации приложений.
Docker Registry для GitLab
Конфигурация
Настройка GitLab Registry
Добавляем nginx reverse proxy
Для удобства (в дальнейшем при настройке Pages нам еще очень пригодится nginx reverse proxy) поднимем reverse proxy, который спрячет GitLab с его родным nginx. Переводить полностью GitLab на сторонний nginx в целом не имеет смысла, так как тогда конфигурация усложняется и при обновлениях GitLab могут быть проблемы.
Конфигурация GitLab
Конфигурация nginx
Допустим, nginx у нас уже установлен. На Centos так же необходимо было закомментировать секцию с приветственной страницей nginx в файле и указать в include директорию с конфигурациями сайтов (или определенную конфигурацию).
Теперь GitLab работает как и прежде, но проксируется.
Добавление Docker Registry
Конфигурация GitLab
Изменим уже известный нам конфигурационный файл.
Конфигурация nginx
Добавим новые части конфигурации в конфиг nginx.
Docker Registry
. warning Стоит так же с помощью фаервола изолировать лишние запросы к Registry, хотя без обращения к серверу, на котором у нас reverse proxy, Registry будет ругаться на то что наш запрос с HTTPS, а клиент HTTP.
Официальная документация
. note «Подсказки так же на странице репозитория в разделе Registry» 
Copyright © 2017 Александр Пинегин aka Bloody Foxy
Делаем свой Dockerhub или что такое docker registry
Если вы собираете свои контейнеры (образы) Docker, то наверняка их где то размещаете, а раз читаете эту статью, то размещаете скорее всего на dockerhub. Проблема такого способа в том, что в бесплатной версии есть ограничения, да и все ваши образы видны всему интернету. А вдруг вы захотите спрятать что то ценное в контейнер и не захотите этим делиться? Тогда на помощь нам приходит docker registry.
Registry
Docker registry это обычный docker контейнер, который выполняет роль репозитория. Это дает нам возможность поднять репозиторий для docker образов, который можно разместить где угодно, привязать доменное именное, сертификат, ограничить доступ к серверу и другие плюшки, которые только сможете придумать.
Конечно чтобы доступ был откуда угодно желательно на сервере (или компьютере) иметь статичный адрес. Можно конечно это все обойти, соединив например компьютеры при помощи VPN сетей, но это уже другая история.
Установка registry
Установка проще быть не может. Лезем в официальную документацию по Docker и находим там статью по docker registry.
У нас происходит запуск контейнера в фоновом режиме с прокинутым портом 5000 на хост и 5000 внутри контейнера. Контейнер называется registry и использует образ registry:2.
Вроде все легко и просто. Registry можно поднять так же и через docker-compose, и через docker swarm. Разницы в способе запуска нет, это всего лишь контейнер.
Docker daemon.json
У нас нет сертификатов, а может и есть, но мы их еще не прикручивали к нашему контейнеру ( а точнее серверу), из-за чего обращение к нашему репозиторию будет происходит без шифрования, подписей и др., т.е по HTTP. Из-за этого docker будет ругаться, т.к он работает только по HTTPS.
Чтобы поставить заглушечку нам нужно создать файл /etc/docker/daemon.json (если такого еще нет) и добавить туда строчку:
IP и PORT меняем наши (вместо IP можно указать доменное имя). Перезапускаем docker:
И вот теперь можно приступить к работе с нашим репозиторием.
Небольшое примечание.
Такую операцию придется делать на каждом хосте, где вы захотите скачать образ из вашего репозитория (docker registry). Все это до тех пор, пока не прикрутите сертификат для HTTPS.
Docker push
Время для самого сладкого — заливки образа в наш приватный репозиторий.
Давайте скачаем какой нибудь образ, чтобы пока не заморачиваться со сборкой своего. Пусть это будет например созданный мной образ для основы контейнеров с криптокошельками:
Образ у нас в системе, теперь нужно дать ему метку:
Мы говорим докеру на какой образ вешать метку и как он будет называться далее. IP адрес и порт указываем нашего регистри (репозитория). Т.е мы говорим докеру, чтобы он залил образ по такому адрес:порт под названием base_our.
Осталось все это дело только запушить:
И вуаля — наш docker образ залился в созданный нами приватный репозиторий.
Теперь чтобы скачать это чудо с другой машинки. Нам нужно всего лишь выполнить:
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Docker. Зачем и как
Есть множество прекрасных публикаций для тех, кто уже пользуется docker-ом. Есть хорошие статьи для тех, кто хочет этому научиться. Я пишу для тех, кто не только не знает, что такое docker, но и не уверен стоит ли ему это знать.
Я сознательно опускаю некоторые технические подробности, а кое где допускаю упрощения. Если вы увидите, что docker – то, что вам нужно, вы легко найдете более полную и точную информацию в других статьях.
Начну я с описания нескольких типичных проблем.
Проблемы
Первая проблема — как передать продукт клиенту.
Предположим у вас есть серверный проект, который вы закончили и теперь его необходимо передать пользователю. Вы готовите много разных файликов, скриптов и пишите инструкцию по установке. А потом тратите уйму времени на решения проблем клиента вроде: «у меня ничего не работает», «ваш скрипт упал на середине — что теперь делать», «я перепутал порядок шагов в инструкции и теперь не могу идти дальше» и т. п.
Всё усугубляется если продукт тиражируемый и вместо одного клиента у вас сотни или тысячи покупателей. И становится еще сложнее, если вспомнить о необходимости установки новых версий продукта.
Вторая проблема — тиражируемость. Пусть вам нужно поднять 5 (или 50) почти одинаковых серверов. Делать это вручную долго, дорого и подвержено ошибкам.
Наконец, третья проблема — переиспользуемость. Предположим у вас есть отдел, который делает браузерные игры. Предположим, что их у вас уже несколько. И все они используют один и тот же технологический стэк (например — java-tomcat-nginx-postgre). Но при этом, чтобы поставить новую игру вы вынуждены заново подготавливать на новом сервере почти одинаковую конфигурацию. Вы не можете просто так взять и сказать — «хочу сервер, как в игре странники но только с другим веб архивом»
Обычные решения
Как обычно решаются эти проблемы.
Установочный скрипт
Первый подход я уже упомянул — вы можете написать скрипт, который установит всё, что вам нужно и запускать его на всех нужных серверах. ( Скрипт может быть как простым sh файлом, так и чем-то сложным, созданным с использованием специальных инструментов).
Недостатки этого подхода — хрупкость и неустойчивость к ошибкам. Как бы хорошо не был написан скрипт, рано или поздно на какой-то машине он упадёт. И после этого падения машина фактически окажется «испорченной» — просто так «откатить» те действия, которые скрипт успел выполнить, у вашего клиента не получится.
Облачные сервисы
Второй подход — использование облачных сервисов. Вы вручную устанавливаете на виртуальный сервер всё, что вам нужно. Затем делаете его image. И далее клонируете его столько раз, сколько вам надо.
Недостатка здесь два. Во-первых, vendor-lock-in. Вы не можете запускать свое решение вне выбранного облака, что не всегда удобно и может привести к потерям несогласных с этим выбором клиентов. Во-вторых, облака медленны. Виртуальные (и даже «bare-metal») сервера предоставляемые облаками на сегодняшний день сильно уступают по производительности dedicated серверам.
Виртуальные машины
Третий подход — использование виртуальных машин. Здесь тоже есть недостатки:
Размер — не всегда удобно качать образ виртуальной машины, который может быть довольно большим. При этом, любое изменение внутри образа виртуальной машины требует скачать весь образ заново.
Сложное управление совместным использованием серверных ресурсов — не все виртуальные машины вообще поддерживают совместное использование памяти или CPU. Те что поддерживают, требуют тонкой настройки.
Подход докера — контейнеризация
И вот тут появляется docker, в котором
Как работает docker
Создание образа
Сначала создается docker image (или образ). Он создается при помощи скрипта, который вы для этого пишете.
Образы наследуются и, обычно, для создания своего первого образа мы берём готовый образ и наследуемся от него.
Чаще всего мы берем образ в котором содержится та или иная версия linux. Скрипт тогда начинается как-то так:
Кроме этого, мы можем копировать в наш образ любые локальные файлы при помощи директивы COPY.
Докер поддерживает гораздо больше различных директив. Например, директива USER roman говорит докеру что все следующие директивы нужно выполнять из под пользователя roman. А директива ENTRYPOINT [“/opt/tomcat/catalina.sh”] задает исполняемый файл, который будет запускаться при старте.
Я не буду перечислять все остальные директивы — в этом нет смысла. Здесь главное — принцип: вы создаёте вот такой скрипт, называете его Dockerfile и запускаете команду docker build, docker выполняет скрипт и создает image.
Если в процессе возникают какие-то ошибки, докер о них сообщает и вы их исправляете. То есть исправление скрипта происходит на этапе создания image. На этапе установки скрипт уже не используется.
Создание контейнера
Когда у вас уже есть docker image вы можете создать из него контейнер на любом физическом сервере, где установлен докер. Если image – это тиражируемый образ некоторой «машины», то container это уже сама «машина», которую можно запускать и останавливать.
Важный момент — при создании контейнера из image, его можно параметризовать. Вы можете передавать докеру переменные окружения, которые он использует при создании контейнера из image. Так вы сможете создавать немного разные машины из одного образа. Например, передать образу web-сервера его доменное имя.
Хорошей практикой в докере считается «упаковка» в один контейнер ровно одного постоянно работающего серверного процесса. Как я уже упоминал, этот процесс работает на уровне физического сервера и честно регулируется установленной там операционной системой. Поэтому, в отличие от виртуальных машин, контейнеры докера не требуют специального управления памятью и процессорами. Использование ресурсов становится простым и эффективным.
Union filesystem
Ок — память и процессор используется эффективно. А как насчёт файловой системы? Ведь если у каждого контейнера докера своя собственная копия операционной системы, то мы получим ту же проблему, что и с виртуальными машинами — тяжеловесные образы, которые содержат одно и тоже.
На самом деле в докере это не так. Если вы используете 100500 контейнеров, основанных на одном и том же образе операционной системы, то файлы этой системы будут скачаны докером ровно один раз. Это достигается за счёт использования докером union file system.
Union file system состоит из слоёв (layers). Слои как бы наложены друг на друга. Некоторые слои защищены от записи. Например, все наши контейнеры используют общие защищенные от записи слои, в которых находятся неизменяемые файлы операционной системы.
Для изменяемых файлов каждый из контейнеров будет иметь собственный слой. Естественно, докер использует такой подход не только для операционной системы, но и для любых общих частей контейнеров, которые были созданы на основе общих «предков» их образов.
Container registry
Получается, что docker image состоит из слоёв. И хорошо было бы уметь скачивать на наш сервер только те слои, которых на нём пока нет. Иначе для установки 100 контейнеров, основанных на Ubuntu мы скачаем Ubuntu внутри их образов 100 раз. Зачем?
Хорошая новость в том, что докер решает эту проблему. Докер предоставляет специальный сервис, называемый docker registry. Docker registry предназначен для хранения и дистрибуции готовых образов. Собрав новый образ (или новую версию образа) вы можете закачать его в docker registry. Соответственно, потом его можно скачать оттуда на любой сервер. Главная фишка здесь в том, что физически качаться будут только те слои, которые нужны.
Например, если вы создали новую версию образа, в котором поменяли несколько файлов, то в registry будут отправлены только слои, содержащие эти файлы.
Аналогично, если сервер качает из registry какой-то образ, скачаны будут только слои, отсутствующие на сервере.
Docker registry существует и как общедоступный сервис и как open source проект, доступный для скачивания и установки на собственной инфрастуктуре.
Использование контейнеров
Созданные контейнеры можно запускать, останавливать, проверять их статус и т д. При создании контейнера можно дополнительно передать докеру некоторые параметры. Например, попросить докер автоматически рестартовать контейнер, если тот упадёт.
Взаимодействие между контейнерами
Если контейнеров на сервере несколько, управлять ими вручную становится проблематично. Для этого есть технология docker compose. Она существует поверх докера и просто позволяет управлять контейнерами на основе единого конфигурационного файла, в котором описаны контейнеры, их параметры и их взаимосвязи (например контейнер A имеет право соединяться с портом 5432 контейнера B)
Выводы
Таким образом докер очень хорошо подходит для решения перечисленных выше задач: