Comments 28
Если гоняете микро-сервисы, попробуйте Kubernetes. Используем его уже где-то полгода, не без проблем, но полет нормальный.
Кубернет требует работы через google cloud, что выглядит очень-очень странным решением. Ну, и ко всему требует коммиты на каждый чих, что лично мне совсем не нравится и является ненужным порогом при освоении технологии.
> Кубернет требует работы через google cloud
Его можно запросто поднять хоть на AWS, хоть на своем железе.
> Ну, и ко всему требует коммиты на каждый чих
Вовсе не обязательно хранить ваши конфигурации в VCS. С ними можно работать как душе угодно (хоть через UI, хоть редактировать напрямую с сервера). А в идеале вообще использовать Helm.
Его можно запросто поднять хоть на AWS, хоть на своем железе.
> Ну, и ко всему требует коммиты на каждый чих
Вовсе не обязательно хранить ваши конфигурации в VCS. С ними можно работать как душе угодно (хоть через UI, хоть редактировать напрямую с сервера). А в идеале вообще использовать Helm.
Аналогично, первая мысль после прочтения: «Зачем писать велосипеды, если есть K8S?».
Насколько я понял, вы имеет в виду Kubernetes? Или по крайней мере практики его использования в качестве средства для оркестрации Docker.
Fabricio не является заменой Kubernetes/Swarm. Главная цель Fabricio — кастомизация логики деплоя через создание типовых классов с описанием логики запуска контейнера (которая в случае Docker Compose и Kubernetes прописывается в файлах YAML) на полноценном языке программирования с всеми вытекающими преимуществами ООП.
При этом на целевой инфраструктуре, в теории, может быть развернута любая система запуска Docker контейнеров (мы ориентируемся в этом случае на Swarm, который начиная с версии Docker 1.12 является частью самого Docker).
Fabricio не является заменой Kubernetes/Swarm. Главная цель Fabricio — кастомизация логики деплоя через создание типовых классов с описанием логики запуска контейнера (которая в случае Docker Compose и Kubernetes прописывается в файлах YAML) на полноценном языке программирования с всеми вытекающими преимуществами ООП.
При этом на целевой инфраструктуре, в теории, может быть развернута любая система запуска Docker контейнеров (мы ориентируемся в этом случае на Swarm, который начиная с версии Docker 1.12 является частью самого Docker).
не знаю чем вам Ансибл не сгодился? мы вполне себе неплохо дженкинс+ансибл используем.
Нужно вам найти ДевОПСа хорошего.
Кстати, до этого мы лет пять строили велосипеды через Фабрику. Теперь вот всем этим занимается Ансибл.
Нужно вам найти ДевОПСа хорошего.
Кстати, до этого мы лет пять строили велосипеды через Фабрику. Теперь вот всем этим занимается Ансибл.
Ansible нам напомнил о некогда довольно популярном Apache Ant, только последний использует XML, а Ansible более модный YAML. Оба ведут себя неплохо до тех пор, пока идешь по дорожке, протоптанной авторами (или пока им хватает энтузиазма развивать продукт).
Да и накладно содержать специалиста по Ansible только ради DevOps обязанностей.
Да и накладно содержать специалиста по Ansible только ради DevOps обязанностей.
А в чем проблема запускать шелл-, питон-скрипты из Ansible?
Так и проблем наверно нет, но их можно и без Ansible запускать. А структура проекта Ansible и без внешних скриптов выглядит довольно запутанно.
С Fabric/Fabricio я могу выбрать такую структуру, которую захочу. И прописать всю логику в одном файле (fabfile.py), либо создать целый подпроект (внутри модуля fabfile) с разделением на роли, инфраструктуры и пр.
С Fabric/Fabricio я могу выбрать такую структуру, которую захочу. И прописать всю логику в одном файле (fabfile.py), либо создать целый подпроект (внутри модуля fabfile) с разделением на роли, инфраструктуры и пр.
Соглашусь, к сожалению, при попытке уйти вправо/влево от того, что предоставляет модуль Ansible, приходится городить raw команды, например, к тем же iptables у меня треть плейбука именно raw, потому как штатно нужного мне функционала, пока не придвидится, и учитывая ньюансы, не проще ли отказаться от обертки и дергать ssh -c somecommmand напрямую…
Вопрос надо ставить «можем ли мы себе позволить отдельного человека по DevOps» и если можем, то при выборе продуктов — его слово решающим должно быть, а не разработчиков или админов.
Для того, чтобы понять эту причину, я задам простой вопрос: кто-нибудь из вас умеет программировать на YAML?
Как по мне, то если процесс деплоя нельзя выразить в декларативной форме, то что-то то ли с архитектурой, то ли с процессом не так. А так тот же Ansible имеет и переменные, и условия, и циклы.
Среди недостатков можно также упомянуть отсутствие autocomplete и возможности прочитать исходный код используемой функции, отсутствие подсказок о типе и количестве аргументов и прочих радостей использования IDE
Вот это более весомый аргумент, но в принципе решаемый плагинами к IDE. Например, в PhpStorm YAML конфиги инфраструктуры Symfony довольно хорошо интегрированы. И для Ansible плагин есть https://plugins.jetbrains.com/plugin/7792
Спасибо за статью!
А можете немого поподробнее про rollback и откат миграций? Как это делает fabric? Очень интересен этот момент.
А можете немого поподробнее про rollback и откат миграций? Как это делает fabric? Очень интересен этот момент.
Команда rollback последовательно запускает два стандартных метода у базовой сущности Fabricio (Container): migrate_back и revert. По-умолчанию, у первого метода отсутствует реализация, но потомки класса могут это поведение переопределить. DjangoContainer при откате миграций на предыдущую версию парсит список примененных миграций у текущей версии контейнера и у той, на которую нужно откатиться, составляет разницу и откатывает только те миграции, которых нет в старом контейнере.
Кто-нибудь из вас умеет программировать на YAML?
Я умею! А на Ruby и Python — наоборот, не умею.
А как дела с сетью? Имеется ввиду, сеть на уровне связки докер-контейнеров. А не на уровне конкртеного контейнера.
docker-compose позволяет настраивать некоторые вещи через:
docker-compose позволяет настраивать некоторые вещи через:
networks:
app_net:
driver: bridge
ipam:
driver: default
config:
- subnet: 172.16.100.0/28
ip_range: 172.16.100.0/28
gateway: 172.16.100.7
ИМХО, Ansible обеспечивает огромный простор для деплоя разнообразных приложений. На данный момент у меня им управляется зоопарк из Docker, LXC и физических серверов. Прекрасно дружит с Jenkins. Присоединюсь ко мнению, что с архитектурой что-то не так, если не хватает декларативного YAML для деплоя. Да и с теми же кастомными скриптами, проще один плейбук запустить, чем ломиться по ssh и выполнять поштучно. А если серверов больше одного, так и тем более.
З.Ы.: Зачем отдельный специалист по Ansible, если там настолько хорошая документация, что рядовой *nix админ со средним английским осилит за неделю, максимум
З.Ы.: Зачем отдельный специалист по Ansible, если там настолько хорошая документация, что рядовой *nix админ со средним английским осилит за неделю, максимум
Не могли бы вы уточнить как именно ansible у вас работает? Посмотрел на http://docs.ansible.com/ansible-container/. Не увидел большой разницы с тем же docker-compose. Увидел, что умеет билдить, пушить и пулить контейнеры, но так и не понял каким образом работает, то что называется деплоем.
Не увидел, опять же, как делать rollback.
или вы просто через ansible, вызывается на host-машине pull && run контейнеров?
Не увидел, опять же, как делать rollback.
или вы просто через ansible, вызывается на host-машине pull && run контейнеров?
Ansible разворачивает проект на новых серверах, после сборки в Jenkins пулит на существующие. Согласен, Compose это все умеет. Но как-то не прижился, потом написали свои костыли и не вспоминали про него)
1. Ansible готовит новый хост (грубо, чистая ось только с sshd) к исполнению докер-контейнеров.
2. Ansible не просто запускает контейнеры, а обеспечивает им всю среду, в частности обеспечивает наличие на хосте файлов, которые монтируются в контейнер (или файлов, которые копируются в контейнер при билде).
2. Ansible не просто запускает контейнеры, а обеспечивает им всю среду, в частности обеспечивает наличие на хосте файлов, которые монтируются в контейнер (или файлов, которые копируются в контейнер при билде).
Ещё есть готовый open source докер PaaS — deis.io
Ринат, во многом ты прав. Но в сути, это обычная проблема, когда программисты пишут деплой, вы делаете так, как привыкли и вам удобнее. Это будет продолжаться ровно до момента, когда вы передадите весь этот набор деплоя в руки эксплуатации/девопсов. После этого будет резко удобно все писать на ansible (или прочих salt/puppet). Ровно потому, что при всей простоте того же fabric, поддержке все же надо будет освоить прилично писать на питоне, и поддерживать ваше понимание об организации кода. Я уже имел опыт перевода с хорошо написанного fabric на ansible. И на ansible, в результате, код получался короче, проще, красивее и быстрее. Особенно если нужно разливать на очень заковыристые inventory.
PS по мне, inventory, это вообще беда fabric.
Это будет продолжаться ровно до момента, когда вы передадите весь этот набор деплоя в руки эксплуатации/девопсов.
На этом месте, как правило, и работа наша заканчивается — это специфика разработки аутсорс. А так-как эксплуатация полностью продолжается на стороне заказчика, то нам нет смысла развивать у себя экспертизу в этой области.
Есть правда у нас в разработке пара типовых решений PaaS, где скорее всего процесс эксплуатации будет на нашей стороне. Поживем увидим.
Sign up to leave a comment.
Автоматизация развертывания Docker-контейнеров на произвольной инфраструктуре