10 команд для Docker, без которых вам не обойтись


Оглавление (нажмите, чтобы открыть):

Docker основные команды. Шпаргалка по командам.

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

#1. docker ps — смотрим список запущенных контейнеров

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

  • -q — «тихий» режим, в котором команда выводит только id контейнеров (полезно, когда вам нужно знать только id или же при использовании этой команды в сценариях).
  • -a — показывает все контейнеры, а не только запущенные.

#2. docker pull — загрузка образа

Как правило, образы создаются на основе базового — из Docker Hub, где есть множество уже готовых образов и которые ты можешь использовать, а не тратить время на создание собственного. Для загрузки образа используется команда docker pull.

#3. docker build — собирает образ

Данная команда собирает образ Docker из файла докера (dockerfile) и контекста сборки. Контекст сборки — это набор файлов, расположенных по определенному пути. Для задания имени образа используйте параметр -t, например, «docker build -t my.». Собирает образ из текущего каталога (».«) — последний параметр это имя каталога, в нашем случае точка указывает, что каталог — текущий.

Docker, часть 2 – работа с контейнерами

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

Команды для работы с контейнерами имеют следующий синтаксис:

Рассмотрим некоторые из них более подробно.

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

Запомните основные постулаты контейнеров в docker

  1. Контейнер живет, пока живет процесс, вокруг которого рождается контейнер.
  2. Внутри контейнера этот процесс имеет p >Создание контейнера

-a – сокращение от –attach (прикрепить). Контейнер можно прикрепить к стандартным потокам STDIN, STDOUT или STDERR.
Запуск существующего контейнера (можно обращаться к контейнеру по идентификатору или имени):

Определить идентификатор или имя можно при помощи команды ps. Опция «–l» означает последний запущенный контейнер:

Как уже было рассмотрено в предыдущей части, команда run объединяет создание и запуск контейнера. Для краткости с ней можно не указывать слово container.

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

Запуск в фоновом режиме

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

Присвоение имени

Чтобы не приходилось узнавать и запоминать идентификатор контейнера, при создании можно назначать каждому контейнеру уникальное имя, используя опцию командной строки —name, как в следующем примере:

После этого можно работать с контейнером (выполнять команды start, stop, remove, top, stats), обращаясь к нему по имени, например:

docker start myname – запуск контейнера
docker stats myname – отображение статистики использования ресурсов
docker top myname – отображение запущенных в контейнере процессов

Если вы попытаетесь выполнить например команду top, из выше указанного примера то получите ошибку

Я думаю если вы внимательно читали статью то сможете сами ответить почему возникает эта ошибка.

Запуск интерактивного сеанса

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

Структура этой команды следующая:

-i задает запуск интерактивного сеанса.
-t выделяет TTY и подключает стандартные потоки ввода и вывода.
ubuntu – образ, используемый для создания контейнера.
bash (или /bin/bash) – запускаемая в контейнере Ubuntu команда.

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

Если вы интерактивно подключены к контейнеру, и вам требуется выйти из сеанса, не прерывая его, при помощи комбинаций клавиш Ctrl+p и Ctrl+q можно выйти из консоли и вернуться к терминалу вашего хоста.

Если вы хотите запустить контейнер в режиме демона используйте опцию ‘-d’.

Для повторного подключения к запущенному контейнеру требуется знать его идентификатор или имя. Для этого запустите команду docker ps, а затем выполните docker attach, указав идентификатор или имя.

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

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

Опция ‘-a’ указывает команде выводить все контейнеры, а не только запущенные, опция -s выводит размер каждого контейнера:

Команда inspect выдает множество полезной информации о контейнере:

Для вывода логов контейнера выполните команду logs:

Остановка контейнера

Обычно контейнер завершается автоматически после завершения процесса, но иногда требуется собственноручно завершить запущенный контейнер. Команда stop осуществляет «мягкое» завершение контейнера, по умолчанию предоставляя 10 секунд для завершения всех процессов:

Для немедленного завершения выполните команду kill. В большинстве ситуаций stop предпочтительнее.

Немедленное завершение всех запущенных контейнеров:

Удаление контейнера

удаление заданного контейнера.

удалить все не запущенные контейнеры.

Изменения в контейнере

Как уже отмечалось в начале, после остановки контейнера все изменения сделанные в нем удаляются. Это не совсем удобно, что же делать если нам нужно сохранить изменения? Для этого мы можем создать собственный контейнер взяв за основу уже готовый. Запустив интерактивный сеанс, мы можем работать в контейнере как на обычной Linux-машине и вносить любые необходимые изменения, например, устанавливать нужные пакеты. Допустим, нам требуется контейнер Ubuntu с сервером Nginx. Установим необходимые для этого программы:


Теперь нужно сохранить эти изменения, чтобы в следующий раз у нас был контейнер, где уже есть все необходимое. Для этого сначала нужно выйти из контейнера, выполнив команду exit, а затем подтвердить сделанные изменения командой commit:

Где идентификатор – это тот идентификатор, который использовался для первоначального запуска, а new-template – назначенное нами имя нового образа. Теперь он будет виден, если выполнить команду docker images:

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

где имя_пользователя – имя, соответствующее вашему аккаунту.

Заключение

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

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

Статья Docker: 10 рекомендаций по безопасности

clevergod

Сегодня мы представим перевод статьи компании Snyk Ltd. авторами которой являются 2 специалиста:

  • @liran_tal — Node.js Security WG & Developer Advocate из компании Snyk
  • @omerlh — DevSecOps Engineer из компании Soluto

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

1. Используйте минимальные образы

Зачастую Вы начинаете проекты с общего образа контейнера Docker, например, писать Dockerfile с FROM node , как обычно. Однако при указании образа ноды вы должны учитывать, что полностью установленный дистрибутив Debian является базовым образом, который используется для его сборки. Если вашему проекту не требуются какие-либо общие системные библиотеки или системные утилиты, лучше избегать использования полнофункциональной операционной системы в качестве базового образа.

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

2. Пользователь с наименьшими привилегиями

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

Чтобы минимизировать воздействие, включите создание выделенного пользователя и выделенной группы в образе Docker для приложения; используйте директиву USER в Dockerfile, чтобы убедиться, что контейнер запускает приложение с минимально возможным доступом. И если изначально в контейнере не предусмотрен выделенный пользователь, рекомендуется его добавить в контейнер перед использованием. Например (вместо username и usergroup укажите свои значения):

  • Создали системного юзера, без пароля, шелла и хоума
  • Создали группу и добавили туда созданного пользователя
  • Дали права на приложение в контейнере

Если Вы фанат Node.js и образов alpine , то всё уже сделано за Вас, пользователь node уже добавлен. Пример:

3. Всегда подписывай и проверяй образы для избежания MITM атак

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

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

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

А теперь попробуйте подтянуть образ который Вы уверены не подписан — запрос будет отклонён и образ не будет загружен.

Как подписывать образы?

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

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

. Notary проверяет подпись образа и блокирует его запуск, если подпись образа недействительна.

Когда Docker Content Trust включен, как мы показали выше, при сборке образа, Docker его подписывает. Когда образ подписывается впервые, Docker генерирует и сохраняет закрытый ключ в

/docker/trust для вашего пользователя. Этот закрытый ключ затем используется для подписи любых дополнительных образов по мере их создания.

Подробные инструкции по настройке подписанных образов см.

