Entrypoint что это
Перейти к содержимому

Entrypoint что это

  • автор:

Основные инструкции Docker

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

Обложка поста Основные инструкции Docker

Это третья часть серии статей про Docker и она всецело посвящена Docker-файлам. В первой части основные концепции Docker объясняются на простых примерах из жизни. Во второй статье — краткий обзор экосистемы Docker.

Docker-образы

Docker-образ создаётся во время сборки, а Docker-контейнер — во время запуска приложения.

Docker-файл — сердце Docker’а. Он указывает Docker’у как построить образ, который будет использоваться при создании контейнера.

Каждый Docker-образ содержит файл с именем Dockerfile (он без расширения). При вызове docker build предполагается, что Dockerfile будет находиться в текущей рабочей директории. Но с помощью флага -f можно указать другое расположение.

Контейнер состоит из ряда слоёв. Все слои доступны только для чтения, кроме последнего – он располагается над остальными. Docker-файл указывает порядок добавления слоёв.

Каждый слой — это просто файл с изменением предыдущего слоя. В Unix практически всё является файлом.
Базовый слой, его ещё называют родительским, – это начальный слой.

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

Инструкция Docker-файла — слово в верхнем регистре, которое стоит перед аргументом какой-либо команды. Каждая строка в Docker-файле может содержать инструкцию, все они обрабатываются сверху вниз. Инструкции выглядят так:

FROM ubuntu:18.04 COPY . /app 

И только инструкции FROM , RUN , COPY и ADD создают слои в конечном образе. Другие инструкции производят настройку, добавляют метаданные или же просто говорят Docker’у сделать что-либо во время запуска (например открыть порт или выполнить команду).

Эта статья предполагает использование Unix Docker-образа. Вы, конечно, можете использовать и Windows Docker-образ, но он медленнее, менее удобный и, вообще, его не часто применяют. Так что, пользуйтесь Unix по возможности.

Несколько Docker-инструкций

  • FROM — задаёт родительский (главный) образ;
  • LABEL — добавляет метаданные для образа. Хорошее место для размещения информации об авторе;
  • ENV — создаёт переменную окружения;
  • RUN — запускает команды, создаёт слой образа. Используется для установки пакетов и библиотек внутри контейнера;
  • COPY — копирует файлы и директории в контейнер;
  • ADD — делает всё то же, что и инструкция COPY . Но ещё может распаковывать локальные .tar файлы;
  • CMD — указывает команду и аргументы для выполнения внутри контейнера. Параметры могут быть переопределены. Использоваться может только одна инструкция CMD ;
  • WORKDIR — устанавливает рабочую директорию для инструкции CMD и ENTRYPOINT ;
  • ARG — определяет переменную для передачи Docker’у во время сборки;
  • ENTRYPOINT — предоставляет команды и аргументы для выполняющегося контейнера. Суть его несколько отличается от CMD , о чём мы поговорим ниже;
  • EXPOSE — открывает порт;
  • VOLUME — создаёт точку подключения директории для добавления и хранения постоянных данных.

Инструкции и примеры к ним

Docker-файл чисто теоретически может содержать только одну строчку:

FROM ubuntu:18.04 
FROM

Docker-файл должен начинаться с инструкции FROM или ARG , за которой следует FROM . Команда FROM говорит Docker’у использовать базовый образ, который соответствует репозиторию и тегу.

В этом примере хранилище образов — Ubuntu. Ubuntu — название официального Docker-репозитория, в котором и содержится данная ОС.

Заметьте, что этот Docker-файл содержит тег для базового образа: 18.04, который указывает Docker’у, какую именно версию образа нужно использовать. Если тег не указан, по умолчанию берётся последняя версия образа. Но лучше всё же указывать тег базового образа. Когда Docker-файл, приведённый выше, используется для создания локального Docker-образа впервые, он загружает слои, указанные в образе Ubuntu.

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

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

Подробнее про Docker-файл

Кроме того, что ваш однострочный образ сжат, он ещё и медленный, предоставляет мало информации и ничего не делает во время запуска контейнера. Посмотрите на более длинный Docker-файл, который запускает более легковесный образ, а также выполняет скрипт во время запуска.

FROM python:3.7.2-alpine3.8 LABEL maintainer="jeffmshale@gmail.com" ENV ADMIN="jeff" RUN apk update && apk upgrade && apk add bash COPY . ./app ADD https://raw.githubusercontent.com/discdiver/pachy-vid/master/sample_vids/vid1.mp4 \ /my_app_directory RUN ["mkdir", "/a_directory"] CMD ["python", "./my_script.py"] 

Но что же это всё обозначает?

В роли базового образа выступает официальный Python-образ с тегом 3.7.2-alpine3.8. Как вы можете увидеть из исходников, образ включает в себя Linux, Python и ничего более. Alpine-образы очень популярны, потому что они маленькие, быстрые и безопасные. Однако Alpine-образы не поставляются сразу со всеми компонентами, характерными для вашей ОС. Некоторые пакеты вам придётся установить самостоятельно.

LABEL

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

ENV

ENV создаёт переменную окружения, которая становится доступной во время запуска контейнера. В примере выше вы могли видеть использование переменной ADMIN при создании контейнера.

ENV удобна для обозначения констант. Если константа используется в нескольких местах файла Dockerfile, и вам понадобится изменить её значение позднее, это можно будет сделать в одном месте.

Docker-файл зачастую предоставляет несколько путей решения одной задачи. Будет хорошо, если в вашем решении будет учитываться баланс Docker-соглашений, прозрачность и скорость. К примеру, RUN , CMD и ENTRYPOINT служат различным целям и могут использоваться для выполнения команд.

