Сегодня затронем еще одну из тем из roadmap, из разряда optional, но с которой стоит хотя бы поверхностно ознакомиться. Речь идет про Docker, ниже будет краткое ознакомление .
Итак, немного разберемся зачем нужен докер. Самый жизненный пример. Предположим есть несколько разработчиков, которые работают над одним проектом.
Допустим, вы поработали локально над кодом, вы молодец, теперь нужно прогнать тесты. Логично для таких целей использовать отдельный компьютер, чтобы проверить что тест работает не только на вашей машине, но и на любой другой. Чтобы не покупать под каждого разработчика такой комп, берут отдельный сервак, достаточно мощный чтобы обслуживать одновременно кучу разработчиков.
Теперь предположим, два разработчика отправили свой код тестироваться на один и тот же сервер. При этом вполне возможна ситуация, что один из разработчиков модифицировал одну из библиотек. Поэтому, если второй разработчик воспользуется той же библиотекой, то вполне возможно, что его тесты будут работать не правильно. Таким образом нам нужно каким то образом изолировать выполнение тестов друг от друга.
Другой пример. Вы собрали программу, под определенное окружение, как это передать другому человеку, чтобы он не мучался, настраивая подобное окружение. Искушенный пользователь скажет, что для этого вполне может подойти виртуальная машина, например Virtual Box и будет по своему прав. Но тут есть два минуса, первое что образа огромные, второе производительность виртуальной машины довольно не высока.
Докер в свою очередь помогает решить подобные проблемы. И его вполне можно представлять себе, чем то похожим на виртуалку, но в отличие от нее от не эмулирует работу железа, а эмулирует только вызовы операционной системы, за счет чего в теории он будет работать быстрее, чем виртуальная машина.
В своей практике, я ежедневно пользуюсь docker при разработке и это удобно, так как я знаю что у других разработчиков будет точно такое же окружение, те же версии пакетов что и у меня, такие же библиотеки. Если случайно удалишь какую то директорию, то не поломаешь основную файловую систему.
Думаю, что приводить процесс установки и запуска hello world не имеет смысла. Предлагаю ознакомиться сразу с тем, как создать образ, который можно было бы перетащить на другой компухтер. Сразу обозначу, что пользуюсь Ubuntu 20.04 поэтому далее речь будет в этом контексте.
Создаем файл с именем Dockerfile, который будет описывать содержимое образа. Внутри него помещаем следущий текст
FROM ubuntu:20.04 |
Тут немного пояснений. Нам нужно указать какой образ будет использоваться в качестве базового, чтобы самим не создавать файловую систему с сисрутом. FROM как раз и говорит о том, что используй базовый образ ubuntu:20.04.
Базовый образ ubuntu:20.04 взялся не с потолка, добрый люди из canonical его подготовили руками за нас. Когда начнется сборка контейнера и локально этот файл не будет найден, то докер полезет в свою базу, найдет этот образ и заботливо его скачает за нас. После этого образ будет уже находиться локально. На сайте docker можно найти огромное количество уже заранее подготовленных образов на любой вкус и цвет.
После этого сохраняем файл и выполняем собираем контейнер
docker build -t test/ubuntu:v1 . |
И запускаем его
docker run -it test/ubuntu:v1 |
после этого коммандная строка будет вида
root@0b9:/# |
Можем посмотреть через top список запущенных программ и увидим что то вроде
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 4116 3388 2948 S 0.0 0.0 0:00.04 bash 9 root 20 0 6100 3380 2880 R 0.0 0.0 0:00.00 top |
Если мы захотим выйти из докера, то пишем
exit |
Посмотреть список запущенных контейнеров можно через
docker ps -a |
Если мы захотим что то добавить в образ, например установить htop, то можно дописать в Dockerfile
RUN apt-get update && apt-get install -y htop |
И заново собрать через docker build. Надо отметить, что сборка контейнера это не сборка готового образа, который можно передать, так как образ ubuntu:20.04 может использоваться в куче разных контейнеров и будет жирно его копировать в каждый из образов, поэтому в контексте докера обычно используют сравнение с слоями. Поэтому стоит рассматривать Dockerfile, как некий рецепт, каждая строчка которого описывает какой из слоев нужно запустить.
Если мы хотим все это добро экспортировать на другую машину, то смотрим список доступных образов
docker images |
Сохраняем его как tar архив и несем на другой комп
docker save -o ./my.tar test/ubuntu |
На другом компьютере загружаем его
docker load -i my.tar |
В кратце по минимуму это все, далее можно копать про объединение контейнеров в docker compose, но оставим эту тему на другой раз.
Добавить комментарий