Как стать автором
Обновить
Все постоянно меняется. Особенно когда дело касается IT. Бывает, меняется эволюционно, бывает, революционно. Иногда топ-менеджмент проникается умными словами типа «эджайл», «бигдата», «блокчейн» и пытается реализовать их (как может). А иногда изменения начинаются снизу, например, с автоматизации и перехода на частые релизы. Этот сценарий уже поинтересней. В этом посте мы разберем, как он реализуется с Red Hat OpenShift по принципам DevOps и CI/CD, с помощью контейнеризации через Docker и управления через Kubernetes. Надеемся, наш опыт будет полезен.
Подробности – под катом
Всего голосов 45: ↑36 и ↓9+27
Комментарии6

Комментарии 6

От статьи создаётся ощущение, что встретился с sales менеджером и его очередной серебряной пулей. Много эпитетов, утрирований и минимум технических деталей

Я сначала познакомился с Kubernetes, а уже потом с OpenShift и у меня только отрицательные впечателния от последнего:


  • Введены свои сущности DeploymentConfig, Route, ImageStream и Релизы
  • Провоцирует на конфигурирование в ручную (oc new-app или oc scale), а не согласно концепции Infrastructure as code (пачкой yaml)
  • Поведение иногда не интуитивное, при ошибке во время деплоя, релиз не откатился, при удалении сломанных ReplicationController-ов автоматом откатилось
  • Надо указывать порты в DeploymentConfig вроде чтоб можно было route пробросить, просто указать порт в Service оказалось не достаточно
  • Встроенный стек логгирования основан на Elastic/Kibana/Fluentd, очень медленно отвечает. У Fluentd очень сложный конфиг, видимо на все случаи жизни.

UI кончено хорош.

ничего хорошего в UI, роут нельзя с кнопки создать, надо yaml загружать
Добавлю минусов:
1. Нет возможности поставить чистый K8s без Ansible, Jenkins и прочего.
2. Сама по себе странная идея, что в production будем разворачиваться из исходников.
3. Довольно низкокачественный Ansible Playbook: если что-то пошло не так, то не исправляется (да и удаление не всегда отрабатывает). Чаще нужно переставлять операционную систему.
4. Встроенный стек мониторинга — спорный вопрос. Мы еще деплоимся в публичные облака через managed K8s и там такого блока нет. Соответственно, в облаке и OpenShift ставим свой стек. В OpenShift получается 2 установки похожих сервисов — неоптимально.
Присоединюсь к предыдущим ораторам — моё впечатление от соприкосновения с OpenShift тоже довольно тягостное. Основные детали уже описали до меня.

Статья называется "чем хорош Openshift".
Написала ее компания, которая ее продает. Мда, во что превращается хабр...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий