Фон

Я Full Stack разработчик в Kontinentalist, где я занимаюсь разработкой как внешней, так и внутренней стороны Konti, а также ее сервера и DevOps. В Kontinentalist наши истории сопровождаются картами и визуализацией данных (ознакомьтесь с нашим последним рассказом о странных животных в Азии здесь). В настоящее время нашим основным продуктом являются наши истории, хотя мы работаем над нашим следующим основным продуктом под названием Платформа карт, который будет универсальной базой геопространственных данных для информации об Азии.

Наш повседневный рабочий процесс разработки выглядит следующим образом: мы разрабатываем серверную часть и интерфейсную часть отдельно, что означает, что они находятся в разных репозиториях. Впоследствии мы развертываем все, от репозитория до облачного сервера, который был настроен для производственной среды.

Проблема

В то время мы не виртуализировали и не контейнеризовали нашу среду разработки. Вместо этого мы разработали приложения на локальных машинах, а затем сразу развернули их на облачном сервере. Спорим, ты догадываешься, что произошло потом. Произошла ошибка типа «это работает на моем локальном компьютере, но не на моем производственном компьютере», что было настолько неприятно, поскольку нам нужно было выяснить, чего не хватает, в чем разница и т. Д. Между нашими местные и производственные машины.

Мы решили, что для решения этой проблемы мы должны изолировать приложения в среде. Вместо того, чтобы отправлять основной источник приложения на облачный сервер для развертывания, мы развернули всю среду. Этот подход можно было бы реализовать, используя виртуальные машины, такие как Vagrant, в качестве среды разработки. Но виртуальная машина не идеальна, если нам нужен быстрый процесс разработки *; требуется гигабайт памяти и кучу времени только для того, чтобы запустить разработку одного приложения.

* Мы серьезно относимся к скорости, эффективности и результативности процесса разработки в Kontinentalist 😌.

Решение

Докер был решением. Это позволило нам решить нашу проблему, позволив нам контейнеризовать нашу среду разработки, и по причинам, которые будут описаны ниже, Docker работает лучше, чем виртуальные машины (и это бесплатно!). Кстати, Docker не платит нам за то, чтобы мы говорили об этом!

Что такое Докер?

Docker - это компьютерная программа, которая выполняет виртуализацию на уровне операционной системы, также известную как контейнеризация. Он был впервые выпущен в 2013 году и разработан Docker, Inc. Docker используется для запуска программных пакетов, называемых контейнерами. - Википедия

В качестве средства виртуализации Docker по-прежнему считается виртуальной машиной, но он более мощный. Я приложил краткое описание различий между Docker и виртуальными машинами.

Docker работает поверх уровня операционной системы и изолирует приложения по контейнерам. Все бункеры / библиотеки, необходимые для приложений из операционной системы, доступны в контейнерах без установки всей операционной системы. Это означает, что каждая среда не требует установки операционной системы, что делает работу настолько эффективной!

Как это работает

Для начала вам необходимо установить Docker Engine на вашу машину. Это основное приложение, которое создает и запускает контейнеры с использованием компонентов Docker.

Говоря с точки зрения программирования, представьте контейнер как экземпляр / объект из класса, а сам класс в Docker называется изображением. Это так просто 😉.

Позвольте мне немного подробнее рассказать о компонентах Docker, прежде чем мы перейдем к процессам Docker:

  • Клиент Docker - это служба интерфейса командной строки, которая отправляет команды через REST API в Docker Daemon.
  • Docker Daemon - это сервер Docker; как он общается через REST API от клиента.
  • Образ Docker - это главный файл, используемый для создания контейнеров Docker.
  • Контейнер Docker - это работающий экземпляр образа Docker.
  • Реестр Docker - это служба, используемая для размещения и распространения образов Docker. По умолчанию Реестр Docker - Docker Hub.

А теперь самое интересное - давайте разберемся, что происходит под капотом!

  1. Клиент отправляет команды с помощью интерфейса командной строки через протокол REST API демону докера. Когда команда предназначена для создания образов, например docker build…
  2. … Демон отправит запрос на получение определенного образа из реестра. По умолчанию реестр находится в Docker-хабе.
  3. Затем демон докера загрузит образ из репозитория реестра образа, который он запросил.
  4. Как только образ будет загружен на ваш компьютер, начнется сборка контейнера. Когда все контейнеры будут подняты, можно начинать! Ура, теперь у вас волшебным образом будут установлены все службы / серверы / все, что вы хотите, на вашем компьютере!

Довольно удобно, да?

Dockerfile

Когда вы выбираете сборку докеров, демон докеров будет искать файл с именем Dockerfile. Dockerfile - это файл, который создает контейнер, который состоит из инструкций о том, каким должен быть контейнер, какие службы вы хотите установить, какие сценарии подготовки вы хотите настроить и т. Д., Тогда оставшийся процесс будет как показано на рис. 4. После того, как образ, который вы определили из файла Docker, был успешно построен, вы можете запустить контейнер, набрав команду docker run (и указав образ, который вы хотите создать контейнер из). Затем он выполнит поиск указанного вами изображения, и как только контейнер будет открыт, все готово.

На рисунке выше показан пример Dockerfile. Он в основном сообщает демону докера установить php с версией 7.1-fpm (строка 1) и установить расширения php, которые были определены в Dockerfile впоследствии (строка 3 и далее). Вы можете ознакомиться со списком команд и соответствующих служб в документации Dockerfile в Docker Hub, то есть в данном случае на php. Документация аккуратная и легкая для понимания.

Использовать Dockerfiles для установки сервисов в контейнере просто, если у вас мало контейнеров, но при этом возникает новая проблема.

Docker Compose

Вот где на помощь приходит Docker Compose!

Docker compose помогает упростить процесс запуска контейнеров. Вместо того, чтобы последовательно запускать файлы Docker из интерфейса командной строки, вам просто нужно отправить одну команду для запуска одного файла создания докеров, запуск docker-compose,, затем все изображения и контейнеры, которые вы установили. вверх из docker-compose.yml.

В приведенном выше файле docker-compose определены три службы: nginx, php и mysql. Это действительно удобно, когда у вас есть несколько контейнеров для запуска, потому что с помощью одной команды эти службы будут установлены и доступны на вашем компьютере из портов, которые вы определили.

Как мы использовали Docker?

Мы говорили о том, как работает Docker, а теперь поговорим о том, как мы его используем в Kontinentalist.

Мы настраиваем структуру проекта, как указано выше. Вот разбивка:

  • Папка etc состоит из необходимых файлов и папок для каждой службы (Dockerfile, файлы конфигурации и т. д.).
  • Папка src является основным источником проекта.
  • И последнее, но не менее важное: файлы. env и docker-compose находятся в корневом каталоге проекта.

Мы не смешали все в корневом каталоге по трем причинам. Во-первых, чтобы упростить доступ к каждому компоненту. Во-вторых, мы не хотели загромождать контейнер, который монтируется основным файлом проекта, ерундой (например, файлами докеров и т. Д.). В связи с этим мы думаем, что эта структура более аккуратная 😙.

Также да, у нас есть два файла для создания докеров, docker-compose.local.yml и docker-compose.production.yml. Это необязательно. Это действительно зависит от ваших предпочтений в отношении вашего рабочего сервера. Для нас, несмотря на то, что мы перешли с «обычного » метода на Docker, мы по-прежнему используем базу данных с предыдущего сервера. Различия между двумя файлами докеров - это база данных. Мы запускаем базу данных из контейнера на локальном компьютере и порты, которые мы предоставляем для каждой службы.

Чтобы запустить приложение, мы просто запускаем одну команду:

docker-compose -f docker-compose. [локальный / производственный] .yml run -d

И чтобы остановиться:

docker-compose -f docker-compose. [локальный / производственный] .yml down -v

Заключение

Подведем итоги, почему мы перешли на Docker!

  1. Переносимость - устраняет основную проблему «работает на моем локальном компьютере, но не работает на производственном компьютере». Нам больше не нужно беспокоиться о том, какие машины и конфигурации использовать для нашей разработки и производства, поскольку все настроено и работает точно так, как определено в Dockerfile.
  2. Скорость - увеличивает скорость разработки, поскольку не нужно загружать и устанавливать операционную систему только для одной среды. Кроме того, время настройки будет короче, поскольку не нужно устанавливать новую операционную систему.
  3. Производительность - оборудование эмулируется виртуальными машинами, в то время как Docker запускает приложения в изолированных контейнерах непосредственно в операционной системе хоста (или на сервере, на котором они размещены), что означает, что приложения, работающие в контейнерах Docker, имеют меньше накладных расходов. а также будет работать быстрее.
  4. Эффективно - поскольку для этого не требуется вся операционная система, занимающая ГБ пространства, размер проекта будет меньше.

Вот и все! Просто и аккуратно, правда? 😊