Comments 26
docker-compose up api
Как просто!
Кроме API нужно ещё поднять конейнер с elastic, mongo запихать данные в mongo и проиндексировать их эластиком. Причём пихать данные нужно только когда у вас подымутся Mongo и эластик. А их ещё надо и сконфигурить.
Делается преднастроеный докерок эластика с данными и всё вместе линкуется одним компоузом. И индексировать эластиком монго… Это как?
docker-compose не ждёт когда подымется mongo или elastic, он знает только запущен конейнер или нет. docker-compose для такой цели можно написать и решить всё через, но он будет довольно сложной штукой с кучей логики в entrypoint.sh
Для таких целей должно быть что-то более умное, чем docker-compose.
Для таких целей должно быть что-то более умное, чем docker-compose.
ну так и апликуха не должна насмерть валиться от кратковременного офлайна эластика
Это да, но чтобы заполнить эластик вам нужны данные в монге, те дождаться, когда отработают все mongorestore.
Чтобы начать заполнять монгу через mongorstore вам нужно знать, что mongo поднялась (ей на это время нужно). Чтобы заполнять эластик вам нужно тоже дождаться, пока подымется эластик. Сам docker-compose всё это не умеет. Те поднять всё одной командой docker-compose up api без вороха sh-скриптов не выйдет.
Это использовать эластик как полнотекстовый поиск, а документы хранить в mongo/postgresql.
Чтобы начать заполнять монгу через mongorstore вам нужно знать, что mongo поднялась (ей на это время нужно). Чтобы заполнять эластик вам нужно тоже дождаться, пока подымется эластик. Сам docker-compose всё это не умеет. Те поднять всё одной командой docker-compose up api без вороха sh-скриптов не выйдет.
И индексировать эластиком монго… Это как?
Это использовать эластик как полнотекстовый поиск, а документы хранить в mongo/postgresql.
Зачем весь этот рестор, если можно иметь докера с уже проиндексированными данными? Оно ведь для разработки. Достаточно иметь плюс минус актуальный снэпшот.
Так для разработки и нужно, чтобы каждое добавление поля в базу бэкендером сразу же было доступно фронтам. Причём чем интенсивнее разработка, тем быстрее должно обновляться API и база.
Иметь образа с данными можно, но строить такие образы намного сложнее. По мне пока самый простой способ, это делать образ уже запущенного и модифицированного контейнера. Те я не знаю, как описать рестор данных в рамках Dockerfile.
Потом для автоматического построения всех этих образов нужна инфраструктура, причём она должна куда-то публиковать образа. А образа должны быть специфичны для веток в которых идёт разработка. Ведь в разных ветках могут быть разные поля в базе. Ну и операция переключения между ветками для фронта будет тоже не такой тривиальной.
Иметь образа с данными можно, но строить такие образы намного сложнее. По мне пока самый простой способ, это делать образ уже запущенного и модифицированного контейнера. Те я не знаю, как описать рестор данных в рамках Dockerfile.
Потом для автоматического построения всех этих образов нужна инфраструктура, причём она должна куда-то публиковать образа. А образа должны быть специфичны для веток в которых идёт разработка. Ведь в разных ветках могут быть разные поля в базе. Ну и операция переключения между ветками для фронта будет тоже не такой тривиальной.
Отличное замечание, я про это не рассказал.
Действительно, полностью избавиться от инструкций и команд не получается.
Мы делаем вот так:
1. docker-compose up api собирает связанные через depends_on образы и запускает их.
2. Все команды на запущенных контейнерах стараемся убирать в Makefile.
Что-то вроде:
Действительно, полностью избавиться от инструкций и команд не получается.
Мы делаем вот так:
1. docker-compose up api собирает связанные через depends_on образы и запускает их.
2. Все команды на запущенных контейнерах стараемся убирать в Makefile.
Что-то вроде:
# Makefile
migrate:
docker-compose run api bundle exec rake db:migrate
depends_on не делает liveness-readiness проверок, просто проверяет состояние контейнера. Лучше уж сказать, чтобы сделал
Команды в Makefile поддерживаю, главное чтобы они не расползались по другим местам :)
docker-compose up -d backend frontend elastic redis postgresКоманды в Makefile поддерживаю, главное чтобы они не расползались по другим местам :)
На прошлой работе также было, дерьма с этим хлебнул знатно. Сейчас же все запросы к апи проксирую через Nginx на стейджовый сервер, проблем не знаю и рекомендую всем сделать также и закопать, наконец, эту стюардессу
После доклада меня спрашивали несколько раз про этот подход, когда фронтенд-разработчик всё запускает не локально, а использует отдельный staging- или dev-сервер для разработки.
Этот способ работает и имеет свои плюсы, но не лишен и недостатков.
Вот некоторые из них:
Этот способ работает и имеет свои плюсы, но не лишен и недостатков.
Вот некоторые из них:
- Невозможность работать офлайн или при плохом Интернете. Многие любят работать из дома, деревни или в дороге.
- Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками. У нас были случаи, когда приходилось создавать необходимую для разработки сущность новости с названием «НЕ УДАЛЯТЬ!», чтобы кто-то её случайно не грохнул. Но, всё равно это периодически случалось.
- Такой сервер достаточно хрупкий. Было несколько ситуаций, когда бекенд-разработчики или эскплуатация начинали шатать сервак. Или, к примеру, накатывали туда какие-нибудь ломающие изменения. Это останавливало разработку у всей команды.
Работаем в распредёлнной команде по такой схеме.
Хороший интернет в наше время must have. Без него вообще плохо.
Почти никогда у нас это не проблема, но зависит от проекта, конечно.
Да, он хрупкий (хотя перед выкладкой прогоняются тесты), но понять почему у фронта упало бекендерам сильно проще, потому что обший сервер пишет логи.
Есть более важная проблема при таком подходе: очень сложно иметь по серверу на фиче-ветку. Можно сделать front-ветку на каждого фронта и если фронту нужно переключиться на какую-то фиче ветку, то то эту ветку мерджат в front-ветку и CI/CD её строит. Однако это запарано, потому народ всё льёт в master.
Невозможность работать офлайн или при плохом Интернете.
Хороший интернет в наше время must have. Без него вообще плохо.
Необходимость делить один и тот же ресурс с другими разработчиками и тестировщиками.
Почти никогда у нас это не проблема, но зависит от проекта, конечно.
Такой сервер достаточно хрупкий.
Да, он хрупкий (хотя перед выкладкой прогоняются тесты), но понять почему у фронта упало бекендерам сильно проще, потому что обший сервер пишет логи.
Есть более важная проблема при таком подходе: очень сложно иметь по серверу на фиче-ветку. Можно сделать front-ветку на каждого фронта и если фронту нужно переключиться на какую-то фиче ветку, то то эту ветку мерджат в front-ветку и CI/CD её строит. Однако это запарано, потому народ всё льёт в master.
Да, кстати, об это я не подумал. Хороший кейс.
Локальное разворачивание позволяет развернуть у себя любую ветку API.
Например, вот так:
Локальное разворачивание позволяет развернуть у себя любую ветку API.
Например, вот так:
cd api
git checkout feature/branch
docker-compose build api
make migrate
docker-compose up api
Мы в итоге, к тому же и пришли. Только у нас не make migrate, а большой скрипт, который инициализирует окружение. Только вот для запуска этого скрипта надо локально установить кучу всего, например, чтобы сделать mongorestore нужно поставить mongo-tools, чтобы проиндексировать эластик, надо собрать соответствующий кусок приложухи, для сборки которого нужно поставить SDK. Так что да, вынести сервера бд в отдельные контейнеры можно, но SDK всё равно надо будет ставить и настраивать.
* go1.11
* MySQL
* Redis
* Elasticsearch
* Capistrano
* syslog
* PostgreSQL
Сколько памяти отъест виртуалка на MacOS/windows чтобы гонять это всё в контейнерах?
на 16 можно жить.
Оно всё достаточно легковесное, в этом и прелесть Docker. Вот пример вывода
Видим, что БД заняла 19 МБ, а API на Java — 352 МБ.
У нас у разработчиков от 8 до 16 ГБ оперативной памяти. Обычно, этого хватает.
По личному опыту, большую часть оперативной памяти во время разработки съедает IDE, Chrome, Telegram, Slack, а не запущенные 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-контейнеры.
Респект автору!
Крутой доклад, спасибо :-)
Надо попробовать, жду второй доклад :)
Sign up to leave a comment.
Docker для фронтендера. Часть 1. Зачем?