Docker tag что это

Как работают теги Docker? — CloudSavvy IT

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

Контейнер против изображения

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

Образ Docker — это то, что вы получаете от запуска docker build с вашим Dockerfile. Он состоит из нескольких слоев для оптимизации использования диска и памяти. Изображение доступно только для чтения.

Контейнер Docker — это экземпляр изображения, в котором на самом деле выполняются процессы. Это файловая система для чтения / записи, поэтому, по сути, изображение — это шаблон, из которого вы создаете несколько контейнеров. Он содержит базовый код и все, что нужно приложению для начала работы. Контейнеры инициализируются с образом при создании, затем он может изменять файловую систему, как им будет угодно.

Изображения — это то, что вы нажимаете в реестре контейнера. Затем на ваших серверах вы можете сослаться на изображение в реестре, чтобы загрузить контейнер.

Теги Отслеживание версий встроенных изображений

Всякий раз, когда вы запускаете docker build Вы создаете новое изображение с уникальным идентификатором, например, «38054d5e8a27».

Теги — это просто метки, которые обеспечивают лучший способ управления контролем версий и выпусками. Они похожи на метки, которые вы можете назначить любой завершенной сборке. Вместо того, чтобы ссылаться на идентификатор сборки, вы можете пометить изображение меткой в ​​формате major.minor.patch и легко определить, какой образ какой, или какой формат предпочитает ваша организация.

Это создаст изображение из Dockerfile и пометит его тегом, который вы указали. Тег является [:TAG] часть, после точки с запятой, хотя Докер скажет: Successfully tagged repository/image:tag «. repository/image part — это просто имя изображения, и если вы планируете отправить его в репозиторий, вы должны пометить его в repository/image:tag формат.

Для Docker Hub имя репозитория — это просто ваше имя пользователя, поэтому команда будет выглядеть примерно так:

Если вы не укажете определенный тег, Docker автоматически помечает его как «последний».

Другая распространенная практика — помечать изображение идентификатором git commit, тем самым связывая управление версиями со встроенными изображениями. Вы можете автоматизировать это довольно легко с git rev-parse :

После того, как изображение помечено, вы можете отправить его в реестр с помощью docker push проходя в repository/image название:

Последнее не всегда означает «последнее»

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

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

Или вручную пометив изображение как latest :

который работает хорошо, если вы используете только последний тег. Но если вы также хотите использовать теги идентификатора версии, вам нужно каждый раз ставить двойные теги на свои изображения, что может привести к тому, что «последний» не всегда означает последнее построенное изображение. Это хорошая практика, чтобы избежать использования latest наряду с другими тегами, чтобы предотвратить эту путаницу. Просто делайте версии тегов каждый раз, либо с помощью номеров патчей вручную, либо с помощью идентификаторов коммитов git.

Источник

Изучаем Docker, часть 5: команды

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

Обзор

Давайте вспомним о том, что образы Docker создают на основе файлов Dockerfile, описывающих всё то, что нужно для сборки образов. Кроме того, не будем забывать и о том, что контейнер — это образ Docker, вызванный к жизни. Для того чтобы эффективно пользоваться командами Docker, в первую очередь нужно выяснить — с чем вы имеете дело — с образом или с контейнером. Если подумать об образах и контейнерах, то можно понять, что образ Docker может либо существовать, либо не существовать. То же самое можно сказать и о контейнерах Docker. Существующий контейнер Docker, кроме того, может пребывать либо в работающем, либо в неработающем состоянии.

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

Общие сведения о командах Docker

Вот кое-что, о чём полезно знать тем, кто хочет работать с Docker:

Цель этого материала заключается в том, чтобы дать вам общие сведения о командах Docker. Так вы, имея общее представление о них и зная о возможностях платформы, доступных благодаря этим командам, сможете, при необходимости, найти подробные сведения о них. Команды, о которых пойдёт речь, испытаны на ОС семейства Linux с использованием движка Docker версии 18.09.1 и API версии 1.39.

Примечание о командах, поддерживаемых Docker CLI 1.13

