Сегодня свершился релиз нового и очень полезного опенсорсного проекта, созданного дирекцией разработки ITSumma — плагина в Grafana для мониторинга Kubernetes. Он включён в официальный графана-стор — grafana.com/grafana/plugins/devopsprodigy-kubegraf-app
Читать полностью »
Потрясающий выпуск GitLab 12.2 поможет командам оптимизировать пайплайны, расширить возможности совместной работы и управлять взаимозависимостями между проектами. Подробности ниже.
Пайплайны CI нужны для автоматизации задач сборки и тестирования, чтобы ускорить поставку ПО и избежать ошибок, присущих обработке вручную. Но в некоторых случаях эффективность пайплайнов GitLab CI/CD далека от идеала. GitLab 12.2 теперь поддерживает направленные ациклические графы (DAG), чтобы создавать зависимости детализированных заданий и управлять ими, а не полагаться на последовательные этапы. Это суперэффективный инструмент, с которым ваши пайплайны CI станут работать быстрее и продуктивнее.
Обновление!. В комментах один из читателей предложил попробовать Linstor (возможно, он сам над ним работает), так что я добавил раздел об этом решении. Еще я написал пост о том, как его установить, потому что процесс сильно отличается от остальных.
Если честно, я сдался и отказался от Kubernetes (во всяком случае, пока). Буду использовать Heroku. Почему? Из-за хранения! Кто бы мог подумать, что я буду больше возиться с хранилищами, чем с самим Kubernetes. Я использую Hetzner Cloud, потому что это недорого и производительность хорошая, и с самого начала я развертывал кластеры с помощью Rancher. Я не пробовал управляемые сервисы Kubernetes от Google/Amazon/Microsoft/DigitalOcean и проч., проч., потому что всему хотел научиться сам. А еще я экономный.
Эмоджи классные, с их помощью можно даже отразить всю суть рассказа о самом популярном пакетном менеджере для Kubernetes:
Конечно, построить весь рассказ на основе одних эмоджи будет трудно, поэтому дальше схемы будут более традиционного формата.
Поговорим про Helm.
Все в этой статье относится к Helm 2. Эта версия сейчас находится в продакшене и, скорее всего, именно его вы сейчас используете, и именно в нем есть угрозы безопасности.
Читать полностью »
Чем быстрее процесс разработки, тем быстрее развивается технологическая компания.
К сожалению, современные приложения работают против нас — наши системы должны обновляться в режиме реального времени и при этом никому не мешать и не приводить к простоям и перерывам. Развертывание в таких системах становится сложной задачей и требует сложных пайплайнов непрерывной поставки даже в маленьких командах.
Эти пайплайны обычно имеют узкое применение, медленно работают и не отличаются надежностью. Разработчики должны сначала создать их вручную, а потом управлять ими, и компании часто нанимают для этого целые команды DevOps.
От скорости этих пайплайнов зависит скорость разработки. У лучших команд развертывание занимает 5–10 минут, но обычно все делается гораздо дольше, и для одного развертывания требуется несколько часов.
Мы в Dailymotion начали использовать Kubernetes в продакшене 3 года назад. Но развертывать приложения на нескольких кластерах то еще удовольствие, поэтому в последние несколько лет мы старались улучшить наши инструменты и рабочие процессы.
GitLab 12.0 — это ключевой выпуск на пути к реализации подхода, который будет охватывать все элементы DevSecOps и позволит всем вносить свой вклад.
У нас был очень увлекательный год — мы много работали над решением, которое объединило бы все команды. Сообщество внесло тысячи дополнений, чтобы GitLab стал еще круче.
Мы верим, что каждый может внести свой вклад, поэтому добавили функции для сотрудничества между разными командами, быстрой поставки отличного кода и объединения Dev, Sec и Ops.
Несмотря на то, что большая часть ИТ-индустрии внедряет инфраструктурные решения на базе контейнеров и облачных решений, необходимо понимать и ограничения этих технологий. Традиционно Docker, Linux Containers (LXC) и Rocket (rkt) не являются по-настоящему изолированными, поскольку в своей работе они совместно используют ядро родительской операционной системы. Да, они эффективны с точки зрения ресурсов, но общее количество предполагаемых векторов атаки и потенциальные потери от взлома все еще велики, особенно в случае мультиарендной облачной среды, в которой размещаются контейнеры.
Корень нашей проблемы заключается в слабом разграничении контейнеров в моменте, когда операционная система хоста создает виртуальную область пользователя для каждого из них. Да, были проведены исследования и разработки, направленные на создание настоящих «контейнеров» с полноценной «песочницей». И большинство полученных решений ведут к перестройке границ между контейнерами для усиления их изоляции. В этой статье мы рассмотрим четыре уникальных проекта от IBM, Google, Amazon и OpenStack соответственно, в которых используются разные методы для достижения одной и той же цели: создания надежной изоляции. Так, IBM Nabla разворачивает контейнеры поверх Unikernel, Google gVisor создает специализированное гостевое ядро, Amazon Firecracker использует чрезвычайно легкий гипервизор для приложений песочницы, а OpenStack помещает контейнеры в специализированную виртуальную машину, оптимизированную для инструментов оркестрации.
Читать полностью »
В Челябинске проходят митапы системных администраторов Sysadminka, и на последнем из них я делал доклад о нашем решении для работы приложений на 1С-Битрикс в Kubernetes.
Битрикс, Kubernetes, Сeph — отличная смесь?
Расскажу, как мы из всего этого собрали работающее решение.
Поехали!
