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