Сначала мы посмотрим на команды, предназначенные для управления контейнерами, затем обсудим управление образами.

Команды для управления контейнерами

Общая схема команд для управления контейнерами выглядит так:

Вот команды, которые могут быть подставлены туда, где мы использовали my_command :

Команды для управления образами

Для управления образами используются команды, которые выглядят так:

Вот некоторые из команд этой группы:

Разные команды

Контейнеры

▍Начало существования контейнера

Вот команда для создания контейнера из образа:

После того, как контейнер создан, его можно запустить следующей командой:

Теперь взглянем на команду, которая позволяет создать и запустить контейнер:

Эта команда тоже способна принимать множество аргументов командной строки. Рассмотрим некоторые из них на примере такой конструкции:

Рассмотрим ещё некоторые примеры команды run :

Вот ещё один пример работы с командой run :

▍Проверка состояния контейнера

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

Эта команда выводит список выполняющихся контейнеров и снабжает этот список некоторыми полезными сведениями о них. Вот ещё один пример этой команды:

Вот команда, которая выводит подробные сведения о контейнере:

Вот команда, выводящая логи контейнера:

▍Завершение работы контейнера

Иногда работающий контейнер надо остановить. Для этого используется такая команда:

Она позволяет останавливать работающие контейнеры, позволяя им корректно завершить работу. У контейнера есть, по умолчанию, 10 секунд, на то, чтобы завершить работу.

Если же контейнер нужно остановить быстро, не заботясь о корректном завершении его работы, можно воспользоваться такой командой:

Вот команда, которая позволяет быстро остановить все работающие контейнеры:

Для удаления остановленного контейнера можно воспользоваться такой командой:

Вот команда, которая позволяет удалить все контейнеры, которые на момент вызова этой команды не выполняются:

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

Образы

▍Создание образов

Вот команда, которая позволяет собирать образы Docker:

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

После того, как образ собран, его можно отправить в удалённый реестр. Благодаря этому им смогут воспользоваться другие люди, его можно будет загрузить и запустить на другом компьютере. Предположим, вы хотите использовать Docker Hub. Если так — вам понадобится завести там учётную запись. Пользоваться этим ресурсом можно бесплатно.

После того, как вы зарегистрируетесь на Docker Hub, вам нужно войти в систему. И хотя команда, которая для этого используется, напрямую к командам, предназначенным для работы с образами, не относится, её полезно будет рассмотреть именно здесь. Речь идёт о следующей команде:

Она позволяет войти в учётную запись на Docker Hub. Для входа в систему вам понадобится ввести имя пользователя и пароль.

После входа в систему можно будет отправлять образы в реестр. Делается это так:

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

▍Исследование образов

Вот команда, которая выводит список образов, выводя, в том числе, и сведения об их размере:

Следующая команда позволяет вывести сведения о промежуточных образах, входящих в состав образа, в частности — данные об их размерах и о том, как они были созданы:

Вот команда, которая выводит подробные сведения об образе, в том числе — данные о слоях, из которых состоит образ:

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

▍Удаление образов

Вот команда, которая позволяет удалить указанный образ:

Если образ хранится в удалённом репозитории, он оттуда удалён не будет.

Вот команда, которая позволяет удалить все локальные образы:

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

Мы рассмотрели основные команды, используемые для управления контейнерами и образами. Поговорим теперь ещё о некоторых командах.

Разные команды

Вот команда, которая выводит сведения о версиях клиента и сервера Docker:

Эта, уже известная вам команда, применяется для входа в реестр Docker:

Такая команда позволяет удалить неиспользуемые контейнеры, сети и образы, которым не назначено имя и тег:

Вот пример её использования:

Итоги

В этом материале мы рассмотрели полезные команды Docker. Если вы только начинаете работать с Docker, то вам стоит обратить внимание на три следующих важнейших команды:

Создание и запуск контейнера:

Отправка образа в удалённый репозиторий:

В следующий раз мы поговорим о работе с данными в Docker.

Уважаемые читатели! Если вы работаете с Docker, то у вас, наверняка, есть собственный список часто используемых команд. Если это так — просим вас этим списком поделиться.

Источник

Создание CI/CD-цепочки и автоматизация работы с Docker

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

Для моего персонального проекта у меня была особая конфигурация. И я знала, что мне нужна возможность разворачивать сайт в продакшне, выполняя всего одно действие: запись кода в ветку master на GitHub. Я, кроме того, знала, что мне, для обеспечения работы моего маленького веб-приложения, не хочется заниматься управлением огромным кластером Kubernetes, или пользоваться технологией Docker Swarm, или поддерживать парк серверов с подами, агентами и всякими другими сложностями. Для того чтобы достичь цели по максимальному упрощению работы, мне понадобилось познакомиться с CI/CD.

Если у вас имеется маленький проект (в нашем случае речь идёт о Node.js-проекте) и вам хотелось бы узнать о том, как автоматизировать развёртывание этого проекта, сделав при этом так, чтобы то, что хранится в репозитории, в точности соответствовало бы тому, что работает в продакшне, то, полагаю, вас может заинтересовать эта статья.

Предварительные требования

Ожидается, что читатель этой статьи имеет базовые знания в области работы с командной строкой и написания Bash-скриптов. Кроме того, ему понадобятся учётные записи Travis CI и Docker Hub.

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

Вот каким в итоге получился мой рабочий процесс.

Что такое CI/CD?

Аббревиатура CI/CD расшифровывается как «continuous integration/continuous deployment» — «непрерывная интеграция/непрерывное развёртывание».

▍Непрерывная интеграция

Непрерывная интеграция — это процесс, в ходе которого разработчики делают коммиты в главное хранилище исходного кода проекта (обычно в ветку master ). При этом качество кода обеспечивается путём проведения автоматизированного тестирования.

▍Непрерывное развёртывание

Непрерывное развёртывание — это частое автоматизированное развёртывание кода в продакшне. Вторая часть аббревиатуры CI/CD иногда раскрывается как «continuous delivery» («непрерывная доставка»). Это, в целом, то же самое, что и «непрерывное развёртывание», но «непрерывная доставка» подразумевает необходимость ручного подтверждения изменений перед запуском процесса развёртывания проекта.

Начало работы

Приложение, на котором я это всё осваивала, называется TakeNote. Это — веб-проект, над которым я работаю, предназначенный для того, чтобы делать заметки. Сначала я попыталась сделать JAMStack-проект, или только фронтенд-приложение без сервера, для того чтобы воспользоваться стандартными возможностями по хостингу и развёртыванию проектов, которые предлагает Netlify. По мере того, как росла сложность приложения, мне понадобилось создать и его серверную часть, а это означало, что мне надо было бы сформировать собственную стратегию по автоматизированной интеграции и автоматизированному развёртыванию проекта.

В моём случае приложение представляет собой Express-сервер, работающий в среде Node.js, обслуживающий одностраничное React-приложение и поддерживающий защищённый серверный API. Эта архитектура следует стратегии, которую можно найти в данном руководстве по фуллстек-аутентификации.

Я посоветовалась с другом, который является экспертом по автоматизации, и спросила его о том, что мне надо сделать для того, чтобы всё это работало так, как мне нужно. Он подкинул мне идею о том, как должен выглядеть автоматизированный рабочий процесс, изложенный в разделе «Цели» этой статьи. То, что я поставила перед собой подобные цели, означало, что мне нужно разобраться в том, как пользоваться Docker.

Docker

Docker — это инструмент, который, благодаря технологии контейнеризации, позволяет легко распространять приложения, а также выполнять их развёртывание и запуск в одном и том же окружении даже в том случае, если сама платформа Docker работает в различных средах. Для начала мне нужно было получить в своё распоряжение инструменты командной строки (CLI) Docker. Инструкцию по установке Docker нельзя назвать очень чёткой и понятной, но из неё можно узнать о том, что для того, чтобы сделать первый шаг установки, надо скачать Docker Desktop (для Mac или Windows).

Docker Hub — это примерно то же самое, что GitHub для git-репозиториев, или реестр npm для JavaScript-пакетов. Это — онлайн-репозиторий для образов Docker. Именно к нему подключается Docker Desktop.

