Файл: Обязательные для изучения материалы.pdf

Как работают секреты
«Секреты» используются Docker сервисами посредством установления явной связи между сервисом и самими секретами. Сервисы, напомню, состоят из задач (отдельных контейнеров), которые могут выполняться на любом узле в пределах вашего кластера. Если ваш сервис состоит из нескольких задач
(контейнеров), связанный с ним «секрет» будет доступен для всех задач этого сервиса.
Docker Swarm кластер использует
Raft Consensus Algorithm для того, чтобы гарантировать, что узлы, участвующие в управлении кластером, договариваются о состоянии кластера. Часть этого процесса включает в себя репликацию состояния всех управляющих узлов кластера при помощи журнала.
Реализация «секретов» в кластере, работающем в Swarm mode режиме, использует алгоритм Raft.
«Секреты» в процессе создания записываются в raft-журнал, что позволяет им реплицироваться на каждый из управляющих узлов кластера. До тех пор, пока кластер работает, журнал Raft хранится в памяти каждого управляющего узла и реплицируется в зашифрованном виде.
В процессе запуска нового сервиса в кластере, если в процессе создания ему предоставлена возможность доступа к тому или иному «секрету», происходит монтирование текстового содержимого
«секретов» в директорию /run/secrets всем задачам (контейнерам) этого сервиса.
Команда docker secret позволяет нам задать «секреты», которые могут быть использованы сервисами, запущенными в Docker Swarm кластере. Есть два способа создания «секрета».
Создание «секрета» из файла
Создайте в рабочей директории файл password.txt который будет содержать секретную информацию, например, пароль к базе данных this-is-my-super-secret-password. Чтобы дать возможность вашим приложениям использовать этот секретный пароль, выполните коману:
$ docker secret create db-password password.txt
Эта команда создаст «секрет» с именем db-password, используя содержимое файла password.txt
Создание «секрета» со стандартных потоков ввода\вывода
Также вы можете создавать «секреты», используя информацию со стандартного потока ввода\вывода:
$ LC_ALL=C < /dev/urandom tr -dc '_A-Z-a-z-0-9' | head -c 32 | docker secret create db-password -

Эта команда также создаст «секрет» db-password, но уже используя сгенерированную информацию из /dev/urandom.
Просмотр «секретов» кластера
Все созданные в кластере секреты могут быть просмотрены при помощи команды:
$ docker secret ls
ID NAME CREATED
UPDATED
iokqhuhj7ix9a57joiarivv8n db-password 3 hours ago 3 hours ago
Удаление «секретов» из кластера
Удаление «секретов» также осуществляется достаточно просто:
$ docker secret rm db-password
Управление сервисом с «секретом»
Запуск
Для того, чтобы запустить ваш сервис и передать ему информацию о «секрете», необходимо выполнить команду:
$ docker service create --name docker_secrets_example -p 5000:5000
--secret db-password amaksimov/docker_secrets_example:v0.1
После чего можно будет убедиться в том, что ваше приложение прочитало файл с секретом:
Если же запустить ваш сервис без указания ключа —secret, например, командой:
$ docker service create --name docker_secrets_example -p 5000:5000 amaksimov/docker_secrets_example:v0.1
То, как и ожидается, ваше приложение об этом сразу же сообщит:

Добавление «секрета» к уже работающему сервису
К сожалению, для того, чтобы добавить секрет к сервису, последний придется пересоздать, предварительно выполнив команду:
$ docker service rm docker_secrets_example
Обновление «секретов» для сервиса
Также к сожалению, для того, чтобы обновить секрет у сервиса, его придется пересоздать.
Заключение
В этой статье мы рассмотрели еще одну возможность Docker, предназначенную для безопасной работы с чувствительными данными ваших приложений. Если у вас возникли какие-либо вопросы, буду рад ответить на них в комментариях в конце статьи.
Docker: решения для хранения образов
-
Андрей Максимов
0 комментариев
На сегодняшний день ни одно решение, построенное на основе или просто использующее Docker, не обходится без хранилища Docker образов (images). Такие хранилища делятся на публично доступные и приватные.
Публично доступные хранилища
Quay.io
—
это хранилище образов Docker от
CoreOS
, который продвигает себя как имеющие «продвинутые триггеры для сборки», «расширенные возможности по управлению привилегиями для команды» и «безопасное хранилище». В настоящий момент из публично доступных решений Quay является наиболее дружественным для использования Enterprise компаниями.
Quay поддерживает любой сервер git, а также позволяет легко создавать сложные рабочие процессы, например, отображение названий веток git в теги Docker. Таким образом, когда вы делаете коммит вашего кода, правильно протегированный Docker образ будет создан автоматически.
Quay предоставляется как публичное решение или же как частная инсталляция. Публичное решение предлагает неограниченное количество бесплатных публичных репозиториев, за приватные репозитории вашей организации придется заплатить.
Docker Hub
является собственным предложением компании Docker. Как и у Quay он предлагает неограниченное количество бесплатных публичных репозиториев и не взимает плату за хранение или

пропускную спо собность. Если вам нужны частные репозитории, они оплачиваются на основе нужного вам количества и количества параллельных сборок. Docker Hub не предлагает возможности гранулярного управления полномочиями, как это сделано у Quay, что может быть проблемой для большего количества Enterprise компаний. Docker Hub также имеет более ограниченную интеграцию git, требуя, чтобы ваш код жил на GitHub или Bitbucket, если вы хотите воспользоваться автоматизированной сборкой. Стоит отметить, что Docker Hub — это основной реестр используемый вами, когда вы выполняете команду docker push или docker pull.
AWS EC2 Container Registry (ECR)
— это относительно новый сервис от Amazon AWS, использовать который имеет смысл только в том случае, если вы уже используете или собираетесь использовать какие-либо другие сервисы от Amazon AWS, например,
Elastic Container Service
. ECR может быть использован как любое другое хранилище образов Docker, но максимальную пользу из него можно извлечь только используя его совместно с другими продуктами
Amazon AWS. Как и большинство других сервисов от AWS, ECR также позволяет очень гибко регулировать уровень доступа и привилегии.
Одна из наиболее важных особенностей ECR в том, что его ценовая политика сильно отличается от Quay и Docker Hub. Вместо того, чтобы брать оплату за количество приватных репозиториев, это решение оплачивается строго по объему занятого стораджа и уровня утилизации сети.
Google Container Registry
— этот репозиторий очень похож на Amazon ECR, только он тесно интегрирован в инфраструктуру облачных сервисов Google. Точно так же его имеет смысл использовать только если часть вашей инфраструктуры будет использовать облачные услуги Google, например, Kubernates.
Ценообразование также похоже на ECR, т.е. вы платите только за объемы хранимых Docker образов и

исходящий сетевой трафик. У данного решения как и у всего облака Google приоритет прежде всего на безопасность, поэтому все пока что не очень удобно, зато очень и очень безопасно. Если вам нужна возможность автоматизировать ваши процессы разработки, тестирования и релизов, скорее всего вам пока не сюда.
Решения для организации частных приватных репозиториев
Docker Registry 2.0
— Открытая версия репозитория, который использует Docker для организации своего
Docker Hub
. Документация на него более, чем исчерпывающая. Возможно все, но это «все» надо настраивать: отказоустойчивость, аутентификацию из правильного источника и само собой управление пользователями. Никакого Web-интерфейса из коробки. Выбирать это решение стоит только если вы готовы потратить какое-то значительное количество времени на «допиливание» этого решения. В противном случае, у Docker можно купить цельное решение для построения контейнерной инфраструктуры
Docker Datacenter
Atomic Registry (RedHat)
— Откр ытая версия репозитория от
RedHat, выполненная на базе одного из проектов OpenShift. Распространяется в виде образов виртуальных серверов, которые можно скачать и запустить в любом Облаке, среде виртуализации или физическом железе. Разработчики хвалят это решение за то, что оно изначально спроектировано для кластеризации и отказоустойчивой работы, красивый Web-интерфейс, а также поддержку SSO и RBAC, что позволяет встроить этот репозиторий в собственную инфраструктуру. Документация достаточная, но далеко не исчерпывающая. Запустив ВМ из образа с этим решением, очень легко понять насколько оно будет вам полезно. На основной странице проекта есть 2 видео, показывающие как поставить и как начать использовать это решение.

Harbor (VMware)
— еще один открытый репозиторий, сделавший ставку на Enterprise компании, реализовав RBAC, репликацию образов между узлами кластера для лучшей балансировки нагрузки, поддержку AD\LDAP, аудитный журнал операций, красивый Web- интерфейс, переведенный на несколько языков, включая русский, REST API и удобный механизм развертывания (виртуальная машина для vSphere в формате OVA).
Portus (Suse)
—
Открытая версия репозитория от Suse. Чуть менее выдающийся Web-интерфейс, чем у предшественников, все те же реализованные RBAC, интеграция с
LDAP, аудит операций, тегирование репозиториев, возможность включить пользователям возможность самостоятельной регистрации с последующей модерацией. Это решение очень простое и понятное.

Sonatype Nexus Repository Manager 3.0 OSS
— Еще один интересный репозиторий, который я доба вляю в этот список уже после того, как статья была опубликована. Это решение позволяет создавать не только репозитории для хранения образов Docker, но в добавок поддерживает и позволяет вам создавать репозитории bower, maven2, npm, nuget, pipi и rubygems. Помимо всего прочего это решение может быть интегрировано с LDAP, позволяет очень гибко разграничивать права доступа пользователей к различным репозиториям, а всю настройку можно легко выполнить в удобном Web-интерфе. Решение абсолютно бесплатное.
Quay.io Enterprise
— Частная инсталляция Quay для установки на площадке и оборудовании конечного заказчика характеризуется возможностью настройки отказоустойчивого режима работы всех компонентов, входящих в состав решения, возможностью организации гео-репликациии образов Docker между датацентрами, возможностью строить процесс непрерывной интеграции, возможностью подключать сканер безопасности образов, например,
Clair
, упоминавшийся в статье
Docker: проверка контейнеров на безопасность
, а также возможность использования LDAP в качестве сторонней базы учетных записей пользователей. Полный список возможностей можно посмотреть тут
Artifactory
— Наверное, самое странное и дорогое решение для хранения образов Docker. Не смотря на то, что это решение можно использовать как SaaS, большинство известных мне компаний успешно используют этот продукт все же в виде отдельной частной инсталляции. Вообще говоря, изначальное назначение этого программного продукта было далеко не хранение образов Docker, однако, с какого-то момента «теперь ваш бинарный репозиторий для хранения артефактов разработки еще и Docker образы хранить умеет».
По материалам
•
An Overview of Docker Registries
•
Comparing Four Hosted Docker Registries
•
Awesome Docker GitHub repository
•
Deploying a private, secured Docker Registry within 15 minutes
Установка приватного Docker репозитория
-
Андрей Максимов
0 комментариев

В этой статье будет рассмотрено как быстро и легко установить собственный приватный Docker репозиторий. Приватный Docker репозиторий может понадобиться вам скорее всего только в одном случае: ограничение доступа к Docker образам периметром вашей организации. В остальных случаях можно пользоваться любыми публично доступными репозиториями.
В качестве решения для организации приватного репозитория мы будем использовать
Sonatype Nexus
Repository Manager 3.0 OSS
. А запускать необходимый контейнер из его образа мы будем при помощи
Docker Compose (
кратко о Docker Compose
).
Для того, чтобы это сделать, создайте в месте, где вы обычно работаете над собственными проектами директорию, например, nexus3, а внутри нее директорию data и файл docker-compose.yml:
$ mkdir -p nexus3/data
$ touch nexus3/docker-compose.yml
$ tree nexus3/
nexus3/
├── data
└── docker-compose.yml
1 directory, 1 file
Содержимое docker-compose.yml будет следующим:
nexus
:
image
:
sonatype/nexus3:latest ports
:
-
"8081:8081"
-
"8123:8123"
volumes
:
- ./data:/nexus-data
В этой конфигурации мы пробрасываем 2 порта до контейнера:
•
8081 — для Web-UI интерфейса
•
8123 — API интерфейс для Docker реестра
Также мы монтируем директорию data текущей директории nexus3 внутрь контейнера (в директорию
/nexus-data) для сохранения состояния контейнера при его перезапусках. При использовании в продуктивной инсталляции вы можете использовать Docker диск (volume), расположенный на NAS или распределенной файловой системе, т.к. GlusterFS, например.
Запуск Docker реестра (Nexus)
Для запуска реестра, как обычно, необходимо выполнить команду docker-compose up с ключем -d для того, чтобы терминал вернул вам управление:
$ docker-compose up -d
Первый запуск Nexus займет какое-то время. Понять, что реестр корректно запустился можно будет по выводу команды docker-compose logs:
$ docker-compose logs
Как только контейнер успешно запустится, вывод команды будет оканчиваться следующими строчками:
nexus_1 |
------------------------------------------------- nexus_1 |