Avdeev 5 дек 2019 в 19:11

Docker для фронтендера. Часть 1. Зачем?

5 мин

29K

Веб-разработка*JavaScript*HTML*

Технотекст 2020

Из песочницы

+18

Комментарии 26

musuk 5 дек 2019 в 19:32

docker-compose up api

Как просто!

Кроме API нужно ещё поднять конейнер с elastic, mongo запихать данные в mongo и проиндексировать их эластиком. Причём пихать данные нужно только когда у вас подымутся Mongo и эластик. А их ещё надо и сконфигурить.

usego 5 дек 2019 в 19:37

Делается преднастроеный докерок эластика с данными и всё вместе линкуется одним компоузом. И индексировать эластиком монго… Это как?

musuk 5 дек 2019 в 20:59

docker-compose не ждёт когда подымется mongo или elastic, он знает только запущен конейнер или нет. docker-compose для такой цели можно написать и решить всё через, но он будет довольно сложной штукой с кучей логики в entrypoint.sh
Для таких целей должно быть что-то более умное, чем docker-compose.

usego 5 дек 2019 в 22:10

ну так и апликуха не должна насмерть валиться от кратковременного офлайна эластика

musuk 5 дек 2019 в 22:46

Это да, но чтобы заполнить эластик вам нужны данные в монге, те дождаться, когда отработают все mongorestore.
Чтобы начать заполнять монгу через mongorstore вам нужно знать, что mongo поднялась (ей на это время нужно). Чтобы заполнять эластик вам нужно тоже дождаться, пока подымется эластик. Сам docker-compose всё это не умеет. Те поднять всё одной командой docker-compose up api без вороха sh-скриптов не выйдет.

И индексировать эластиком монго… Это как?

Это использовать эластик как полнотекстовый поиск, а документы хранить в mongo/postgresql.

usego 6 дек 2019 в 00:50

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

musuk 6 дек 2019 в 10:36

Так для разработки и нужно, чтобы каждое добавление поля в базу бэкендером сразу же было доступно фронтам. Причём чем интенсивнее разработка, тем быстрее должно обновляться API и база.
Иметь образа с данными можно, но строить такие образы намного сложнее. По мне пока самый простой способ, это делать образ уже запущенного и модифицированного контейнера. Те я не знаю, как описать рестор данных в рамках Dockerfile.
Потом для автоматического построения всех этих образов нужна инфраструктура, причём она должна куда-то публиковать образа. А образа должны быть специфичны для веток в которых идёт разработка. Ведь в разных ветках могут быть разные поля в базе. Ну и операция переключения между ветками для фронта будет тоже не такой тривиальной.

usego 6 дек 2019 в 10:42

Мы используем локальный гитлаб, там вся необходимая инфраструктура встроена. Да, время вложить в «поразбираться» придётся, но где это сейчас не требуется? Я это к тому, что проблемы как таковой нет, при наличии правильного инструментария и процессов.

Avdeev 6 дек 2019 в 12:14

Отличное замечание, я про это не рассказал.

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

Мы делаем вот так:

1. docker-compose up api собирает связанные через depends_on образы и запускает их.
2. Все команды на запущенных контейнерах стараемся убирать в Makefile.

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

# Makefile
migrate:
  docker-compose run api bundle exec rake db:migrate

Stormwalker 6 дек 2019 в 13:48

depends_on не делает liveness-readiness проверок, просто проверяет состояние контейнера. Лучше уж сказать, чтобы сделал

docker-compose up -d backend frontend elastic redis postgres

и увидел заветную запись в логах, если надо что-то сделать. Еще есть костыли типа wait-for-it.sh.

Команды в Makefile поддерживаю, главное чтобы они не расползались по другим местам :)

inoyakaigor 5 дек 2019 в 20:54

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

Avdeev 6 дек 2019 в 12:02

После доклада меня спрашивали несколько раз про этот подход, когда фронтенд-разработчик всё запускает не локально, а использует отдельный staging- или dev-сервер для разработки.

Этот способ работает и имеет свои плюсы, но не лишен и недостатков.

Вот некоторые из них:

Невозможность работать офлайн или при плохом Интернете. Многие любят работать из дома, деревни или в дороге.
Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками. У нас были случаи, когда приходилось создавать необходимую для разработки сущность новости с названием «НЕ УДАЛЯТЬ!», чтобы кто-то её случайно не грохнул. Но, всё равно это периодически случалось.
Такой сервер достаточно хрупкий. Было несколько ситуаций, когда бекенд-разработчики или эскплуатация начинали шатать сервак. Или, к примеру, накатывали туда какие-нибудь ломающие изменения. Это останавливало разработку у всей команды.

musuk 6 дек 2019 в 13:31

Работаем в распредёлнной команде по такой схеме.

Невозможность работать офлайн или при плохом Интернете.

Хороший интернет в наше время must have. Без него вообще плохо.

Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками.

Почти никогда у нас это не проблема, но зависит от проекта, конечно.

Такой сервер достаточно хрупкий.

Да, он хрупкий (хотя перед выкладкой прогоняются тесты), но понять почему у фронта упало бекендерам сильно проще, потому что обший сервер пишет логи.

Есть более важная проблема при таком подходе: очень сложно иметь по серверу на фиче-ветку. Можно сделать front-ветку на каждого фронта и если фронту нужно переключиться на какую-то фиче ветку, то то эту ветку мерджат в front-ветку и CI/CD её строит. Однако это запарано, потому народ всё льёт в master.

Avdeev 6 дек 2019 в 14:41

Да, кстати, об это я не подумал. Хороший кейс.

Локальное разворачивание позволяет развернуть у себя любую ветку API.

Например, вот так:

cd api
git checkout feature/branch
docker-compose build api
make migrate
docker-compose up api

musuk 6 дек 2019 в 15:02

Мы в итоге, к тому же и пришли. Только у нас не make migrate, а большой скрипт, который инициализирует окружение. Только вот для запуска этого скрипта надо локально установить кучу всего, например, чтобы сделать mongorestore нужно поставить mongo-tools, чтобы проиндексировать эластик, надо собрать соответствующий кусок приложухи, для сборки которого нужно поставить SDK. Так что да, вынести сервера бд в отдельные контейнеры можно, но SDK всё равно надо будет ставить и настраивать.

Avdeev 6 дек 2019 в 15:32

Не уверен, но, думаю, можно попробовать сделать образ с SDK, который при старте инициализирует окружение.

vasyapivo 5 дек 2019 в 21:02

* go1.11
* MySQL
* Redis
* Elasticsearch
* Capistrano
* syslog
* PostgreSQL

Сколько памяти отъест виртуалка на MacOS/windows чтобы гонять это всё в контейнерах?

lasc 6 дек 2019 в 06:17

на 16 можно жить.

TheRaven 6 дек 2019 в 11:23

Нельзя. Буквально вчера развернул себе бекенд на 12 (!) контейнерах, запустил фронт, IDE, Skype, Firefox, AIMP… и память всё, кончилась. Хорошо что вся эта требуха докерная сама спрятана в виртуалку, сегодня буду её на отдельную тачку выносить.

Avdeev 6 дек 2019 в 11:47

Оно всё достаточно легковесное, в этом и прелесть Docker. Вот пример вывода 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 МБ.

У нас у разработчиков от 8 до 16 ГБ оперативной памяти. Обычно, этого хватает.

По личному опыту, большую часть оперативной памяти во время разработки съедает IDE, Chrome, Telegram, Slack, а не запущенные docker-контейнеры.

vasyapivo 6 дек 2019 в 11:53

Но ведь вопрос не в том, сколько памяти потребляет контейнер, вопрос в том, сколько ест виртуалка без которой вы на MacOS или Win ничего не сможете сделать. Docker build выполняется именно на виртуалке, и если сама апа ест 14 мегабайт, то вопрос в том, сколько будет жрать ресурсов docker build.

Avdeev 6 дек 2019 в 12:44

Да, Вы правы. Плюс ещё примерно 4 ГБ на виртуалку на MacOS.

TheGodfather 23 дек 2019 в 22:55

А какая разница, сколько ест docker build? Он выполняется в общем случае на произвольной машине, не совпадающей с сервером и один раз. А все занимаемое время уже сбилженный контейнер просто работает.