Итак, для того чтобы приступить к работе с Docker, нужно сделать две вещи:

Далее, войдите в Docker Hub, введя, когда вас об этом спросят, свое имя пользователя и пароль:

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

▍Образы

Образ — это нечто вроде плана, содержащего инструкции по сборке контейнера. Это неизменяемый снимок файловой системы и настроек приложения. Разработчики могут с лёгкостью обмениваться образами.

Эта команда выведет таблицу со следующим заголовком:

Далее мы будем рассматривать некоторые примеры команд в таком же формате — сначала идёт команда с комментарием, а потом — пример того, что она может вывести.

▍Контейнеры

Контейнер — это исполняемый пакет, который содержит всё, что нужно для выполнения приложения. Приложение при таком подходе всегда будет работать одинаково, независимо от инфраструктуры: в изолированном окружении и в одной и той же среде. Речь идёт о том, что в разных окружениях запускаются экземпляры одного и того же образа.

Тег — это указание на конкретную версию образа.

▍Краткая справка по командам Docker

▍Файл Dockerfile

Надо отметить, что у меня нет приложения-примера для этого материала. Но тут, для экспериментов, подойдёт любое простое Node-приложение.

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

В зависимости от выбранного базового образа вам может понадобиться установить дополнительные зависимости. Дело в том, что некоторые базовые образы (вроде Node Alpine Linux) созданы с целью сделать их как можно более компактными. В результате в них могут отсутствовать некоторые программы, на которые вы рассчитываете.

▍Сборка, тегирование и запуск контейнера

▍Сборка

Сначала надо собрать образ, указав имя, и, что необзательно, тег (если тег задан не будет, система автоматически назначит образу тег latest ).

После выполнения этой команды можно наблюдать за тем, как Docker выполняет сборку образа.

Сборка может занять пару минут — тут всё зависит от того, сколько у вас имеется зависимостей. После завершения сборки можно выполнить команду docker images и взглянуть на описание своего нового образа.

▍Запуск

Если перейти теперь по адресу localhost:5000 — можно увидеть страницу работающего приложения, которая выглядит точно так же, как страница приложения, работающего в продакшн-окружении.

▍Назначение тега и публикация

Для того чтобы воспользоваться одним из созданных образов на продакшн-сервере, нужно, чтобы у нас была бы возможность загрузить этот образ с Docker Hub. Это значит, что сначала надо создать на Docker Hub репозиторий для проекта. После этого в нашем распоряжении окажется место, куда можно оправить образ. Образ надо переименовать так, чтобы его имя начиналось с нашего имени пользователя на Docker Hub. После этого должно идти название репозитория. В конце имени может располагаться любой тег. Ниже показан пример именования образов по этой схеме.

Теперь можно собрать образ с назначением ему нового имени и выполнить команду docker push для отправки его в репозиторий Docker Hub.

Если всё пройдёт как надо, образ будет доступен на Docker Hub и его легко можно будет загрузить на сервер или передать другим разработчикам.

Следующие шаги

К настоящему моменту мы убедились в том, что приложение, в виде контейнера Docker, работает локально. Мы загрузили контейнер на Docker Hub. Всё это значит, что мы уже очень неплохо продвинулись к цели. Теперь надо решить ещё два вопроса:

Надо отметить, что здесь можно воспользоваться и другой комбинацией сервисов. Например, вместо Travis CI можно воспользоваться CircleCI или Github Actions. А вместо DigitalOcean — AWS или Linode.

Мы решили работать с Travis CI, а в этом сервисе у меня уже кое-что настроено. Поэтому сейчас я кратко расскажу о том, как подготовить его к работе.

Travis CI

Travis CI — это инструмент для тестирования и развёртывания кода. Мне не хотелось бы входить в тонкости настройки Travis CI, так как каждый проект уникален, и это не принесёт особой пользы. Но я расскажу об основах, которые позволят вам начать работу в том случае, если вы решите пользоваться Travis CI. Что бы вы ни выбрали — Travis CI, CircleCI, Jenkins, или что-то другое, везде будут применяться похожие методы настройки.

Для того чтобы приступить к работе с Travis CI, перейдите на сайт проекта и создайте учётную запись. Затем интегрируйте Travis CI с вашим GitHub-аккаунтом. Вам, в ходе настройки системы, понадобится указать репозиторий, работу с которым вы хотите автоматизировать, и включить доступ к нему. (Я пользуюсь GitHub, но уверена, что Travis CI может интегрироваться и с BitBucket, и с GitLab, и с другими подобными сервисами).

Каждый раз, когда Travis CI принимается за работу, запускается сервер, выполняющий указанные в конфигурационном файле команды, включая развёртывание соответствующих веток репозитория.

▍Жизненный цикл задания

▍Тестирование

В конфигурационном файле я собираюсь настроить локальный сервер Travis CI. В качестве языка я выбрала Node 12 версии и указала системе на то, что нужно установить зависимости, необходимые для использования Docker.

Если вы хотите, чтобы в вашем репозитории выводились бы значки со сведениями о покрытии кода тестами, тут вы можете найти краткую инструкцию об использовании Jest, Travis CI и Coveralls для сбора и вывода этих сведений.

Здесь заканчиваются те действия, которые выполняются для всех ветвей репозитория и для pull-запросов.

▍Развёртывание

Скрипт развёртывания решает две задачи:

Итак, первая часть скрипта — это отправка образа на Docker Hub. Сделать это довольно просто. Использованная мной схема составления тегов подразумевает комбинирование git-хэша и git-тега, если он существует. Это позволяет обеспечить создание уникального тега и упрощает идентификацию сборки, на которой он основан. DOCKER_USERNAME и DOCKER_PASSWORD — это пользовательские переменные окружения, которые можно задать с помощью интерфейса Travis CI. Travis CI автоматически обработает секретные данные так, чтобы они не попали в чужие руки.

Настроить работу сервера было не особенно сложно. Так, я настроила дроплет, основанный на базовом образе. Надо отметить, что выбранная мной система требует выполнения однократной ручной установки Docker и однократного ручного запуска Docker. Я, для установки Docker, использовала Ubuntu 18.04, поэтому вы, если тоже используете Ubuntu, чтобы сделать то же самое, можете просто следовать этому простому руководству.

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

Некоторые вещи, на которые стоит обратить внимание

Возможно, когда вы подключитесь к серверу по SSH из Travis CI, вы увидите предупреждение, которое не позволит продолжить установку, так как система будет ждать реакции пользователя.

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

На практике эта команда может выглядеть так:

А вот как выглядит то, что она выдаёт — строка в кодировке base64:

Вот команда, о которой говорилось выше

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

TLS/SSL и балансировка нагрузки

После того, как я сделала всё то, о чём шла речь выше, последней вставшей передо мной проблемой стало то, что у сервера не было SSL. Так как я пользуюсь Node.js-сервером, для того, чтобы заставить работать обратный прокси Nginx и Let’s Encrypt, нужно изрядно повозиться.

Итоги

После того, как я сделала всё то, о чём рассказала в этом материале, меня уже не пугала ни платформа Docker, ни концепции автоматизированных CI/CD-цепочек. Я смогла настроить цепочку непрерывной интеграции, в ходе выполнения которой производится тестирование кода до попадания его в продакшн и автоматическое развёртывание кода на сервере. Всё это для меня пока ещё относительно ново, и я уверена, что есть способы улучшить мой автоматизированный рабочий процесс и сделать его эффективнее. Поэтому если у вас есть идеи на этот счёт — дайте мне знать. Надеюсь, эта статья помогла вам в ваших делах. Мне хочется верить, что прочтя её, вы узнали столько же, сколько узнала я, пока разбиралась со всем тем, о чём в ней рассказала.

P.S. В нашем маркетплейсе имеется образ Docker, который устанавливается в один клик. Вы можете проверить работу контейнеров на VPS. Всем новым клиентам бесплатно предоставляются 3 дня для тестирования.

Уважаемые читатели! Пользуетесь ли вы технологиями CI/CD в своих проектах?

Источник