Сегодня почти у каждого проекта мобильного приложения есть базовая инфраструктура: ваш код хранится на git хостинге и весь новый код регулярно проверяется на CI, чтобы не сломать старый. Если ваша команда в несколько человек производит не очень много кода, то скорее всего вы настроили весь пайплайн один раз и радуетесь его работе. Но что если ваша мобильная команда это пара десятков или даже сотен разработчиков? Много разработчиков производят много кода, что создает нагрузку на инфраструктуру, увеличивает вероятность сломать важные флоу приложения и просто навсего унести время сборки проекта в небеса. Единожды кем-то настроенный пайплайн обречен на изменения, если он не справляется с нагрузкой.
Вы уже наверное поняли о чем пойдет речь под катом? В виде интересной истории я расскажу вам про типичные проблемы мобильных команд (да-да, вы можете узнать в них свои), а также что такое Mobile DevOps, как он поможет решить проблемы и, наконец, как получить этот самый Mobile DevOps к вам в команду.
Приветствую всех Хабровчан. Сегодня говорим про Helm и то, как мы у себя в Nixys пришли к универсальному чарту, который стали использовать в своей работе как стандартный инструмент и почему это сделало нашу работу эффективнее.
Цель статьи - показать один из возможных подходов для организации гибкого развёртывания dev/test стендов. Показать какие преимущества предоставляет нам IaC подход в сочетании с современными инструментами.
Infrastructure as Code — это подход, который подразумевает описание инфраструктуры в виде коде с его последующим применением для внесения необходимых изменений. Но, как именно писать код, IaC не говорит, только даёт инструменты. Один из таких инструментов — Terraform.
21 мая в Слёрм пройдёт практический интенсив «Terraform Мега». Мы пообщались с его автором Павлом Селиванов, архитектором Yandex.Cloud. Он рассказал, каких принципов нужно придерживаться, когда описываешь инфраструктуру, чтобы на выходе не получить непонятный и плохо поддерживаемый код.
Прошло чуть больше 2 месяцев с момента релиза первой версии универсального чарта, и мы рады представить чарт версии 2.0. В этой статье расскажу что нового, и рассмотрим на примере, как это работает.
В статье пойдет речь о программном продукте для управления и мониторинга критически важной инфраструктуры, который создан с учетом 20-и летнего опыта работы в этой сфере. Создание системы заняло более 6 лет. В настоящее время есть успешные внедрения. Программное обеспечение распространяется бесплатно.
«Как быстро мы упремся в сетевой канал, который использует Kafka — через года два или раньше?»
Когда у вас 2 собственных дата-центра, тысячи железных серверов, виртуалки и хостинг для сотен тысяч сайтов, Kubernetes может существенно упростить управление всем этим добром. Как показала практика, с помощью Kubernetes можно декларативно описывать и управлять не только приложениями, но и самой инфраструктурой. Я работаю в крупнейшем чешском хостинг-провайдере WEDOS Internet a.s и сегодня расскажу о двух своих проектах — Kubernetes-in-Kubernetes и Kubefarm.
С их помощью можно буквально за пару команд, используя Helm, развернуть полностью рабочий Kubernetes внутри другого Kubernetes-кластера. Как и зачем? Добро пожаловать под кат!
Network architecture at hyperscalers is a subject to constant innovation and is ever evolving to meet the demand. Network operators are constantly experimenting with solutions and finding new ways to keep it reliable and cost effective. Hyperscalers are periodically publishing their findings and innovations in a variety of scientific and technical groups.
The purpose of this article is to summarize the information about how hyperscalers design and manage networks. The goal here is to help connecting the dots, dissect and digest the data from a variety of sources including my personal experience working with hyperscalers.
DISCLAIMER: All information in this article is acquired from public resources. This article contains my own opinion which might not match and does not represent the opinion of my employer.
Материал переведен. Ссылка на оригинал
В первой статье из серии "Архитектура контейнеров" (перевод, оригинал на англ.) мы рассмотрели разницу между пользовательским пространством и пространством ядра. Сегодня мы продолжим изучение этой темы и посмотрим подробнее на пользовательское пространство.
Перевод оригинальной статьи, где автор пишет о подходе Infrastructure as Code с его основными концепциями, оценивает преимущества такого подхода и сравнивает главные инструменты для работы с IaC на сегодняшний день: Terraform, Pulumi и Crossplane.
- cfdb — модуль развёртывания и автонастройки узлов и кластеров баз данных и доступа к ним с высокой доступностью и защитой от сбоев.
- Как proof-of-concept поддерживаются MySQL и PostgreSQL на базе Percona Server/XtraDB Cluster и официальных сборок PostgreSQL+repmgr.
- Изоляция ресурсов на базе cgroups, интеграция с настройками сетевого фильтра через модуль
cfnetworkи строгий контроль доступа средствами СУБД.- Запись на один узел для минимизации конфликтов и распределение нагрузки для read-only доступа.
- Автоматическая проверка здоровья кластера и фактической осуществимости доступа.
- Ручное и автоматическое локальное резервное копирование, автоматизированное восстановление данных.
- Поддержка автоматической миграции уже существующих баз данных
Kubernetes используют так или иначе сейчас примерно все, но и задачи решаются совсем разные. Я расскажу про наши требования и разработанные под них решения для управления множеством кластеров. По теме GitOps не так много статей и обсуждений на Хабре, в отличие от англоязычных источников, поэтому будет интересно и услышать мнение тех, кто применял подход на своей практике.
В этой статье вы прочитаете о лучших практиках запуска Java-приложений в Kubernetes. Большинство из этих рекомендаций будут справедливы и для других языков.
Однако я рассматриваю все правила в рамках характеристик Java, а также показываю решения и инструменты, доступные для приложений на базе JVM.
Некоторые из этих рекомендаций по Kubernetes навязаны дизайном при использовании самых популярных Java-фреймворков, таких, как Spring Boot или Quarkus. Я покажу вам, как эффективно использовать их для упрощения жизни разработчиков.
Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys, которая помогает другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.
Сегодня я приглашаю вас вместе со мной пройти путь «от незнания к best practices» в работе с Terraform. Этот материал подготовлен для серии наших одноименных видеороликов на YouTube, но мы решили дополнить его и предложить вам более детальное описание процесса в этой статье.
Не забывайте следить за нашими обновлениями на YouTube, Habr и подписывайтесь на наш Telegram‑канал DevOps FM — мы всегда рады новым друзьям. Начнём?
Всем привет! Меня зовут Виктор, я DevOps‑инженер компании Nixys — мы помогаем другим компаниям внедрять в их IT‑решения передовые практики DevOps, MLOps и DevSecOps.
А еще — делимся знаниями и опытом в этой сфере. Сегодня представляем продолжение серии обучающих видеороликов на YouTube "Terraform: от незнания к best practices" и выкладываем сразу два видео!
Привет всем. Меня зовут Алексей, я DevOps-инженер, и сегодня я хочу рассказать немного об одном инфраструктурном решении моего ключевого заказчика.
Немного о моей работе и разделении ответственности. Я предоставляю услуги по настройке и сопровождению облачной инфраструктуры на основе GCP, а также мониторинг, алертинг, логи и т.д. В Altenar я являюсь частью команды автоматизации, которая также занимается релизными пайплайнами, улучшением различных процессов в компании и другими важными вещами. CI, сборки, сеть, доступы - за это отвечают другие команды, и этих частей я касаюсь очень мало либо совсем не трогаю их.
В моей команде издревна использовался flux v1 для кластеров на VM и для GKE в формате "один кластер - один репозиторий", с подключенными "шаблонами" в виде Git submodules. У такого подхода есть свои минусы, один из самых существенных - первая версия flux уже не поддерживается с конца 2020 года.
Таким образом, у нас был некий техдолг в виде первого flux, и необходимость рано или поздно обновляться до версии 2 или переходить на другие инструменты. Был выбран первый вариант, заодно я решил кое-что улучшить в нашей текущей структуре, убрав кучу различных репозиториев и отказавшись от "шаблонов-сабмодулей".
Особенность переезда - часть кластеров я мог пересоздавать без проблем сразу с новой инсталляцией flux v2, например, мой сэндбокс и дев кластер, а часть - в продакшене, для которых надо было продумать вопросы DR если что-то пойдет не так и создать мануал для переезда с минимальным downtime.
Как работает связь между подами в Kubernetes?
Как трафик достигает пода?
В этой статье вы узнаете, как работает низкоуровневая сеть в Kubernetes.