4. Ищи, исправляй и следи за уязвимостями в open source ПО.

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

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

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

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

Просканировать образ Docker на уязвимости можно с помощью этих команд:

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

Сделать это можно командой:

На основе сканирования, выполненного пользователями Snyk, было обнаружено, что 44% сканирования образов Docker имели известные уязвимости и для которых были доступны более новые и более безопасные базовые версии образов. Этот совет по исправлению положения уникален для Snyk, в соответствии с которым разработчики могут предпринимать действия и обновлять свои образы Docker.

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

5. Не оставляйте важную информацию в образах Docker.

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

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

FROM: ubuntu as intermediate


Используйте команду secret

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

Остерегайтесь рекурсивной копии
Вы также должны быть внимательны при копировании файлов в создаваемый образ. Например, команда COPY . . рекурсивно копирует всю папку контекста сборки в образ Docker, что может также привести к копированию конфиденциальных файлов

Если в вашей папке есть конфиденциальные файлы (private.key; settings.json и т.д.), удалите их или используйте .dockerignore, чтобы игнорировать их.

6. Используйте фиксированные теги для неизменности

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

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

  • Предпочитайте наиболее конкретный доступный тег. Если образ имеет несколько тегов, таких как: 8 и: 8.0.1 или даже: 8.0.1-alpine, предпочтите последнее, так как он является наиболее конкретной ссылкой на образ. Избегайте использования самых общих тегов, например, последних. Имейте в виду, что при закреплении определенного тега он может быть в конечном итоге удален.
  • Чтобы устранить проблему, связанную с тем, что определенный тег образа становится недоступным и становится ограничителем показа для групп, которые полагаются на него, рассмотрите возможность запуска локального зеркала этого образа в реестре или учетной записи, которая находится под вашим собственным контролем. Важно принять во внимание затраты на обслуживание, необходимые для этого подхода, потому что это означает, что вам нужно поддерживать реестр. Хорошей практикой является тиражирование образа, которое вы хотите использовать в вашем реестре, чтобы убедиться, что образ, который вы используете, не изменяется.
  • Будьте очень конкретны! Вместо того, чтобы тянуть метку, потяните образ, используя конкретную ссылку SHA256 на образ Docker, который гарантирует, что вы получите один и тот же образ для каждого запроса. Однако обратите внимание, что использование ссылки SHA256 может быть рискованным, если изменится образ, тот же хеш больше не сработает.

7. Используйте COPY вместо ADD

Docker предоставляет две команды для копирования файлов с хоста в образ Docker при его создании: COPY и ADD.

Инструкции похожи по своей природе, но отличаются по своей функциональности:

  • COPY — рекурсивно копирует локальные файлы с указанием явных исходных и целевых файлов или каталогов. С COPY вы должны объявить места.
  • ADD — рекурсивно копирует локальные файлы, неявно создает каталог назначения, когда он не существует, и принимает архивы как локальные или удаленные URL-адреса в качестве источника, который он расширяет или загружает соответственно в каталог назначения.

Эти различия между ADD и COPY важны. Помните об них, чтобы избежать потенциальных проблем безопасности:

Когда удаленные URL-адреса используются для загрузки данных непосредственно в исходное местоположение, они могут привести к атакам типа «человек посередине», которые изменяют содержимое загружаемого файла. Кроме того, происхождение и подлинность удаленных URL-адресов должны быть дополнительно проверены. При использовании COPY источник для файлов, которые будут загружены с удаленных URL-адресов, должен быть объявлен через безопасное соединение TLS, и их происхождение также должно быть проверено.

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

Когда используются локальные архивы, ADD автоматически извлекает их в каталог назначения. Хотя это может быть приемлемо, это добавляет риск уязвимостей Zip-бомб и уязвимостей

, которые затем могут запускаться автоматически.

8. Используйте метки данных

Метки образов предоставляют метаданные для образа, которые вы создаете. Это помогает пользователям понять, как легче использовать образ. Самым распространенной меткой является «maintainer», которая указывает адрес электронной почты и имя лица, поддерживающего этот образ. Добавьте метаданные с помощью следующей команды LABEL:

В дополнение к вышеуказанной метке добавьте любые метаданные, которые важны для вас. Эти метаданные могут содержать: хеш коммита, ссылку на соответствующую сборку, статус качества (все ли тесты прошли?), исходный код, ссылку на местоположение файла SECURITY.TXT и т. д.

Хорошей практикой является принятие файла SECURITY.TXT (RFC5785), который указывает на вашу политику ответственного раскрытия для вашей схемы меток Docker при добавлении меток, например:

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

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

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

Голанг является отличным примером. Чтобы построить приложение Golang, вам нужен компилятор Go. Компилятор создает исполняемый файл, который работает в любой операционной системе, без зависимостей, включая чистые образы.

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

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

10. Используйте линтер

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

Одним из таких линтеров является

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

Пример статического анализа кода безопасности в dockerfile lint от hadolint

Hadolint становится еще более мощным, когда используется в интегрированной среде разработки (IDE). Например, при использовании hadolint в качестве расширения VSCode при вводе появляются ошибки лининга. Это помогает в написании лучших Dockerfiles быстрее.

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

Как и для чего использовать Docker

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

Содержание

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

(В статье намеренно опущены многие детали, чтобы не грузить информацией, которая не нужна для ознакомления).

Установка

Докер поставляется в виде Community Edition (CE) и Enterprise Edition (EE). Нас интересует CE. На главной странице этой версии доступны ссылки для скачивания под все популярные платформы. Выберите вашу и установите Докер.

В работе Докера есть одна деталь, которую важно знать при установке на Mac и Linux. По умолчанию Докер работает через unix сокет. В целях безопасности сокет закрыт для пользователей, не входящих в группу docker. И хотя установщик добавляет текущего пользователя в эту группу автоматически, Докер сразу не заработает. Дело в том, что если пользователь меняет группу сам себе, то ничего не изменится до тех пор, пока пользователь не перелогинится. Такова особенность работы ядра. Для проверки того, в какие группы входит ваш пользователь, можно набрать команду id .

Проверить успешность установки можно командой docker info :

Она выдает довольно много информации о конфигурации самого Докера и статистику работы.

Запуск

На этом этапе команды на выполнение даются “как есть” без объяснения деталей. Подробнее о том, как их формировать и что в них входит разбирается позже.

Начнем с самого простого варианта:

При первом вызове данная команда начнет скачивать образ (image) nginx, поэтому придется немного подождать. После того, как образ скачается, запустится bash, и вы окажетесь внутри контейнера (container).

Побродите по файловой системе, посмотрите папку /etc/nginx . Как видите, её содержимое не совпадает с тем, что находится у вас на компьютере. Эта файловая система появилась из образа nginx. Все, что вы сделаете здесь внутри, никак не затронет вашу основную файловую систему. Вернуться в родные скрепы можно командой exit .

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

Команда выполняется практически мгновенно, так как образ уже загружен. В отличие от предыдущего старта, где запускается баш и начинается интерактивная сессия внутри контейнера, запуск команды cat /etc/nginx/nginx.conf для образа nginx выведет на экран содержимое указанного файла (взяв его из файловой системы запущенного контейнера) и вернет управление в то место, где вы были. Вы не окажетесь внутри контейнера.

Последний вариант запуска будет таким:


Данная команда не возвращает управление, потому что стартует nginx. Откройте браузер и наберите localhost:8080 . Вы увидите как загрузилась страница Welcome to nginx!. Если в этот момент снова посмотреть в консоль, где был запущен контейнер, то можно увидеть, что туда выводится лог запросов к localhost:8080 . Остановить nginx можно командой Ctrl + C .

Несмотря на то, что все запуски выполнялись по-разному и приводили к разным результатам, общая схема их работы — одна. Докер при необходимости автоматически скачивает образ (первый аргумент после docker run ) и на основе него стартует контейнер с указанной командой.

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

Контейнер — запущенный процесс операционной системы в изолированном окружении с подключенной файловой системой из образа.

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

Попробуйте выполнить команду docker run -it ubuntu bash и наберите ps auxf внутри запущенного контейнера. Вывод будет таким:

Как видно, процесса всего два, и у Bash P >/home командой ls /home и убедиться, что она пустая. Также обратите внимание, что внутри контейнера по умолчанию используется пользователь root .

Зачем все это?

Докер — универсальный способ доставки приложений на машины (локальный компьютер или удаленные сервера) и их запуск в изолированном окружении.

Вспомните, когда вам приходилось собирать программы из исходников. Этот процесс включает в себя следующие шаги:

  • Установить все необходимые зависимости под вашу операционную систему (их список еще надо найти).
  • Скачать архив, распаковать.
  • Запустить конфигурирование make configure .
  • Запустить компиляцию make compile .
  • Установить make install .

Как видите, процесс нетривиальный и далеко не всегда быстрый. Иногда даже невыполнимый из-за непонятных ошибок. И это не говоря про загрязнение операционной системы.

Докер позволяет упростить эту процедуру до запуска одной команды причем с почти 100% гарантией успеха. Посмотрите на вымышленный пример, в котором происходит установка программы Tunnel на локальный компьютер в папку /usr/local/bin используя образ tunnel:

Запуск этой команды приводит к тому, что в основной системе в папке /usr/local/bin оказывается исполняемый файл программы, находящейся внутри образа tunnel. Команда docker run запускает контейнер из образа tunnel, внутри происходит компиляция программы и, в конечном итоге, она оказывается в папке /usr/local/bin основной файловой системы. Теперь можно стартовать программу, просто набрав tunnel в терминале.

А что если программа, которую мы устанавливаем таким способом, имеет зависимости? Весь фокус в том, что образ, из которого был запущен контейнер, полностью укомплектован. Внутри него установлены все необходимые зависимости и его запуск практически гарантирует 100% работоспособность независимо от состояния основной ОС.

Часто даже не обязательно копировать программу из контейнера на вашу основную систему. Достаточно запускать сам контейнер когда в этом возникнет необходимость. Предположим, что мы решили разработать статический сайт на основе Jekyll. Jekyll — популярный генератор статических сайтов, написанный на Ruby. Например, гайд который вы читаете прямо сейчас, находится на статическом сайте, сгенерированном с его помощью. И при его генерации использовался Докер (об этом можно прочитать в гайде: как делать блог на Jekyll).

Старый способ использования Jekyll требовал установки на вашу основную систему как минимум Ruby и самого Jekyll в виде гема (gem — название пакетов в Ruby). Причем, как и всегда в подобных вещах, Jekyll работает только с определенными версиями Ruby, что вносит свои проблемы при настройке.

С Докером запуск Jekyll сводится к одной команде, выполняемой в папке с блогом (подробнее можно посмотреть в репозитории наших гайдов):

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

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

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

Но в какой-то момент все изменилось. Картинка стоит тысячи слов:

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

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

Больше всего Docker повлиял именно на серверную инфраструктуру. До эры Докера управление серверами было очень болезненным мероприятием даже не смотря на наличие программ по управлению конфигурацией (chef, puppet, ansible). Основная причина всех проблем — изменяемое состояние. Программы ставятся, обновляются, удаляются. Происходит это в разное время на разных серверах и немного по разному. Например, обновить версию таких языков, как PHP, Ruby или Python могло стать целым приключением с потерей работоспособности. Проще поставить рядом новый сервер и переключиться на него. Идейно Докер позволяет сделать именно такое переключение. Забыть про старое и поставить новое, ведь каждый запущенный контейнер живет в своем окружении. Причем, откат в такой системе тривиален: все что нужно — остановить новый контейнер и поднять старый, на базе предыдущего образа.

Приложение в контейнере

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

  1. Все приложение — один контейнер, внутри которого поднимается дерево процессов: приложение, веб сервер, база данных и все в этом духе.
  2. Каждый запущенный контейнер — атомарный сервис. Другими словами каждый контейнер представляет из себя ровно одну программу, будь-то веб-сервер или приложение.

На практике все преимущества Docker достигаются только со вторым подходом. Во-первых, сервисы, как правило, разнесены по разным машинам и нередко перемещаются по ним (например, в случае выхода из строя сервера), во-вторых, обновление одного сервиса, не должно приводить к остановке остальных.

Первый подход крайне редко, но бывает нужен. Например, Хекслет работает в двух режимах. Сам сайт с его сервисами использует вторую модель, когда каждый сервис отдельно, но вот практика, выполняемая в браузере, стартует по принципу один пользователь — один контейнер. Внутри контейнера может оказаться все, что угодно в зависимости от практики. Как минимум, там всегда стартует сама среда Хекслет IDE, а она в свою очередь порождает терминалы (процессы). В курсе по базам данных в этом же контейнере стартует и база данных, в курсе, связанном с вебом, стартует веб-сервер. Такой подход позволяет создать иллюзию работы на настоящей машине и резко снижает сложность в поддержке упражнений. Повторюсь, что такой вариант использования очень специфичен и вам вряд ли понадобится.

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

Работа с образами

Docker — больше, чем просто программа. Это целая экосистема со множеством проектов и сервисов. Главный сервис, с которым вам придется иметь дело — Registry. Хранилище образов.

Концептуально оно работает так же, как и репозиторий пакетов любого пакетного менеджера. Посмотреть его содержимое можно на сайте https://store.docker.com/ (либо по старому адресу https://hub.docker.com/), кликнув по ссылке Containers.

Когда мы выполняем команду run docker run , то Docker проверяет наличие указанного образа на локальной машине и скачивает его по необходимости. Список образов, уже скачанных на компьютер, можно посмотреть командой docker images :

Разберемся с тем, как формируется имя образа, и что оно в себя включает.

Вторая колонка в выводе выше называется TAG. Когда мы выполняли команду docker run nginx , то на самом деле выполнялась команда docker run nginx:latest . То есть мы не просто скачиваем образ nginx, а скачиваем его конкретную версию. Latest — тег по умолчанию. Несложно догадаться что он означает последнюю версию образа.

Важно понимать что это всего лишь соглашение, а не правило. Конкретный образ вообще может не иметь тега latest, либо иметь, но он не будет содержать последние изменения, просто потому что никто их не публикует. Впрочем, популярные образы следуют соглашению. Как понятно из контекста, теги в Докере изменяемы, другими словами, вам никто не гарантирует, что скачав образ с одним и тем же тегом на разных компьютерах в разное время вы получите одно и тоже. Такой подход может показаться странным и ненадежным, ведь нет гарантий, но на практике есть определенные соглашения, которым следуют все популярные образы. Тег latest действительно всегда содержит последнюю версию и постоянно обновляется, но кроме этого тега активно используется семантическое версионирование. Рассмотрим https://store.docker.com/images/nginx

