JohnDaniels
@JohnDaniels

Как правильно организовать разработку с использованием docker?

Да, таких вопросов тут много, пусть будет еще один).

Мне нужно привести в порядок работу над большим приложением, и я немного в затруднении.
Дано: 2 бэкенда (логика - symfony, api - lumen), 3 фронта (vue), sphinx, rabbitMQ, supervisor, еще куча всего + службные скрипты на go.
Сейчас все лежит в одном репозитории и запускается с помощью filezilla и такой-то матери, докера нет в принципе.
Я хочу разделить все это месиво на отдельные части и настроить человеческий деплой.

1. Как организовать git? Пока хочу сделать просто отдельные репозитории для каждой части, т.е 1 репа для symfony, по одной для каждого фронта и т д - насколько я пожалею об этом в будущем? Будет ли это удобно для сборки и деплоя? Где хранить docker-compose.yml в таком случае? Может, стоит смотреть в сторону submodules?

2. Контейнеры - как все это разделить. Например, sphinx - ставить в отдельный контейнер? На чем нужно основывать это решение?

3. Какой инструмент для деплоя выбрать на первое время? Желательно что-нибудь простое.

4. Как подготовить VPS к деплою? ОС, виртуализация - имеет значение?

5. Как быть с панелью управления сервером (isp) - она вроде не должна мешаться но мало ли.

6. Что делать с временными и пользовательскими файлами на сервере (логи, аватарки и т д).
Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так? Как сделать чтобы ничего не пропало?

Буду благодарен если пнете в нужном направлении.
  • Вопрос задан
  • 311 просмотров
Решения вопроса 1
gecube
@gecube
системный администратор, программист... все дела..
Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.

1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.

3. ansible, gitlab-ci

4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

5. никак. Она с докерами никак не дружит.

6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

> Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

Совсем высокоуровнего - да, так.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы