Комментарии 28
О, прям админ-порн. Круто получилось! Моя хотеть.
Про автоматизацию WAS можно поподробнее?
Про автоматизацию WAS можно поподробнее?
Вместе c WASовской утилитой wsadmin использовали питоновскую библиотеку wsadminlib.py (которую пришлось чуть дописать) для реализации функций:
— создания и конфигурации transport chain,
— создания и конфигурации виртуального хоста,
— настройки параметров аутентификации (ИБ) и создания пользователей.
— создания и конфигурации transport chain,
— создания и конфигурации виртуального хоста,
— настройки параметров аутентификации (ИБ) и создания пользователей.
А где про девопс-то? Увидел только про автоматизацию и набор более-менее стандартных инструментов…
Для Continuous Delivery есть еще Drone. Вы его рассматривали с каких-нибудь сторон? Спасибо.
А девопс — это только автоматизация, разве? Ну то есть тут написали про инструменты, причины выбора, а про то как это всё работает или должно работать с организационной точки зрения — нет. И работает это прямо в одном конвейре с админами ваших клиентов? Одними и теми же инструментами удаётся пользоваться и вашим разработчикам и админам заказчиков? Если да, то огромные шаблоны виртуалок как передаёте?
В посте акцент был намеренно смещен на инструменты DevOps, это верно подмечено.
По поводу организации, как говорится «it depends», есть разные ситуации (у нас довольно много проектов и заказчиков):
1. Заказчик предоставил доступ в инфраструктуру и широкие полномочия. В этом случае конвейер поставки единый, мы централизованно управляем развертыванием в тесте, пред-проде, проде и т.п на стороне заказчика. Теми же инструментами, что и у себя.
2. Доступ ограничен, заказчик хочет контролировать развертывание сам. У заказчика настраивается свой конвейер поставки. В зависимости от уровня зрелости конвейер может начинаться как с хранилища предоставленных дистрибутивов так и с хранилища исходников плюс бинарный репозиторий. Инструментарий DevOps в этом случае установлен на стороне заказчика. Инструменты могут отличаться от наших, особенно если у заказчика уже что-то раньше использовалось в других проектах.
Шаблоны виртуальных машин мы стараемся не передавать, это противоречит принципу infrastructure as a code.
По поводу организации, как говорится «it depends», есть разные ситуации (у нас довольно много проектов и заказчиков):
1. Заказчик предоставил доступ в инфраструктуру и широкие полномочия. В этом случае конвейер поставки единый, мы централизованно управляем развертыванием в тесте, пред-проде, проде и т.п на стороне заказчика. Теми же инструментами, что и у себя.
2. Доступ ограничен, заказчик хочет контролировать развертывание сам. У заказчика настраивается свой конвейер поставки. В зависимости от уровня зрелости конвейер может начинаться как с хранилища предоставленных дистрибутивов так и с хранилища исходников плюс бинарный репозиторий. Инструментарий DevOps в этом случае установлен на стороне заказчика. Инструменты могут отличаться от наших, особенно если у заказчика уже что-то раньше использовалось в других проектах.
Шаблоны виртуальных машин мы стараемся не передавать, это противоречит принципу infrastructure as a code.
НЛО прилетело и опубликовало эту надпись здесь
Можно с нуля купить монолитную коробку с готовым функционалом, но в большинстве случаев у заказчиков уже частично есть инструменты практик CI/CD с соответствующими капитальными вложениями. Нам требовалась универсальность и совместимость с различными уже работающими в инфраструктуре CI (Jenkins и TeamCity), поэтому наше решение строилось по модульному принципу, подбирая для каждого модуля наиболее оптимальное решение.
Ну и мы ориентировались на open source решения, не все готовы потратить $100.000
Ну и мы ориентировались на open source решения, не все готовы потратить $100.000
Ок, расскажите пожалуйста при чем тут «Atlassian-стек Bitbucket+JIRA+Confluence+Bamboo+Hipchat» к например постройке сетей Terraform-ом или автоматизации Ansible-ом? Что из этого заменит OpenStack?
> Уверен, что для заказчика такой проект будет стоить больше $100.000.
Даже если так (что не правда), то с Atlassian вы будете платит тонны бабла каждый год и слезть будет очень уж не просто.
В общем я не вижу особых проблем в логике автора поста.
> Уверен, что для заказчика такой проект будет стоить больше $100.000.
Даже если так (что не правда), то с Atlassian вы будете платит тонны бабла каждый год и слезть будет очень уж не просто.
В общем я не вижу особых проблем в логике автора поста.
НЛО прилетело и опубликовало эту надпись здесь
Готовое и с интеграциями всего и везде не всегда есть. Даже если будет взят Atlassian стек — он не покроет абсолютно всё. У каждого бизнеса свои потребности, своя модель, свои практики.
> Честно говоря, не понимаю, что вы имеете ввиду конкретно указывая инструменты, которые просто инструменты, а не DevOps вовсе.
DevOps — это методология (и часто так называют профессию) и для ее реализации нужны разные инструменты: Jira, Redmine, GitLab. Я действительно не совсем понимаю о чем вы. С помощью чего инженер, который работает над DevOps практиками, должен работать?
> Честно говоря, не понимаю, что вы имеете ввиду конкретно указывая инструменты, которые просто инструменты, а не DevOps вовсе.
DevOps — это методология (и часто так называют профессию) и для ее реализации нужны разные инструменты: Jira, Redmine, GitLab. Я действительно не совсем понимаю о чем вы. С помощью чего инженер, который работает над DevOps практиками, должен работать?
НЛО прилетело и опубликовало эту надпись здесь
Ок, т.е. в вашем понимании Девопс задачи полностью покрывает Atlassian стек (т.е. Битбакет, Бамбу, Хипчат и т.п. ). А дальше кто будет делать то, что Atlassian стек не покрывает? Совсем другой человек? Какое название этой профессии?
НЛО прилетело и опубликовало эту надпись здесь
Вы ответили вопросом на вопрос, но я отвечу. В моем понимании девопсов должны отвечать за очень много вещей, в том числе автоматизацию (Ansiblе, Puppet), использование API клауд-платформ (например, посредством Terraform), управлением серверами аутентификации (например, openLDAP) и т.п. В общем по-сути это люди, которые раньше назывались просто инфраструктурными админами, когда не было этих новомодных названий.
НЛО прилетело и опубликовало эту надпись здесь
> Использование Ansible и др. систем не отменяет, тот стек, который я указывал, а дополняет его.
В любом случае Bamboo, Jira, Hipchat, Bitbuсket достаточно легко заменяемы например с помощью GitlabCI/Jenkins, Redmine/Gitlab (если не нужно фанатично считать часы, а важно именно выполнение задач), Slack/Telegram (или что там еще есть нормального), Gitlab соответсвенно. Сложности и затраченное время будет именно тратится не на эти тулзы, а на разные Puppet, Terraform и т.п., так как здесь реально много чего нужно обдумывать и делать.
Что примером Gitlab, что Bitbuсket достаточно готовы «из-коробки» для использования и не нуждаются в большом количестве времени на настройку.
> И потом потерять контроль над процессом, потому что гений самоучка, который запускал эту систему из многих разнородных компонентов решил свалить и никто из оставшихся не знает как она работает. Думаю, ответ очевиден.
Это уже проблема менеджмента, если увесь процесс завязан на одного человека и нет документации. И тем более не проблема использования Atlassian продуктов или чего-то другого.
В любом случае Bamboo, Jira, Hipchat, Bitbuсket достаточно легко заменяемы например с помощью GitlabCI/Jenkins, Redmine/Gitlab (если не нужно фанатично считать часы, а важно именно выполнение задач), Slack/Telegram (или что там еще есть нормального), Gitlab соответсвенно. Сложности и затраченное время будет именно тратится не на эти тулзы, а на разные Puppet, Terraform и т.п., так как здесь реально много чего нужно обдумывать и делать.
Что примером Gitlab, что Bitbuсket достаточно готовы «из-коробки» для использования и не нуждаются в большом количестве времени на настройку.
> И потом потерять контроль над процессом, потому что гений самоучка, который запускал эту систему из многих разнородных компонентов решил свалить и никто из оставшихся не знает как она работает. Думаю, ответ очевиден.
Это уже проблема менеджмента, если увесь процесс завязан на одного человека и нет документации. И тем более не проблема использования Atlassian продуктов или чего-то другого.
НЛО прилетело и опубликовало эту надпись здесь
> Atlassian котируется на биржах и инвесторы не позволят ей исчезнуть, что нельзя сказать о OpenSource, разработка которых может быть завязана на несколько энтузиастов.
Тут имхо вопрос скорее личного восприятия ситуации на рынке. По-моему, то что в Atlassian стоящее и за что нужно платить — это Jira. Да и то необходимости в нем для построения Devops процессов я не вижу, он скорее полезен для управленцев, которые хотят «чтоб все логали время».
> что нельзя сказать о OpenSource, разработка которых может быть завязана на несколько энтузиастов.
Конкретно за приведенными продуктами стоят корпорации и у многие бизнес строят на этих утилитах. Например Cloudbees , Ansible от RedHat и т.п. Опенсорс — не обязательно значит, что разработка ведется энтузиастами во время обеденного перерыва.
Тут имхо вопрос скорее личного восприятия ситуации на рынке. По-моему, то что в Atlassian стоящее и за что нужно платить — это Jira. Да и то необходимости в нем для построения Devops процессов я не вижу, он скорее полезен для управленцев, которые хотят «чтоб все логали время».
> что нельзя сказать о OpenSource, разработка которых может быть завязана на несколько энтузиастов.
Конкретно за приведенными продуктами стоят корпорации и у многие бизнес строят на этих утилитах. Например Cloudbees , Ansible от RedHat и т.п. Опенсорс — не обязательно значит, что разработка ведется энтузиастами во время обеденного перерыва.
НЛО прилетело и опубликовало эту надпись здесь
Да, действительно, Concourse более эффективен для масштабных проектов с сотнями/тысячами релизов в день. Но у GoCD для промышленных масштабов есть возможность использовать PostgreSQL, кроме того, простота в установке и возможности Pipeline as a code позволяют быстро развертывать несколько инстансов GoCD и децентрализовывать его функционал.
> возможности Pipeline as a code
В Дженкинса тоже это есть. Я бы еще рекомендовал бы посмотреть на GitLab CI.
В Дженкинса тоже это есть. Я бы еще рекомендовал бы посмотреть на GitLab CI.
Gitlab CI в нынешней версии (11.4) уже очень даже торт.
Появилась целая куча очень полезных фич: include, only:changes и прочие.
Не хватает пока блокировки .gitlab-ci.yaml от разработчиков, но скорость развития среды такова, что я уже не успеваю отслеживать все нововведения.
Я прям очень за них горд: разработчики гитлаб реально молодцы!!!
Появилась целая куча очень полезных фич: include, only:changes и прочие.
Не хватает пока блокировки .gitlab-ci.yaml от разработчиков, но скорость развития среды такова, что я уже не успеваю отслеживать все нововведения.
Я прям очень за них горд: разработчики гитлаб реально молодцы!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Devops в кровавом энтерпрайзе