Теги, в которых присутствует полная семантическая версия (x.x.x) всегда неизменяемы, даже если в них встречается что то еще, например 1.12.2-alphine. Такую версию смело нужно брать для продакшен-окружения. Теги, подобные такому 1.12, обновляются при изменении path версии. То есть внутри образа может оказаться и версия 1.12.2 и в будущем 1.12.8. Точно такая же схема и с версиями, в которых указана только мажорная версия, например 1. Только в данном случае обновление идет не только по патчу, но и по минорной версии.

Как вы помните, команда docker run скачивает образ если его нет локально, но эта проверка не связана с обновлением содержимого. Другими словами, если nginx:latest обновился, то docker run его не будет скачивать, он использует тот latest, который прямо сейчас уже загружен. Для гарантированного обновления образа существует другая команда: docker pull . Вот она всегда проверяет обновился ли образ для определенного тега.

Кроме тегов имя образа может содержать префикс: например, etsy/chef . Этот префикс является именем аккаунта на сайте, через который создаются образы, попадающие в Registry. Большинство образов как раз такие, с префиксом. И есть небольшой набор, буквально сотня образов, которые не имеют префикса. Их особенность в том, что эти образы поддерживает сам Docker. Поэтому если вы видите, что в имени образа нет префикса, значит это официальный образ. Список таких образов можно увидеть здесь: https://github.com/docker-library/official-images/tree/master/library

Удаляются образы командой docker rmi .

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

Управление контейнерами

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

Проследите путь команды docker run . Несмотря на то, что команда одна, с точки зрения работы Докера выполняется два действия: создание контейнера и запуск. Существуют и более сложные варианты исполнения, но в этом разделе мы рассмотрим только базовые команды.

Запустим nginx так, чтобы он работал в фоне. Для этого после слова run добавляется флаг -d :

После её выполнения Докер выводит идентификатор контейнера и возвращает управление. Убедитесь в том, что nginx работает, открыв в браузере ссылку localhost:8080 . В отличие от предыдущего запуска, наш nginx работает в фоне, а значит не видно его вывода (логов). Посмотреть его можно командой docker logs , которой нужно передать идентификатор контейнера:


Вы так же можете подсоединиться к выводу лога в стиле tail -f . Для этого запустите docker logs -f 431a3b3fc24bf8440efe2bca5bbb837944d5ae5c3b23b9b33a5575cb3566444e . Теперь лог будет обновляться каждый раз, когда вы обновляете страницу в браузере. Выйти из этого режима можно набрав Ctrl + C , при этом сам контейнер остановлен не будет.

Теперь выведем информацию о запущенных контейнерах командой docker ps :

  • CONTAINER_ID — идентификатор контейнера. Так же, как и в git, используется сокращенная запись хеша.
  • IMAGE — имя образа, из которого был поднят контейнер. Если не указан тег, то подразумевается latest.
  • COMMAND — команда, которая выполнилась на самом деле при старте контейнера.
  • CREATED — время создания контейнера
  • STATUS — текущее состояние.
  • PORTS — проброс портов.
  • NAMES — алиас. Докер позволяет кроме идентификатора иметь имя. Так гораздо проще обращаться с контейнером. Если при создании контейнера имя не указано, то Докер самостоятельно его придумывает. В выводе выше как раз такое имя у nginx.

(Команда docker stats выводит информацию о том, сколько ресурсов потребляют запущенные контейнеры).

Теперь попробуем остановить контейнер. Выполним команду:

Если попробовать набрать docker ps , то там этого контейнера больше нет. Он удален.

Команда docker ps выводит только запущенные контейнеры. Но кроме них могут быть и остановленные. Причем, остановка может происходить как и по успешному завершению так и в случае ошибок. Попробуйте набрать docker run ubuntu ls , а затем docker run ubuntu bash -c «unknown» . Эти команды не запускают долго живущего процесса, они завершаются сразу по выполнению, причем вторая с ошибкой, так как такой команды не существует.

Теперь выведем все контейнеры командой docker ps -a . Первыми тремя строчками вывода окажутся:

Здесь как раз два последних наших запуска. Если посмотреть на колонку STATUS, то видно, что оба контейнера находятся в состоянии Exited. То есть запущенная команда внутри них выполнилась, и они остановились. Разница лишь в том, что один завершился успешно (0), а второй с ошибкой (127). После остановки контейнер можно даже перезапустить:

Только в этот раз вы не увидите вывод. Чтобы его посмотреть воспользуйтесь командой docker logs determined_tereshkova .

Взаимодействие с другими частями системы

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

Interactive mode

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

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

Дело в том, что bash запускает интерактивную сессию внутри контейнера. Для взаимодействия с ней нужно оставить открытым поток STDIN и запустить TTY (псевдо-терминал). Поэтому для запуска интерактивных сессий нужно не забыть добавить опции -i и -t . Как правило их добавляют сразу вместе как -it . Поэтому правильный способ запуска баша выглядит так: docker run -it ubuntu bash .

Ports

Если запустить nginx такой командой docker run nginx , то nginx не сможет принять ни один запрос, несмотря на то, что внутри контейнера он слушает 80 порт (напомню, что каждый контейнер по умолчанию живет в своей собственной сети). Но если запустить его так docker run -p 8080:80 nginx , то nginx начнет отвечать на порту 8080.

Флаг -p позволяет описывать как и какой порт выставить наружу. Формат записи 8080:80 расшифровывается так: пробросить порт 8080 снаружи контейнера в контейнер на порт 80. Причем, по умолчанию, порт 8080 слушается на 0.0.0.0 , то есть на всех доступных интерфейсах. Поэтому запущенный таким образом контейнер доступен не только через localhost:8080 , но и снаружи машины (если доступ не запрещен как нибудь еще). Если нужно выполнить проброс только на loopback, то команда меняется на такую: docker run -p 127.0.0.1:8080:80 nginx .

Docker позволяет пробрасывать столько портов, сколько нужно. Например, в случае nginx часто требуется использовать и 80 порт и 443 для HTTPS. Сделать это можно так: docker run -p 80:80 -p 443:443 nginx Про остальные способы пробрасывать порты можно прочитать в официальной документации.

Volumes

Другая частая задача связана с доступом к основной файловой системе. Например, при старте nginx-контейнера ему можно указать конфигурацию, лежащую на основной фс. Докер прокинет её во внутреннюю фс, и nginx сможет её читать и использовать.

Проброс осуществляется с помощью опции -v . Вот как можно запустить баш сессию из образа Ubuntu, подключив туда историю команд с основной файловой системы: docker run -it -v

/.bash_history:/root/.bash_history ubuntu bash . Если в открытом баш понажимать стрелку вверх, то отобразится история. Пробрасывать можно как файлы так и папки. Любые изменения производимые внутри volume меняются как внутри контейнера, так и снаружи, причем по умолчанию доступны любые операции. Как и в случае портов, количество пробрасываемых файлов и директорий может быть любым.

При работе с Volumes есть несколько важных правил, которые надо знать:

  • Путь до файла во внешней системе должен быть абсолютным.
  • Если внутренний путь (то, что идет после : ) не существует, то Докер создаст все необходимые папки и файл. Если существует, то заменит старое тем, что было проброшено.

Кроме пробрасывания части фс снаружи, Докер предоставляет еще несколько вариантов создания и использования Volumes. Подробнее — в официальной документации.

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

Конфигурирование приложения внутри контейнера, как правило, осуществляется с помощью переменных окружения в соответствии с 12factors. Существует два способа их установки:

  • Флаг -e . Используется он так: docker run -it -e «HOME=/tmp» ubuntu bash
  • Специальный файл, содержащий определения переменных окружения, который пробрасывается внутрь контейнера опцией —env-file .

Подготовка собственного образа

Создание и публикация собственного образа не сложнее его использования. Весь процесс делится на три шага:

  • Создается файл Dockerfile в корне проекта. Внутри описывается процесс создания образа.
  • Выполняется сборка образа командой docker build
  • Выполняется публикация образа в Registry командой docker push

Рассмотрим процесс создания образа на примере упаковки линтера eslint (не забудьте повторить его самостоятельно). В результате сборки, мы получим образ, который можно использовать так:

То есть достаточно запустить контейнер из этого образа, подключив папку с файлами js для проверки как Volume во внутреннюю папку /app .

1. Конечная структура папки, на основе файлов которой соберется образ, выглядит так:

Файл eslintrc.yml содержит конфигурацию линтера. Он автоматически прочитывается если лежит в домашней директории под именем .eslintrc.yml . То есть этот файл должен попасть под таким именем в папку /root внутрь образа.

2. Создание Dockerfile

Dockerfile имеет довольно простой формат. На каждой строчке указывается инструкция (директива) и её описание.

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

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

Основная инструкция в Dockerfile. Фактически здесь указывается sh команда, которая будет выполнена в рамках окружения, указанного во FROM при сборке образа. Так как по умолчанию все выполняется от пользователя root, то использовать sudo не нужно (и скорее всего его нет в базовом образе). К тому же учтите, что сборка образа — процесс не интерактивный. В тех ситуациях, когда вы используете команду, которая может запросить что-то от пользователя, необходимо подавлять этот вывод. Например, в случае пакетных менеджеров делают так: apt-get install -y curl . Флаг -y как раз говорит о том что нужно производиться установку без дополнительных вопросов.

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

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

WORKDIR

Инструкция, устанавливающая рабочую директорию. Все последующие инструкции будут считать, что они выполняются именно внутри указанной папки. По сути она действует как команда cd . Кроме того, когда мы запускаем контейнер, то он также стартует из папки WORKDIR. Например, запустив bash вы окажетесь внутри неё.


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

3. Сборка

Для сборки образа используется команда docker build . С помощью флага -t передается имя образа, включая имя аккаунта и тег. Как обычно, если не указывать тег, то подставляется latest.

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

4. Публикация

Для успешного выполнения публикации нужно соблюсти два условия:

  • Зарегистрироваться на Docker Cloud и создать там репозиторий для образа.
  • Залогиниться в cli интерфейсе используя команду docker login .

Docker Compose

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

Docker Compose позволяет управлять набором контейнеров, каждый из которых представляет из себя один сервис проекта. Управление включает в себя сборку, запуск с учетом зависимостей и конфигурацию. Конфигурация Docker Compose описывается в файле docker-compose.yml , лежащем в корне проекта, и выглядит примерно так:

В бою

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

  1. Скачать новый образ.
  2. Остановить старый контейнер.
  3. Поднять новый контейнер.

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

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

Докер под капотом

Изоляция, которую предоставляет Докер, достигается благодаря возможностям ядра Cgroups и Namespaces. Они позволяют запускать процесс операционной системы не только в изолированном окружении, но и с ограничением по использованию физических ресурсов, таких как памяти или процессора.

Четыре класса задач, для которых Docker подходит идеально

Содержание статьи

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

Есть четыре класса задач, для которых Docker подходит если не идеально, то лучше любого другого инструмента. Это:

  • Упрощение процесса разворачивания/сопровождения проектов. Docker позволяет разбить проект на небольшие независимые, удобные в сопровождении компоненты, работать с которыми гораздо комфортнее, чем с реальными сущностями вроде Apache 2.4.12, установленного на хосте 1.2.3.4, работающем под управлением CentOS 6.
  • Continous development и zero-downtime deployment. Каждый образ Docker — вещь в себе, включающая сервис (или набор сервисов), окружение для его запуска и необходимые настройки. Поэтому контейнеры можно передавать между членами команды в ходе цикла «разработка -> тестирование -> внедрение» и быстро внедрять изменения, просто переключая настройки на новые контейнеры.
  • IaaS/PaaS. Благодаря легковесности контейнеров Docker можно использовать в качестве движка виртуализации в IaaS, а благодаря простоте миграции Docker становится идеальным решением для запуска сервисов в PaaS.
  • Запуск небезопасного кода. Docker позволяет запустить любой, в том числе графический софт внутри изолированного контейнера с помощью одной простой команды. Поэтому он идеально подходит для запуска разного рода недоверенного или просто небезопасного кода.

В следующих разделах мы рассмотрим все четыре применения Docker с простыми и не очень примерами.

Кейс номер 1. Поднимаем LAMP

В качестве примера разбиения приложения на составные компоненты рассмотрим пример LAMP + WordPress. Это абсолютно стандартная настройка, за тем исключением, что ее компоненты будут работать в обособленных контейнерах. А это, в свою очередь, позволит нам: а) обезопасить хост-систему и другие контейнеры в случае проникновения в один из них; б) получить возможность легко масштабировать нашу инсталляцию, разнеся ее компоненты по разным машинам; в) выполнить миграцию с помощью пары простых команд; г) упростить обкатку новых версий nginx, PHP или MySQL.

Итак, для начала нам понадобится базовый образ для наших будущих контейнеров. Пусть это будет CentOS. Скачиваем образ, запускаем контейнер и обновляем систему:

Теперь делаем commit, чтобы создать новый образ. Назовем его centos:updated:

На основе нашего обновленного образа создадим два новых. Один — для запуска Apache и PHP (к сожалению, мы не сможем разнести их по разным контейнерам по сугубо техническим причинам), второй — для MySQL. Начнем с Apache:

Добавляем IP-адрес и имя хоста в /etc/hosts и редактируем конфиг Apache, указав имя хоста и web root:

Пробуем открыть адрес 172.17.0.20 в браузере в хост-системе, должна появиться стандартная страничка phpinfo(). Если это так — все ОK, можно закоммитить изменения в новый контейнер:

Теперь настроим контейнер с MySQL с выносом базы данных на хост-систему (мы же не хотим потерять ее после остановки контейнера):

Создаем базу данных и юзера, как показано на скриншоте «Создаем базу данных», после чего — новый контейнер:

Создаем базу данных

Хакер #196. Все о Docker

Смотрим, что у нас получилось:

Теперь нам необходимо установить WordPress, и здесь у нас есть два пути: мы можем вновь запустить контейнер example:www и распаковать архив WordPress в каталог /var/www/html/ внутри него либо можем распаковать его в какой-нибудь каталог на хост-системе и просто смонтировать его внутрь контейнера при запуске. Первый способ позволяет с удобством таскать контейнеры между машинами, второй более удобен при разработке веб-приложений. Для примера пойдем по второму пути. Итак, скачиваем и распаковываем WordPress в каталог /root/html/ на хост-системе:

Все. Теперь осталось только запустить контейнеры с правильными опциями:

Открываем в браузере адрес контейнера www и видим инсталлятор WordPress.

Два работающих контейнера: Apache/PHP + MySQL Запущенный WordPress

Кейс номер 2. Отлаживем, тестируем, внедряем

В предыдущем примере мы для простоты настройки вынесли WordPress на хост-систему, хотя в крупных продакшен-проектах части веб-приложения (или все приложение целиком) следует запускать в отдельных контейнерах. Это даст возможность просто и быстро выполнять миграцию, обкатывать изменения и оперативно внедрять их с помощью простой замены одного контейнера на другой. Как это сделать, должно быть понятно после прочтения предыдущей статьи.

Однако здесь тебя ждет небольшая проблема, и заключается она в том, что для замены одного контейнера на другой придется вручную перенастраивать все зависимые от него контейнеры. А это, во-первых, не очень-то и удобно, а во-вторых, требует времени. Решить эту проблему можно разными средствами, в том числе встроенным в Docker механизмом линковки (о нем мы поговорим в следующей статье), но он имеет ряд проблем, поэтому лучше будет воспользоваться множество раз обкатанной в продакшене системой DNS discovery на основе связки SkyDNS и Skydock.

Основная идея этого метода состоит в том, чтобы поднять локальный DNS-прокси SkyDNS и приложение Skydock, которые, работая в тандеме, будут автоматически назначать контейнерам локальные хостнеймы, основанные на имени образа и контейнера Docker. Как следствие, контейнер с обновленным образом того же MySQL из примера выше можно будет включить в общую настройку, просто запустив его, а затем остановив «старый» контейнер. И все это без дополнительных настроек.


Чтобы добавить SkyDNS к уже существующей конфигурации (возьмем для примера все тот же LAMP), достаточно выполнить несколько команд. Для начала установим и запустим сам SkyDNS:

Здесь все довольно просто: с помощью опции -p мы пробрасываем порт 53 с виртуального сетевого моста внутрь контейнера SkyDNS (172.17.42.1 — дефолтовый IP-адрес моста docker0, создаваемого демоном Docker), а с помощью опции -nameserver самого SkyDNS указываем fallback DNS-сервер, который будет использован для резолвинга глобальных хостнеймов. Последняя опция, -domain задает имя домена первого уровня для локальных хостнеймов.

Далее необходимо запустить Skydock. Здесь все еще проще:

Здесь мы с помощью опции -v пробрасываем в контейнер UNIX-сокет Docker, необходимый Skydock для получения уведомлений о запуске и остановке контейнеров и их имен, а далее идет несколько опций самого Skydock:

  • -ttl 30 — время жизни DNS-записи в секундах;
  • -environment dev — имя домена второго уровня для контейнеров;
  • -s /docker.sock — путь до проброшенного ранее сокета;
  • -domain docker — домен первого уровня;
  • -name skydns — имя контейнера со SkyDNS.

Это все. Теперь, если перезапустить контейнеры с Apache и MySQL из предыдущего примера, то они получат имена www.dev.docker и mysql.dev.docker (а если бы мы дали им имена, то они бы стали доменами четвертого уровня). В ситуации с LAMP это нам ничего не даст, кроме чуть большего удобства управления, но в более сложной конфигурации со множеством различных сервисов позволит на лету менять контейнеры (запускаем новый, завершаем старый, никаких настроек, главное, чтобы имена образов и контейнеров совпадали) и даже балансировать нагрузку — SkyDNS будет отдавать IP-адреса с одинаковым именем хоста по очереди, в режиме round-robin.

Кейс номер 3. IaaS и кластеры

Описанный выше пример отлично работает, но в силу централизованной архитектуры Docker и, как следствие, самого Skydock, работает он только на одной физической (как вариант — виртуальной) машине. Чтобы решить эту проблему, нужна некая облачная платформа, которая позволит запускать контейнеры на кластере машин, выполнять их оркестрацию и балансировку нагрузки. На данный момент существует три ключевых проекта, позволяющих связать Docker и кластеры: OpenStack, CoreOS и Kubernetes (плюс фирменные инструменты от разработчиков Docker, но они до сих пор в стадии альфа/бета).

OpenStack

Поддержка Docker в OpenStack есть в трех формах:

  • драйвер гипервизора в Nova;
  • плагин и шаблон для системы оркестрации Heat;
  • движок в каталоге приложений для Murano.

Поддержка драйвера гипервизора Nova, позволяющего запустить OpenStack поверх Docker вместо классических технологий виртуализации (KVM, vSphere и так далее), появилась в релизе Havana. Сам драйвер достаточно прост в установке и настройке и хорошо интегрируется с Glance (сервис, отвечающий за хранение образов) и Neutron (NaaS). Все, что нужно сделать, — это установить драйвер с помощью pip и внести небольшие изменения в файлы конфигурации Nova и Glance. Весь процесс описан на официальной wiki-странице.

Фреймворк оркестрации OpenStack Heat поддерживает Docker, начиная с релиза IceHouse. Его задача — управление Docker, запущенным поверх виртуальной или реальной машины. С помощью одного конфигурационного файла он позволяет запустить одну или несколько машин, установить в них Docker, а затем запустить контейнеры с нужными сервисами внутри. Пример файла конфигурации для автоматического запуска виртуальной машины, установки в нее Docker и запуска контейнера cirros:

Murano, выполняющий роль каталога приложений в OpenStack, поддерживает Docker с января 2014 года. Он позволяет публиковать, искать и разворачивать Docker-контейнеры с приложениями так же просто, как и обычные приложения. Благодаря этой функциональности можно запустить набор сервисов внутри Docker-контейнеров с помощью нескольких кликов мышью прямо из графического интерфейса.

Драйвер Docker для Nova и его связь с остальными компонентами OpenStack

Принцип работы плагина Docker для Heat

CoreOS

CoreOS — еще один крупный проект, имеющий прямое отношение к Docker. Это минималистичный Linux-дистрибутив, предназначенный для запуска контейнеров в больших кластерах и уже поддерживаемый Amazon, Azure, DigitalOcean, Google и Rackspace в публичных облаках. В рамках проекта также развивается система etcd, представляющая собой распределенное хранилище ключ — значение, предназначенное для управления конфигурацией кластера и service discovery, а с недавнего времени и альтернативная система управления контейнерами Rocket.

Главная задача etcd — распределенное хранение информации о местонахождении каждого компонента кластера, а именно информации о контейнерах, такой как IP-адреса, открытые порты и другое. Демон etcd запускается на каждом CoreOS-хосте и поддерживает консистентное состояние между всеми нодами кластерами с возможностью автоматического выбора новой мастер-ноды etcd в случае выхода текущей из строя. Фактически etcd решает обозначенную выше проблему связи между контейнерами, запущенными на разных машинах.

Rocket

В 2014 году в рамках проекта CoreOS началась разработка новой системы контейнерной виртуализации Rocket, которая должна прийти на смену Docker. Двумя основными поводами для «изобретения велосипеда» стали:

  1. Безопасность и децентрализация. Среди задач Rocket — решить одну из фундаментальных проблем Docker, проблему централизации (на каждой машине свой никак не связанный с другими демон docker). Rocket должен быть таким же простым, как Docker, но с акцентом на децентрализацию и безопасность.
  2. Открытый формат контейнеров. Docker — это ориентированная на приложения платформа, и поддержка консистентного стандартизованного формата контейнеров не входит в задачи его разработчиков. В противовес разработчики Rocket предлагают собственный расширяемый формат AppContainer, который должен стать неким стандартом в области контейнеров.

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

Kubernetes

Свою руку к Docker приложила и Google, запустив проект Kubernetes. Компания открыла его код в июне 2014 года, и уже совсем скоро благодаря усилиям Mirantis он появится в каталоге приложений OpenStack.

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

Kubernetes отходит от традиционной модели пула контейнеров и использует вместо этого понятие подов (pods). Каждый под — это группа объединенных общей задачей контейнеров, которые могут быть и микросервисом, и массивным приложением, разнесенным на несколько машин. Для запуска подов используется специальный планировщик, который автоматически подбирает наиболее подходящие для разворачивания сервиса ноды. В любой момент поды могут быть горизонтально масштабированы с помощью контроллера репликации.

Кейс номер 4. Запускаем софт в песочнице

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

Есть два способа сделать то, что нам нужно. Первый — это использовать связку из виртуального X-сервера Xephyr и проброса аудиоустройств в контейнер. Второй — использовать функцию форвардинга протокола X11 в SSH и сервер PulseAudio для передачи звука по сети. Первый способ более прост в настройке, но требует, чтобы графическое приложение в контейнере работало внутри окна фиксированного размера (Xephyr — это X-сервер внутри X-сервера), поэтому мы пойдем по второму пути.

Для наглядности процесса создадим контейнер с Firefox с нуля. Не будем возиться с консолью и коммитами, а просто напишем простенький Dockerfile, который все сделает за нас. Для этого создаем в домашнем каталоге каталог

/tmp (на самом деле имя может быть любым) и копируем в него наш публичный SSH-ключ:

Далее здесь же создаем файл Dockerfile со следующим содержимым:

И собираем образ на его основе:

Теперь нам необходимо настроить PulseAudio на хост-системе так, чтобы он мог принимать звуковые потоки по сети. Для этого используем приложение paprefs:

Запускаем paprefs, переходим на вкладку Network Server и отмечаем галочками опции Enable network access to local sound devices и Don’t requre authentication. Далее запускаем SSH внутри нашего контейнера с Firefox:

Выясняем его IP-адрес:

И подключаемся по SSH

Опция -X здесь отвечает за проброс X11, а -R 4713:localhost:4713 создает обратный туннель между портом 4713 контейнера и тем же портом хост-системы. Это дефолтовый порт PulseAudio, а туннель нужен для того, чтобы Firefox смог получить к нему доступ. Оказавшись в контейнере, набираем следующую команду:

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

Вместо выводов

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

10 команд для Docker, без которых вам не обойтись

В недавнем разговоре произошло кое-что любопытное.

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

«Docker по своему существу больше походит на предприятие»

«Он ориентировочно работает только на OSx и едва на Windows»


«Я не уверен, что могу запустить его на месте без «головняка»»

…И многие другие.

В этих утверждениях есть доля правды (см. #3 и #5 ниже, в качестве примера), но из-за этих крох правды часто не замечается, что не является правдой или то, что больше не является правдой.

И со статьями, которые ничего не делают кроме как выдают жаргон, требуют огромное количество фреймворков и обсуждают как справиться с 10 тысяч триллионов запросов за секунду, используя только 30 тысяч контейнеров, автоматизируя 5 тысяч микросервисов, содержащихся в 6 сотнях облаках, основанных на примерах сервера…

Поэтому легко понять, почему о Docker существует столько мифов.

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

Итак, давайте лучше рассмотрим типичные мифы — некоторые я видел, в некоторые я раньше верил — и попытаемся найти в них правду, так же как и решения, если их можно найти.

Миф #10: я не могу разрабатывать с Docker…потому что я не могу редактировать Docker файлы

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

Образ продукции Docker должен быть изменен только в целях продукции.

Итак, как же я могу справиться с нуждами разработки с помощью Docker? Если я не могу редактировать Dockerfile с целью добавить инструменты и конфигурации, как же я должен разрабатывать приложения в Docker?

Я мог бы скопировать и вставить производственный Dockerfile в мой и затем изменять его под себя. Но мы все знаем, что дупликация — это корень всего зла. И мы знаем, что дупликация — это корень всего зла. Потому что дупликация — это корень всего зла.

Решение

Лучше, чем делать дубликат Dockerfile и потенциально создавать больше проблем, решением станет использование Docker примера создания образов из образов.

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

Настройка SSH и MOTD баннера в CentOS

Установка и настройка ClamAV Linux

15 примеров CURL в Linux

rConfig — резервное копирование конфигов сетевого оборудования

Разбираемся с Docker: установка и использование

Приложение в контейнере

Сегодня речь в статье пойдет о Docker. Все, кто хоть как-то касаются сферы IT слышали про Docker, но не все знают, что же это такое. Итак, сегодня мы простыми словами расскажем о том, что такое Docker, чем это отличается от виртуализации, покажем подробный процесс инсталляции на CentOS 7 и установим просто графический интерфейс Portainer, для управления контейнерами. Также немного коснемся команд для использования Docker.

Что такое Docker?

Docker — это платформа, которая может “упаковать” приложение, его зависимости, middleware и так далее в так называемый “контейнер”, после чего у вас появится возможность развернуть данный контейнер на любом сервере, на котором установлен Docker — причем буквально за доли секунды, одной командой.

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

И хоть кажется, что Docker выглядит и работает как виртуальная машина, на самом деле они очень разные: виртуальная машина эмулирует сервер целиком, включая все аппаратные ресурсы, а контейнер изолирует приложение, процессы, юзеров и файловую систему. При этом все контейнеры используют общее Linux ядро хоста и запускается в нативном режиме только на Linux машинах, но зато на одной машине можно запустить примерно в 5-6 раз больше контейнеров, чем виртуальных машинах. Ниже на схеме показаны различия:

Установка Docker

Как было упомянуто в начале статьи, устанавливать Докер мы будем на CentOS 7 — процесс установки крайне простой и быстрый.

Итак, сначала необходимо установить с помощью yum несколько пакетов:

Далее необходимо установить stable репозиторий для Докера, который вам понадобится, даже если вы захотите устанавливать билды из edge и test репозиториев:

Затем устанавливаем сам Docker:

yum install docker-ce

И, наконец, запускаем Docker:

Проверяем, что Docker запустился и работает в два шага:

Вы должны увидеть следующий вывод:


После этого пробуем развернуть контейнер hello-world:

Если все шаги были выполнены корректно, то на экране должно появится следующее:

Установка Portainer

Portainer — это очень удобный графический интерфейс для управления Docker или Docker Swarm. Устанавливается он практически в одно действие — так как сам точно также является контейнером. Итак:

Создаем разметку для Portainer:

И затем запускаем сам контейнер:

После чего заходите на сетевой адрес вашего сервера на порт 9000, и вы должны увидеть окно с предложением установить пароль администратора:

Далее выбираем где находится наш Докер — на этом же сервере, или на другом (в нашем случае — Local) и кликаем Connect.

После чего вас встретит красивый дэшборд:

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

Итак, сначала кликните на Containers — вы увидите все имеющиеся контейнеры с информацией о них:

Как вы можете видеть, у нас на данный момент запущен только один контейнер — Portainer, и доступ к нему открыт по порту 9000 (столбец Published Ports), и адрес во внутренней сети Docker — 172.17.0.2.

Далее кликните на App Templates в меню справа — и вы увидите весь список приложений, который можно запустить одним кликом:

Зайдем во вкладку Httpd:

Сперва, назовите данный контейнер как-нибудь — мы назвали test-merionet. Затем, можете кликнуть на Show advanced options и вы увидите возможность выбора какой порт, протокол и том будет использоваться данным контейнером. Затем просто нажмите на Deploy the container.

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

Отсюда вы увидите, что httpd сервер доступен на 32768 порту. Итак, пробуем зайти на данный сервер через браузер:

Вы должны будете увидеть надпись It works! так же как на скриншоте выше — дальнейшую настройку httpd мы пока оставляем за кадром.

Донастройка Docker и полезные команды

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

Первым делом, настройте автозапуск для сервиса Docker:

Затем, вы можете проверить запущенные контейнеры в консоли (на случай если вам не нравится идея использования GUI) с помощью команды

Теперь немного о командах и синтаксисе — будем показывать на примерах:

Допустим, нам нужно запустить CentOS и выполнить в нем команду echo:

Запустить CentOS и подключиться к его терминалу:

Можете сразу указать нужные порты с помощью ключа -p и запустить контейнер в бэкграунде с помощью ключа —d:

Итак, совсем немного об опциях для команды docker run — полный список можно найти по ссылке https://docs.docker.com/engine/reference/commandline/run/#description

  • -p — открываем конкретные порты через пробел — порт доступа и порт на контейнере, к примеру docker run -p 9876:80 %imagename%
  • -P — открываем сразу все порты;
  • -t — подключение к терминалу контейнера;
  • -i — интерактивный режим, STDIN все время будет открыт;

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

Заключение

На этом всё, спасибо за внимание! Пишите в комментариях, что еще вам интересно узнать про Докер — в следующих статьях мы покроем такие темы как: создание своего собственного Докер-файла и образа, как подключить папку файловой системы с вашего хоста, интересное на Docker Hub и так далее.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

�� Топ самых важных команд Docker

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

Это основные команды Docker, необходимые для начала работы с контейнерами и образами Docker.

Найти версию Docker

Давайте проверим версию Docker, установленную на машине.

Команда info выводит информацию о количестве контейнеров и образов вместе с информацией об операционной системе, версии ядра, процессоре, памяти и имени хоста.

Контейнеры Docker

Создать Docker контейнер

  • -d: запустить контейнер в фоновом режиме и вывестиь идентификатор контейнера
  • -i: запустить контейнер в интерактивном режиме
  • -t: выделяет терминал tty, который требуется для подключения к контейнеру
  • –Name: имя контейнера
  • –Hostname: установить хост для контейнера

Список Docker Контейнеров

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

Доступ к Docker контейнерам

Проверьте запущенный процесс в контейнере

Команда top показывает запущенный процесс и его детали.

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

Команда stats выполняет прямую трансляцию статистики использования ресурсов контейнера.

Статистика будет похожа на команду top Linux.

Скопируйте файл / папку из Docker контейнера

Команда cp позволит вам копировать файлы / папки из контейнеров в хост-систему.

Следующая команда скопирует файл /root/tobecopied в /root хост-машины.

Убить контейнер Docker

Команда kill отправляет сигнал SIGTERM для уничтожения работающего контейнера.

Запустить Docker Контейнер

Команда start позволяет запустить остановленный контейнер.

Перезапуск Docker контейнера

Команда restart позволяет перезапустить контейнер.

Остановит Docker контейнер

Команда stop поможет вам остановить контейнер:

Переименовать Docker контейнер

Команда rename предоставляет возможность изменить имя контейнера, например из docker-fedora в MyFedora.

Удалить Docker Контейнер

Команда rm поможет вам удалить контейнер.

Если контейнер работает, используйте -f, чтобы принудительно удалить его.

Образы Docker

Поиск образов Docker

Скачать образ Docker

Список образов Docker

Отобразить список доступных образов Docker в системе:

Удалить образ Docker

Вы можете удалить образы с помощью команды rmi или rm

Как в Docker передать команду в рабочий процесс приложения?

Создаю контейнер с флагами: docker run -d -it —name Game
В контейнере запускается java приложение — игра.
Скажите пожалуйста, каким образом можно передать в неё команды?

Раньше она работала с помощью «Screen». Я в любой момент подключался ( screen –x ) через терминал к рабочей сессии «Screen» и мог вводить консольные, игровые команды, а вот в случае со Docker не могу понять каким образом это можно делать.

  • Вопрос задан более двух лет назад
  • 679 просмотров

Если я правильно вас понял, в таком случае вас интересует exec команда. Напишите некое подобие прослойки скрипта который будет обращаться к процессу. Покладите его в контейнер. И запускайте в ваших скриптах в виде:

скрипт соответственно должен находить нужный пид и работать с ним. Здесь нужно немного баш магии. Например:

Если это ваше приложение, на вашем же месте я бы привинтил простенький контроллер умеющий общаться с сетью. Например минимальный web-сервер. И управлял curl`ом.

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

docker attach Game

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

Например что нибудь вроде:
docker attach Game && команда

Александр Назаров, я вам уже отвечал на этот вопрос. То, что вы хотите сделать делается через exec. А не attach.
Вам нужен pid процесса и pipe в его команды.
Как обучающий эксперимент запустите в одном терминале cat в другом
pidof cat
оно выплюнет вам пид вашего ката, возможно не одного. Вас интересует последний. Самый большой.

После этого вводите:

Смотрите что у вас в терминале где запущен cat

Эквивалентно поступайте с вашей задачей.
Разжевать ещё мельче маловероятно, что получиться.

Команды для работы с Docker

Образы

# Скачать образ ubuntu с тегом latest

# То же самое, но указанное явно

# Скачать все теги образа ubuntu

# Получить список образов, которые есть на локальной машине

# Просмотр информации об образе
# Пример вывода — https://gist.github.com/bessarabov/4afa32c1ff3c958d4a9f

# Удалить образ ubuntu:latest

# Создать образ (в текущей папке должен находится файл Dockerfile)
# Эта команда создаст образ bessarabov/sample_nginx с тегом latest

# Создать новый тег на основе уще существующего образа

Работа с контейнерами

# Запустить контенейр в интерактивном режиме
# (ключи -i -t можно объединить в -it)

# Получить список контенеров
# (если не указать ключ -a, то будет показаны только работающие контенеры)

# Удалить контенер (можно удалить только остановленный контейнер).
# Команде можно передать как CONTAINER ID, так и NAME

# Запустить контейнер и автоматически удалить его после того как он
# остановится

# Запустить контейнер и указать ему имя ‘sample’. Если явно не указывать
# имя, то оно будет создано автоматически, типа ‘silly_hopper’

# Запустить контейнер в виде демона, сделать чтобы порт 8000 на хост
# машине соответствовал 80 порту в контейнере

# Вот как выглядит инфа об этом контейнере:

# Запуск контейнера, без его удаления. Следует помнить, что когда вы используете команду docker run, контейнер создается заново стирая все изменения, которые были произведены в нем. Для запуска контейнера не с нуля используется команда

Мастер Йода рекомендует:  Использование модуля для работы с шаблонами
Добавить комментарий