Docker — это контейнер для приложения. В котором уже всё настроено — и операционная система, и сервер приложения, и вся инфраструктура. Бери да используй!
Докер активно используют разработчики и тестировщики для проверки приложений. Его используют и для поставок клиентам готового продукта. В нем поднимают приложения, гоняют автотесты... А также упоминают в вакансиях и спрашивают на собеседованиях =))
Поэтому в этой статье я расскажу на простом языке и с картиночками, что это вообще такое. А за кровавыми техническими подробностями идите в раздел «статьи и видео по теме».
Краткое содержание (в блоггере сделать кликабельным его не могу, увы, не нахожу тут якорей):
- Что это и зачем он нужен
- Чем docker отличается от VM
- Преимущества docker перед VM
- Архитектура docker
- Как docker работает
- Зачем докер тестировщикам
- Статьи и видео по теме
- Итого
Что это и зачем он нужен
Допустим, вы решили купить велосипед. Сравните две ситуации:
*******************************************************************
1. Вам привезли все детали отдельно. Причем велосипед хитрый, так что деталей много, в том числе много мелких.
А инструкция по сборке местами неполная, местами устаревшая — детали выглядят уже по-другому, поди угадай, о чем речь!
2. Вам привезли готовый велосипед. Садись и используй!
Его уже собрали. За вас. Это сделали опытные мастера, которые легко найдут нужную деталь среди исходников, и соберут все в правильной последовательности. Ведь они знают, как это делается.
*******************************************************************
Именно в этом фишка докера. Вам не надо настраивать окружение, его уже настроили до вас — те люди, которые разбираются в этом, умеют это делать. Вам как пользователю — очень удобно! Тык-тык, и оно работает!
А уж разработчику как удобно! Потому что нет больше этих ситуаций:
— Вааааась, у меня не работает!
— А у меня работает!!
— Что я делаю не так? (((
(через 20 минут изучения программы на компьютере тестировщика и ее окружения)
— Так ты же количество файловых дескриптеров не увеличила. Посмотри, ну это же в инструкции было!
— Ой, да? Пропустила, наверное...
Когда приложение выходит за рамки простого «Hello Word», для его запуска нужно выполнить ряд действий: подготовить операционную систему, установить сервер приложения, прописать все нужные параметры в нем...
Чем больше инструкция, тем больше шанс что-то продолбать из нее. Особенно если ПО человек устанавливает впервые. Это человеческий фактор!
У меня на одном из проектов было 3 коробочных продукта, которые мы передавали заказчикам. Каждый настраивается по своему. Есть, конечно, общие моменты — все продукты просят одну версию Java и сервера приложений JBoss.
Но:
- У каждого продукта свои параметры для настройки сервера приложения
- У разных заказчиков разная OS — Windows, Linux
- У разных заказчиков разная БД — Oracle, MariaDb
Поэтому, если разворачивать приложение впервые — инструкция получается очень длинной! Мы разбили её на небольшие кусочки — вот отдельно настройка системы, отдельно установка. Получается набор небольших статей:
Вот только этих статей набралось 80 штук! Представляете, как это выглядит?
Разумеется, если заказчик пытается впервые настроить всё сам, лучше надергать ему ссылок — чтобы ему не пришлось отсеивать лишнее, но при этом чтобы он не пропустил нужное.
И все равно что-то, да пропустит. Благо что обычно — на тестовом стенде. На «боевом» окружении (с которым работают реальные пользователи) админы поднимают приложение очень осторожно, внимательно вчитываясь в каждый пункт инструкции. Или вообще доверяют это нам — выделяют рабочее место, встречают, дают доступ, а мы уже всё настраиваем.
А с тестовыми стендами сильно не церемонятся. Особенно когда разворачивают уже третий или пятый стенд. Так, это вроде настроили, это тоже.
А потом тестировщики со стороны заказчика обращаются к нам с вопросами:
— А почему нагрузочные тесты упали?
— Вы памяти мало выделили / количество файловых дескриптеров в системе не увеличили / вот этот пункт тоже пропустили.
Ах, если бы не надо было каждый раз настраивать 20+ пунктов! Просто запустить приложение и всё... Как раз для этого и нужен докер! Как в этом случае происходила бы настройка:
- Мы уточняем у Заказчика исходные данные — какая OS, какая база данных, какая планируется нагрузка.
- Мы всё это настраиваем — а так как мы хорошо знаем наше приложение, то пропустить что-то шансы малы. И те мы покрываем тестированием — один настроил докер, второй выверил, что ничего не забыли.
- Отдаем заказчику докер-образ, где всё настроено
- Он запускает одно приложение (докер-контейнер), и у него всё работает. Профит!
И ведь в моем примере в настройке ошибаются админы — люди с техническим бекграундом, каждый день работающие с ПО. А что, если наше приложение общедоступное? И мы хотим, чтобы установить его смог абсолютно любой человек?
Вот, например, Jenkins — бесплатное ПО для CI (continuous integration). Посмотрим на инструкцию по установке. У них есть установка через докер!
Или «Test It», Test Management System — это довольно сложный продукт, который требует кучи настроек. Чем грузить пользователя длинной инструкцией и огребать потом в техподдержке «у меня не работает, разберитесь почему», также используют докер.
Докер решает проблему «пользователь забыл что-то настроить», уменьшает количество запросов в техподдержку и облегчает поставку продукта — когда мы сами всё настроили, то спим спокойно, не ошибутся теперь!
Чем docker отличается от VM
Принципы работы у них очень похожи. Но докер — это не виртуальная машина. И работает он на другом уровне. Давайте разберемся в отличиях.
Исходно у нас есть наш основной компьютер, на котором мы всё запускаем. Его принято называть хост-машиной, или хостом.
Хост система — та система, в которой стартует контейнер докера или виртуальная машина. Это может быть отдельный сервер или домашний компьютер. Или даже виртуальная машина!
Любая программа, запущенная на Хосте, обращается к OS этой системы. И через нее к железу.
Обычная ВМ (виртуальная машина) — по сути своей компьютер в компьютере. У него есть собственное железо, хоть и виртуальное: своя операционная система, своё ядро... Да, железо работает на ресурсах хост-системы, но программа, установленная на виртуалке, будет обращаться именно к железу виртуальной машины.
В отличие от виртуальных машин докер не создает отдельное ядро. Не требует установки операционной системы, выделения памяти и процессорных мощностей.
Вместо этого он использует существующую в линукс-системах технологию, которая позволяет запускать код в отдельных namespace. Код, запущенный таким образом, полностью отделен от работы основной системы, но при этом использует память и процессор просто как очередная программа в системе.
То есть программа, запущенная в докере, обращается напрямую к железу хост-системы.
По крайней мере так работает в linux системах. Именно там «настоящий» докер: он работает на технологиях, доступных в этой OS.
В мак или винде такой технологии нет. А значит, сами по себе они не могут выступать хост-машинами. Поэтому для того, чтобы все работало на других ОС, были созданы специальные инструменты — например, Docker Desktop и Docker Toolbox. Если не вдаваться в подробности, при запуске они создают виртуальную машину с линукс, и уже она выступает хост-машиной для всех ваших контейнеров докера.
Преимущества docker перед VM
1. Контейнеры докера стартуют быстрее виртуальных машин, ведь им не надо загружать операционную систему.
2. Потребление ресурсов (диска, процессора, памяти) не увеличивается само по себе, ведь в контейнере мощности используются только для запущенных программ, а не для ОС.
3. Сам образ контейнера весит меньше, ведь в нем только нужные вам программы и больше ничего лишнего.
Архитектура docker
Докер имеет клиент-серверную архитектуру. Есть клиент, с которого вы посылаете запросы через restful api, и докер-демон, который их обрабатывает, а также создает, запускает и распределяет ваши контейнеры.
Клиент и сервер могут находиться как на одной машине, так и на разных. Технически ничего не мешает вам подключиться к удаленному серверу докер при помощи вашего клиента.
Клиент докера обычно представляет собой командный интерфейс. Поэтому увы, красивых кнопочек в интерфейсе не ждите, работайте через консоль.
Как docker работает
Мы знаем, что докер — это программа, которая помогает нам положить приложение в некий контейнер.
Но где этот контейнер взять? Вот, допустим, я установила докер... А дальше то что делать?
Контейнеры создаются из образов (image). Образ — это шаблон. Он рассказывает:
- какое окружение разворачивать,
- какие скрипты в нем запускать.
Есть ряд стандартных образов — например, ubuntu. Он хранится в общедоступном репозитории. Это что-то типа github, даже называется похоже — Docker Hub. Это такая библиотека для популярных шаблонов контейнеров.
Вы можете скачать оттуда любой образ, а потом на его основе сделать свой. Например, вам нужна операционная система ubuntu, в которой уже установлен ряд программ:
- vim
- mc
- …
В таком случае вы берете из Docker Hub готовый образ ubuntu, устанавливаете туда все нужные программы, а потом сохраняете свой образ. Теперь у вас есть собственный шаблон, подходящий именно для вас. И теперь можно моментально создавать нужный контейнер, а не тратить каждый раз время на установку доп программ в базовый.
Если для работы с контейнером вам нужно взять файлы с вашего локального компьютера, вы просто подключаете их к контейнеру. Это делается через том (volume).
Том — директории или файлы, которые можно подключать к контейнеру. Это что-то типа выделенного жесткого диска. Его можно подключить к любому компу, но он не связан с конкретной машиной, и продолжит хранить данные, даже если его отключить.
Это основа, которую вы будете использовать постоянно:
- container — сам контейнер с приложением
- image — образ, из которого вы создаете контейнер
- volume — директории или файлы, которые можно подключать к контейнеру
Ну а в остальном вам поможет «docker help» внутри программы =)
Зачем докер тестировщикам
Когда докер только появился, его считали очередной утилитой для devops или сисадминов. А тестировщики, мол, дальше как-нибудь на виртуалках поработают. Но потом стало понятно, что докер удобнее. Какие плюшки он дает?
Изоляция процессов
Докер позволяет изолировать любые процессы, в том числе и процессы запуска тестов. Значит, мы можем сколько угодно раз запустить наши тесты на нужной системе, так еще и сделать это быстрее, чем с ВМ (виртуальной машиной). И для этого нам потребуется компьютер меньшей мощности.
Быстрое разворачивание окружений
Докер умеет быстро разворачивать систему. Если нужно запустить тест, теперь не надо каждый раз разворачивать на свою машину testNG или selenium, достаточно скачать и запустить нужный вам докер-контейнер. И при этом потребление памяти будет куда ниже, чем у виртуалки. А, значит, контейнеров, запущенных одновременно, может быть сколько угодно.
Проверка разных версий
Докер позволяет проверить разные версии одной программы. Или работу программы на разных окружениях:
- centos 6
- centos 7
Или на разных серверах приложения:
- jboss 6
- jboss 7.1
- wildfly 8.0
Или с разными версиями Java:
- JDK 7
- JDK 10
- JDK 11
В докере это сделать намного проще и быстрее, чем в «обычных» условиях. Загрузил контейнер из образа, проверил, контейнер прибил. Профит!
Чистота на рабочей машине
Вы можете поддерживать чистоту на своей рабочей машине. Если нужно попробовать другую версию какой-то программы, не нужно будет ставить ее в параллели или удалять старую. Можно просто запустить ее в другом контейнере.
Отделение от инфраструктуры
Вы можете отделить приложение от инфраструктуры. Вариант «на моей машине все работает» с докер-контейнером случается куда реже, чем с машиной разработчика.
Статьи и видео по теме
На Хабре есть целый цикл статей про докер:
- Часть 1: основы
- Часть 2: термины и концепции
- Часть 3: файлы Dockerfile
- Часть 4: уменьшение размеров образов и ускорение их сборки
- Часть 5: команды
- Часть 6: работа с данными
Еще статьи:
Полное практическое руководство по Docker: с нуля до кластера на AWS (хабр)
Что такое Docker, и как его использовать? Подробно рассказываем (библиотека программиста)
Видео:
Docker для тестировщика. Контейнеры, чем они отличаются от виртуальных машин и зачем они нужны — видео от Арсения Батырова, на основе которого построена эта статья (с разрешения автора, за что ему отдельное спасибо)
Курс от Арсения — Docker: инструменты тестировщика. Очень хорош, сама проходила =)
Итого
Doker — программа, которая позволяет положить любой софт в замкнутую среду (контейнер). А потом передавать этот контейнер дальше, на любой компьютер.
Фишка в том, что разработчик ПО настраивает всё сам:
- операционную систему
- сервер приложения
- само приложение
А пользователю передает уже готовый и настроенный продукт. Тем самым сокращая запросы в техподдержку «я попытался просто тык-тык, не читая инструкцию, теперь расскажите мне, что же я пропустил».
Также докер используется в тестировании и разработке вместо виртуальных машин, потому что имеет ряд преимуществ. Он изолирует процессы, быстро поднимает окружения и позволяет легко и быстро прогонять автотесты на разных версиях системы.
См также другие статьи из цикла «Что такое...»:
Что такое клиент-серверная архитектура
Что такое CI (Continuous Integration)
Что такое регулярные выражения (regexp)
PS — это выдержка из моей книги терминов, написана в помощь студентам моих курсов
Комментариев нет:
Отправить комментарий