Docker from scratch что это
Create a base image
Estimated reading time: 3 minutes
Most Dockerfiles start from a parent image. If you need to completely control the contents of your image, you might need to create a base image instead. Here’s the difference:
A parent image is the image that your image is based on. It refers to the contents of the FROM directive in the Dockerfile. Each subsequent declaration in the Dockerfile modifies this parent image. Most Dockerfiles start from a parent image, rather than a base image. However, the terms are sometimes used interchangeably.
A base image has FROM scratch in its Dockerfile.
This topic shows you several ways to create a base image. The specific process will depend heavily on the Linux distribution you want to package. We have some examples below, and you are encouraged to submit pull requests to contribute new ones.
Create a full image using tar
In general, start with a working machine that is running the distribution you’d like to package as a parent image, though that is not required for some tools like Debian’s Debootstrap, which you can also use to build Ubuntu images.
It can be as simple as this to create an Ubuntu parent image:
There are more example scripts for creating parent images in the Docker GitHub repository.
Create a simple parent image using scratch
Note: Because Docker Desktop for Mac and Docker Desktop for Windows use a Linux VM, you need a Linux binary, rather than a Mac or Windows binary. You can use a Docker container to build it:
To run your new image, use the docker run command:
This example creates the hello-world image used in the tutorials. If you want to test it out, you can clone the image repo.
More resources
Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps
Сборка образов для Docker на основе базового образа, как правило, предполагает вызов команд в окружении этого базового образа. Например — вызов команды apt-get, которая есть в базовом образе, для установки новых пакетов.
Часто возникает необходимость доустановить в базовую систему некоторый набор утилит, с помощью которых происходит установка или сборка некоторых файлов, которые требуются в итоговом образе. Например, чтобы собрать Go-приложение, надо установить компилятор Go, положить все исходные коды приложения в базовом образе, скомпилировать требуемую программу. Однако в итоговом образе требуется лишь скомпилированная программа без всего набора утилит, который использовался для компиляции этой программы.
Проблема известная: одним из путей её решения может быть сборка вспомогательного образа и перенос файлов из вспомогательного образа в результирующий. Для этого появились Docker multi-stage builds или образы-артефакты в dapp (Обновлено 13 августа 2019 г.: в настоящее время проект dapp переименован в werf, его код переписан на Go, а документация значительно улучшена). И данный подход идеально решает проблему подобную переносу результатов компиляции исходных кодов в итоговый образ. Однако он не решает все возможные проблемы…
Вот другой пример: для сборки образа используется Chef в локальном режиме. Для этого в базовый образ ставится chefdk, монтируются или добавляются рецепты, запускаются эти рецепты, которые настраивают образ, устанавливают новые компоненты, пакеты, файлы-конфиги и прочее. Аналогично может быть использована другая система управления конфигурациями — например, Ansible. Однако установленный chefdk занимает около 500 Мб и существенно увеличивает размеры итогового образа — оставлять его там нет смысла.
Но multi-stage builds в Docker уже не решат эту проблему. Что, если пользователю не хочется знать о том, каков побочный эффект работы программы — в частности, какие файлы она создает? Например, чтобы не держать лишние явные описания всех экспортируемых путей из образа. Хочется просто запустить программу, получить какой-то результат в образе, но чтобы программа и все окружение, нужное для ее работы, осталось вне итогового образа.
В случае с chefdk можно было бы монтировать директорию с этим chefdk в сборочный образ на время сборки. Но с этим решением есть проблемы:
В поисках приключений
Теория
Динамически скомпилированная программа в Linux зависит от местоположения линкера ld-linux в системе. Например, бинарник bash в ubuntu:16.04 скомпилирован так, что зависит от линкера /lib64/ld-linux-x86-64.so.2 :
Причем эта зависимость является статической и вкомпилирована в сам бинарник:
Таким образом, надо: а) скомпилировать условный /myutils/bin/bash так, чтобы он использовал линкер /myutils/lib64/ld-linux-x86-64.so.2 ; б) чтобы линкер /myutils/lib64/ld-linux-x86-64.so.2 был настроен на динамическую линковку библиотек из /myutils/
Собираем дистрибутив dappdeps
Почему набор образов нашего «дистрибутива» называется dappdeps? Потому что эти образы использует сборщик dapp — они собираются под нужды этого проекта.
Итак, наша конечная цель:
Собираем dappdeps/toolchain
Глава 5 «Constructing a Temporary System» руководства Linux From Scratch как раз описывает процесс построения временного chroot-окружения в /tools с некоторым набором утилит, которым затем собирается главный целевой дистрибутив.
Итоговый образ dappdeps/toolchain — это и есть «temporary system» в терминологии LFS. GCC в данной системе все еще завязан на системные пути к библиотекам, однако мы не будем добиваться того, чтобы GCC работал в любом базовом образе. Образ dappdeps/toolchain — вспомогательный, он будет использоваться далее, в т.ч. для сборки уже реально независимых от общих системных библиотек программ.
Используем Omnibus вместе с dappdeps/toolchain
Для сборки таких проектов, как chefdk или GitLab, используется Omnibus. Он позволяет создать самодостаточные наборы (self-contained bundle) с программой и всеми зависимыми библиотеками, кроме системного линкера и libc. Все инструкции описываются читаемыми удобными Ruby-рецептами. Также у проекта Omnibus есть библиотека уже написанных рецептов omnibus-software.
Итак, попробуем описать сборку остальных dappdeps-дистрибутивов с использованием Omnibus. Однако, чтобы избавиться от зависимости от системного линкера и libc, будем собирать все программы в Omnibus с использованием компилятора из dappdeps/toolchain. В этом случае программы окажутся завязаны на glibc, который тоже есть в dappdeps/toolchain.
Для этого сохраним содержимое dappdeps/toolchain как архив:
Добавим этот архив через директиву Dockerfile ADD и распакуем содержимое архива в корень сборочного контейнера:
Перед запуском сборки через omnibus добавляем в переменную PATH путь /.dapp/deps/toolchain/0.1.1/bin в качестве приоритетного, чтобы использовался GCC из dappdeps/toolchain.
Результат работы Omnibus — это пакет (в нашем случае — DEB), содержимое которого распаковывается и переносится в /.dapp/deps/
Собираем dappdeps/base
Проект для Omnibus описывается с помощью файла проекта omnibus/config/projects/dappdeps-base.rb :
Проект Omnibus и Dockerfile для dappdeps/base можно найти здесь.
Собираем dappdeps/gitartifact
В случае с dappdeps-gitartifact необходим лишь рецепт сборки Git, а он уже есть в omnibus-software — остается только подключить его в текущий Omnibus. В остальном все аналогично.
Проект Omnibus и Dockerfile для dappdeps/gitartifact можно найти здесь.
Собираем dappdeps/chefdk
Для chefdk тоже уже есть готовый проект Omnibus. Остается лишь добавить его в сборочный контейнер через Dockerfile и заменить стандартные пути установки chefdk /opt/chefdk на /.dapp/deps/chefdk/2.3.17-2 (наш путь установки будет включать в себя версию Chef).
Dockerfile для сборки dappdeps/chefdk можно найти здесь.
Собираем dappdeps/ansible
Для сборки Ansible также заводим Omnibus-проект, в котором устанавливаем интерпретатор Python, pip и описываем software-рецепт для Ansible:
Как видно, образ с Ansible представляет собой встроенный Python, pip и установленный через pip Ansible с зависимостями.
Проект Omnibus и Dockerfile для dappdeps/ansible можно найти здесь.
Как использовать дистрибутив dappdeps?
Чтобы пользоваться образами dappdeps через монтирование томов, предварительно для каждого образа необходимо создать контейнер и указать, какой том хранится в этом контейнере. Этого требует Docker на данный момент.
Создаем остальные контейнеры:
Финальный аккорд — создаем образ из получившегося контейнера и… видим, что от dappdeps в нем остались лишь пустые директории mount-point’ов!
Казалось бы, о чем еще можно мечтать.
Дальнейшие работы и проблемы
Какие проблемы с dappdeps?
Необходимо провести работу по уменьшению размеров dappdeps/toolchain. Для этого надо разделить toolchain на 2 части: часть, необходимая для сборки новых утилит в dappdeps, и часть с базовыми библиотеками типа glibc, которые необходимо монтировать в runtime уже для запуска этих утилит.
Для работы модуля Ansible apt в dappdeps/ansible пришлось добавить содержимое пакета python-apt в Ubuntu прямо в образ без пересборки. В этом случае модуль apt работает без проблем в базовых образах на основе DEB, но требуется наличие glibc определенной версии. Поскольку сам apt — это дистрибутиво-специфичный модуль, то такое допустимо.
Чего не хватает в Dockerfile?
Выводы
Мы убедились, что идея работает и позволяет использовать в сборочных инструкциях GNU- и другие CLI-утилиты, запускать интерпретатор Python или Ruby, запускать даже Ansible или Chef в Alpine или scratch-образах. При этом писателю сборочных инструкций не требуется знать побочный эффект выполнения запускаемых команд и явно перечислять, какие файлы необходимо импортировать, как в случае с Docker multi-stage builds.
Результаты данной работы применяются и на практике: dapp использует dappdeps-образы в сборочных контейнерах. Например, Git из dappdeps/gitartifact используется для работы с патчами, и утилита Git с некоторой гарантией ведет себя одинаково во всех базовых образах. Однако то, как dapp использует dappdeps, выходит за рамки данной статьи.
Целью данной статьи было донести саму идею и показать на реальном практическом примере возможность ее применения.
Изучаем Docker, часть 1: основы
Технологии контейнеризации приложений нашли широкое применение в сферах разработки ПО и анализа данных. Эти технологии помогают сделать приложения более безопасными, облегчают их развёртывание и улучшают возможности по их масштабированию. Рост и развитие технологий контейнеризации можно считать одним из важнейших трендов современности.
Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.
Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.
Метафоры и Docker
Мы постоянно сталкиваемся с метафорами. Если заглянуть в словарь Ожегова, то окажется, что метафора — это «скрытое образное сравнение, уподобление одного предмета, явления другому». Метафоры помогают нам ухватывать суть новых для нас явлений. Например, виртуальные контейнеры можно сравнить с обычными пластиковыми контейнерами. Такое сравнение, через сопоставление уже известных нам свойств обычных контейнеров со свойствами виртуальных контейнеров, поможет сначала с ними познакомиться, а потом и понять их сущность.
Как вы понимаете, мы собираемся начать разговор о Docker с понятия «контейнер».
Контейнер
Как и обычный пластиковый контейнер, контейнер Docker обладает следующими характеристиками:
Живые организмы
Ещё один подход к размышлениям о контейнерах Docker заключается в сравнении их с экземплярами живых организмов. «Экземпляр» — это нечто, существующее в некоей форме. Это не просто код. Это код, который стал причиной существования чего-то большего, чем он сам, чего-то, образно говоря, живого. Как и другие живые организмы, экземпляры контейнеров появляются на свет, живут и умирают.
Монстр, вызванный к жизни
Контейнеры Docker — это вызванные к жизни образы Docker.
Программное обеспечение
Контейнеры Docker можно сравнивать не только с обычными контейнерами или с живыми организмами. Их можно сравнить и с программами. В конце концов, контейнеры — это программы. И, на фундаментальном уровне, контейнер представляет собой набор инструкций, который выполняется на некоем процессоре, обрабатывая какие-то данные.
Контейнер — это программа
Во время выполнения контейнера Docker внутри него обычно выполняется какая-то программа. Она выполняет в контейнере некие действия, то есть — делает что-то полезное.
Например, код, который работает в контейнере Docker, возможно, отправил на ваш компьютер тот текст, который вы сейчас читаете. Вполне возможно и то, что именно код, выполняющийся в контейнере Docker, принимает голосовые команды, которые вы даёте Amazon Alexa, и преобразует их в инструкции для ещё каких-нибудь программ, работающих в других контейнерах.
Благодаря использованию Docker можно, на одном и том же компьютере, одновременно запускать множество контейнеров. И, как и любые другие программы, контейнеры Docker можно запускать, останавливать, удалять. Можно исследовать их содержимое и создавать их.
Концепции Docker
▍Виртуальные машины
Предшественниками контейнеров Docker были виртуальные машины. Виртуальная машина, как и контейнер, изолирует от внешней среды приложение и его зависимости. Однако контейнеры Docker обладают преимуществами перед виртуальными машинами. Так, они потребляют меньше ресурсов, их очень легко переносить, они быстрее запускаются и приходят в работоспособное состояние. В этом материале можно найти подробное сравнение контейнеров и виртуальных машин.
▍Образ контейнера Docker
Выше мы уже говорили об «образах». Что это такое? Хороший вопрос. То, что в терминологии Docker называется «образом», или, по-английски, «image», это совсем не то же самое, что, например, фотография (это — одно из значений слова «image»).
Образы Docker — это не фотографии
Образы контейнеров Docker можно сравнить с чертежами, с формочками для печенья, или с пресс-формами для изготовления пластиковых изделий. Образы — это неизменные шаблоны, которые используются для создания одинаковых контейнеров.
Образы контейнеров Docker похожи на формочки для печенья
В образе контейнера Docker содержится образ базовой операционной системы, код приложения, библиотеки, от которого оно зависит. Всё это скомпоновано в виде единой сущности, на основе которой можно создать контейнер.
▍Файл Dockerfile
Файл Dockerfile содержит набор инструкций, следуя которым Docker будет собирать образ контейнера. Этот файл содержит описание базового образа, который будет представлять собой исходный слой образа. Среди популярных официальных базовых образов можно отметить python, ubuntu, alpine.
И, наконец, в образе может содержаться, поверх всех остальных, ещё один тонкий слой, данные, хранящиеся в котором, поддаются изменению. Это — небольшой по объёму слой, содержащий программу, которую планируется запускать в контейнере.
▍Контейнер Docker
▍Репозиторий контейнеров
Если вы хотите дать возможность другим людям создавать контейнеры на основе вашего образа, вы можете отправить этот образ в облачное хранилище. Самым крупным подобным хранилищем является репозиторий Docker Hub. Он используется при работе с Docker по умолчанию.
Мы уже довольно много всего обсудили. Пришло время собрать всё это вместе и сравнить работу с контейнерами Docker с приготовлением пиццы.
Готовим с Docker
Готовая пицца — это контейнер
Духовка — это платформа Docker
Духовка, в которой готовится пицца, напоминает платформу Docker. Духовку устанавливают на кухне, с её помощью можно готовить еду. Точно так же Docker устанавливают на компьютере для того, чтобы «готовить» контейнеры.
Духовку, если она электрическая, включают, поворачивая ручку регулятора температуры. Команда docker run image_name — это нечто вроде такого регулятора температуры, «поворот» которого приводит к тому, что система создаёт и запускает контейнер.
Готовая пицца — это и есть контейнер Docker.
А есть пиццу — значит пользоваться приложением, запущенным в контейнере.
Как и приготовление пиццы, подготовка к работе контейнеров Docker занимает некоторое время, но в финале и в том и в другом случаях получается что-то вкусное.
Итоги
Здесь мы, на концептуальном уровне, рассмотрели основы Docker. Надеемся, приведённые здесь сравнения помогли вам разобраться в том, что такое Docker, и ощутить ценность метафор в деле освоения новых технологий.
Уважаемые читатели! Эта публикация представляет собой перевод первой статьи из серии учебных материалов по Docker. По словам автора, всего планируется выпустить 5 таких материалов. Уже готовы вторая, третья и четвёртая части. Подскажите нам, стоит ли переводить следующие статьи этой серии?
Docker самый простой и понятный туториал. Изучаем докер, так, если бы он был игровой приставкой
Добро пожаловать в гайд по изучению Docker, в котором я проиллюстрирую вам совершенно иной подход при разработке ваших приложений с его помощью. Эту статью вы можете считать как быстрый старт, введение в Docker.
Когда вы полностью прочитаете эту статью, уверен, вы поймёте, что такое Docker, для чего нужен, и где используется.
Когда я наконец-то понял все тонкости работы с Docker (на полное изучение которого ушло несколько месяцев), и начал правильно применять его при разработке (а он как раз и нужен для разработки, в большей степени), то почувствовал, как будто обрёл какую-то сверхспособоность. Смотря на свой опыт изучения Докера, я понял, что мне есть что рассказать, и чем поделиться. В этой статье я постарался создать максимально понятную для новичков инструкцию, благодаря которой вы сможете полностью изучить Docker за 30 минут. Я долго думал о том, чтобы написать туториал, и наконец-то осилил эту задачу, и, как мне кажется, получилось неплохо 🙂
Эта инструкция так же подходит для тех, кто не имеет никаких знаний, или опыта работы с докером, или аналогичным программным обеспечением. Вы получите все важные знания, необходимые для работы. Статья построена по принципу от простого к сложному. В итоге статьи вы будете чётко понимать, что такое Docker, зачем нужен, как с ним работать, и применять его для разработки: создавать окружение, необходимое для создания вашего приложения.
Эта статья, в больше мере, нацелена на получение практических знаний, и только немного теории, построенной на аналогиях из жизни. Потому, эта статья имеет окрас веселья и лайтовости, в большей мере, чем супер-конкретики и теоретических нюансов.
Так же, прошу заметить, если вы используете Vagrant, и решите установить Docker, то Vagrant перестанет работать. Такая жизнь, но с этим можно смириться, тем более, субъективно, Docker круче ^^.
Что вы узнаете из этой статьи
Что такое Docker
О том, как появился Docker:
Но, что это на самом деле значит?
Давайте на секунду забудем про Докер, и вспомним про такую ностальгическую штуку, как GameBoy Color :
Если вы помните, игры для этой приставки поставлялись в виде картриджей:
И я уверен в том, что производители видео игр пользуются успехом из-за своей простоты:
Раньше, вы, создавая приложения, к примеру на PHP, устанавливали локально PHP, MySql, возможно, NodeJs, при этом устанавливая зависимости в виде нужных расширений и библиотек. И, в случае передачи вашего скрипта какому-то знакомому, ему требовалось настраивать аналогичное окружение, аналогичных версий, иметь аналогичные расширения и конфигурацию, чтобы успешно запустить ваше приложение.
Сейчас же, при использовании Докера, такой проблемы не возникнет впринципе. Теперь вам достаточно иметь установленную программу Docker, которая по одной вашей команде установит окружение, описанное в конфиге для запуска вашего приложения.
Какое программное обеспечение можно запустить с помощью докера? В техническом плане, Docker чем-то похож на виртуальную машину:
Docker позволяет запустить ОС Linux в изолированной среде очень быстро, в течение нескольких минут.
Зачем использовать Docker?
Кошмар при установке ПО, с которым приходится сталкиваться. У вас когда-нибудь было такое, что вы пытаетесь установить ПО на ваш компьютер, а оно отказывается работать? Вы получаете несколько непонятных вам ошибок, из-за которых ничего не запускается. И после нескольких часов гугления, на десятой странице гугла. и на каком-то форуме, до этого неизвестного вам, вы наконец-то находите случайный комментарий, который помогает исправить вашу проблему.
Docker спасёт нас. Docker, как и Game Boy приставка, берёт стандартизированные части программного обеспечения и запускает их так, как Game Boy запускал бы игру.
Как разработчик, теперь вы не должны волноваться о том, на какой системе будет запущено ваше приложение.
Как пользователь, вам не нужно волноваться о том, что вы скачаете неподходящую версию ПО (нужного для работы программы). В Докере эта программа будет запущена в аналогичных условиях, при которых это приложение было разработано, потому, исключается факт получить какую-то новую, непредвиденную ошибку.
Для пользователя все действия сводятся к принципу подключи и играй.
Установка Docker
Docker предоставляет 2 сборки:
После установки потребуется перезагрузка системы, и уже можно начинать полноценно работать с Докером.
docker-compose (вывод обеих команд будет примерно одинакового содержания).
Если вы используете Linux, то, docker-compose нужно будет устанавливать отдельно по инструкции.
Что такое Docker Image?
Рассмотрим пример скачивания нашего первого образа.
Зная эту команду, скачаем образ Ubuntu 18.10 :
Это как поездка за новым картриджем в магазин, только намного быстрее :).
Теперь, для того, чтобы посмотреть список всех загруженных образов, нужно выполнить:
Проводя аналогии, команда docker images выглядит как коллекция картриджей от приставки, которые у вас есть сейчас:
Что такое Docker контейнер?
А сам образ игры никак не модифицируется, все файлы, содержащие изменения хранятся где-то локально на приставке.
Запуск Docker контейнера соответствует тому, что вы играете в свою Gamecube игру. Docker запускает ваш образ в своей среде, аналогично тому, как Gamecube запускает игру с диска, не модифицируя оригинальный образ, а лишь сохраняя изменения и весь прогресс в какой-то песочнице.
Для запуска контейнера существует команда:
Давайте запустим наш первый контейнер Ubuntu: 
Команда echo ‘hello from ubuntu’ была выполнена внутри среды Ubuntu. Другими словами, эта команда была выполнена в контейнере ubuntu:18.10.
Теперь выполним команду для проверки списка запущенных контейнеров: 
Здесь пустота. это потому что docker ps показывает только список контейнеров, которые запущены в данный момент (наш же контейнер выполнил одну команду echo ‘hello from ubuntu’ и завершил свою работу).
Выполнение неограниченное количество команда внутри контейнера
Давайте добавим немного интерактивности в наше обучение. Мы можем подключиться к консоли виртуальной ОС ( Ubuntu 18.10 ), и выполнять любое количество команд без завершения работы контейнера, для этого, запустим команду:
Узнаём ID контейнера
Docker контейнер является полностью независимым от системы хоста, из которой он запускался. Как изолированная виртуальная машина. И в ней вы можете производить любые изменения, которые никак не повлияют на основную операционную систему.
Контейнер является полностью независимым и изолированным от основной операционной системы, аналогично виртуальной операционной системе. Вы можете вносить любые изменения внутри виртуалки, и никакие из этих изменений не повлияют на основную операционную систему.
Теперь откройте новое окно терминала (не закрывая и не отключаясь от текущего), и выполните команду docker ps 
Только на этот раз вы можете увидеть, что контейнер с Ubuntu 18.10 в текущий момент запущен.
Теперь вернёмся назад к первому окну терминала (который находится внутри контейнера), и выполним:
В моём случае, CONTAINER_ID последнего контейнера = 7579c85c8b7e (у вас же, он будет отличаться)
Запустим контейнер командой:
Теперь остановим и удалим Docker контейнеры командами:
docker stop
docker rm
Что такое DockerFile?
Docker позволяет вам делиться с другими средой, в которой ваш код запускался и помогает в её простом воссоздании на других машинах.
К примеру, если вы разрабатывали приложение на php7.2, и использовали ElasticSearch 9 версии, и сохранили это в Dockerfile-е, то другие пользователи, которые запустят образ используя ваш Dockerfile, получат ту же среду с php7.2 и ElasticSearch 9.
С Dockerfile вы сможете подробно описать инструкцию, по которой будет воссоздано конкретное состояние. И делается это довольно-таки просто и интуитивно понятно.
Представьте, что вы играете в покемонов
Вы пытаетесь пройти первый уровень, но безрезультатно. И я, как ваш друг, хочу с этим помочь. У меня есть 2 таблетки варианта:
Инструкция прохождения первого уровня
Что является более полезным? Я склоняюсь, что это второй вариант. Потому что он демонстрирует, как добиться желаемого состояния. Это не просто чёрный ящик, который переносит игру на второй уровень.
С докером вы так же имеете два варианта при создании образа:
Я склоняюсь ко второму варианту, потому что он более подробный, гибкий, и редактируемый (вы можете переписать Dockerfile, но не можете перемотать состояние образа в случае прямых изменений).
Пришло время попрактиковаться на реальном примере. Для начала, создадим файл cli.php в корне проекта с содержимым:
Для просмотра полного списка команд можете перейти по ссылке
При написании Dockerfile, начинать следует с наиболее актуального существующего образа, дополняя его в соответствии с потребностями вашего приложения.
К примеру, мы могли не использовать образ php:7.2-cli, а могли взять ubuntu:18.10, последовательно выполняя команды в RUN одна за одной, устанавливая нужное ПО. Однако, в этом мало смысла, когда уже есть готовые сборки.
Теперь, запустим контейнер из нашего образа командой docker run pyramid 
Круто! Shell скрипт был успешно скопирован, и выполнен благодаря указанному в Dockerfile параметру CMD.
Однако, сейчас этот контейнер недостаточно гибкий. Нам бы хотелось, чтобы можно было удобно изменять количество строк, из скольки состоит пирамида.
Для этого, отредактируем файл cli.php, и изменим, чтобы количество аргументов принималось из командной строки. Отредактируем вторую строку на:
Почему это работает?
Когда контейнер запускается, вы можете переопределить команду записанную в Dockerfile в поле CMD.
Для этого, дополним Dockerfile:
Мы немного поменяли формат записи. В таком случае, CMD будет добавлена к тому, что выполнится в ENTRYPOINT.
Теперь, заново пересоберём образ
И запустим контейнер с желаемым аргументом
Монтирование локальной директории в Docker-контейнер
Когда игра читает файлы сохранений, файловая система Game Cube внедряет их в текущий сеанс игры (представим это, даже если это не так). Игра может изменять файл сохранений, и это изменение отразится на файловой системе Game Cube, т.е. возникает двусторонняя связь.
Монтирование директории в контейнер позволяет ему читать и писать данные в эту директорию, изменяя её состояние.
При выполнении этой команды, указанная папка смонтируется в папку /mounted, внутри файловой системы контейнера, а команда touch mounted/testfile создаст новый файл под названием testfile, который вы можете увидеть из основной ОС.
Монтирование папки позволяет вам изменять файлы вашей основной системы прямо во время работы внутри Docker контейнера.
Это удобная особенность, которая позволяет нам редактировать код в редакторе на основной ОС, а изменения будут сразу же применяться внутри контейнера.
Что такое Docker Volumes?
Вы можете вставить вашу карту внутрь приставки, точно так же, как и Docker Volume может быть прикреплён к любому из контейнеров.
С Docker Volum-ами мы имеем контейнер, который хранит постоянные данные где-то на нашем компьютере (это актуально, потому что после завершения работы контейнер удаляет все пользовательские данные, не входящие в образ). Вы можете прикрепить Volume-данные к любому из запущенных контейнеров.
Вместо того, чтобы каждый раз, при запуске контейнера, писать, какие из папок вы хотите смонтировать, вы просто можете создать один контейнер с общими данными, который потом будете прикреплять.
Лично я, не использую это очень часто на практике, потому что есть много других методов по управлению данными. Однако, это может быть очень полезно для контейнеров, которые должны сохранять какие-то важные данные, или данные, которыми нужно поделиться между несколькими контейнерами.
Порты контейнеров
Docker позволяет нам получить доступ к какому-то из портов контейнера, пробросив его наружу (в основную операционную систему). По умолчанию, мы не можем достучаться к каким-либо из портов контейнера. Однако, в Dockerfile опция EXPOSE позволяет нам объявить, к какому из портов мы можем обратиться из основной ОС.
Для этого, на по-быстрому, запустим Docker-образ php-apache, который работает на 80 порту.
А так же, в этой папке создадим файл Dockerfile :
Пробежимся по командам:
FROM: это вам уже знакомо, это образ с уже установленным php и apache
WORKDIR: создаст папку если она не создана, и перейдёт в неё. Аналогично выполнению команд mkdir /var/www/html && cd /var/www/html
EXPOSE: Apache по-умолчанию запускается на 80 порту, попробуем «прокинуть» его в нашу основную ОС (посмотрим как это работает через несколько секунд)
Для работы с сетью в Docker, нужно проделать 2 шага:
Это что-то похоже на подключение вашей PS4 приставки к телевизору по HDMI кабелю. При подключении кабеля, вы явно указываете, какой HDMI-канал будет отображать видео.
Выполним первый шаг прокидывания порт. Сбилдим контейнер:
И после этого, запустим контейнер:
После чего, попробуем перейти по адресу localhost:80
Но, это не сработало, потому что мы ещё не выполнили 2 шаг по маппингу портов.
Выйдите из контейнера, нажав CTRL+C.
Теперь, осталось сообщить нашему компьютеру, какой порт контейнера ему нужно слушать, и для этого формат записи будет такой:
И мы можем указать любое соответствие портов, но сейчас просто укажем, что порт системы 80 будет слушать 80 порт контейнера:
И теперь, если перейти по адресу localhost:80, то должны увидеть успешный ответ: 
Оказывается, это даже легче, чем подключение HDMI-кабеля. Сейчас, можем попробовать выполнить запуск на разных портах: 
Теперь, немного подчистим за собой: нужно остановить и удалить контейнеры, которые в даный момент мы запустили:
Для *nix пользователей есть небольшой хак, который позволит остановить и удалить все контейнеры Docker:
Docker образ: прослойка данных и кеширование
Docker умнее, чем вы могли бы подумать :).
Каждый раз, когда вы собираете образ, он кешируется в отдельный слой. Ввиду того, что образы являются неизменяемыми, их ядро никогда не модифицируются, потому применяется система кеширования, которая нужна для увеличения скорости билдинга.
Каждая команда в Dockerfile сохраняется как отельный слой образа.
Рассмотрим это на примере нашего прошлого Dockerfile-а:
Когда вы пишите свой Dockerfile, вы добавляете слои поверх существующего основного образа (указанного в FROM), и создаёте свой собственный образ (Image).
FROM: говорит Докеру взять за основу этот существующий образ. А все новые команды будут добавлены слоями поверх этого основного образа.
COPY: копирует файлы с основной ОС в образ
WORKDIR: устанавливает текущую папку образа в /var/www/html
Слой Образа Докера это как точка сохранения в игре Super Mario. Если вы хотите изменить какие-то вещи, произошедшие до этой точки сохранения, то вам придётся перезапустить этот уровень полностью. Если вы хотите продолжить прогресс прохождения, вы можете начать с того места, где остановились.
Для иллюстрации этого, добавим новые строки в Dockerfile:
После чего, пересоберём образ:
Выполнив эту команду, из вывода в консоль можете увидеть, что некоторые слои были взяты из кеша. Это как раз те команды, выше которых в Dockerfile не было добавлено/изменено содержимого.
И можно заметить, что в случае изменения Dockerfile, билдинг занимает больше времени, потому что не используется кеш. Где бы вы не написали команду, все закешированные команды, которые находятся ниже в Dockerfile, будут перебилжены заново. А те, что находятся выше, будут по-прежнему браться из кеша.
Если честно, то это действительно крутая функция. Docker следит за изменениями в файлах и использует кеш всегда, когда это нужно (когда были произведены изменения в каких-то из файлов). Изменение ваших файлов потенциально может затрагивать будущие команды, из-за чего, и все последующие слои билдятся заново, а не берутся из кеша.
Какие выводы из этого можно сделать:
В заключение, так же хочу сказать, как можно уменьшить размер слоёв Docker образов.
В Dockerfile вы можете иметь несколько команд (RUN) на выполнение:
В результате выполнения этой команды, будет создано 3 разных слоя в образе. Вместо этого, все команды стараются объединить в одну строку:
Если команда становится длинной, и нечитаемой, то для переноса на следующую строку делаем так:
Технически, только команды ADD, COPY, и RUN создают новый слой в Docker образе, остальные команды кешируются по-другому
Что такое Docker-Compose?
Docker Compose управляет контейнерами, запускает их вместе, в нужной последовательности, необходимой для вашего приложения.
Его можно назвать дирижёром в мире Docker-а.
Docker-compose организовывает совместных запуск контейнеров, как инструменты в групповой игре в определённых участках песни.
Каждый инструмент имеет конкретную задачу в группе оркестра. Труба создаёт основную мелодию песни; фортепиано, гитара дополняют основную мелодию; барабаны задают ритм; саксофоны добавляют больше гармонии и т.д.
Каждый из инструментов имеет свою конкретную работу и задачу, как и наши контейнеры.
Docker-compose написан в формате YAML который по своей сути похож на JSON или XML. Но YAML имеет более удобный формат для его чтения, чем вышеперечисленные. В формате YAML имеют значения пробелы и табуляции, именно пробелами отделяются названия параметров от их значений.
Мы можем использовать этот файл для билдинга нашего предыдущего образа apache:
После выполнения этой команды, Docker спарсит файл docker-compose и создаст описанные сервисы на основе инструкций во вкладке build.
И теперь, запустим эти сервисы, которые создали:
В результате чего, сервер должен был запуститься, и стать доступным по адресу localhost:8080.
Теперь, отключитесь от консоли, нажав CTRL+C.
С docker-compose.yml мы переносим все параметры, ранее записываемые в командной строке при запуске контейнера в конфигурационный YAML файл.
Добавленная строка примонтирует текущую директорию основой операционной системы к директории /var/www/html контейнера.
Теперь, выполните по очереди команды:
При удалении, вас спросят, действительно ли удалять, напишите y и нажмите кнопку enter. Эти команды остановят и удалят все контейнеры, описанные в файле docker-compose.yml (то же самое, как мы ранее запускали docker stop и docker rm )
Теперь перебилдим сервисы, потому что мы изменили Dockerfile:
И опять, по адресу localhost:8080 поднимется наш сервер.
Вместо того, чтобы копировать каждый раз файлы в образ, мы просто примонтировали папку, содержащую исходный код приложения. И теперь, каждый раз не придётся делать ребилд образа, когда файлы изменяются, теперь изменения происходят в лайв режиме, и будут доступны без перестройки образа.
Чтобы в этом убедиться, изменим файл index.php, добавим в него скрипт нами любимой пирамиды:
И теперь, если перейти по адресу localhost:8080?count=10, то увидим, что пирамида выводится: 
Монтирование вашей локальной папки как Docker Volume это основной метод как разрабатывать приложения в контейнере.
где, вместо
а вместо
К примеру, эта команда может выглядеть так:
Но, сделаем это на основе текущего Dockerfile:
И в результате должны получить 
Пока что, в docker-compose.yml описан только один сервис, потому разворачиваем мы только один контейнер. Но реальный файл docker-compose выглядит больше. К примеру, для Laravel он такой:
Как писать Микро Сервисы с Docker? Что такое микросервисы?
Ниже я постараюсь кратко описать, что такое микросервисы:
Одиночный миросервис выполняет одну конкретнкую задачу. Он никак не связан с другими существующими микросервисами. Вместе же, микросервисы образуют приложение.
Микросервис должен выполнять свою задачу в изолированной среде, управлять своей собственной локальной информацией, и быть независимым от общей системы настолько, насколько это возможно. В основном, каждый из микросервисов имеет собственную, отдельную базу данных (если она нужна).
Это позволяет создавать максимально гибкие и легко масштабируемые приложения.
Идея разделения по ответственности предоставляет преимущество в том, что команда разработчиков может работать параллельно, фокусируясь над разными компонентами.
В основном, микросервисы имеют канал коммуникации мужду собой, в виде REST API, который возвращает данные в JSON, или что-то типа того.
Иногда бывает неясно, насколько большой, или маленькой должна быть задача микросервиса, которую он должен решать. Это решение лежит на плечах разработчика, здесь нет чёткого правила.
Использование микросервисов позволяет быстро масшабироваться под большой нагрузкой, без масшабирования остальных частей вашего приложения. То есть, такая архитектура позволяет вам масшабировать систему компонентно, там, где это требуется. В случае монолитной, единой системы, вам придётся масшабировать всё приложение.
Ввиду того, что статья и так получилась достаточно большой, то пример реализации микросервисной архитектуры я покажу в следующей статье на эту тему. Я принял решение подготовить более качественный материал на эту тему вместе с примерами кода.
Резюме
Я попытался написать эту статью максимально просто, построив всё объяснение на аналогиях и примерах их жизни. Эта статью можно считать простой инструкцией по работе с Docker. Помимо того, что я описал, как пользоваться Docker-ом, добавив несколько рабочих примеров, которые вы можете попробовать у себя на компьютере, я добавил много дополнительной информации, и некоторых тонкостей работы с Docker-ом. Надеюсь, что эта статья показала вам, что такое Docker, и с чем его едят. В следующей статья я затрону более продвинутые темы и приведу примеры.
Subscribe to Блог php программиста: статьи по PHP, JavaScript, MySql
Get the latest posts delivered right to your inbox