Методология разработки программного обеспечения
Привет, Хабр! В этой статье хотел бы поделиться опытом участия в процессе цифровизации огромной компании. Под катом расскажу об особенностях, с которыми столкнулся при взаимодействии с большим количеством команд разработки. На их основе во второй части статьи рассмотрим, какие принципы помогли справиться с работой в таких условиях и оптимизировать ее.
Представьте, что вам требуется управлять множеством серверов, расположенных в различных точках земного шара. Каждое устройство нужно настроить, обновлять ПО и мониторить.
Можно делать это руками, подключаясь к каждому отдельно, но это не наш метод. О том, что выбираем мы, поговорим в этой статье.
Sentry из коробки поддерживает большое множество средств для авторизации, появилась необходимость использовать уже существующие учетные записи с нужными правами.
Из этого появилась небольшая статья по установке Sentry Self-Hosted и подключения к LDAP.
Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса.
В последней части, оптимизируем процесс обнаружения регрессии размера андроид приложения.
Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.
Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.
Ну а API-шлюз, как новинку в этой области, мы оставили на десерт, решив посвятить ему целый пост.
В погоне за лучшей или, правильнее сказать, удобной жизнью я начал искать решение, которое помогало бы писать чарты для Kubernetes и лучше разбираться в зависимостях — что, куда и откуда подставляется в созданных чартах. Так я наткнулся на программу под названием Monokle. В ее описании сказано: «Вы сможете составлять чарты, быстро находить какие либо несовместимости или неправильный код, а также деплоить ваши чарты сразу в K8s». Глаза загорелись, я приступил к установке.
Это третья статья из цикла. В прошлой части мы разбирали типы метрик, и уже там начали встречаться перцентили. Это полезная штука, но для неподготовленного читателя она выглядит просто как математическая дичь. Эта статья поможет разобраться в перцентилях по-инженерному, не заканчивая профильный факультет.
Из этой статьи вы узнаете, зачем нужны моки для модульного тестирования операторов Kubernetes и как их писать. Эти концепции применимы к операторам на разных языках и фреймворках. Здесь мы будем использовать Golang, controller-runtime и библиотеку testify.
Что делать с понятием, соединяющим две разных технических области? Добавить третью! DevOps соединил «development» и «operations», но что в этом случае произошло с «testing»? А что должно произойти, чтобы всё было по уму?
Руслан Ахметзянов @arg89уже выступал у нас и на девопс-конференции DevOops, и на конференции по тестированию Heisenbug. Сейчас он готовит новый доклад, а мы готовим новые DevOops и Heisenbug — и в ожидании этого решили расшифровать для Хабра его предыдущее выступление. Кто-то может не согласиться с его выводами, но так даже интереснее!
Далее повествование идёт от лица спикера.
На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.
Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая). Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.
Надежность (reliability) программного продукта всегда является одним из приоритетов компании. Особенно это актуально для ПО, превратившегося в ежедневный инструмент для своих пользователей. Они рассчитывают на заявленный функционал, поэтому любая невозможность его использования подрывает доверие, а следовательно, и желание им пользоваться.
В этой статье пойдет речь о главных инструментах Site Reliability Engineering (SRE) и о том, как они влияют на повышение надежности систем.
В этой статье мы рассмотрим плейбуки Ansible — схемы для действий по автоматизации. Плейбуки — это простой, целостный и воспроизводимый способ определить все действия, которые мы хотели бы автоматизировать.
В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».
В этом тексте я предлагаю порассуждать, что же должно быть в нормальном взрослом firmware репозитории безотносительно к конкретному проекту.
То есть перечислить самые универсальные и переносимые программные компоненты (кирпичики), которые могут пригодиться в практически любой сборке.
Как бы мы себя не обманывали - Размер имеет значение! И конечно, мы будем говорить о размере нашего андроид приложения, куда мы добавляем кучу классных features, и даже не задумываемся как это может негативно повлиять на размер приложения. Поэтому мы научимся обнаруживать регрессию размера нашего приложения на CI для автоматизации этого процесса.
В данной части, обсудим как можно проверять размер в pull request, что позволит автоматизировать весь процесс обнаружения регрессии, до того как изменения попали в development.
Хочу рассказать об интересном эксперименте, суть которого заключалась в развертывании и настройке Kubernetes на двух старых ноутбуках — один из них, кроме того, был с процессором на архитектуре i386. В качестве теоретической основы использовалось руководство Kubernetes The Hard Way, которое по ходу дела пришлось немного доработать, а в качестве системы на хостах — Gentoo (да, вам не показалось). Давайте погрузимся в этот увлекательный хардкор!
Цепочка поставок в пищевой промышленности и ритейле — это сложная, медленная и ненадёжная система. В этой статье мы рассмотрим развёртывание Apache Kafka для обработки данных в реальном времени в таких сферах, как производство, логистика, розничная торговля, доставка, рестораны и другие части бизнеса. Это будут примеры из настоящих компаний: Walmart, Albertsons, Instacart, Domino’s Pizza, Migros и т. д.
