Docker это популярный инструмент, который благодаря использованию контейнеров предоставляет все необходимое для запуска приложений. Используя Docker-контейнеры, вы можете быть уверенными в том, что приложение будет работать одинаково на любых машинах, на которых вы его запустите.
Из этого руководства вы узнаете о связи контейнеров и образов Docker, а также о том, как устанавливать, запускать, останавливать и удалять контейнеры.
Образ Docker можно представить в качестве некоторого шаблона, который используется для создания контейнеров. Образы обычно начинаются с корневой файловой системы, к которой затем сверху слоями добавляются различные изменения и соответствующие им параметры запуска. В отличие от типичных дистрибутивов Linux, образ Docker обычно содержит только части, которые необходимы для запуска приложения. У образов нет статусов, и они не изменяются. Правильнее сказать, что они являются исходной точкой, основой для контейнеров Docker.
Образы «оживают» в тот момент, когда вы вводите команду docker run - она сразу же создает контейнер в результате добавления поверх образа новый уровень для чтения и записи. Эта комбинация уровней только для чтения (поверх которых добавляется уровень для чтения и записи) также известна как UnionFS - файловая система, производящая каскадно-объединённое монтирование файловых систем. Когда в существующий файл запущенного контейнера вносится какое-либо изменение, файл копируется из области только для чтения на уровень для записи и чтения, где и применяются эти изменения. И теперь изначальный файл скрыт версией с уровнем для записи и чтения, но он не удален. Подобные изменения в уровне для записи и чтения существуют только внутри данного отдельного контейнера. Когда контейнер удаляется, все изменения также теряются (если они не были сохранены).
Каждый раз, когда вы используете команду docker run, из того образа, который вы указываете, создается новый контейнер. Ниже будут рассмотрены более конкретные примеры.
Шаг 1: создание двух контейнеров
Написанная ниже команда docker run создает новый контейнер, который в качестве основания будет использовать образ Ubuntu. Ключ -t предоставит терминал, а -i - возможность взаимодействовать с ним. Для того, чтобы оказаться внутри контейнера, можно использовать стандартную команду bash. То есть вы можете ввести:
$ docker run -ti ubuntu
$ docker run -i -t ubuntu:14.04 /bin/bash
(во втором случае вы запустите команду /bin/bash внутри контейнера и автоматически окажетесь внутри контейнера)
В командной строке появится подтверждение того, что вы находитесь внутри контейнера в качестве суперпользователя. После знака @ вы увидите ID контейнера, в котором находитесь:
Root@11cc47339ee1:/#
Теперь, используя команду echo, внесите изменения в директорию /tmp, а затем проверьте, что изменения были записаны при помощи команды cat:
Echo "Example1" > /tmp/Example1.txt cat /tmp/Example1.txt
На экране вы должны увидеть:
Теперь выйдите из контейнера:
Как только данная команда была выполнена, и вы вышли из командной строки, контейнер Docker перестал работать. Увидеть это вы можете, если используете команду docker ps:
Среди запущенных контейнеров вы не увидите тот, который использовался выше:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Однако вы можете добавить ключ -a для того, чтобы увидеть все контейнеры - как работающие, так и остановленные - и тогда вам высветится контейнер, в котором вы работали ранее:
$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 11cc47339ee1 ubuntu "/bin/bash" 9 minutes ago Exited (127) 10 seconds ago small_sinoussi
Когда создается контейнер, у него появляется ID и автоматически сгенерированное название. В данном случае 11cc47339ee1 - это идентификационный номер (ID) контейнера, а small_sinoussi - сгенерированное имя. Команда ps -a показывает эти данные, а также образ, из которого контейнер был создан (в данном случае ubuntu), когда контейнер был создан (9 минут назад), и какая команда была в нем запущена ("/bin/bash”). Также вы можете посмотреть статус контейнера (из него вышли 10 секунд назад). В том случае, если бы контейнер до сих пор работал, вы бы увидели статус "Up" и время, которое он уже работает.
Теперь вы можете еще раз ввести команду для создания контейнера:
$ docker run -ti ubuntu
Несмотря на то, что команда выглядит так же, как и в прошлый раз, она создаст абсолютно новый контейнер - он будет иметь другой идентификационный номер, а если вы попробуете посмотреть содержимое файла Example1, который редактировали ранее, то вы его не найдете.
Root@6e4341887b69:/# cat /tmp/Example1
Вывод будет:
Cat: /tmp/Example1: No such file or directory
Вам может показаться, что данные исчезли, но дело, конечно же, не в этом. Выйдите из второго контейнера, чтобы убедиться, что оба контейнера (в том числе первый с нужным файлом) существуют в системе.
Root@6e4341887b69:/# exit $ docker ps -a
Вывод будет:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6e4341887b69 ubuntu "/bin/bash" About a minute ago Exited (1) 6 seconds ago kickass_borg 11cc47339ee1 ubuntu "/bin/bash" 15 minutes ago Exited (127) 6 minutes ago small_sinoussi
Шаг 2: перезапуск первого контейнера
Для того, чтобы заново запустить уже созданный контейнер, необходимо команду start использовать с двумя ключами -ai. В конце вам необходимо написать идентификационный номер контейнера, с которым вы хотите работать, либо его название. В итоге ваша команда будет выглядеть следующим образом:
Docker start -ai 11cc47339ee1
Теперь вы снова находитесь в оболочке bash внутри контейнера и можете убедиться в том, что файл, который вы создавали в начале статьи, все еще находится здесь:
Cat /tmp/Example1.txt
Вы увидите на экране:
Теперь вы можете выйти из контейнера:
Таким образом, все изменения внутри контейнера сохраняются, даже если вы останавливаете и потом заново запускаете контейнер. Данные удаляются лишь в том случае, когда удаляется сам контейнер. Также пример выше показывает, что изменения касаются одного отдельного контейнера (а не всех контейнеров сразу).
Шаг 3: удаление обоих контейнеров
Завершающим шагом будет удаление двух контейнеров, которые вы создали, следуя данному руководству. Для этого необходимо использовать команду docker rm. Однако она действует только на остановленные контейнеры. После команды необходимо указать идентификационный номер либо название одного или нескольких контейнеров. К примеру, чтобы удалять контейнеры, созданные ранее, необходимо ввести команду:
Docker rm 6e4341887b69 small_sinoussi
На экране высветится:
6e4341887b69 small_sinoussi
Теперь оба контейнера были удалены.
Из данного руководства вы узнали об основных командах для работы в Docker и научились создавать, останавливать, вновь запускать и удалять контейнеры.
Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker - «Understanding docker» .
Платформа и средства контейнерной виртуализации могут быть полезны в следующих случаях:
Например, ваши разработчики пишут код локально и делятся своим стеком разработки (набором docker образов) с коллегами. Когда они готовы, отравляют код и контейнеры на тестовую площадку и запускают любые необходимые тесты. С тестовой площадки они могут оправить код и образы на продакшен.
Портируемость и легковесная природа docker позволяет легко динамически управлять вашей нагрузкой. Вы можете использовать docker, чтобы развернуть или погасить ваше приложение или сервисы. Скорость docker позволяет делать это почти в режиме реального времени.
Docker использует архитектуру клиент-сервер. Docker клиент общается с демоном Docker, который берет на себя тяжесть создания, запуска, распределения ваших контейнеров. Оба, клиент и сервер могут работать на одной системе, вы можете подключить клиент к удаленному демону docker. Клиент и сервер общаются через сокет или через RESTful API.
Одна из причин, по которой docker легковесен - это использование таких уровней. Когда вы изменяете образ, например, обновляете приложение, создается новый уровень. Так, без замены всего образа или его пересборки, как вам возможно придётся сделать с виртуальной машиной, только уровень добавляется или обновляется. И вам не нужно раздавать весь новый образ, раздается только обновление, что позволяет распространять образы проще и быстрее.
В основе каждого образа находится базовый образ. Например, ubuntu, базовый образ Ubuntu, или fedora, базовый образ дистрибутива Fedora. Так же вы можете использовать образы как базу для создания новых образов. Например, если у вас есть образ apache, вы можете использовать его как базовый образ для ваших веб-приложений.
Примечание! Docker обычно берет образы из реестра Docker Hub.
Docker образы могут создаться из этих базовых образов, шаги описания для создания этих образов мы называем инструкциями. Каждая инструкция создает новый образ или уровень. Инструкциями будут следующие действия:
Эти инструкции хранятся в файле Dockerfile . Docker считывает это Dockerfile , когда вы собираете образ, выполняет эти инструкции, и возвращает конечный образ.
С помощью docker клиента вы можете искать уже опубликованные образы и скачивать их на вашу машину с docker для создания контейнеров.
Docker Hub предоставляет публичные и приватные хранилища образов. Поиск и скачивание образов из публичных хранилищ доступно для всех. Содержимое приватных хранилищ не попадает в результат поиска. И только вы и ваши пользователи могут получать эти образы и создавать из них контейнеры.
$ sudo docker run -i -t ubuntu /bin/bash
Давайте разберемся с этой командой. Клиент запускается с помощью команды docker , с опцией run , которая говорит, что будет запущен новый контейнер. Минимальными требованиями для запуска контейнера являются следующие атрибуты:
Что же происходит под капотом, когда мы запускаем эту команду?
Docker, по порядку, делает следующее:
Это создает изолированный уровень, каждый аспект контейнера запущен в своем простанстве имен, и не имеет доступ к внешней системе.
Список некоторых пространств имен, которые использует docker:
Справка по командам управления образами и контейнерами Docker.
Образ - это статический билд на основе определенной OS.
Контейнер - это запущенный инстанс образа.
Чтобы запускать Docker контейнеры под своим пользователем (без sudo), нужно добавиться в соответствующую группу:
Sudo usermod -aG docker YOU_USER
Управление сервисом Docker"а:
Sudo service docker start|stop|restart|status sudo restart docker # алиас
Список доступных образов:
Docker images
Скачать образ (или весь репозиторий) из официального регистра (хранилища образов):
Docker pull ubuntu:14.04
Посмотреть информацию об образе:
Docker inspect ubuntu
Удалить образ:
Docker commit CONTAINER_ID IMAGE_NAME
После запуска Docker контейнера сервисы/демоны (как-то SSH, Supervisor и прочие) не будут запускаться автоматически! Я потратил несколько часов на отладку ошибки: "ssh_exchange_identification: read: Connection reset by peer ", при попытке подключиться к контейнеру по SSH. А оказалось, что всего-то не запускался демон sshd. Вы должны будете вручную запускать нужные демоны или супервизор после старта контейнера:
Docker exec CONTAINER_ID bash -c "service ssh start"
Список всех контейнеров (запущенных и остановленных):
Docker ps -a
Удалить контейнер(ы):
Docker rm CONTAINER_ID CONTAINER_ID
Удалить все контейнеры:
Docker rm $(docker ps -aq)
Создать и запустить Docker контейнер c Ubuntu 14.04 в интерактивном режиме (открыть shell этого контейнера):
Docker run -it ubuntu bash docker run [опции] образ [команда] -i Интерактивный режим, держим STDIN открытым -t Allocate/creates a pseudo-TTY that attaches stdin and stdout --name Имя контейнера вместо ID -w Указать рабочую директорию (--workdir) -e Установить переменную окружения в контейнере -u Пользователь:группа под которым должен быть запущен контейнер -v Смонтировать в контейнер файл или каталог хост-системы -p Пробросить порт(ы) контейнера - <порт хост-системы>:<порт контейнера> (--publish=) --entrypoint Заменить дефолтную команду из ENTRYPOINT файла Dockerfile
Чтобы отсоединить TTY без остановки контейнера нажмите Ctr + P + Ctrl + Q .
Создать и запустить Docker контейнер в режиме демона с пробросом SSH порта:
Docker run -itd -p 127.0.0.1:221:22 ubuntu
Создать и запустить контейнер с последующим удалением этого контейнера после остановки (полезно для отладки):
Docker run -i -t --rm ubuntu bash
Запустить остановленный контейнер интерактивно:
Docker start -i CONTAINER_ID
Подключиться к демонизированному контейнеру:
Docker attach CONTAINER_ID
Внутри Docker только Linux , и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.
Докер - это двойная изоляция.
Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.
Это почти виртуальная машина. Почти, да не совсем.
Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.
Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно . Запускаем в этих операционных системах в Докере.
С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.
Docker - это одна программа внутри индивидуального окружения с индивидуальной версией операционной системы. За счет слоеных контейнеров, если вы используете один корень для всех образом, то размер Docker контейнера всего-то на несколько килобайтов больше размера бинарного файла, запускаемого под Docker.
Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.
Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.
Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.
Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.
Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.
Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD . Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.
Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов , собранных воедино, для управления контейнерной виртуализацией. Но очень удобный .
Зачем это используется?
Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.
Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.
Поэтому кто-то из этих умных ребят родил новую концепцию - каждая программа на серверах запускается в своем индивидуальном окружении, с индивидуальными настройками операционной системы .
Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер , с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.
Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.
До этого люди мучались, придумывали хитрые инсталяторы...
Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.
Другими словами:
Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно , которые требует несовместимых настроек операционной системы . Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.
Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.
Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.
Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:
Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.
То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ
.
Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).
Docker — самая распространенная система контейнеризации, позволяющая запускать необходимое для разработки ПО в контейнерах не устанавливая его на локальную систему. В рамках данного материала разберем docker управление контейнерами.
Над всей структурой выстроена особым образом сеть, что позволяет пробрасывать желаемым образом порты и делать контейнер доступным снаружи (по умолчанию он работает на локальном IP адресе) через виртуальный бридж. Контейнер при этом может быть доступен как миру, так и одному адресу.
Установим Docker на Ubuntu или Debian сервер если он еще не установлен по инструкции . Лучше выполнять команды от имени непривилегированного пользователя через sudo
Запуск самого простого контейнера покажет, что все работает
Базовые комагды для управления контейнерами
Вывести все активные контейнеры можно так
С ключем -a будут выведены все контейнеры, в том числе неактивные
Dicker назначает имена контейнерам случайным образом, при необходимости можно указать имя непосредственно
docker run —name hello-world
Запускаем контейнер с именем my-linux-container на основе образа ubuntu и переходим в консоль контейнера указывая оболчку bash
docker run -it —name my-linux-container ubuntu bash
Чтобы выйти из контейнера и вновь оказаться на хост системе нужно выполнить
Все образы, на основе которых создаются контейнеры скачиваются с hub.docker.com автоматически при первом создании контейнера, те, что уже существуют локально можно увидеть выполнив docker images
Создание контейнера из уже скачанного образа будет происходить значительно быстрее (практически мгновенно)
При выходе из контейнера с exit он останавливается, чтобы этого не происходило выходить можно сочетанием клавиш CTRL + A + P
Можно убрать все контейнеры, не являющиеся активными
docker rm $(docker ps -a -f status=exited -q)
Или удалять их по одному
Вместо идентификатора в последней команде можно указать имя
В docker управление контейнерами производится за счет небольшого количества интуативно понятных команд:
docker container start ID
docker container stop ID
docker container restart ID
docker container inspect ID
Последняя особенно полезна, она выводит всю информацию о контейнере, конфигурационных файлах и используемых разделах диска. Весь список команд можно легко найти в помощи или на официальном сайте Docker-а
Образы обычно создаются из уже существующих за счет использования дополнительных опций, указанных в Dockerfile
FROM ubuntu
CMD echo «hello world»
Сейчас создается новый образ на основе стандартного с ubuntu
Собираем образ дав ему имя (точка в конце команды означает, что используется текущий каталог, а значит и Dockerfile в нем)
docker build -t my-ubuntu .
docker images теперь покажет и созданный только что образ my-ubuntu
Его можно запустить, в консоль при этом будет выведено hello world и это единственное отличие от дефолтного образа
Обычно нужны более сложные правила, например в образ нам нужно включить python3 — перйдем в новый каталог и создадим Dockerfile
FROM ubuntu
CMD apt-get update && apt-get install python3
Все инструкции записываются в одну строку
docker build -t my-ubuntu-with-python3 .
Запускаем контейнер переходя внутрь
docker run -it my-ubuntu-with-python3 bash
Внутри от имени root нужно выполнить dpkg -l | grep python3 , команда покажет, что пакет присутствие в системе, что означает успех