RUN

RUN создаёт слой во время запуска. Docker фиксирует состояние образа после каждой инструкции RUN .

Чаще всего используется для установки нужных пакетов внутрь контейнера. В примере выше RUN apk update && apk upgrade говорит Docker’у обновить пакеты из базового образа. && apk add bash указывает на то, что для базового образа нужно установить bash .

apk — это сокращение от Alpine Linux package manager. Если вы используете базовый образ не Alpine Linux, то установка пакетов производится командой RUN apt-get .

RUN и её родственные инструкции: CMD , ENTRYPOINT — могут быть как форме оболочки, так и в форме shell-скрипта. Во втором случае используют JSON-синтаксис: RUN [«my_executable», «my_first_param1», «my_second_param2»] . А в примере выше использовалась форма оболочки: RUN apk update && apk upgrade && apk add bash .

Позднее в вашем Docker-файле вы будете создавать новую директорию, используя [«mkdir», «/a_directory»] . Не забывайте, что в JSON нужно использовать двойные кавычки!

COPY

Инструкция COPY . ./app говорит Docker’у, что нужно скопировать файлы и папки из вашей локальной сборки в рабочую директорию образа. COPY создаст все нужные папки, если они отсутствуют.

ADD

ADD делает то же самое, что и COPY , но с двумя отличиями. ADD может загружать файлы по URL, а также извлекать локальные TAR-файлы.

В примере выше ADD копировала файлы по URL внутрь директории контейнера. Но официальныя документация не рекомендует использовать ADD так, потому что потом вы попросту не сможете удалить файлы. А дополнительные файлы увеличивают размер образа.

Ещё официальная документация для ясности рекомендует использовать, когда это возможно, COPY вместе ADD . Жаль только, что в Docker’е невозможно использовать ADD и COPY в одной команде.

Заметьте, инструкция содержит символ \ . Это нужно для лучшей читаемости – так вы разбиваете длинную инструкцию на несколько строк.

CMD

CMD — инструкция для запуска чего-либо во время запуска самого контейнера. По ходу сборки она не фиксирует никакого результата. В примере выше во время сборки запускался скрипт my_script.py .

Ещё пара моментов о CMD :

  • Только одна CMD -инструкция на весь Docker-файл. Иначе все кроме последней будут проигнорированы;
  • CMD может включать исполняемый файл;
  • Если же CMD не содержит никакого файла, обязательно должна быть инструкция ENTRYPOINT . В этом случает обе инструкции должны быть в формате JSON;
  • Аргументы командной строки для запуска Docker переопределяют аргументы, предоставленные CMD в Docker-файле.

Готовы к большему?

В следующем примере представлены ещё несколько Docker-инструкций:

FROM python:3.7.2-alpine3.8 LABEL maintainer="jeffmshale@gmail.com" # Install dependencies RUN apk add --update git # Set current working directory WORKDIR /usr/src/my_app_directory # Copy code from your local context to the image working directory COPY . . # Set default value for a variable ARG my_var=my_default_value # Set code to run at container run time ENTRYPOINT ["python", "./app/my_script.py", "my_var"] # Expose our port to the world EXPOSE 8000 # Create a volume for data storage VOLUME /my_volume 

В Docker-файле вы можете добавлять комментарии. Комментарии начинаются со знака # .

Обычно установка пакетов — приоритетная задача для Docker’а. Как говорилось ранее, есть несколько способов загрузки пакетов при помощи инструкции RUN .

Для Alpine Docker-образа вы используете apk. apk для типичной Linux-сборки — apt-get . Например, пакеты для базового Ubuntu-образа могут быть установлены и обновлены так: RUN apt-get update && apt-get install my_package .

В дополнение к apk и apt-get , Python-пакеты могут быть установлены через pip, wheel и conda. Методы варьируются в зависимости от языка.

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

Можно использовать RUN вместе с pip и списком нужных пакетов. Для этого объедините команды установки пакетов в одну инструкцию и разделите их символом продолжения строки ( \ ). Этот метод позволяет улучшить читаемость и уменьшить количество слоев (из-за отсутствия возможности использовать несколько RUN инструкций).

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

WORKDIR

Меняет текущую рабочую директорию в контейнере для инструкций: COPY , ADD , RUN и ENTRYPOINT .

  • Предпочтительно задать абсолютный путь с помощью WORKDIR, а не перемещаться по файловой системе с помощью команд cd в Docker-файле;
  • WORKDIR автоматически создаёт директорию, если её ещё нет;
  • Можно использовать несколько WORKDIR -инструкций. Если используются относительные пути — каждая инструкция поменяет рабочую директорию.

ARG

Определяет переменную для передачи из командной строки в образ. Для ARG можно указать значение по умолчанию: ARG my_var=my_default_value .

В отличие от ENV -переменных, ARG -переменные не доступны для запущенных контейнеров. Однако вы можете использовать их для установки дефолтных значений для ENV -переменных, когда вы создаёте образ. И затем ENV-переменные сохраняются. Больше про это вы найдёте здесь.

ENTRYPOINT

ENTRYPOINT тоже позволяет вам задавать дефолтные команды и аргументы во время запуска контейнера. Она похожа на CMD , но параметры ENTRYPOINT не переопределяются, если контейнер запущен с параметрами командной строки.

Вместо этого аргументы командной строки, передаваемые docker run myimagename , добавляются к аргументам инструкции ENTRYPOINT . Например, docker run my_image bash добавляет аргумент bash в конец, ко всем другим аргументам ENTRYPOINT .

Docker-файл обязательно должен содержать либо CMD -инструкцию, либо ENTRYPOINT -инструкцию.
В официальной документации есть несколько советов, которые помогут сделать выбор между CMD и ENTRYPOINT для начальной команды:

  • Если вам нужно запускать одну и туже команду несколько раз, выбирайте ENTRYPOINT ;
  • Используйте ENTRYPOINT , когда ваш контейнер выступает в роли исполняющейся программы;
  • При наличии дополнительных дефолтных аргументов, которые могут быть изменены через командную строку, лучше подойдёт CMD .

В примере выше, ENTRYPOINT [«python», «my_script.py», «my_var»] запускает в контейнере Python-скрипт my_script.py с аргументом my_var . Затем переменная my_var может быть использована в my_script argparse. Заметьте, у my_var есть дефолтное значение, ранее установленное в Docker-файле при помощи ARG . Так что, если аргумент не будет задан через командную строку, возьмётся его значение по умолчанию.

Как правило, Docker рекомендует вам использовать исполняемую форму с JSON-синтаксисом ENTRYPOINT [«executable», «param1», «param2»] .

EXPOSE

Инструкция EXPOSE показывает, какой порт пробрасывать из контейнера.

Используйте команду docker run с флагом -p для пробрасывания и сопоставления нескольких портов во время запуска. Флаг в верхнем регистре -P будет пробрасывать все открытые порты.

VOLUME

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

Заключение

В этой статье не были упомянуты такие инструкции, как USER , ONBUILD , STOPSIGNAL , SHELL , и HEALTHCHECK , информацию про них вы сможете найти здесь.

Следите за новыми постами по любимым темам

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

Как устроен Dockerfile

Dockerfile — это текстовый файл, в котором описан рецепт создания образа Docker. Рецепт состоит из инструкций, которые выполняются последовательно. Они содержат информацию об операционной системе, выбранной платформе, фреймворках, библиотеках, инструментах, которые нужно установить.

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

Как понять

Скопировать ссылку «Как понять» Скопировано

Современные веб-приложения работают очень просто только для пользователя, который может смотреть видео, читать тексты, слушать музыку или заказывать еду «в один клик». Под капотом — это сложный набор приложений, взаимодействующих между собой. Если одно из приложений в цепочке сломается, клиент не сможет решить свою задачу. Важная задача веб-разработчика — сделать приложение максимально живучим в самых разных условиях. Решение задачи заключается в том, чтобы воспроизвести одинаковое, «правильное» поведение веб-приложения.

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

Инструкции записываются построчно. На первом месте указывается команда для Docker, которую нужно выполнить, а затем — список аргументов этой команды:

 # CommentINSTRUCTION arguments # Comment INSTRUCTION arguments     

Образ Docker легче всего представить в виде слоёного пирога или бургера: новый слой — новая инструкция. Образы для типичного веб-приложения могут быть собраны примерно так:

Примеры образов Docker для веб-приложений

Каждая новая инструкция — новый слой. В качестве инструкции можно выполнить команду в терминале, скопировать файлы внутрь образа или настроить связь с внешним миром с помощью сетевого окружения и томов. Docker объединяет файловые системы отдельных слоёв в одну во время сборки, используя механизм Union File Systems.

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

После того как слои образа описаны в файле конфигурации, необходимо произвести сборку образа с помощью команды:

 docker build docker build     

Как пишется

Скопировать ссылку «Как пишется» Скопировано

Работу с Dockerfile можно разбить на два этапа: описание инструкций и сборка образа. Набор инструкций — последовательность действий, чтобы собрать образ.

Описание инструкций Dockerfile

Скопировать ссылку «Описание инструкций Dockerfile» Скопировано

FROM . Установка базового образа

Скопировать ссылку «FROM. Установка базового образа» Скопировано

Dockerfile обычно начинается с инструкции FROM . Эта инструкция задаёт базовый образ.

В качестве базового образа может быть использован образ с чистой операционной системой, образ с уже установленной и настроенной платформой или вообще любой другой образ. Вот так можно установить Ubuntu 18.04 как базовый образ:

 FROM ubuntu:18.04 FROM ubuntu:18.04      
 FROM node FROM node      
RUN . Запуск команд терминала

Скопировать ссылку «RUN. Запуск команд терминала» Скопировано

Инструкция RUN позволяет запускать команды терминала при сборке. Это самая используемая инструкция, ей можно создать папку, установить недостающие пакеты или запустить shell скрипт.

Например, установим платформу Node.js поверх образа с чистой Ubuntu:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npm FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm      

При сборке образа теперь будет произведена установка последней версии Node.js.

COPY и ADD . Копирование файлов проекта

Скопировать ссылку «COPY и ADD. Копирование файлов проекта» Скопировано

Инструкции COPY и ADD позволяют перенести файлы с компьютера, который запускает сборку, внутрь образа.

Например, перенесём все содержимое папки, где лежит Dockerfile в папку /app внутри образа:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmCOPY . /app FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm COPY . /app      

Используйте COPY , она только копирует указанную папку во внутреннюю папку образа. Инструкция ADD слишком всемогущая и можно случайно использовать её неверно. Например, она может скачать файл из Интернета перед копированием или разархивировать архив.

ENTRYPOINT и CMD . Запуск приложения

Скопировать ссылку «ENTRYPOINT и CMD. Запуск приложения» Скопировано

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

