зачем нужен docker python
Разбор особенностей официального Docker-образа Python
Официальный Docker-образ Python весьма популярен. Кстати, я и сам рекомендовал одну из его вариаций в качестве базового образа. Но многие программисты не вполне понимают того, как именно он работает. А это может привести к путанице и к возникновению различных проблем.
В этом материале я собираюсь поговорить о том, как создан этот образ, о том, какую он может принести пользу, о его правильном использовании и о его ограничениях. В частности, я разберу тут его вариант python:3.8-slim-buster (в состоянии, представленном файлом Dockerfile от 19 августа 2020 года) и по ходу дела остановлюсь на самых важных деталях.
Читаем файл Dockerfile
▍Базовый образ
Начнём с базового образа:
Оказывается, что базовым образом для python:3.8-slim-buster является Debian GNU/Linux 10 — текущий стабильный релиз Debian, известный ещё как Buster (релизы Debian называют именами персонажей из «Истории игрушек»). Бастер — это, если кому интересно, собака Энди.
Итак, в основе интересующего нас образа лежит дистрибутив Linux, который гарантирует его стабильную работу. Для этого дистрибутива периодически выходят исправления ошибок. В варианте slim установлено меньше пакетов, чем в обычном варианте. Там, например, нет компиляторов.
▍Переменные среды
Далее — взглянем на настройки языка:
Насколько я знаю, современный Python 3, по умолчанию, и без этой настройки, использует UTF-8. Поэтому я не уверен в том, что в наши дни в исследуемом Dockerfile нужна эта строка.
Здесь есть и переменная окружения, содержащая сведения о текущей версии Python:
В Dockerfile есть ещё переменная окружения с GPG-ключом, используемая для верификации загружаемого исходного кода Python.
▍Зависимости времени выполнения
Python’у для работы нужны некоторые дополнительные пакеты:
▍Установка Python
Теперь выполняется установка набора инструментальных средств компиляции. А именно, загружается и компилируется исходный код Python, после чего деинсталлируются ненужные пакеты Debian:
Тут происходит много всего, но самое важное — это следующее:
▍Настройка символьных ссылок
▍Установка pip
У менеджера пакетов pip имеется собственный график выхода релизов, отличающийся от графика релизов Python. Например, в этом Dockerfile выполняется установка Python 3.8.5, выпущенного в июле 2020. А pip 20.2.2 вышел в августе, уже после выхода Python, но Dockerfile устроен так, чтобы была бы установлена свежая версия pip :
▍Точка входа в образ
В итоге в Dockerfile указывается точка входа в образ:
Используя CMD вместо ENTRYPOINT мы, запуская образ, по умолчанию получаем доступ к python:
Но, при необходимости, можно указывать при запуске образа и другие исполняемые файлы:
Итоги
▍В состав образа входит Python
Программисты, использующие этот образ, порой совершают одну и ту же ошибку, которая заключается в повторной установке Debian-версии Python:
▍В образ входит самая свежая версия pip
▍Образ не выполняет установку обновлений безопасности Debian
Хотя базовые образы debian:buster-slim и python часто обновляются, имеется определённый промежуток между моментами выхода обновлений безопасности Debian и включением их в образы. Поэтому нужно самостоятельно устанавливать обновления безопасности для базового дистрибутива Linux.
Какими Docker-образами вы пользуетесь для выполнения Python-кода?
Как превратить скрипт на Python в «настоящую» программу при помощи Docker
Никого не интересует, умеете ли вы разворачивать связанный список — всем нужно, чтобы можно было легко запускать ваши программы на их машине. Это становится возможным благодаря Docker.
Для кого предназначена эта статья?
Вам когда-нибудь передавали код или программу, дерево зависимостей которой напоминает запутанную монтажную плату?
Как выглядит управление зависимостями
Без проблем, я уверен, что разработчик любезно предоставил вам скрипт установки, чтобы всё работало. Итак, вы запускаете его скрипт, и сразу же видите в оболочке кучу сообщений логов ошибок. «У меня на машине всё работало», — обычно так отвечает разработчик, когда вы обращаетесь к нему за помощью.
Docker решает эту проблему, обеспечивая почти тривиальную портируемость докеризованных приложений. В этой статье я расскажу, как быстро докеризировать ваши приложения на Python, чтобы ими можно было легко делиться с любым человеком, у которого есть Docker.
В частности, мы рассмотрим скрипты, которые должны работать как фоновый процесс.
Репозитории Github и Docker
Если вам более удобна наглядность, то изучите репозитории Github и Docker, где будет хоститься этот код.
Но… почему Docker?
Контейнеризацию можно сравнить с размещением вашего ПО в грузовом контейнере, обеспечивающем стандартный интерфейс для компании-грузоперевозчика (или другого компьютера-хоста), который позволяет взаимодействовать с ПО.
Контейнеризация приложений на самом деле является золотым стандартом портируемости.
Общая схема Docker/контейнеризации
Контейнеризация (особенно при помощи docker) открывает перед вашим программным приложением огромные возможности. Правильно контейнеризированное (например, докеризированное) приложение можно развёртывать с возможностью масштабирования через Kubernetes или Scale Sets любого поставщика облачных услуг. И да, об этом мы тоже поговорим в следующей статье.
Наше приложение
В нём не будет ничего особо сложного — мы снова работаем с простым скриптом, отслеживающим изменения в каталоге (так как я работаю в Linux, это /tmp ). Логи будут передаваться на stdout, и это важно, если мы хотим, чтобы они отображались в логах docker (подробнее об этом позже).
main.py: простое приложение мониторинга файлов
Эта программа будет выполняться бесконечно.
Как обычно, у нас есть файл requirements.txt с зависимостями, на этот раз только с одной:
Создаём Dockerfile
В моей предыдущей статье мы создали скрипт процесса установки в Makefile, благодаря чему им очень легко делиться. На этот раз мы сделаем нечто подобное, но уже в Docker.
Нам необязательно вдаваться в подробности устройства и работы Dockerfile, об этом есть более подробные туториалы.
Краткое описание Dockerfile — мы начинаем с базового образа, содержащего полный интерпретатор Python и его пакеты, после чего устанавливаем зависимости (строка 6), создаём новый минималистичный образ (строка 9), копируем зависимости и код в новый образ (строки 13–14; это называется многоэтапной сборкой, в нашем случае это снизило размер готового образа с 1 ГБ до 200 МБ), задаём переменную окружения (строка 17) и команду исполнения (строка 20), на чём и завершаем.
Сборка образа
Завершив с Dockerfile, мы просто выполняем из каталога нашего проекта следующую команду:
Запуск образа
После завершения сборки можно начинать творить магию.
Один из самых замечательных аспектов Docker заключается в том, что он предоставляет стандартизованный интерфейс. Так что если вы правильно спроектируете свою программу, то передавая её кому-то другому, достаточно будет сказать, что нужно изучить docker (если человек ещё его не знает), а не обучать его тонкостям устройства вашей программы.
Хотите увидеть, что я имею в виду?
Команда для запуска программы выглядит примерно так:
Здесь многое нужно объяснить, поэтому разобьём на части:
-d — запуск образа в detached mode, а не в foreground mode
—restart=always — при сбое контейнера docker он перезапустится. Мы можем восстанавливаться после аварий, ура!
—e DIRECTORY=’/tmp/test’ — мы передаём при помощи переменных окружения каталог, который нужно отслеживать. (Также мы можем спроектировать нашу программу на python так, чтобы она считывала аргументы, и передавать отслеживаемый каталог таким способом.)
-v /tmp/:/tmp/ — монтируем каталог /tmp в каталог /tmp контейнера Docker. Это важно: любой каталог, который мы хотим отслеживать, ДОЛЖЕН быть видимым нашим процессам в контейнере docker, и именно так это реализуется.
directory-monitor — имя запускаемого образа
После запуска образа его состояние можно проверять с помощью команды docker ps :
Docker создаёт crazy-имена для запущенных контейнеров, потому что люди не очень хорошо запоминают значения хэшей. В данном случае имя crazy_wozniak относится к нашему контейнеру.
Теперь, поскольку мы отслеживаем /tmp/test на моей локальной машине, если я создам в этом каталоге новый файл, то это должно отразиться в логах контейнера:
Логи Docker демонстрируют, что приложение работает правильно
Вот и всё, теперь ваша программа докеризирована и запущена на вашей машине. Далее нам нужно решить проблему передачи программы другим людым.
Делимся программой
Ваша докеризированная программа может пригодиться вашим коллегам, друзьям, вам в будущем, да и кому угодно в мире, поэтому нам нужно упростить её распространение. Идеальным решением для этого является Docker hub.
Если у вас ещё нет аккаунта, зарегистрируйтесь, а затем выполните логин из cli:
Логинимся в Dockerhub
Далее пометим и запушим только что созданный образ в свой аккаунт.
Добавляем метку и пушим образ
Теперь образ находится в вашем аккаунте docker hub
Чтобы убедиться, что всё работает, попробуем выполнить pull этого образа и использовать в сквозном тестировании всей проделанной нами работы:
Сквозное тестирование нашего образа docker
Весь этот процесс занял всего 30 секунд.
Что дальше?
Надеюсь, мне удалось убедить вас в потрясающей практичности контейнеризации. Docker останется с нами надолго, и чем раньше вы его освоите, тем больше получите преимуществ.
Суть Docker заключается в снижении сложности. В нашем примере это был простой скрипт на Python, но можно использовать этот туториал и для создания образов произвольной сложности с деревьями зависимостей, напоминающими спагетти, но конечного пользователя эти трудности не коснутся.
Источники
На правах рекламы
Вдсина предлагает виртуальные серверы на Linux или Windows. Используем исключительно брендовое оборудование, лучшую в своём роде панель управления серверами собственной разработки и одни из лучших дата-центров в России и ЕС. Поспешите заказать!
Docker. Зачем и как
Есть множество прекрасных публикаций для тех, кто уже пользуется docker-ом. Есть хорошие статьи для тех, кто хочет этому научиться. Я пишу для тех, кто не только не знает, что такое docker, но и не уверен стоит ли ему это знать.
Я сознательно опускаю некоторые технические подробности, а кое где допускаю упрощения. Если вы увидите, что docker – то, что вам нужно, вы легко найдете более полную и точную информацию в других статьях.
Начну я с описания нескольких типичных проблем.
Проблемы
Первая проблема — как передать продукт клиенту.
Предположим у вас есть серверный проект, который вы закончили и теперь его необходимо передать пользователю. Вы готовите много разных файликов, скриптов и пишите инструкцию по установке. А потом тратите уйму времени на решения проблем клиента вроде: «у меня ничего не работает», «ваш скрипт упал на середине — что теперь делать», «я перепутал порядок шагов в инструкции и теперь не могу идти дальше» и т. п.
Всё усугубляется если продукт тиражируемый и вместо одного клиента у вас сотни или тысячи покупателей. И становится еще сложнее, если вспомнить о необходимости установки новых версий продукта.
Вторая проблема — тиражируемость. Пусть вам нужно поднять 5 (или 50) почти одинаковых серверов. Делать это вручную долго, дорого и подвержено ошибкам.
Наконец, третья проблема — переиспользуемость. Предположим у вас есть отдел, который делает браузерные игры. Предположим, что их у вас уже несколько. И все они используют один и тот же технологический стэк (например — java-tomcat-nginx-postgre). Но при этом, чтобы поставить новую игру вы вынуждены заново подготавливать на новом сервере почти одинаковую конфигурацию. Вы не можете просто так взять и сказать — «хочу сервер, как в игре странники но только с другим веб архивом»
Обычные решения
Как обычно решаются эти проблемы.
Установочный скрипт
Первый подход я уже упомянул — вы можете написать скрипт, который установит всё, что вам нужно и запускать его на всех нужных серверах. ( Скрипт может быть как простым sh файлом, так и чем-то сложным, созданным с использованием специальных инструментов).
Недостатки этого подхода — хрупкость и неустойчивость к ошибкам. Как бы хорошо не был написан скрипт, рано или поздно на какой-то машине он упадёт. И после этого падения машина фактически окажется «испорченной» — просто так «откатить» те действия, которые скрипт успел выполнить, у вашего клиента не получится.
Облачные сервисы
Второй подход — использование облачных сервисов. Вы вручную устанавливаете на виртуальный сервер всё, что вам нужно. Затем делаете его image. И далее клонируете его столько раз, сколько вам надо.
Недостатка здесь два. Во-первых, vendor-lock-in. Вы не можете запускать свое решение вне выбранного облака, что не всегда удобно и может привести к потерям несогласных с этим выбором клиентов. Во-вторых, облака медленны. Виртуальные (и даже «bare-metal») сервера предоставляемые облаками на сегодняшний день сильно уступают по производительности dedicated серверам.
Виртуальные машины
Третий подход — использование виртуальных машин. Здесь тоже есть недостатки:
Размер — не всегда удобно качать образ виртуальной машины, который может быть довольно большим. При этом, любое изменение внутри образа виртуальной машины требует скачать весь образ заново.
Сложное управление совместным использованием серверных ресурсов — не все виртуальные машины вообще поддерживают совместное использование памяти или CPU. Те что поддерживают, требуют тонкой настройки.
Подход докера — контейнеризация
И вот тут появляется docker, в котором
Как работает docker
Создание образа
Сначала создается docker image (или образ). Он создается при помощи скрипта, который вы для этого пишете.
Образы наследуются и, обычно, для создания своего первого образа мы берём готовый образ и наследуемся от него.
Чаще всего мы берем образ в котором содержится та или иная версия linux. Скрипт тогда начинается как-то так:
Кроме этого, мы можем копировать в наш образ любые локальные файлы при помощи директивы COPY.
Докер поддерживает гораздо больше различных директив. Например, директива USER roman говорит докеру что все следующие директивы нужно выполнять из под пользователя roman. А директива ENTRYPOINT [“/opt/tomcat/catalina.sh”] задает исполняемый файл, который будет запускаться при старте.
Я не буду перечислять все остальные директивы — в этом нет смысла. Здесь главное — принцип: вы создаёте вот такой скрипт, называете его Dockerfile и запускаете команду docker build, docker выполняет скрипт и создает image.
Если в процессе возникают какие-то ошибки, докер о них сообщает и вы их исправляете. То есть исправление скрипта происходит на этапе создания image. На этапе установки скрипт уже не используется.
Создание контейнера
Когда у вас уже есть docker image вы можете создать из него контейнер на любом физическом сервере, где установлен докер. Если image – это тиражируемый образ некоторой «машины», то container это уже сама «машина», которую можно запускать и останавливать.
Важный момент — при создании контейнера из image, его можно параметризовать. Вы можете передавать докеру переменные окружения, которые он использует при создании контейнера из image. Так вы сможете создавать немного разные машины из одного образа. Например, передать образу web-сервера его доменное имя.
Хорошей практикой в докере считается «упаковка» в один контейнер ровно одного постоянно работающего серверного процесса. Как я уже упоминал, этот процесс работает на уровне физического сервера и честно регулируется установленной там операционной системой. Поэтому, в отличие от виртуальных машин, контейнеры докера не требуют специального управления памятью и процессорами. Использование ресурсов становится простым и эффективным.
Union filesystem
Ок — память и процессор используется эффективно. А как насчёт файловой системы? Ведь если у каждого контейнера докера своя собственная копия операционной системы, то мы получим ту же проблему, что и с виртуальными машинами — тяжеловесные образы, которые содержат одно и тоже.
На самом деле в докере это не так. Если вы используете 100500 контейнеров, основанных на одном и том же образе операционной системы, то файлы этой системы будут скачаны докером ровно один раз. Это достигается за счёт использования докером union file system.
Union file system состоит из слоёв (layers). Слои как бы наложены друг на друга. Некоторые слои защищены от записи. Например, все наши контейнеры используют общие защищенные от записи слои, в которых находятся неизменяемые файлы операционной системы.
Для изменяемых файлов каждый из контейнеров будет иметь собственный слой. Естественно, докер использует такой подход не только для операционной системы, но и для любых общих частей контейнеров, которые были созданы на основе общих «предков» их образов.
Container registry
Получается, что docker image состоит из слоёв. И хорошо было бы уметь скачивать на наш сервер только те слои, которых на нём пока нет. Иначе для установки 100 контейнеров, основанных на Ubuntu мы скачаем Ubuntu внутри их образов 100 раз. Зачем?
Хорошая новость в том, что докер решает эту проблему. Докер предоставляет специальный сервис, называемый docker registry. Docker registry предназначен для хранения и дистрибуции готовых образов. Собрав новый образ (или новую версию образа) вы можете закачать его в docker registry. Соответственно, потом его можно скачать оттуда на любой сервер. Главная фишка здесь в том, что физически качаться будут только те слои, которые нужны.
Например, если вы создали новую версию образа, в котором поменяли несколько файлов, то в registry будут отправлены только слои, содержащие эти файлы.
Аналогично, если сервер качает из registry какой-то образ, скачаны будут только слои, отсутствующие на сервере.
Docker registry существует и как общедоступный сервис и как open source проект, доступный для скачивания и установки на собственной инфрастуктуре.
Использование контейнеров
Созданные контейнеры можно запускать, останавливать, проверять их статус и т д. При создании контейнера можно дополнительно передать докеру некоторые параметры. Например, попросить докер автоматически рестартовать контейнер, если тот упадёт.
Взаимодействие между контейнерами
Если контейнеров на сервере несколько, управлять ими вручную становится проблематично. Для этого есть технология docker compose. Она существует поверх докера и просто позволяет управлять контейнерами на основе единого конфигурационного файла, в котором описаны контейнеры, их параметры и их взаимосвязи (например контейнер A имеет право соединяться с портом 5432 контейнера B)
Выводы
Таким образом докер очень хорошо подходит для решения перечисленных выше задач:
Быстрое знакомство с Docker-контейнерами для Django-разработчика
Разработка такого проекта как кешбек-сервис подразумевает использование различных сервисов, нетипичных для обычного ноутбука, даже если это ноутбук разработчика. Postgresql, Redis, Celery и так далее. Желание создать комфортную среду разработки и тестирования привело нас к необходимости использование какой-то системы виртуализации/изоляции. Как вариант — некоторое время использовался Vagrant, но это всё-таки ovrerhead и наши поиски оптимального способа привели, на данный момент, к Docker.
Docker — платформа для запуска приложений в изолированных контейнерах. Использование контейнеров в Linux позволяет программному обеспечение быть изолированным от базовой системы. В отличии от Virtualbox, исключаются системные издержки (overhead), необходимые для виртуализации оборудования. Docker может помочь в разработке и развертывании веб-приложений и сервисов. Давайте посмотрим, как это происходит.
Зачем мне нужен Docker?
Docker может быть использован различными способами. Он может обеспечивать работу сервисов в фоновом режиме, например, PostgreSQL заданной версии. В docker может быть помещено наше приложение (dockerizing application) и таким образом мы мы можем использовать образы подобных контейнеров для развертывания нашего приложения на продакшене.
Для python-разработчиков Docker может быть описан как virtualenv для любого приложения. Это может быть как Python-интерпретатор так и какой-нибудь сервер. Это очень удобно, когда вы хотите протестировать новые версии или хотите запустить устаревшие приложения на вашем сервере.
Установка Docker
Docker доступен в репозиториях в различных Linux дистибутивах. OSX и MS Windows пользователи могут использовать VirtualBox, на котором установлена Linux система для того, чтобы запустить Docker.
Для установки последней версии я использую PPA для Ubuntu. Когда Docker установлен, вы можете добавить себя в группу “docker” для того, чтобы в дальнейшем не требовлось использовать sudo.
Первые контейнеры
Когда Docker готов, мы можем запустить множество контейнеров из registry.hub.docker.com, например Python. Для запуска этого контейнера, просто выполните:
Для начала запущенный Docker скачает несколько файлов. Когда процесс завершится, мы получим дефолтную консоль Python-интерпретатора. Команда -it запускает контейнер в интерактивном режиме и привязывает ее к консоли для взаимодействия. —rm удалит текущий контейнер после выхода. “Python” — это название исходника для контейнера. После “:” мы видим тег, который обычно показывает версию — в этом случае версия Python в контейнере.
Мы также можем поменять стандартное поведение контейнера, например запустить собственный скрипт. Для использования команды из командной строки просто добавьте следующее:
Когда наш контейнер будет запущен, внутри него запустится команда “ls”, которая покажет все файлы и фильтры в главной директории.
Dockerfile
Файл Dockerfile содержит “рецепт приготовления” нашего контейнера. Если мы хотим запустить скрипт на Python, вот что мы должны написать:
FROM указывает на базовый контейнер, в данном случае — образ Python 3.4. Дальше мы можем использовать ADD, RUN, ENV команды для конфигурации контейнера. RUN команда будет выполнять задачи, когда контейнер построен. Команда CMD выполнится в начале запуска контейнера. Операции построения образов кэшируются и пропускает следующие версии (RUN команда из примера запустит построения первого билда, но не второго).
В терминале мы можем написать следующее:
Dockerfile на Django
django-ckeditor содержит демонстрационное приложение, которое может быть запущено через manage.py и runserver. Попробуем сделать Dockfile, который создаст образ этого приложения:
Я использую здесь Python 3.4. Весь код из репозитория будет добавлен в папку “ckeditor” контейнера. Я также устанавливаю DJANGO_SETTINGS_MODULE переменную окружения, добавляю зависимости и собственно редактор. Дальше валидация, сбор статики и в конце CMD для запуска сервера. Также удобно сделать сервер доступным снаружи контейнера, для этого мы запускаем его на 0.0.0.0 IP
Опция —publish позволяет сопоставить (mapping) публичный IP/Port адреса из запущенного локального контейнера с локальным. В этом примере 192.168.0.110 это порт хоста. Публичный порт может быть доступен через 8080 из моего localhost. Без опции publish сервер будет доступен только из запущенно IP адреса контейнера.
Конфигурация Dockerfile, которую я показал не идеальна и будет работать только с SQLite базой данны. Docker позволяет запускать разные сервисы в разных контейнерах. Например, давайте попробуем, использовать PostgreSQL базу данных во втором контейнере.
Так давайте запустим экземпляр PostgreSQL:
Конетйнер запустится в фоновом режиме и мы можем проверить его статус и название командой docker ps. Названия по умолчанию задаются случайные, например “clever_ptolemy”. Сейчас мы создали базу данных на этом сервере, но сначала нам нужен IP-адрес. Мы можем получить его из docker inspect INSTANCE_NAME, которая покажет список переменных в контейнере, включая IP-адрес. Дальше мы можем создать базу данных:
База данных создана и сейчас мы можем настроить ее в контейнере приложения. Докер позволяет сделать это используя переменные окружения. Для Django можно использовать dj_database_url:
from os import environ
Теперь мы должны передать env переменную с именем базы данных в контейнер чтобы заставить его работать. Это может быть сделать так:
Первой выполняется команда syncdb, она создаст таблицы в базе данных. Далее запускается development сервер.