Выбор linux для docker
Обновлено: 07.07.2024
Docker — это приложение, упрощающее процесс управления процессами приложения в контейнерах. Контейнеры позволяют запускать приложения в процессах с изолированными ресурсами. Они похожи на виртуальные машины, но более портативные, более эффективно расходуют ресурсы и в большей степени зависят от операционной системы хоста.
Подробное описание различных компонентов контейнера Docker см. в статье Экосистема Docker: знакомство с базовыми компонентами.
В этом обучающем модуле мы установим и начнем использовать Docker Community Edition (CE) на сервере Ubuntu 20.04. Вы самостоятельно установите Docker, поработаете с контейнерами и образами и разместите образ в репозитории Docker.
Предварительные требования
Для выполнения этого руководства вам потребуется следующее:
- Один сервер Ubuntu 20.04, настроенный в соответствии с руководством по начальной настройке сервера Ubuntu 20.04, включая пользователя non-root user с привилегиями sudo и брандмауэр.
- Учетная запись на Docker Hub, если вы хотите создавать собственные образы и загружать их на Docker Hub, как показано в шагах 7 и 8.
Шаг 1 — Установка Docker
Пакет установки Docker, доступный в официальном репозитории Ubuntu, может содержать не самую последнюю версию. Чтобы точно использовать самую актуальную версию, мы будем устанавливать Docker из официального репозитория Docker. Для этого мы добавим новый источник пакета, ключ GPG от Docker, чтобы гарантировать загрузку рабочих файлов, а затем установим пакет.
Первым делом обновите существующий список пакетов:
Добавьте ключ GPG для официального репозитория Docker в вашу систему:
Добавьте репозиторий Docker в источники APT:
Потом обновите базу данных пакетов и добавьте в нее пакеты Docker из недавно добавленного репозитория:
Убедитесь, что установка будет выполняться из репозитория Docker, а не из репозитория Ubuntu по умолчанию:
Вы должны получить следующий вывод, хотя номер версии Docker может отличаться:
Обратите внимание, что docker-ce не установлен, но является кандидатом на установку из репозитория Docker для Ubuntu 20.04 (версия focal ).
Docker должен быть установлен, демон-процесс запущен, а для процесса активирован запуск при загрузке. Проверьте, что он запущен:
Вывод должен выглядеть примерно следующим образом, указывая, что служба активна и запущена:
После установки Docker у вас будет доступ не только к службе Docker (демон-процесс), но и к утилите командной строки docker или клиенту Docker. Мы узнаем, как использовать команду docker позже в этом обучающем руководстве.
Шаг 2 — Настройка команды Docker без sudo (необязательно)
По умолчанию команда docker может быть запущена только пользователем root или пользователем из группы docker, которая автоматически создается при установке Docker. Если вы попытаетесь запустить команду docker без префикса sudo или с помощью пользователя, который не находится в группе docker, то получите следующий вывод:
Если вы не хотите каждый раз вводить sudo при запуске команды docker , добавьте свое имя пользователя в группу docker :
Чтобы применить добавление нового члена группы, выйдите и войдите на сервер или введите следующее:
Вы должны будете ввести пароль вашего пользователя, чтобы продолжить.
Проверьте, что ваш пользователь добавлен в группу docker, введя следующее:
Если вам нужно добавить пользователя в группу docker , для которой вы не выполнили вход, объявите имя пользователя явно, используя следующую команду:
В дальнейшем в статье подразумевается, что вы запускаете команду docker от имени пользователя в группе docker. В обратном случае вам необходимо добавлять к командам префикс sudo .
Давайте перейдем к знакомству с командой docker .
Шаг 3 — Использование команды Docker
Использование docker подразумевает передачу ему цепочки опций и команд, за которыми следуют аргументы. Синтаксис имеет следующую форму:
Чтобы просмотреть все доступные субкоманды, введите:
Для 19-й версии Docker полный список субкоманд выглядит следующим образом:
Чтобы просмотреть параметры, доступные для конкретной команды, введите:
Чтобы просмотреть общесистемную информацию о Docker, введите следующее:
Давайте изучим некоторые из этих команд. Сейчас мы начнем работать с образами.
Шаг 4 — Работа с образами Docker
Контейнеры Docker получают из образов Docker. По умолчанию Docker загружает эти образы из Docker Hub, реестр Docker, контролируемые Docker, т.е. компанией, реализующей проект Docker. Любой может размещать свои образы Docker на Docker Hub, поэтому большинство приложений и дистрибутивов Linux, которые вам потребуется, хранят там свои образы.
Чтобы проверить, можно ли получить доступ к образам из Docker Hub и загрузить их, введите следующую команду:
Данный вывод говорит о том, что Docker работает корректно:
Вы можете выполнять поиск доступных на Docker Hub с помощью команды docker с субкомандой search . Например, чтобы найти образ Ubuntu, введите:
Скрипт пробежится по Docker Hub и вернет список всех образов с именами, совпадающими со строкой запроса. В данном случае вывод будет выглядеть примерно следующим образом:
В столбце OFFICIAL OK указывает на образ, созданный и поддерживаемый компанией, реализующей проект. После того как вы определили образ, который хотели бы использовать, вы можете загрузить его на свой компьютер с помощью субкоманды pull .
Запустите следующую команду, чтобы загрузить официальный образ ubuntu на свой компьютер:
Вывод должен выглядеть следующим образом:
После того как образ будет загружен, вы сможете запустить контейнер с помощью загруженного образа с помощью субкоманды run . Как вы уже видели на примере hello-world , если образ не был загружен, когда docker выполняется с субкомандой run , клиент Docker сначала загружает образ, а затем запускает контейнер с этим образом.
Чтобы просмотреть образы, которые были загружены на ваш компьютер, введите:
Вывод команды должен выглядеть примерно следующим образом:
Как вы увидите далее в этом обучающем руководстве, образы, которые вы используете для запуска контейнеров, можно изменить и использовать для создания новых образов, которые затем могут быть загружены (помещены) на Docker Hub или другие реестры Docker.
Давайте более подробно рассмотрим, как запускаются контейнеры.
Шаг 5 — Запуск контейнеров Docker
В качестве примера мы запустим контейнер с самым последним образом образ Ubuntu. Сочетание переключателей -i и -t предоставляет вам доступ к интерактивной командной оболочке внутри контейнера:
Необходимо изменить приглашение к вводу команды, чтобы отразить тот факт, что вы работаете внутри контейнера, и должны иметь следующую форму:
Обратите внимание на идентификатор контейнер в запросе команды. В данном примере это d9b100f2f636 . Вам потребуется этот идентификатор для определения контейнера, когда вы захотите его удалить.
Теперь вы можете запустить любую команду внутри контейнера. Например, сейчас мы обновим базу данных пакетов внутри контейнера. Вам не потребуется начинать любую команду с sudo , потому что вы работаете внутри контейнера как root-пользователь:
После этого вы можете установите любое приложение внутри контейнера. Давайте установим Node.js:
Эта команда устанавливает Node.js внутри контейнера из официального репозитория Ubuntu. После завершения установки проверьте, что Node.js был установлен успешно:
Вы увидите номер версии, отображаемый в терминале:
Любые изменения, которые вы вносите внутри контейнера, применяются только к контейнеру.
Чтобы выйти из контейнера, введите exit .
Далее мы рассмотрим управление контейнерами в нашей системе.
Шаг 6 — Управление контейнерами Docker
После использования Docker в течение определенного времени, у вас будет много активных (запущенных) и неактивных контейнеров на компьютере. Чтобы просмотреть активные, используйте следующую команду:
Вывод будет выглядеть примерно следующим образом:
В этом обучающем руководстве вы запустили два контейнера: один из образа hello-world и другой из образа ubuntu . Оба контейнера больше не запущены, но все еще существуют в вашей системе.
Чтобы просмотреть все контейнеры — активные и неактивные, воспользуйтесь командой docker ps с переключателем -a :
Вывод будет выглядеть следующим образом:
Чтобы просмотреть последний созданный вами контейнер, передайте переключатель -l :
Чтобы запустить остановленный контейнер, воспользуйтесь docker start с идентификатором контейнера или именем контейнера. Давайте запустим контейнер на базе Ubuntu с идентификатором 1c08a7a0d0e4 :
Контейнер будет запущен, а вы сможете использовать docker ps , чтобы просматривать его статус:
Чтобы остановить запущенный контейнер, используйте docker stop с идентификатором или именем контейнера. На этот раз мы будем использовать имя, которое Docker присвоил контейнеру, т.е. quizzical_mcnulty :
После того как вы решили, что вам больше не потребуется контейнер, удалите его с помощью команды docker rm , снова добавив идентификатор контейнера или его имя. Используйте команду docker ps -a , чтобы найти идентификатор или имя контейнера, связанного с образом hello-world , и удалить его.
Вы можете запустить новый контейнер и присвоить ему имя с помощью переключателя --name . Вы также можете использовать переключатель --rm , чтобы создать контейнер, который удаляется после остановки. Изучите команду docker run help , чтобы получить больше информации об этих и прочих опциях.
Контейнеры можно превратить в образы, которые вы можете использовать для создания новых контейнеров. Давайте посмотрим, как это работает.
Шаг 7 — Внесение изменений в контейнер для образа Docker
После запуска образа Docker вы можете создавать, изменять и удалять файлы так же, как и с помощью виртуальной машины. Эти изменения будут применяться только к данному контейнеру. Вы можете запускать и останавливать его, но после того как вы уничтожите его с помощью команды docker rm , изменения будут утрачены навсегда.
Данный раздел показывает, как сохранить состояние контейнера в виде нового образа Docker.
После установки Node.js внутри контейнера Ubuntu у вас появился контейнер, запускающий образ, но этот контейнер отличается от образа, который вы использовали для его создания. Но позже вам может снова потребоваться этот контейнер Node.js в качестве основы для новых образов.
Затем внесите изменения в новый экземпляр образа Docker с помощью следующей команды.
Например, для пользователя sammy с идентификатором контейнера d9b100f2f2f6 команда будет выглядеть следующим образом:
Когда вы вносите образ, новый образ сохраняется локально на компьютере. Позже в этом обучающем руководстве вы узнаете, как добавить образ в реестр Docker, например, на Docker Hub, чтобы другие могли получить к нему доступ.
Список образов Docker теперь будет содержать новый образ, а также старый образ, из которого он будет получен:
Вывод будет выглядеть следующим образом:
В данном примере ubuntu-nodejs является новым образом, который был получен из образа ubuntu на Docker Hub. Разница в размере отражает внесенные изменения. В данном примере изменение состояло в том, что NodeJS был установлен. В следующий раз, когда вам потребуется запустить контейнер, использующий Ubuntu с предустановленным NodeJS, вы сможете использовать новый образ.
Вы также можете создавать образы из Dockerfile , что позволяет автоматизировать установку программного обеспечения в новом образе. Однако это не относится к предмету данного обучающего руководства.
Теперь мы поделимся новым образом с другими, чтобы они могли создавать из него контейнеры.
Шаг 8 — Загрузка образов Docker в репозиторий Docker
Следующим логическим шагом после создания нового образа из существующего является предоставление доступа к этому образу нескольким вашим друзьям или всему миру на Docker Hub или в другом реестре Docker, к которому вы имели доступ. Чтобы добавить образ на Docker Hub или любой другой реестр Docker, у вас должна быть там учетная запись.
Данный раздел посвящен добавлению образа Docker на Docker Hub. Чтобы узнать, как создать свой собственный частный реестр Docker, ознакомьтесь со статьей Настройка частного реестра Docker на Ubuntu 14.04.
Чтобы загрузить свой образ, выполните вход в Docker Hub.
Вам будет предложено использовать для аутентификации пароль Docker Hub. Если вы указали правильный пароль, аутентификация должна быть выполнена успешно.
Примечание. Если ваше имя пользователя в реестре Docker отличается от локального имени пользователя, которое вы использовали при создании образа, вам потребуется пометить ваш образ именем пользователя в реестре. Для примера, приведенного на последнем шаге, вам необходимо ввести следующую команду:
Затем вы можете загрузить свой образ с помощью следующей команды:
Чтобы загрузить образ ubuntu-nodejs в репозиторий sammy, необходимо использовать следующую команду:
Данный процесс может занять некоторое время, необходимое на загрузку образов, но после завершения вывод будет выглядеть следующим образом:
После добавления образа в реестр он должен отображаться в панели вашей учетной записи, как на изображении ниже.
Если при попытке добавления возникает подобная ошибка, вы, скорее всего, не выполнили вход:
Выполните вход с помощью команды docker login и повторите попытку загрузки. Проверьте, появился ли образ на вашей странице репозитория Docker Hub.
Теперь вы можете использовать docker pull sammy / ubuntu-nodejs , чтобы загрузить образ на новый компьютер и использовать его для запуска нового контейнера.
Заключение
В этом обучающем руководстве вы установили Docker, поработали с образами и контейнерами, а также добавили измененный образ на Docker Hub. После знакомства с основами, вы можете переходить к другим обучающим руководствам Docker в сообществе.
Сборка образов для 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 в сборочный образ на время сборки. Но с этим решением есть проблемы:
- Не любая программа, нужная для сборки, устанавливается в отдельный каталог, который легко примонтировать в сборочный образ. В случае с Ansible надо монтировать Python в нестандартное место, чтобы не конфликтовать с системным Python, что уже может вызывать проблемы.
- Примонтированная программа будет зависеть от используемого базового образа. Если программа собрана для Ubuntu, то она может не запуститься в не предусмотренном для нее окружении — например, в Alpine. Даже chefdk, который является omnibus-пакетом со всеми своими зависимостями, все равно зависит от системного glibc и не будет работать в Alpine, где используется musl libc.
В поисках приключений
Теория
Необходимо получить образ, в котором содержится набор программ в некоторой статически определенной нестандартной директории — например, /myutils . Любая программа в /myutils должна зависеть только от библиотек в /myutils .
Динамически скомпилированная программа в 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/ .
Первым шагом будет сборка образа toolchain , который будет содержать всё, что необходимо для сборки и последующей работы других программ в нестандартной root-директории. Для этого нам как нельзя кстати придутся инструкции проекта Linux From Scratch.
Собираем дистрибутив dappdeps
Почему набор образов нашего «дистрибутива» называется dappdeps? Потому что эти образы использует сборщик dapp — они собираются под нужды этого проекта.
Итак, наша конечная цель:
- Образ dappdeps/toolchain с компилятором GCC для сборки других приложений и библиотекой glibc.
- Образ dappdeps/base с набором программ и всех зависимых библиотек: bash, gtar, sudo, coreutils, findutils, diffutils, sed, rsync, shadow, termcap.
- Образ dappdeps/gitartifact с утилитой Git и всеми зависимостями.
- Образ dappdeps/chefdk с omnibus-пакетом chefdk, который содержит все зависимости Chef, в т.ч. интерпретатор Ruby.
- Образ dappdeps/ansible с утилитой Ansible, который содержит все зависимости, в т.ч. интерпретатор Python.
Главное условие заключается в том, чтобы утилиты из этих образов располагались в нестандартном месте, а именно — в /.dapp/deps/ , и не зависели ни от каких утилит или библиотек в стандартных системных путях. Также в dappdeps-образах не должно быть никаких других файлов, кроме /.dapp/deps .
Такие образы позволят создавать на их основе контейнеры с томами, где содержатся утилиты, и монтировать их в другие контейнеры с использованием опции --volumes-from для Docker.
Собираем dappdeps/toolchain
Глава 5 «Constructing a Temporary System» руководства Linux From Scratch как раз описывает процесс построения временного chroot-окружения в /tools с некоторым набором утилит, которым затем собирается главный целевой дистрибутив.
В нашем случае немного переиначим директорию chroot-окружения. В параметре --prefix при компиляции будем указывать /.dapp/deps/toolchain/0.1.1 . Это та директория, которая будет появляться в сборочном контейнере, при монтировании в него dappdeps/toolchain — в ней содержатся все нужные утилиты и библиотеки. Нам требуются лишь GNU binutils, GCC и glibc.
Собирается образ с использованием Docker multi-stage builds. В образе на основе ubuntu:16.04 подготавливается все окружение и производится компиляция и установка программ в /.dapp/deps/toolchain/0.1.1 . Затем эта директория копируется в scratch-образ dappdeps/toolchain:0.1.1. Dockerfile можно найти здесь.
Итоговый образ 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 :
Рассмотрим на примере rsync , как выглядит software-рецепт для Omnibus:
Директивой source указывается URL, откуда надо скачать исходные коды. Зависимости от других компонентов указаны директивой dependency по имени. Имя собираемого компонента задано директивой name . Каждый software-рецепт в свою очередь может указывать зависимости от других компонентов. Внутри блока build указаны стандартные команды сборки из исходных кодов.
Проект 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-toolchain : по этому имени все объявленные томы этого контейнера можно использовать для монтирования в другие контейнеры с помощью --volumes-from . Параметр-команду с произвольным текстом no-such-cmd требуется указать для Docker, но данный контейнер никогда не будет запущен — он так и останется в состоянии Created .
Создаем остальные контейнеры:
Вот мы и дошли до кульминации, ради которой задумывался весь этот сыр-бор. Итак, в качестве демонстрации возможностей установим в образ Alpine пакеты nginx и tree , запустив Ansible из dappdeps/ansible через Bash из dappdeps/base:
Финальный аккорд — создаем образ из получившегося контейнера и… видим, что от dappdeps в нем остались лишь пустые директории mount-point'ов!
Казалось бы, о чем еще можно мечтать.
Дальнейшие работы и проблемы
Какие проблемы с dappdeps?
Необходимо провести работу по уменьшению размеров dappdeps/toolchain. Для этого надо разделить toolchain на 2 части: часть, необходимая для сборки новых утилит в dappdeps, и часть с базовыми библиотеками типа glibc, которые необходимо монтировать в runtime уже для запуска этих утилит.
Для работы модуля Ansible apt в dappdeps/ansible пришлось добавить содержимое пакета python-apt в Ubuntu прямо в образ без пересборки. В этом случае модуль apt работает без проблем в базовых образах на основе DEB, но требуется наличие glibc определенной версии. Поскольку сам apt — это дистрибутиво-специфичный модуль, то такое допустимо.
Чего не хватает в Dockerfile?
Для использования тома из образа dappdeps/toolchain приходится сначала создавать архив этого образа, а затем добавлять его в другой образ через директиву Dockerfile ADD (см. раздел «Используем Omnibus вместе с dappdeps/toolchain»). Со стороны Dockerfile не хватает функционала, который бы позволял просто подключать директорию другого образа на время сборки как VOLUME , т.е. аналог опции --volumes-from для Dockerfile.
Выводы
Мы убедились, что идея работает и позволяет использовать в сборочных инструкциях GNU- и другие CLI-утилиты, запускать интерпретатор Python или Ruby, запускать даже Ansible или Chef в Alpine или scratch-образах. При этом писателю сборочных инструкций не требуется знать побочный эффект выполнения запускаемых команд и явно перечислять, какие файлы необходимо импортировать, как в случае с Docker multi-stage builds.
Результаты данной работы применяются и на практике: dapp использует dappdeps-образы в сборочных контейнерах. Например, Git из dappdeps/gitartifact используется для работы с патчами, и утилита Git с некоторой гарантией ведет себя одинаково во всех базовых образах. Однако то, как dapp использует dappdeps, выходит за рамки данной статьи.
Целью данной статьи было донести саму идею и показать на реальном практическом примере возможность ее применения.
Мы рассмотрим процесс установки Docker на системы семейства Linux — а именно, CentOS, Fedora и Ubuntu.
Ubuntu
Docker на Ubuntu ставится, относительно, просто.
Обновляем список пакетов:
Устанавливаем докер командой:
apt-get install docker docker.io
Разрешаем автозапуск докера и стартуем его:
systemctl enable docker
systemctl start docker
CentOS 8
dnf install wget
Скачиваем конфигурационный файл для репозитория докер:
Теперь устанавливаем docker:
dnf install docker-ce docker-ce-cli
И разрешаем автозапуск сервиса и стартуем его:
systemctl enable docker --now
CentOS 7
yum install wget
Скачиваем файл репозитория:
yum install docker-ce docker-ce-cli containerd.io
Запускаем его и разрешаем автозапуск:
systemctl enable docker --now
Fedora
Устанавливаем плагин, дающий дополнительные инструменты при работе с пакетами:
yum install dnf-plugins-core
dnf install docker-ce docker-ce-cli containerd.io
Запускаем его и разрешаем автозапуск:
systemctl enable docker --now
Проверка
Чтобы убедиться, что docker в рабочем состоянии, выполняем команду:
docker run hello-world
Сначала система обнаружит, что нужного образа нет и загрузит его:
После отобразит приветствие:
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker.
Docker работает корректно.
Установка Compose
Команда docker-compose позволяет развернуть многоконтейнерные Docker-приложения.
* где 1.29.2 — последняя версия файла.
Даем права файлу на исполнение:
chmod +x /usr/bin/docker-compose
Запускаем docker-compose с выводом его версии:
Возможные проблемы
1. undefined symbol: seccomp_api_set
Сервис докера не запускается, а в логе можно увидеть следующий текст ошибки:
/usr/bin/containerd: symbol lookup error: /usr/bin/containerd: undefined symbol: seccomp_api_set
Причина: ошибка возникает, если установить свежую версию containerd на систему с необновленной библиотекой libseccomp.
Решение: обновляем libseccomp.
yum update libseccomp
apt-get --only-upgrade install libseccomp2
2. error initializing network controller list bridge addresses failed no available network
Сервис докера не запускается, а в логе можно увидеть следующий текст ошибки:
error initializing network controller list bridge addresses failed no available network
Причина: система не может создать docker-интерфейс.
Решение: создаем docker-интерфейс вручную. Устанавливаем утилиту для работы с bridge-интерфейсами.
yum install bridge-utils
apt-get install bridge-utils
brctl addbr docker0
Назначаем IP-адреса на созданный интерфейс:
ip addr add 192.168.84.1/24 dev docker0
* в нашем примере для docker мы задали адрес 192.168.84.1.
На момент написания данной статьи существуют два разных издания Docker:
Docker Community Edition (DCE) — подходит для разработчиков и маленьких команд.
Docker Enterprise Edition (DEE) — подходит для использования большими командами в продакшене.
Docker Enterprise Edition также имеет разные издания:
Все примеры данного урока созданы с помощью Docker Community Edition, который является бесплатным.
Установка RPM-пакета Docker на Linux
На самом деле, процесс установки Docker довольно простой и понятный. Сейчас мы рассмотрим установку Docker из RPM-дистрибутива (сокр. от англ. «Red Hat Package Manager») операционной системы на базе Linux. К данным дистрибутивам относятся следующие:
В моем случае, это Fedora 31.
Сначала нам нужно добавить репозиторий Docker. Для этого устанавливаем пакет dnf-plugins-core , который позволяет управлять репозиториями из командной строки с помощью следующей команды:
sudo dnf -y install dnf-plugins-core
Далее добавляем стабильный репозиторий Docker:
После добавления репозиториев устанавливаем Docker с помощью следующей команды:
sudo dnf install docker-ce docker-ce-cli containerd.io
Если команда запросит подтверждение GPG-ключа (сокр. от англ. «GNU Privacy Guard»), то проверьте, совпадает ли фингерпринт со значением 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35 . Если совпадает, то подтверждайте.
Fedora 31 может возвратить вам исключение CGroups , поэтому для решения данной проблемы вы должны включить обратную совместимость для CGroups следующей командой:
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
Дальше вам нужно запустить daemon-сервис самого Docker:
sudo systemctl start docker
Чтобы проверить, что процесс установки прошел успешно, вы можете запустить следующую команду:
docker run hello-world
Последним шагом является добавление пользователя в группу Docker для возможности запуска Docker-команд без прав суперпользователя:
sudo usermod –aG docker $USER && newgrp docker
Поздравляю, вы успешно установили Docker на RPM-дистрибутив Linux!
Установка DEB-пакета Docker на Linux
Сейчас мы рассмотрим установку DEB-пакета Docker на Linux на примере Ubuntu 18.04 LTS, но эта инструкция также подойдет и для следующих дистрибутивов:
Ubuntu Eoan 19.10
Ubuntu Bionic 18.04 (LTS)
Ubuntu Xenial 16.04 (LTS)
Debian Stretch 9
Debian Buster 10
Также всё будет работать и на других Linux-дистрибутивах, которые основаны на вышеперечисленных.
Docker Community Edition доступен для следующих архитектур:
x86_64 (или amd64)
ppc64le (IBM Power)
Если вы уже когда-нибудь пробовали установить Docker, то у вас могли остаться старые и ненужные пакеты, для их удаления воспользуемся следующей командой:
sudo apt-get remove docker docker-engine docker.io containerd runc
При этом содержимое директории /var/lib/docker, где Docker хранит образы (images), контейнеры (containers), хранилища (volumes) и настройки сетей (networks), будут сохранены. Пакет Docker Engine Community сейчас называется docker-ce .
Есть 3 способа установки Docker CE в Ubuntu:
Способ №1: Настроить поддержку репозитория Docker и установить его оттуда.
Способ №2: Загрузить DEB-пакет и установить его вручную.
Способ №3: Воспользоваться автоматическими скриптами, которые позволяют установить Docker.
Сейчас мы рассмотрим установку Docker из репозиториев, так как этот способ наиболее безопасен и позволит обновлять Docker вместе с системой.
Итак, первым делом нам нужно добавить Docker-репозиторий — это место, где хранятся все нужные для установки Docker пакеты. Безопасность данного способа заключается в том, что эти репозитории имеют цифровую подпись, гарантирующую получение именно того пакета Docker, который нужен и ничего лишнего.
Для начала обновим список существующих репозиториев в системе:
sudo apt-get update
Далее установим пакеты:
Затем подтверждаем наши намерения символом y и нажимаем Enter :
После подтверждения получим следующий вывод:
Далее нам нужно добавить официальный GPG-ключ для Docker репозитория:
После чего нажимаем Enter .
Проверяем цифровой отпечаток ключа 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88 , сравнивая последние 8 символов с помощью следующей команды:
sudo apt-key fingerprint 0EBFCD88
Воспользуемся следующей командой, чтобы добавить стабильный репозиторий Docker:
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
После этого нам снова нужно обновить список репозиториев:
sudo apt-get update
И, собственно, устанавливаем сам Docker:
sudo apt-get install docker-ce docker-ce-cli containerd.io
После скачивания и установки Docker нам нужно добавить пользователя в группу Docker, чтобы иметь возможность использовать команды Docker без прав суперпользователя:
sudo usermod -aG docker $USER
Чтобы обновления в группах вступили в силу, воспользуемся следующей командой:
Проверяем, всё ли ок:
docker run hello-world
Читайте также: