Ответы пользователя по тегу Непрерывная интеграция
  • Docker. Как контролировать код, базу данных и выпуск в production?

    UnknownHero
    @UnknownHero Автор вопроса
    Добавлю ответ на свой же вопрос.

    Прошло достаточно времени и я успел посмотреть и попробовать множество инструментов связанных с Docker.

    Создал 2 приложения , первый этой сам сайт для которого хотел сделать инфраструктуру , второй это инструменты администрирования, тестирования и деплоя.

    Приложение для администрирование развёрнуто на 1-м сервере, на нём есть Docker Registry , Jenkins и ещё пару веб страниц с разной информацией. Всё это обернул в Nginx , работает здорово. Само приложение тоже использует Docker , но обновлять его нужно руками (ssh and etc).

    Сайт ( который на самом деле состоит из бизнес логики , DAL , Postgresql , Rest API , web-frontend , web-backend и ещё пару уровней абстракции :) ) использует содержит около 10 Dockerfile.

    Внутри приложения использую инструменты сборки (grunt для nodejs) и собираю приложение во время сборки образа (docker build) , либо после запуска контейнера для продолжительной разработки с помощью FIG.

    После правки кода, заливаю всё в git репозиторий, Jenkins собирает образы (docker build) и отправляет в Docker Registry, после чего сообщает серверам (сейчас он 1), что нужно обновить образы (docker pull) , и перезапустить контейнеры. Там где нужно сохранить данные , использую data containers , их я не перезапуска и не трогая.
    Со временем хочу сохранять состояние data containers (docker commit) и заливать их на Docker registry (docker push) для бэкапа некоторых данных.

    Сервер собирает и перезапускает обновлённые контейнеры с помощью самописных bash скриптов (они не сложные ), т.к. родные для Docker инструменты для этих целей ещё в стадии разработки (Docker swarm , Docker machine , Docker compose) , а стороние решения скорее всего умрут после выхода этих инструментов.

    Через Environment variables говорю контейнеру в каком он режими работает (local/test/live), но нужно это только для минификаций и уровня логгирования. В этих настройках - чем меньше различия,тем лучше.

    Всё это загнал в vagrant , отлично работает ,но требует хорошое железо для разработки.

    В планах:
    - научиться тегировать образы, что бы можно было откатить все сервера до рабочего состояния в случае багов.
    - добавить процесс автоматического тестирования и оценки качества в Jenkins (для docker приложений нужно поднимать ещё jenkins slave )
    - прикрутить ansible для деплоя и прочих удобностей для администрирования. Связать его с Jenkins

    Итог:
    -Однин раз написал, везде использую.
    - Автоматизация до уровня commit = staging deploy
    - Разделение административных инструментов и сервисов от бизнес приложения.
    - Независимые компоненты ,которые можно легко заменить, слабая связаность.
    ну и минусы:
    - одному тяжело уследить за таким зоопарком )) Был бы администратор/DevOps , было бы зачительно быстрее всё.
    Ответ написан
    1 комментарий