Инструкция ENTRYPOINT используется для запуска приложения при старте контейнера:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmCOPY . /appENTRYPOINT ["node", "/app/app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm COPY . /app ENTRYPOINT ["node", "/app/app.js"]      

В отличие от инструкции RUN эта инструкция получает полный доступ к инфраструктуре терминала на компьютере пользователя. Вместе с командой запуска контейнера вы можете передавать параметры команде, которая прописана после ENTRYPOINT или пользоваться системой сигналов Linux. Внутрь образа можно положить программу и запускать её внутри контейнера, передавая через параметры текстовые файлы со своего компьютера. Например, можно упаковать в контейнер утилиту для проверки орфографии yaspeller. В примере ниже она используется для проверки орфографии слов на русском и английском языках в файлах с расширением * . md и * . txt :

 FROM nodeRUN npm install yaspeller -gENTRYPOINT ["yaspeller"] FROM node RUN npm install yaspeller -g ENTRYPOINT ["yaspeller"]      

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

 docker build -t yaspeller . docker build -t yaspeller .      

Запускать проверку орфографии в любой папке для файлов с расширением * . md и * . txt можно теперь простой командой:

 docker run --rm yaspeller . docker run --rm yaspeller .      

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

Инструкция CMD делает практически то же самое. Обычно это также команда запуска приложения:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmCOPY . /appCMD ["node", "/app/app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm COPY . /app CMD ["node", "/app/app.js"]      

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

В чем же разница между ENTRYPOINT и CMD ? В ваших намерениях.

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

Есть две формы записи аргументов ENTRYPOINT и CMD : в виде строки и в виде массива строк. Первый вариант (так называемый shell режим) используется редко, поскольку не позволяет гибко настраивать работу образа. Обычно используется второй вариант (так называемый exec режим) — массив строк, который может состоять из команды и её параметров. Среди аргументов инструкции CMD строка с командой может и отсутствовать, если эта инструкция идёт после инструкции ENTRYPOINT . В этом случае строки массива рассматриваются как аргументы по умолчанию для команды, обозначенной в ENTRYPOINT .

ENV . Переменные окружения

Скопировать ссылку «ENV. Переменные окружения» Скопировано

Переменные окружения задаются инструкцией ENV .

Через переменные окружения передают ключи и пароли к сервисам, режим работы, другие секретные и не очень значения. Например, запуск приложения Node.js для конечного пользователя обозначается дополнительной инструкцией:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmCOPY . /appENV NODE_ENV=productionCMD ["node", "/app/app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm COPY . /app ENV NODE_ENV=production CMD ["node", "/app/app.js"]      
WORKDIR . Рабочая папка проекта

Скопировать ссылку «WORKDIR. Рабочая папка проекта» Скопировано

Инструкция WORKDIR задаёт рабочую папку приложения. Все инструкции в Dockerfile будут выполняться относительно неё.

Устанавливать рабочую папку — хороший тон. Она позволяет явно указать место, где будет происходить вся работа. Добавим её в нашу конфигурацию:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmWORKDIR /appCOPY . .ENV NODE_ENV=productionCMD ["node", "app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm WORKDIR /app COPY . . ENV NODE_ENV=production CMD ["node", "app.js"]      
USER . Запуск от имени пользователя

Скопировать ссылку «USER. Запуск от имени пользователя» Скопировано

Если приложение нужно запускать от имени пользователя системы, то используйте инструкцию USER с именем пользователя. Например, если вы хотите запускать приложение от имени пользователя node _ user , то конфигурационный файл будет выглядеть так:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmWORKDIR /appCOPY . .ENV NODE_ENV=productionUSER node_userCMD ["node", "app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm WORKDIR /app COPY . . ENV NODE_ENV=production USER node_user CMD ["node", "app.js"]      
EXPOSE . Проброска порта вовне

Скопировать ссылку «EXPOSE. Проброска порта вовне» Скопировано

Для запуска веб-приложения на компьютере вы используете веб-сервер, запущенный локально. Обычно веб-приложение становится доступным по адресу http : / / localhost : 8080 . Цифры в конце означают порт, открытый для запросов со стороны браузера или других приложений. Чтобы открыть в браузере веб-приложение, запущенное внутри контейнера, нужно «пробросить» запросы от браузера внутрь контейнера, а ответ от веб-приложения из контейнера наружу. Для этого используется перенаправление пакетов в виртуальном сетевом окружении (Docker Network):

Проброска портов образов Docker для веб-приложений

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

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmWORKDIR /appCOPY . .ENV NODE_ENV=productionUSER node_userEXPOSE 8080CMD ["node", "app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm WORKDIR /app COPY . . ENV NODE_ENV=production USER node_user EXPOSE 8080 CMD ["node", "app.js"]      

Запись EXPOSE 8080 означает, что на компьютере, на котором запущен Docker, веб-приложение будет доступно по адресу http : / / localhost : 8080 .

ARG . Аргументы командной строки

Скопировать ссылку «ARG. Аргументы командной строки» Скопировано

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

Передавать данные можно с помощью аргументов команды docker build на этапе сборки образа. Во время сборки эти аргументы можно использовать как переменные, достаточно их определить инструкцией ARG . Можно задать и значения по умолчанию на тот случай, если пользователь не укажет нужные аргументы. Например, передать имя пользователя внутрь контейнера можно следующим образом:

 docker build --build-arg user=node_user . docker build --build-arg user=node_user .      

В Dockerfile надо будет добавить соответствующие инструкции:

 FROM ubuntu:18.04RUN sudo apt update && sudo apt install nodejs && sudo apt install npmWORKDIR /appCOPY . .ENV NODE_ENV=production# Значение по умолчанию 'deploy' (можно не указывать)ARG user=deployUSER $userEXPOSE 8080CMD ["node", "app.js"] FROM ubuntu:18.04 RUN sudo apt update && sudo apt install nodejs && sudo apt install npm WORKDIR /app COPY . . ENV NODE_ENV=production # Значение по умолчанию 'deploy' (можно не указывать) ARG user=deploy USER $user EXPOSE 8080 CMD ["node", "app.js"]      

Важно, что так не следует передавать секретные данные, поскольку их можно будет увидеть в истории Docker:

 docker history docker history      

Для безопасной передачи секретных данных лучше использовать тома Docker.

Многоступенчатая сборка образа

Скопировать ссылку «Многоступенчатая сборка образа» Скопировано

С точки зрения оптимизации сборки, уменьшения размера образа и ускорения приложения, образ можно собирать в несколько этапов. Например, с помощью платформы Node.js произвести сборку веб-приложения на первом этапе, а на втором — запустить готовый бандл с помощью веб-сервера. Операция копирования из первого промежуточного образа во второй целевой пройдёт совершенно незаметно. После сборки образ будет занимать мало дискового пространства, в нем будет все самое необходимое для работы веб-приложения:

 # Сборка проекта на платформе Node.jsFROM node:lts-alpine as build-stageWORKDIR /appCOPY package*.json ./RUN npm installCOPY . .RUN npm run build # Запуск приложения на сервереFROM nginx:stable-alpine as production-stageCOPY --from=build-stage /app/dist /usr/share/nginx/htmlEXPOSE 80CMD ["nginx", "-g", "daemon off;"] # Сборка проекта на платформе Node.js FROM node:lts-alpine as build-stage WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # Запуск приложения на сервере FROM nginx:stable-alpine as production-stage COPY --from=build-stage /app/dist /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]      

Имя промежуточного образа build — stage служит для передачи результата работы первой стадии сборки.

Рекомендации

Скопировать ссылку «Рекомендации» Скопировано

Для того чтобы использовать образы эффективнее, необходимо следовать рекомендациям от команды Docker:

  1. Нужно создавать образы так, чтобы жизненным циклом контейнера можно было удобно управлять. Образ не должен хранить внутреннее состояние. Данные внутрь образа можно передать на этапе сборки с помощью аргументов командной строки, а на этапе работы контейнера можно пользоваться томами Docker.
  2. Необходимо понимать контекст запуска веб-приложения: папка проекта, удалённый ресурс (remote source) или репозиторий.
  3. Надо понимать, что Dockerfile может запускаться вне контекста через стандартный поток ввода.
  4. Используйте файл .dockerignore для того, чтобы в образ попадали только нужные файлы и папки. От всего лишнего лучше избавиться на этапе сборки.
  5. Используйте сборку приложения в несколько стадий. Это позволит существенно уменьшить размер образа.
  6. Не устанавливайте то, что не будете использовать в образе.
  7. Необходимо разделять приложения на обособленные части, которые способны выполняться независимо. Этот процесс носит название декаплинга (Decoupling).
  8. Минимизируйте количество слоёв в образе. Это повышает производительность образа как при сборке, так и при работе контейнера.
  9. Если параметры инструкции записываются в несколько строк (с помощью символа переноса строки \ ) необходимо выстраивать аргументы в алфавитном порядке. Это повышает читаемость файла и упрощает отладку.
  10. Используйте кэш Docker только для тех слоёв, которые будут нужны для сборки других образов. Для этого достаточно добавить параметр — — no — cache = true в команду сборки docker build .

Сборка образа

Скопировать ссылку «Сборка образа» Скопировано

Образ Docker можно собрать тремя способами:

– указав путь к папке PATH ;
– указав путь к репозиторию URL ;
– используя стандартный поток ввода – .

Чаще всего используется первый способ с указанием пути. Самая простая команда для сборки образа:

 docker build . docker build .      

С помощью этой команды собираться образ будет из текущей папки ( . в конце), в которой должен быть Dockerfile .

Использование нескольких Dockerfile

Скопировать ссылку «Использование нескольких Dockerfile» Скопировано

Иногда возникает необходимость использования нескольких вариантов сборок в одном проекте. В этом случае не обойтись без нескольких файлов с инструкциями. При сборке можно указать другое имя для файла конфигурации или относительный путь внутри PATH , нужно использовать флаг -f :

 docker build -f containers/dockerfile-mode-1 . docker build -f containers/dockerfile-mode-1 .      

Точно так же можно указать относительный путь для проекта или репозитория по некоторому URL . Например, Docker может скачать не только репозиторий GitHub, но и произвольный архив с проектом, распаковать его и собрать образ:

 docker build -f ctx/Dockerfile http://server/ctx.tar.gz docker build -f ctx/Dockerfile http://server/ctx.tar.gz     

Поддерживаются архивы форматов bzip2, gzip, xz.

Файлы и папки проекта, исполняемый файл приложения, архив или репозиторий Git составляют контекст образа. Но Docker позволяет собирать образы без контекста из стандартного потока ввода. Собрать такой образ можно командой:

 docker build - < Dockerfile docker build -  Dockerfile     
Исключение файлов из сборки .dockerignore

Скопировать ссылку «Исключение файлов из сборки .dockerignore» Скопировано

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

 # Комментарий*/temp**/*/temp*temp? # Комментарий */temp* */*/temp* temp?     

– * / temp позволяет не включать в образ файлы или папки, имена которых начинаются на temp , и которые находятся в любой папке первого уровня (например, /somedir / temporary . txt или /somedir / temp );
– * / * / temp* — делает то же, но для папок второго уровня;
– temp ? — позволяет не включать в образ файлы и папки из корневой папки образа, имена которых начинаются на temp и состоят из пяти символов, последний из которых может быть любым.

На практике

Скопировать ссылку «На практике» Скопировано

Игорь Коровченко советует

Скопировать ссылку «Игорь Коровченко советует» Скопировано

�� При сборке образа Docker ищет файл с исключениями, исходя из имени основного файла конфигурации. Например, команда docker build — f myapp . Dockerfile . будет в первую очередь искать файл исключений по пути myapp . Dockerfile . dockerignore . Если такого файла не найдётся, то при наличии будет использоваться .dockerignore .

�� Все объекты Docker обязательно имеют имя. Если оно не назначается пользователем, то в качестве имени используется хэш. Чтобы работать с образами было удобнее, лучше выбирать имя. Кроме имени можно также использовать теги. Обычно теги указывают на версию или особенности той или иной сборки образа. Совокупность образов с одним именем, но разными тегами, — это репозиторий образов. Например, можно собрать образ с указанием имени и тега командой:

 docker build -t vieux/apache:2.0 . docker build -t vieux/apache:2.0 .      

Имя образа vieux / apache использует принятое в терминологии Docker соглашение. До слэша / указывается имя пользователя, после — имя образа или репозитория образов. В качестве имени пользователя чаще всего подразумевается имя пользователя в реестре репозиториев. Исторически первым и самым крупным является официальный реестр компании Docker — Docker Hub.

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

�� Важно отслеживать размер образа, и пользоваться образами с умом. Вы можете загрузить к себе образ командой pull . Например, для образа Node.js:

 docker pull node docker pull node      

Уже на этапе клонирования образа вы увидите его размер. После скачивания и установки также можно получить информацию об образе с помощью команды:

 docker image inspect node docker image inspect node      

В терминале будет выведена информация об образе в формате JSON. По ключу » Size» можно увидеть размер образа в байтах. Большое внимание в технологии Docker уделяется скорости сборки и размеру образов. Именно поэтому рекомендуется использовать наименьший образ операционной системы, который обеспечивает весь набор инструментов и служб, необходимый для запускаемого приложения. Практически стандартом стало использование Alpine Linux в качестве базовой операционной системы. В официальном репозитории образов Node.js есть образ и на основе этой операционной системы: node : lts — alpine .

На собеседовании

Скопировать ссылку «На собеседовании» Скопировано

Разница между CMD и ENTRYPOINT в образах Docker – CloudSavvy IT

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

В CMD а также ENTRYPOINT могут быть перезаписаны в каждом изображении индивидуально. Эффективное использование этих рекомендаций упрощает использование вашего контейнера за счет сокращения длины вводимых вами команд.

Что является отправной точкой?

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

Docker устанавливает точку входа по умолчанию /bin/sh -c . Это означает, что при запуске контейнера вы будете находиться в сеансе оболочки. Для многих контейнеров желательно, чтобы по умолчанию запускался другой процесс. Вы хотите, чтобы безголовые сервисы начали работать сразу.

Установка ENTRYPOINT директива в Dockerfile Указывает Docker запускать определенную команду при запуске контейнера. Это будет процесс переднего плана, а не сеанс оболочки по умолчанию.

ENTRYPOINT ["date"]

Это создало контейнер Dockerfile будет ли он date заказывать. В виде date не является длительным процессом на переднем плане, контейнер выйдет сразу после этого.

Точки входа должны быть исполняемыми двоичными файлами или скриптами. Ваш контейнер не запустится, если вы укажете недопустимую точку входа. Если вы используете собственный сценарий, убедитесь, что в нем установлен бит исполняемого файла. Вы можете добавить права на исполнение с помощью chmod +x my-script.sh .

Добавьте команду (CMD)

В CMD инструкция – это что-то вроде неправильного употребления. Он предоставляет стандартные аргументы для команды, определяемой ENTRYPOINT .

ENTRYPOINT ["date"] CMD ["+%A"]

В этом примере контейнер поворачивается date +%A . В +%A аргумент в пользу date отображает текущий день недели (например, Monday ).

CMD предназначен для перезаписи. docker run позволяет указать другую команду для отдельного экземпляра контейнера:

docker run my-image +%B

Стандарт CMD будет перезаписан +%B заставляя контейнер отображать название текущего месяца. Это работает, потому что точка входа изображения остается неизменной. В CMD всегда добавляется к ENTRYPOINT , поэтому последняя команда становится date +%B .

Вы должны использовать ENTRYPOINT чтобы определить основной исполняемый файл вашего контейнера. Использовать CMD для определения аргументов по умолчанию для этого исполняемого файла. Он будет перезаписан, если контейнер будет запущен с другими аргументами.

Трансфер от точки въезда

Вы можете заставить Docker запускать изображение с настраиваемой точкой ввода. Дай —entrypoint флаг docker run :

docker run --entrypoint /bin/sh my-image

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

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

Какой использовать?

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

Как пользователь изображений, вы обычно можете перезаписывать CMD . docker run имеет прозрачную поддержку перезаписи команд. Любые аргументы, указанные после имени изображения, интерпретируются как CMD строка для контейнера.

Режимы точки входа: Shell или Exec

Докер на самом деле поддерживает две разные его формы ENTRYPOINT : режим exec и режим оболочки. Режим Exec характеризуется использованием конструкции массива для указания параметров. В режиме оболочки команда указывается в виде одной строки.

# exec mode ENTRYPOINT ["binary", "--param", "--another-param"] # shell mode ENTRYPOINT binary --param --another-param

При использовании режима оболочки ваш двоичный файл будет работать как подпроцесс /bin/sh -c . Это дает вашей точке доступа доступ к переменным среды, определенным оболочкой.

Однако у режима оболочки есть компромиссы. Вы не можете использовать CMD так что пользователи не могут делать переводы. Аргументы, данные docker run будут проигнорированы; ваш контейнер всегда будет использовать точку входа как есть.

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

ENTRYPOINT exec binary --param --another-param

Преимущества подхода Docker к точке входа

Отделение точки входа от аргументов позволяет скрыть сложность ваших контейнеров. Это особенно полезно при создании служебных контейнеров для инкапсуляции программ CLI.

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

Подумайте, упаковали ли мы вышеперечисленное Dockerfile в виде date:latest :

# default entrypoint (/bin/sh -c) docker run date:latest date +%A # with `date` as the entrypoint docker run date:latest +%A`

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

Резюме

Докера ENTRYPOINT а также CMD инструкции – частый источник путаницы. Их именование маскирует их намеченные цели.

Использовать ENTRYPOINT для установки «команды», которая будет выполняться при запуске новых контейнеров. Вы можете определить стандартные аргументы с помощью CMD . ENTRYPOINT а также CMD объединяются для создания последней командной строки контейнера.

Когда ты docker run , Docker заменяет изображение по умолчанию CMD с аргументами, которые вы предоставляете. Если вам нужно перезаписать точку входа изображения, используйте —entrypoint флаг.

Удобнее виртуальной машины: для чего нужен Docker и как он работает — разбираем основные команды

Виртуализация на уровне операционной системы становится все более популярным решением при развертывании приложений в разных средах. Самый удачный инструмент для этого — Docker.

Експертний курс від robotdreams: Product Manager PRO.
Керуйте продуктом на високому рівні.

В двух статьях на Highload я расскажу об основных возможностях инструмента. Вы узнаете, как установить, настроить и запустить Docker, а также как работать с его ключевыми элементами: Dockerfile, Docker Image и Docker Container.

Docker и принцип контейнеров — почему так удобнее?

Виртуальная машина выступает в качестве эмулятора ПО. Предположим, на компьютере уже есть Windows и нужно дополнительно установить, например, Ubuntu. Создаем на том же компьютере виртуальную машину и уже на нее устанавливаем дополнительную операционную систему. В результате у нас будет два компьютера одновременно. Но для виртуальной машины нужно место на жестком диске, достаточно оперативной памяти и ресурсов процессора.

В противоположность этому появился принцип контейнеров, на котором построены Docker и другие подобные инструменты. Главное отличие — в собственной инфраструктуре и единой для всех сред ОС. Сверху этого основания устанавливается Docker, благодаря которому можно создавать множество контейнеров, апликаций и т.п.

Docker разделяет единое ядро ​​ОС на отдельные контейнеры, под каждый из которых выделяется свой процесс. Это гораздо удобнее, чем виртуальная машина. Вам не нужно искать еще и память, диск, оперативку, ведь отдельный процесс тянет значительно меньше ресурсов.

Ефективний курс від robotdreams: Blockchain-розробник.
Революційні рішення в технологіях.

Когда вы работаете со многими виртуальными машинами, они часто мешают друг другу. Docker же может запускать в ядре любое приложение, которое будет полностью изолировано от других. Кроме того, на фоне конкурентов Docker выигрывает за счет простого синтаксиса. Также его можно запустить на всех популярных платформах: Linux, Windows, Mac.

Как работает Docker

Главный принцип работы с Docker можно описать в виде лозунга из трех слов: Build, Ship, Run. Каждое из них означает определенный этап и элемент системы:

    Build . Здесь имеется в виду создание Dockerfile. Это инструкция, по которой «корабль» строится и отправляется «в плавание». В файле вы описываете образ будущего продукта, принципы его работы и создание.

Так все и работает: строите Dockerfile, из него создаете Docker Image, а на его основе запускаете Docker Container. Далее о каждом элементе системы расскажу по отдельности.

Dockerfile

Dockerfile — это обычный текстовый документ, который мы называем Dockerfile без всяких точек в конце. Этот файл размещается в папке с проектом. В нем вы записываете команды, по которым будет создаваться Image, а затем запускаться Container.

На иллюстрации ниже прописаны следующие команды:

Захоплюючий курс від laba: HR-менеджер.
Розвивайте персонал і підтримуйте бізнес.

  • Берем Python 3.10.2.
  • Создаем директорию и устанавливаем туда Django.
  • Копируем весь проект, открываем порт 8000 и с помощью CMD запускаем runserver нашего Django.

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


Команды CMD и ENTRYPOINT

Может показаться, что они одинаковы по функционалу, но это не совсем так. CMD — команда, которая прописывается в консоль при запуске Dockerfile. Если вернуться к предыдущему примеру, то для запуска сервера нужны python , manage.py , runserver , IP и порт. И все это прописывается именно в CMD, после чего запускается сервер.

ENTRYPOINT также запускает команду, которую мы хотим прописать. Но он выполняет это перед CMD, если мы используем их вместе. Именно поэтому ENTRYPOINT и называется «точкой входа» — это будет первая команда.

Для разбора процесса Running CMD рассмотрим пример.

Берем Debian, копируем проект, запускаем apt-get update и сводим CMD. Если нам нужно сменить эту команду, то при запуске Docker можно прописать docker run image . Тогда выполнится команда, прописанная в Dockerfile по дефолту.

Если мы хотим выполнить другую команду, то пишем docker run my-image и указываем новую команду. Это может быть, например, указание проверить список всех элементов Ubuntu. В результате предварительная команда будет заменена в CMD на ту, которую мы указали:

Если ENTRYPOINT и CMD использовать вместе, первая всегда стартует быстрее. Она может потребоваться, когда к основным командам из CMD нужно запустить еще какую-нибудь команду. К примеру, определенная проверка проекта. В таком случае вы прописываете соответствующую команду ENTRYPOINT, а затем основные параметры в CMD. Этот процесс представлен на иллюстрации ниже:

Експертний курс від robotdreams: Product Manager PRO.
Керуйте продуктом на високому рівні.

Также можно переписать определенные параметры. При указании docker run my-container запишутся параметры и ENTRYPOINT уже в Dockerfile. А если нужно запустить другие CMD-команды, то понадобится docker run my-container cmd :

Чтобы переписать ENTRYPOINT, нужно написать команду docker run —entrypoint и путь entrypoint.sh (это entrypoint, который будет меняться), а также название контейнера. Обратите внимание: вы должны указать, что переписываете именно ENTRYPOINT:

Выбирая между CMD и ENTRYPOINT, я советую именно CMD. По-моему, с ним легче работать. ENTRYPOINT лучше оставить для тех случаев, когда контейнер должен делать что-то уже на старте: проверять процессы или ожидать чего-нибудь. Тогда сочетание этих команд будет оправдано.

Dockerignore

Рассказывая о Dockerfile, следует упомянуть и о Dockerignore. Это аналог .gitignore в Git. Благодаря этому функционалу при копировании проекта в контейнер можно указать определенные файлы, которые не хотите переносить вместе с другими. Это может касаться pycache, логов, environments, docs и так далее. В таком случае прописываете имя файлов в dockerignore и они будут просто игнорироваться при копировании проекта.


Dockerfile создается по принципу Layers — слой за слоем

Сначала вы прописываете основу будущего контейнера. К примеру, при FROM python это будет Python определенной версии, и он становится на базовый уровень всей схемы. В нашем случае далее идет Django, но могут быть и нужны для проекта библиотеки, requirements.txt, зависимости и т.д. Все это формирует средний слой документа. В конце есть верхний слой, который запускает приложение — это CMD-команда:

Этот процесс сравним со строительством дома. В качестве фундамента выступает самая большая часть: Python, Ubuntu, Anaconda и т.д. Далее следуют основные этажи, более компактные по размеру библиотеки и зависимости. И уже на чердаке размещается самая маленькая и самая легкая часть — run проекта контейнера.

Чтобы все слои были понятны, советую тщательно прописывать Layers. Сравните на следующей иллюстрации примеры плохого и хорошего выполнения слоев в Dockerfile. Код в левой и правой частях изображения выполняет по существу одно и то же, но размеры отличаются чуть ли не вдвое. Разобраться сложно, особенно если нет достаточного опыта с Docker.

В другом примере сразу понятно, что к чему. Здесь четко видно установленные Python, Java и virtual environment, а также их активацию. В плохом же примере множество записей об обновлениях, установке и ребилде Python, установке зависимостей, активации virtual environments и многом другом. Это не только труднее читать. Это еще и сложнее делать. Поэтому Dockerfile с множеством слоев будет запускаться дольше.

Docker Image

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

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

Представим другую ситуацию. Вы создаете образ на основе CentOS, который может установить веб-сервис nginx, но вам нужен еще один CentOS уже с другим ПО. В таком случае не нужно делать два разных Dockerfile и Docker Image. Вы просто берете Docker Image CentOS, запускаете его и в отдельных контейнерах устанавливаете необходимое ПО.

Основные команды Docker Image

При работе с Docker Image выделяют несколько наиболее используемых команд:

  • docker image —help показывает основные команды в Image с их кратким описанием.

  • docker image build [OPTIONS] PATH . Билдит сам Image для последующего запуска Container. С помощью этой команды можно назвать свой Image. Для этого добавьте тег -t , а затем укажите желаемое название (в моем примере test ). Вам остается прописать путь к директории (точка в приведенном примере означает текущую директорию). После запуска команды и начнет строиться Image: от создания директории, установки Django, whitenoise, gunicorn до копирования.

В моем случае Docker image сбилден на основе этого Dockerfile:

  • docker image inspect [OPTIONS] IMAGE . Эта команда выдает всю информацию о Image. Это могут быть ID, дата создания, связанные контейнеры и энвайроменты, версия Python, имеющиеся pip и get pip, CMD и ENTRYPOINT, Volumes, директории и т.д. При запуске команды указывайте название интересующего вас Image.

  • docker image ls показывает список всех Image в Docker. На примере изображен перечень из нескольких тестовых Docker Image:

  • docker image rm [OPTIONS] IMAGE предназначена для удаления Image. Ниже на иллюстрации я изобразил типичный сценарий такой процедуры. Сначала с помощью docker image ls получил список всех Image. Далее прописал docker image rm , указав название Image, которое нужно удалить dockertest2 . Еще одна проверка docker image ls показала: этого Image больше нет у Docker.

  • docker image tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG] . С помощью этой команды можно записать Docker Image. Это пригодится при использовании Docker Hub, где у всех собранных Images есть теги. В следующей статье поговорим о нем поподробнее.

Продолжение статьи о возможностях Docker читайте скоро на Highload.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *