Комментарии 17
Расскажите про безопасность. Вы качаете имаджи без проверки подписей? Или на http нет подписей?
Следующий шаг — поставить Kubernetes и окончательно отвязать сервисы от машин?
Мы начинали наши исследования с coreos, kubernetes и многих других модных штук. Они клевые, но для нас не несут никакого бизнес value. А вот непрерывное развертывания влияет и несет добро.
А возможность штатно отключать машины без прерывания сервиса? Ядро там обновить, или жёсткий диск заменить.
«обновить ядро» — в случае облаков это часто невозможно, а на самом деле не нужно. У нас машины живут около месяца, и в процессе постоянно меняются. В принципе такая же история с жесткими дисками.
В общем случае, для веб серверов, эта проблема (zero downtime) решается тем что бекенд отключается от балансера, а потом снова подключается (после всех нужных изменений), либо подключается новый.
В общем случае, для веб серверов, эта проблема (zero downtime) решается тем что бекенд отключается от балансера, а потом снова подключается (после всех нужных изменений), либо подключается новый.
Если вы не знакомы с таким подходом к конфигурации, то рекомендую обратиться вот к этому документу от компании heroku.
Теперь этот документ есть и на русском: habrahabr.ru/post/258739/#config
Почему не используете штатный модуль docker от ansible?
По поводу deploy-a — либо не понял, либо не увидел, но каким обрзом вы вводите в работе обновленный контейнер? В deploy-ном скрипте видно, что вы выкачиваете новый образ из docker hub-а и запускаете контейнер с автоудалением после завершения работы. Но не видно, чтобы контейнер где-то тормозился, чтобы подняться уже из нового образа.
По поводу deploy-a — либо не понял, либо не увидел, но каким обрзом вы вводите в работе обновленный контейнер? В deploy-ном скрипте видно, что вы выкачиваете новый образ из docker hub-а и запускаете контейнер с автоудалением после завершения работы. Но не видно, чтобы контейнер где-то тормозился, чтобы подняться уже из нового образа.
Почему не используете штатный модуль docker от ansible?
В разделе «Разворачивание инфраструктуры» я подробно ответил на этот вопрос.
По поводу deploy-a — либо не понял, либо не увидел, но каким обрзом вы вводите в работе обновленный контейнер?
Посмотрите содержимое upstart скрипта, там видно и остановка и старт.
Целый час на сборку? Что то вы делаете не так. у вас видимо копирования образов не происходит. Кроме того, зачем вы отдельно собираете образ для прода? Выкладывайте протестированный образ со стейджинга прямо на прод. Для этого он конечно должен быть отвязан от конкретных машин.
у вас видимо копирования образов не происходит.кэширования конечно же.
Из статьи видно что не у нас, а у докер хаба.
Стейджинг это autobuild репозиторий на докер хаба. На тот момент когда мы это делали, нельзя было одновременно с ним работать как с обычным репозиторием и autobuild. Поэтому у нас два разных репозитория. В будущем мы конечно уйдем от автосборки прямо на хабе, пустив все это дело через нормальное cd.
Стейджинг это autobuild репозиторий на докер хаба. На тот момент когда мы это делали, нельзя было одновременно с ним работать как с обычным репозиторием и autobuild. Поэтому у нас два разных репозитория. В будущем мы конечно уйдем от автосборки прямо на хабе, пустив все это дело через нормальное cd.
Интересно узнать про локальную разработку рельсового приложения. Про деплой расписано подробно, а про то как вы с такой структурой работаете ежедневно локально непонятно. Какие инструменты облегчают в этом деле? Используете ли IDE в работе?
Конкретно мы в своей команде используем vim, но это вопрос личных предпочтений. Главное что мы используем в локальной разработке это vagrant, а докер только для сервисов, таких как, база данных. Вести непосредственно разработку внутри докера теоретически можно, но я не уверен что это вам что то даст, особенно если вы только в начале пути.
Ну и конечно обязательно ansible.
Ну и конечно обязательно ansible.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker Workflow