Docker для фронтендера. Часть 2. Что ты такое?


    Продолжаю делать расшифровку своего доклада Docker для фронтендера с конференции FrontendConf 2019.


    В предыдущей части я постарался ответить на вопрос, зачем фронтенд-разработчику может понадобиться Docker. Сегодня попытаюсь простым языком рассказать, что это за инструмент, как он работает, и сравнить его с другими известными во фронтенде понятиями.


    Содержание


    1. Docker для фронтендера. Часть 1. Зачем?
    2. Docker для фронтендера. Часть 2. Что ты такое?
    3. Docker для фронтендера. Часть 3. Немного рецептов

    Что ты такое?


    Кто не знает, что такое Docker, представляют его себе по-разному.



    Кто-то думает, что это средство для установки контейнера на машину.



    Под анонсом в ВК предыдущей части этой статьи появилась пара шуточных комментариев.



    И только сисадмины, похоже, что-то знают.



    Ребята из Docker, Inc представляют нам этот инструмент через маркетинговый слоган:


    Отлаживайте ваше приложение, а не среду
    Безопасно собирайте, делитесь и запускайте любое приложение где угодно

    Она немного лукавят. Собирать, делиться и запускать действительно можно. Но с "безопасно" и с "где угодно" дела обстоят не совсем так.


    Про проблемы с безопасностью можно узнать, например, в этой статье, а про "где угодно" я расскажу чуть дальше.


    Виртуализация


    Возможность виртуализации появилась достаточно давно.


    Когда я занимался разработкой в 2012 году, моя команда делала проекты на Ruby on Rails. У меня возникала необходимость запускать у себя на ноутбуке такие вещи, как Ruby, MySQL, PostgreSQL. Это всё довольно плохо работало под Windows, поэтому приходилось использовать виртуализацию.


    Тогда существовали такие решения, как VirtualBox, VMware Workstation, Vagrant. Всё рабочее окружение выносилось на виртуалку, а в хост-системе оставались только IDE, Git, браузер.



    Вот эта схема, взятая из документации Docker, как раз показывает, как работают виртуальные машины (VM).


    У нас есть Infrastructure (наш компьютер) и Hypervisor (VMWare, VirtualBox или ещё что-то). И на всём этом мы запускаем виртуальную машину, которая включает гостевую операционную систему (Guest OS), нужные библиотеки (Bins/Libs) и наше приложение (App).


    Естественно, что сами виртуальные машины получались очень большие и неповоротливые. Накладные расходы на обслуживание виртуалки были высоки. Мой ноутбук с трудом всё это вывозил.



    Docker, Inc предложили нам не тянуть в виртуальный контейнер гостевую операционную систему, а пользоваться хост-системой и получать изоляцию процессов при помощи механизма контрольных групп (cgroups) в Linux.


    Это значительно уменьшило размеры образов. Например, образ alpine:3.11.0 (дистрибутив Linux, ориентированный на безопасность, легковесность и нетребовательность к ресурсам) весит всего 2.5 MB, а docker-образ с node:alpine — всего 27 MB.


    Т.е. наш сайт/приложение вполне можно запаковать в 30 MB образ, который достаточно будет запустить в Docker, и он будет работать где угодно? Да, но есть нюансы.


    Установка Docker


    Docker распространяется в двух изданиях: Community Edition (CE) и Enterprise Edition (EE). Нам нужен Docker CE, т.к. он бесплатный и решает все нужные нам задачи.


    А ещё Docker бывает Desktop и Server.



    Server


    Server-версии предназначены для установки на Linux и поддерживают 4 дистрибутива и только некоторые архитектуры. Поэтому заявление, что вы можете запустить docker-контейнер "где угодно" не совсем корректно.


    Desktop


    Desktop-версии предназначены для установки на компьютеры разработчикам. И это то, что нам будет помогать во время разработки наших классных приложений. В частности, я использую Docker Desktop for Mac.


    Установка на компьютер выглядит максимально привычно для пользователя Mac.



    Ну или, если вы любите Homebrew.


    brew cask install docker

    После этого приложение становится доступно в верхней строке состояния (top status bar) и из консоли.



    Нюанс заключается в том, что контрольные группы (cgroups) Linux отсутствуют на Mac и Windows (сюрприз, сюрприз), поэтому Docker Desktop использует Mac OS Hypervisor framework и Microsoft Hyper-V, соответственно.



    То есть для поддержки виртуализации придётся отдать ещё примерно 4 GB оперативной памяти. Зато потом работающие контейнеры уже будут заниматься гораздо меньше места, чем если бы они были запущены на отдельных виртуальных машинах.


    Вывод команды docker stats:


    CONTAINER ID        NAME                                   MEM USAGE
    e4941ea92ce7        nginx_1                                3.16MiB
    1b023bfff38f        api_1                                  351.5MiB
    e07c6958e378        pg_1                                   18.64MiB
    1fa783f5fdbc        terminal-front_1                       14.89MiB
    72e9dfa0805a        adminer_1                              11.19MiB
    e9ce9f965867        admin-front_1                          1.312MiB
    3edacc59a77b        certbot_1                              1.547MiB

    Видим, что БД заняла 19 МБ, а API на Java — 352 МБ.


    Что входит в Docker Desktop


    Docker разрабатывается в виде модульной архитектуры, поэтому устанавливая Docker Desktop, вы получаете сразу несколько программ.


    Docker Engine


    Docker Engine включает в себя инструменты для построения контейнеров, реестр контейнеров, инструменты оркестрации, среду выполнения и многое другое. Это проект с открытым исходным кодом, написанный на Go. Он запускается как daemon, который предоставляет RESTful API для выполнения команд.


    Такое решение позволяет управлять контейнерами почти откуда угодно, например, из браузера, Node.js или даже из Minecraft.



    Docker CLI client


    Консольный клиент для Docker Engine API.


    Тоже проект с открытым исходным кодом, написанный на Go.


    Docker Compose


    Инструмент для описания и запуска мультиконтейнерных приложений. Чрезвычайно полезная вещь в разработке.


    Позволяет почувствовать себя SRE. Написан, естественно, на Python.


    Docker Machine


    Инструмент для управления удалёнными хостами, на которых установлен Docker. Нами в разработке не используется, но идёт в комплекте с остальным.


    Kitematic


    Графический интерфейс для Docker Engine API с открытым исходным кодом, написанный на JavaScript (Electron).


    Идеально для тех, кто не любит консоль и даже для GIT использует графический интерфейс.


    Инструмент довольно сырой, но рабочий (v0.17.9, > 800 открытых issues).



    Docker — это не только для админов


    Теперь немножко вольных аналогий для фронтенд-разработчиков, чтобы показать, что этот инструмент имеет много общего с привычными для нас, фронтендеров, вещами, такими как Node.js и NPM.


    Image


    Docker-образ. Можем его куда-нибудь опубликовать, например, в DockerHub. А ещё мы можем опубликовать NPM-пакет.


    Dockerfile


    Рецепт для сбора образа. У нас нет рецептов, но есть манифест пакета/приложения — package.json.


    docker build


    Собираем docker-образ. Ну а мы во фронтенде собираем своё приложение — npm run build.


    DockerHub



    Не путать с другим популярным хабом. Это реестр docker-образов. У нас есть свой реестр — NPM Registry.


    docker run


    Консольная команда, которая запускает контейнер. Ближайший аналог из мира фронтенда — команда npm start.


    Проект начат как проприетарная разработка


    Проект Docker начат в 2008 году как внутренняя собственническая разработка компании dotCloud и лишь в марте 2013 был опубликован в open source.


    У нас есть Node.js, который хоть и был изначально open source, но до февраля 2015 года и скандальной истории с io.js находился под управлением компании Joyent.


    Используется для всего подряд


    Все мы знаем, что NPM — это Node Package Manager. Раньше так и было, но сейчас там лежат пакеты не только для Node.js, но и для браузера.


    А ещё там могут лежать не пакеты. При желании туда можно положить набор шрифтов или даже фильм.


    Тоже самое с DockerHub. Туда можно опубликовать что угодно. Никакой премодерации нет.


    Есть альтернативы, призванные заменить


    Все мы знаем, что есть альтернативные менеджеры пакетов, который вы можете использовать, если вам не нравится NPM. Это Yarn, pnpm, jspm.


    Docker тоже можно заменить на альтернативы. Например, Podmad или Buildah.


    Немного рецептов


    Надеюсь, я смог в общих чертах рассказать про этот инструмент.


    В следующей части планирую показать рецепты и конкретные кейсы использования Docker для фронтендера.

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 9

      +2
      Спасибо за статью, жду с нетерпением 3 часть, очень хочется попробовать докер во фронтенде
        +1
        Докер для веб разработки — отличная технология.
        Раньше я статьи на Хабре, где изображены кит и контейнеры просто пролистывал.
        Но вот как-то с партнером подумали, почитали и стали пользоваться. Очень удобно.
        Приведу наш кейс, хотя мы новички, и возможно более опытные нам подскажут как лучше.

        В докере два образа — База Postgres и сервер Апач.
        Файлы проектов в репозитории, их локальные версии в папке, которую прилинковали в образ Апача, а также некоторые конфиги веб сервера.

        Вот так:
        // Postgres
        docker run -d --rm --name db --net mynetwork -p 5432:5432 pg10_oct27
        
        // Apache PHP ...
        docker run -p 80:80 -d --rm --name app --net mynetwork --entrypoint /run-httpd.sh -v /Users/admin/Documents/WWW/:/home/www/ -v /Users/admin/Documents/WWW/virtual.conf:/etc/httpd/conf.d/virtual.conf -v /Users/admin/Documents/WWW/15-xdebug.ini:/etc/php.d/15-xdebug.ini app;
        
        // для MacOS, на Linux не нужно
        sudo ifconfig lo0 alias 10.254.254.254 
        

        Ну и файл hosts должен соответствовать virtual.conf.

        Это все для разработки, а рабочий сервер имеет туже конфигурацию, и слить туда файлы не проблема.

        Вуаля, пашет у меня на Маке и у партнера на Линуксе. Теперь не надо каждому конфигурить сервер, нужные версии базы и PHP, плагины и т.д. Теперь если надо поставить все на ноутбук — не проблема, или если еще участник в проекте, то ему за 15 минут мы можем развернуть готовое рабочее место.

        Людям, сделавшим Докер, выражаю благодарность. Хороший кит.
          0
          Отличный рецепт, спасибо!

          Могу посоветовать ещё посмотреть ещё в сторону Docker Compose.
          Он позволяет создать YAML-файл со всеми настройками и запускать связку контейнером одной командой

          Что-то вроде:

          # docker-compose.yml
          version: '3.7'
          services:
            db:
              ...
              ports:
                - 5432:5432
          
            app:
              ...
              volumes:
              - /Users/admin/Documents/WWW/:/home/www/
              - /Users/admin/Documents/WWW/virtual.conf:/etc/httpd/conf.d/virtual.conf
              - /Users/admin/Documents/WWW/15-xdebug.ini:/etc/php.d/15-xdebug.ini
              ports:
                - 80:80
          


          $ docker-compose up

        0
        ИМХО много сумбура и опять ни о чём. Так зачем для фронтенда Докер-то? Первая часть про бэкенд, вторая теория и про GUI для Мака.

        Не отписался под первой частью:
        Можно сказать, что мы сейчас живём в Эру Docker.

        Да ну? Эру аж с большой буквы? И вы на Маке эту Эру ощутили по сути в виртуалке?

        это запуск API на своём уютном макбуке.

        Вот это это многое объясняет. Уютном макбуке.

        И только сисадмины, похоже, что-то знают.

        Ага, что лишняя прослойка производительности ну никак не прибавляет. И надёжности тоже.

        У меня возникала необходимость запускать у себя на ноутбуке такие вещи, как Ruby, MySQL, PostgreSQL. Это всё довольно плохо работало под Windows, поэтому приходилось использовать виртуализацию.

        Извините, за Ruby не скажу, но MySQL, PostgerSQL, NodeJS (и NPM разумеется), Apache2, PHP, и даже Bind волне себе неплохо живут на Windows без всяких виртуалок, так зачем переходить на Мак (или хакинтош?) и там городить Докер? Не проще ли было тогда просто поставить Linux?
          +1

          Неплохо не значит хорошо. С одной стороны в большинстве таких продуктов Windows поддерживается по остаточному принципу, с другой — в продакшен оно обычно под Linux крутится и нет-нет и различия всплывают, с одной регистронезависимостью windows можно несколько дней потерять.


          Да и под Linux я уже несколько лет предпочитаю под докером проекты запускать. Основная причина: практическое отсутствие проблем с версиями библиотек и сред с минимумом накладных расходов. Из общесистемных зависимостей по сути один Докер да баш в проектах. Ну и какой-то прокси, автоматически настраивающий роуты к вновь поднятому контейнер.


          Да это можно решить другими способами, например через nvm для одного проекта переключаться на 8 ноду, для другого на 10. Но эти способы уникальны для стэка, а для тех же баз я бы вообще не взялся искать способ поставить "нативно" несколько баз паралельно даже одной версии, не говоря о разных.


          Да, сам Докер не без недостатков (одни ухищрения что бы заставить всё прозрачно работать от текущего пользователя чего стоят) и не первая технология контейнеризации под Linux (а кроссплатформенные вообще есть?). Но про эру Докер вполне можно говорить. Возможно конкуренты его скоро вытеснят, или он станет, например, унаследованным рантаймом для k8s. Но принес контейнеры в массы именно он. А от них индустрия уже вряд ли откажется, пока не появится что-то, сочетающее плюсы контейнеров и виртуалок без части их минусов. Bare metal останется только либо для простых проектов, только либо для очень требовательных к производительности/надёжности и при этом не масштабируемых горизонтально.

            0
            Переходить на Mac совершенно не обязательно. Всё это верно и для Windows, и для Linux.
            Я выбрал для примеров Mac, т.к. сам сейчас им пользуюсь, и по моим наблюдениям, много фронтендеров тоже пользуются им.

            В первой части я как раз пытался ответить на вопрос «зачем?».
            Если вкратце, то я подобрал вот такие пункты:

            1. Быстро, без боли и в одну команду разворачиваем нужное окружение (API, БД, сервисы) на рабочем компьютере (Mac, Windows, Linux)
            2. Уменьшаем риск сломать хост-систему, ставя на компьютер абстрактную Java
            3. Сами готовим своё приложение к продакшену и отвечаем за его эксплуатацию
            +1
            Спасибо за расшифровку! Материал действительно интересный, а для меня ещё и актуальная тема!
              +1
              А третьей части так и нет :( Avdeev
                +1

                Спасибо, что следите. :)


                В течение месяца будет.
                Я недавно провёл МК на РИТ++, сейчас подсоберу материал с подготовки к нему и сделаю третью часть.


                Что интересно, уже можно немного обновить первые две части. Например, Kitematic отлично заменяется на встроенный Docker Desktop Dashboard.

              Only users with full accounts can post comments. Log in, please.