Docker для локальной веб-разработки - введение
Всем привет! Эта статья начинает серию переводов замечательных статей об использовании Docker для локальной веб-разработки.
В этой серии⚓︎
- Введение: почему это должно вас волновать? ⬅️ вы здесь
- Часть 1: базовый стек LEMP
- Часть 2: посадите свои образы на диету
- Часть 3: трёхуровневая архитектура с фреймворками
- Часть 4: сглаживание ситуации с помощью Bash
- Часть 5: HTTPS для всего
- Часть 6: открываем локальный контейнер для доступа в Интернет
- Часть 7: использование многоэтапной сборки для внедрения воркера
- Часть 8: запланированные задачи
- Заключение: куда идти дальше
Для кого эта серия уроков⚓︎
Среди разработчиков знакомство с Docker варьируется от смутно слышавших об этой технологии до использующих её на ежедневной основе, причем последняя категория поет ей дифирамбы, в то время как первая иногда всё ещё борется с самой концепцией контейнеров.
Где бы вы ни находились на своем пути, у вас, как у разработчика, есть множество причин, по которым вы можете захотеть изучить эту технологию, включая, но не ограничиваясь этими:
«Я прочитал несколько статей о Docker и теперь ищу что-то более практичное»
«Я использую решение на базе Vagrant (такое как Homestead), но сталкиваюсь с некоторыми ограничениями»
«Я уже использую готовое решение, такое как Laradock, и хочу понять, как всё работает под капотом»
«Я хочу получить больший контроль над средой разработки»
«Я хочу лучше понять архитектуру приложений»
«Мой текущий проект использует микросервисы»
Какими бы ни были ваши мотивы, вы можете заметить появление темы, связанной с пониманием и контролем. На мой взгляд, Docker — это расширение возможностей разработчика, от предоставления безопасной среды, в которой можно легко опробовать технологии, не испортив локальное окружение, до открытия ворот в мир ИТ.
Целью этой серии уроков является демистификация технологии, которая иногда может показаться пугающей, при этом предоставляя большинство инструментов, которые могут понадобиться разработчику для локального создания веб-проекта с помощью Docker. Основное внимание уделяется среде разработки и не рассматривается развёртывание приложений Docker, хотя конечный результат может стать основой для развёртываемой установки.
Предварительных знаний о Docker не требуется, но умение работать с терминалом будет полезно, также как и знакомство с Git по SSH.
Мы начнем наш путь с базового стека LEMP и постепенно будем увеличивать сложность среды по мере продвижения, охватывая всё больше и больше примеров использования. Хотя основное внимание уделяется PHP на стороне сервера, общие принципы могут быть применены к любому языку.
Вы можете обнаружить, что остановились на определенном этапе, потому что все ваши потребности уже были покрыты, только чтобы вернуться позже, когда вам понадобится больше. В любом случае, каждая часть серии сопровождается собственной веткой Git, которую вы можете форкнуть или скачать и использовать в качестве отправной точки для собственных проектов.
Вот и всё, что касается лифта. Уже убедились? Отлично, давайте перейдем к первой части. Если нет, давайте попробуем развеять некоторые сомнения, которые у вас ещё могут быть, начиная с небольшой биографической справки.
«Почему я должен тебя слушать?»⚓︎
Я бэкенд-разработчик с более чем десятилетним опытом, работавший с различными типами компаний в трех разных странах. Я наблюдал эволюцию среды разработки с течением времени, начиная с первых дней использования WAMP и Notepad++ и заканчивая переходом на полноценные IDE и собственные виртуальные машины, затем перешел на Vagrant и, в конечном итоге, Homestead.
Ещё в 2015 году я изучал возможность использования Docker локально в качестве среды разработки и написал об этом в паре статей, которые были подхвачены тогдашним бюллетенем Docker, но в итоге отказался от этой идеи, в основном из-за проблем с производительностью.
Однако в начале 2018 года я был вынужден вернуться к этой идее, поскольку Vagrant начал демонстрировать свои ограничения в проекте, над которым я тогда работал (подробнее об этом в следующем разделе). Снова изучив Docker, я понял, что прогресс был достигнут как в плане производительности, так и в плане внедрения.
Повозившись несколько дней, я создал достойную среду разработки, способную справиться со сложностью приложения и, как я вскоре понял, значительно упростить работу новых разработчиков.
С тех пор я успешно внедрил и усовершенствовал аналогичную систему в нескольких компаниях.
«Я уже пользуюсь услугами Vagrant/Homestead»⚓︎
Homestead — это здорово. Я использовал готовую виртуальную машину (VM) Laravel в течение многих лет, как для личных проектов, так и для проектов клиентов. В ней есть практически всё, что нужно для PHP-приложений, и она позволяет очень быстро создавать новые сайты.
Почему же я перешел на новую версию?
Короткий ответ — микросервисы.
Ещё в начале 2018 года передо мной была поставлена задача раскрыть API из устаревшего монолита для обслуживания нового одностраничного приложения и постепенно выводить монолит из эксплуатации, извлекая всю его бизнес-логику в микросервисы. Счастливые дни.
Внезапно мне пришлось управлять устаревшим кодом на PHP 5.x, с одной стороны, и микросервисами на PHP 7.x, с другой.
Вначале я заставил обе версии языка работать на одной виртуальной машине, но это потребовало некоторых грязных обходных путей, которые сделали общий пользовательский опыт ужасным. Кроме того, со временем мне потребовалось бы добавить другие микросервисы с разными стеками, и управлять ими всеми на одной виртуальной машине было нереально.
Я недолго пытался запустить отдельные блоки Vagrant для каждого микросервиса, но запуск всей установки оказался слишком тяжелым для моей машины, а управление такими вещами, как связь между виртуальными машинами, казалось очень громоздким.
Мне нужно было что-то другое, и этим чем-то другим стал Docker. Но как он может помочь в данной ситуации?
Одним из обещаний Docker является предоставление изолированных сред (контейнеров), работающих на одной виртуальной машине, за несколько секунд. В моем случае это означало замену всех моих тяжелых виртуальных машин Vagrant на одну сверхбыструю виртуальную машину с Docker и запуск всех моих микросервисов поверх нее, каждый в своем изолированном контейнере.
Используя собственный логотип Docker в попытке проиллюстрировать это, можно сказать, что это напоминает переход от каждого ящика, требующего отдельного кита для переноски, к одному киту, переносящему все ящики, как показано на рисунке.
Теперь вернитесь к предыдущему предложению и замените «кит» на «виртуальную машину», а «ящик» на «микросервис» — вы должны понять идею.
Несмотря на то, что это слишком упрощенное объяснение, именно этот момент стал для меня решающим. Для меня, как разработчика, этот сценарий использования имел идеальный смысл и повлиял на то, как я работал на ежедневной основе, гораздо больше, чем попытки понять, как работает виртуализация или общие операционные системы.
Означает ли это, что вы должны использовать Docker локально, только если ваше приложение включает микросервисы?
Ответ — и да, и нет. Чем сложнее приложение — чем из большего количества подвижных частей оно состоит — тем больше вероятность того, что вам понадобится такое решение, как Docker.
Но даже если ваше приложение довольно простое, запуск и остановка нескольких контейнеров намного быстрее, чем загрузка и остановка виртуальной машины, а в случае, если ваше приложение будет развиваться каким-то неожиданным образом (как это всегда бывает), использование Docker с самого начала даст вам уверенность в том, что ваша система будет защищена от будущего.
Кроме того, вместо использования готовой виртуальной машины типа Homestead, содержащей гораздо больше инструментов, чем нужно для конкретного приложения, использование Docker так, как я предлагаю, гарантирует, что вы установите только то, что вам действительно нужно, в проактивном режиме. Вы вновь обретаете контроль над своим окружением.
«Как насчет [вставьте любимое решение на базе Docker]?»⚓︎
Уже существует множество сред разработки на базе Docker, и кажется, что новые появляются каждую неделю.
Laradock был, пожалуй, первым, получившим некоторую популярность, и является для Docker тем же, чем Homestead является для Vagrant: предварительно упакованной средой для PHP-приложений. Хотя я лично не использую его, я слышал много хорошего, и он может оказаться достаточным для ваших нужд. Их девиз — «Сначала используйте Docker, а потом изучайте его», что, на мой взгляд, является отличным подходом.
Laravel представила Sail (свою официальную среду на базе Docker) в конце 2020 года; есть также Takeout, DDEV и, я уверен, множество других, которые очень хороши в своем деле.
Однако цель этой серии — дать вам более глубокое понимание Docker, чтобы вы могли создать свою собственную среду, идеально соответствующую требованиям любого проекта. Если всё, что вы хотите сделать на данный момент — это использовать среду на базе Docker, не утруждая себя самостоятельной настройкой, то, конечно, попробуйте одно из вышеупомянутых решений, и не стесняйтесь вернуться, когда захотите создать свою собственную, индивидуальную установку.
В целом, я рассматриваю этот бум сред на базе Docker как хороший знак — подтверждение того, что это подходящий инструмент для работы, который в будущем получит более широкое распространение.
«Бессерверные вычисления — это путь к успеху»⚓︎
Бессерверные вычисления находятся на подъеме, и поговаривают, что они придут на смену Docker.
Между тем, другие утверждают, что сравнение спорно, поскольку эти две технологии служат совершенно разным целям.
Что касается локальной разработки, то сравнение в основном не имеет значения 0 бессерверные или нет, вам понадобится локальная среда для создания ваших проектов, и какими бы ни были их спецификации, Docker подойдет для этого.
«Производительность ужасна»⚓︎
Раньше она была ужасной. Сейчас она в основном в порядке.
Производительность в Linux всегда была на высоте, а после выхода WSL 2 она стала хорошей и в Windows.
Остается macOS, где скорость остается болевой точкой в зависимости от контекста, из-за низкой производительности базовой реализации совместного использования файлов (gRPC-FUSE). Однако есть способы улучшить её, которые упоминаются в этой серии статей.
Хотя вы вряд ли получите такую же скорость, как в Homestead или в Valet, она будет приемлемой.
«В мои обязанности не входит работа с Docker»⚓︎
Наконец, некоторые разработчики просто отвергают Docker, считая, что это не их проблема. Это справедливое замечание, поскольку Docker находится где-то за пределами сферы разработки приложений. Если уж на то пошло, сисадмин или инженер DevOps должны настроить его для вас, верно?
Хотя вы имеете право так думать, DevOps не только относится к людям, заинтересованным как в системном администрировании, так и в кодинге, эффективно действуя как мосты между ними, но и может рассматриваться как люди с обеих сторон, встречающиеся на полпути.
Справедливости ради следует отметить, что вам не нужно знать Docker, чтобы быть хорошим разработчиком. Я просто хочу сказать, что, игнорируя его, вы упускаете возможность стать лучше.
Он не улучшит ваш синтаксис и не научит вас новым паттернам проектирования, но он поможет вам понять, как написанный вами код вписывается в общую картину.
Это похоже на игру на инструменте без обучения нотной грамоте: вы можете звучать хорошо, но вряд ли сможете написать симфонию. Если сделать шаг назад и поразмышлять над архитектурой приложения, чтобы понять, как различные части подходят друг другу, это даст вам бесценную перспективу, которая повлияет на технический выбор, который вы сделаете для своего приложения.
Независимо от вашей специализации — backend, frontend или fullstack — и в какой бы степени вы ни относились к движению DevOps, я обещаю, что изучение шестеренок, которые заставляют ваши приложения работать, стоит вашего времени, и вы станете лучшим разработчиком благодаря этому.
Всё дело в путешествии⚓︎
В конечном счете, вы можете не полностью принять конечный результат этой серии. Будь то по причинам производительности, как упоминалось ранее, или потому, что вы чувствуете, что некоторые аспекты настройки слишком сложны или не работают для вас, эта среда разработки может не полностью удовлетворить вас в предложенном виде.
Но это не является истинной целью данной серии статей. Хотя вы можете принять мой подход за чистую монету, моя главная цель — дать вам достаточно уверенности, чтобы интегрировать Docker в ваш рабочий процесс разработки любым способом, который вы считаете нужным — предоставить достаточно практических знаний, чтобы адаптировать его к вашим собственным условиям использования.
И я могу гарантировать, что к концу этой серии у вас появится множество идей о том, как использовать Docker с пользой для себя.
Ну так что вы решили? Начнём изучение Docker?
Оригинальная статья: Docker for local web development, introduction: why should you care? (English)