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

Comments 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".
Написала ее компания, которая ее продает. Мда, во что превращается хабр...

Sign up to leave a comment.