DevOps FM

Выбор размера нод Что ж, выбор зависит от множества факторов, как всегда! Истина где-то посередине и не стоит выбирать ни одну из крайностей. Вам нужно ответить на вопросы ниже, чтобы найти свой оптимальный размер. Какой тип приложений вы запускаете? Вы запускаете микросервисы из множества контейнеров, которые занимают мало места, или несколько монолитов, требующих гигабайты оперативной памяти и целые ядра CPU? Базы данных? Или все вместе? Можно ли объединить приложения в группы? Для смешанных окружений, можете ли вы разделить приложения по категориям? Например, если вы запускаете микросервисное приложение, которое работает с БД MySQL, вы разделяете его компоненты на группы приложений и баз данных. Аналогично, если вы запускаете вместе и монолиты и микросервисы, как ELK стек для мониторинга кластера, вы можете разместить его компоненты по разным группам. Для простоты я назвал только три категории, но вы можете создать столько, сколько хотите. Максимальное количество ресурсов для каждой категории Если вы можете сгруппировать приложения по категориям, то после этого вам нужно понять сколько максимум ресурсов может потребоваться на одно приложение из каждой категории. Например, если вы запускаете микросервисы, монолиты и БД в кластере, вам нужно взять максимальные затраты на один инстанс БД, микросервис или монолит. Посчитать количество приложений в каждой категории Следующий шаг это найти планируемое количество приложений в каждой из категорий. У вас может быть, например, 8 БД MySQL, 200 микросервисов и 9 монолитов. Запишите их. Не перебарщивайте. Kubernetes спроектирован для масштабирования и вы всегда можете использовать автоматическое масштабирование кластера у некоторых провайдеров. Либо, вы можете добавить ноду вручную позже. Поместите каждую категорию в отдельный пул нод Лучший способ оптимизировать ноды это создать пул нод под каждую категорию. Большинство Kubernetes кластеров работают с различными пулами нод и разнородные ноды можно подключать к самостоятельно управляемым кластерам. Заложите отказоустойчивость Нужно иметь минимум две ноды в каждом пуле для достижения отказоустойчивости. Kubernetes рекомендует максимум 110 контейнеров на ноду. Так же есть ещё системные контейнеры, которые запущены на нодах, так что имейте это ввиду. Может вам придется согласовать это значение с вашим облачным провайдером, так как они могут предоставлять разного уровня жесткости ограничения на количество подов, запущенных на ноде. Идея в том, чтобы не вылезать за лимит. Подгоните свои ноды под контейнеры для оптимального управления ресурсами Если мы ожидаем падение одной ноды за раз, то должны заложить избыток ресурсов на каждой ноде так, чтобы при падении на них могли переехать ресурсы с упавшей ноды. Подгоните ваши контейнеры и ноды для лучшего возможного управления ресурсами. Например, если у нас есть 20 контейнеров, лучше всего будет распределить по 4 пода на одну ноду, тогда нам нужно иметь в запасе 20% ресурсов на каждой ноде, вместо 100% как если бы у нас было всего 2 ноды. Как мы пришли к этой цифре? Просто возьмите квадратный корень от количества контейнеров и округлите в меньшую сторону. Это даст вам максимальное количество контейнеров, которое должно быть у вас на ноде. Учтите нагрузку от самого Kubernetes Учтите тот факт, что системные компоненты Kubernetes так же будут потреблять какое-то количество CPU и памяти на каждой ноде, поэтому на самом деле вам будет доступно меньше ресурсов, чем есть на ноде. Уточните эти параметры у вашего облачного провайдера и добавьте к ресурсам ноды. *️⃣2/3: продолжение следует :)

На сегодня, 15.08.2023, назначен релиз Kubernetes 1.28 🎉 Для знакомства с улучшениями рекомендуем классную статью из блога с забавным названием Ku🍺netes. Всего запланировано 44 изменения, из которых 19 Alpha, 14 Beta и 11 Stable.

Всем DevOps! 🖖 Продолжаем наблюдать за реакцией сообщества на заявление HashiCorp. Вот, например, на Hacker News рассуждают о плюсах и минусах смены лицензии. Там же поделились репозиторием Open-Terraform. Open-Terraform — это форк Terraform от Hashicorp с открытым исходным кодом, который сохраняет лицензию MPL после объявления Hashicorp об изменении лицензии на BSL. В общем, будем наблюдать. Кроме Terraform лицензию изменили у всех основных продуктов компании (Vault, Vagrant, Consul, Nomad, Packer, Boundary). Затронуло ли вас изменение лицензии HashiСorp? Планируете переходить на альтернативы?

👋 Друзья, коллеги, господа! У нас накипело! ⌨️ Полгода назад взломали сервера нашего крупного клиента. Причина — «дыра» в выделенных серверах в ЦОДе провайдера. Перевезли к себе и защитили. 🔴 Месяц назад упала инфраструктура у другого клиента... ... и снова на выделенных серверах у крупного провайдера. 📍 Неделю назад «умерли» сервера ещё у трёх — тоже перевезли к себе. 📌 При этом цены на «дедики» летят в космос, техподдержка не радует вовлечённостью, а клиенты и партнёры сетуют на качество. Выделенные сервера — не наш бизнес. Мы — сервис-провайдер и занимаемся облаками, но пул клиентов растёт, и вам нравится то, что мы делаем. Поэтому мы создаём новый сервис по аренде выделенных серверов: 💸 с адекватными ценами; 🤝 качественной техподдержкой; ✅ клиентом на первом месте. Мы хотим учесть пожелания каждого, поэтому проводим короткий опрос на 3 минуты. Пожалуйста, поделитесь своим мнением, вы очень поможете. ❗️Все новости и обновления нового сервиса будут в этой группе. Присоединяйтесь, если вы ждали Hetzner по-русски.

HashiCorp меняет лицензию на исходный код Компания сообщила, что переходит с Mozilla Public License v2.0 (MPL 2.0) на лицензию Business Source (BSL, также известную как BUSL) v1.1 для всех будущих выпусков продуктов HashiCorp. API-интерфейсы HashiCorp, SDK и почти все другие библиотеки останутся MPL 2.0. Подробнее про лицензию BSL можно узнать здесь.

Всем DevOps! 🖖 В одной из рассылок (старый добрый email 🥰) была поднята интересная тема. Итак, полторы недели назад инженер по машинному обучению написал анализ под названием «Падение Stack Overflow». Из собранных им данных и из данных, которыми делится StackOverflow с самой активной частью комьюнити, следует, что Stack Overflow потерял около 50% своего трафика. Впрочем оказалось, что данные о трафике не учитывают изменения в Google Analytics. С учетом этого падение составило бы 35%. Тем не менее, самая тревожная часть статистики — это не трафик, а снижение количества задаваемых вопросов и ответов. Кажется, что падение Stack Overflow (и прочих подобных сайтов) связано с активным развитием AI-инструментов для написания кода (ChatGPT, Copilot и т.д.) — пользователи все больше отдают им предпочтение. Автор рассылки связался со Stack Overflow, чтобы получить официальный комментарий и разобраться в ситуации. Вобщем, можете посмотреть это письмо в Telegraph, ну и поделиться своим мнением в комментариях :) Пользуетесь ли вы AI-инструментами для работы с кодом? Или просто для рабочих задач? А Stack Overflow — пользуетесь?

Failover & Fallback Похожие термины, но важно понимать различие :) То, что вы думаете, может не совпадать с тем, что вы говорите, то, что вы говорите, может не совпадать с тем, что слышится, а то, что слышится, может не совпадать с тем, что реализуется! В небольшой серии (первая часть, вторая часть) подробно рассказывается про эти стратегии (очень наглядные схемы) и разницу между ними, описываются ситуации, в которых стоит отдать предпочтение тому или иному варианту. ❓Failover — переключение с основной системы на запасную, если первая вышли из строя или недоступна. ❓Fallback — возврат к предыдущему состоянию или конфигурации, если изменение или обновление вызвало проблемы.

Все еще боитесь PostgreSQL? Считаете ее слишком сложной? 🤯 Популярность СУБД PostgreSQL в России растет с каждым днем, также как и востребованность специалистов по ней :) Подписывайтесь на Postgres Guru и больше не бойтесь! В канале вас ждут: ▪️ Основы PostgreSQL; ▪️ Методы повышения производительности; ▪️ Разбор ошибок и их решения; ▪️ Полезные SQL запросы и функции PostgreSQL; ▪️ Случаи из практики; ▪️ Новости из мира PostgreSQL и немного юмора 😁 Подписывайтесь и становитесь востребованными специалистами по PostgreSQL!

Всем DevOps! 🖖 Думаем, вы видели новости про массовый сбой в работе VPN-протоколов OpenVPN и WireGuard. В связи с этим хотим напомнить про хорошую серию статей на Хабре: ▪️Статья «Интернет-цензура и обход блокировок: не время расслабляться» — опыт других стран по части блокировок. ▪️Статья «Современные технологии обхода блокировок: V2Ray, XRay, XTLS, Hysteria, Cloak и все-все-все» — обзор самых передовых протоколов и технологий, которые позволяют делать передаваемый трафик не похожим вообще ни на один существующий стандартный протокол, либо наоборот, позволяют максимально достоверно маскироваться под безобидный HTTPS-трафик. ▪️Статья «Программы-клиенты для протоколов недетектируемого обхода блокировок сайтов: V2Ray/XRay, Clash, Sing-Box, и другие» — найти хороший клиент даже для тех же V2Ray/XRay в наше время не так-то просто. Большая часть того, что находится при поиске в интернете “в лоб” и даже в списках типа Awesome V2Ray — или уже неподдерживаемое, или довольно кривое, или не умеющее в актуальные версии и фичи, а самые жемчужины прячутся где-нибудь в глубинах Github’а и аппсторов. ▪️Статья «Обход блокировок: настройка сервера XRay для Shadowsocks-2022 и VLESS с XTLS-Vision, Websockets и фейковым веб-сайтом» — как настроить свой личный прокси‑сервер с современными протоколами для обхода блокировок. Настройка сервера на базе XRay с протоколами Shadowsocks-2022 и VLESS с транспортом XTLS‑Vision и фейковым веб‑сайтом. ▪️Статья «Bleeding-edge обход блокировок с полной маскировкой: настраиваем сервер и клиент XRay с XTLS-Reality быстро и просто» — XTLS-Reality: как настроить клиент и сервер для нее. Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XRay для XTLS-Reality гораздо проще ▪️Статья «3X-UI: Shadowsocks-2022 & XRay (XTLS) сервер с простой настройкой и приятным интерфейсом» — установка и использование графической панели 3X-UI для сервера X-Ray с поддержкой всего того, что умеет X-Ray: Shadowsocks-2022, VLESS с XTLS и т.д.

17 минут чтива... Туториал кратенький так сказать Keycloak — больно не будет (правда уровень сложности hard, но вы не обращайте внимания 🙃) Алексей, DevOps-инженер компании Nixys, рассказал про проект, в рамках которого совершенствовали систему контроля доступа и показал, как реализовать единую точку авторизации через Keycloak. ➡️ Приятного чтения!

Всем DevOps! 🖖 Некоторое время назад мы рассказывали про отличную книгу «Ansible for DevOps». А еще у автора этой книги есть много полезных репозиториев с ролями Ansible. Собрали некоторые из них, но рекомендуем посмотреть GitHub автора целиком. ❓Роль Ansible — это набор файлов, задач, шаблонов, переменных и обработчиков, которые вместе служат определенной цели, например, для настройки службы. Роли позволяют легко повторно использовать код и делиться решениями Ansible с другими пользователями, что делает работу с большими средами более управляемой. ▪️Ansible-role-kubernetes — роль Ansible, которая устанавливает Kubernetes в Linux. ▪️Ansible-role-docker — роль Ansible, которая устанавливает Docker в Linux. ▪️Ansible-role-nginx — неофициальная роль для Nginx (есть официальная). Устанавливает Nginx на серверы RedHat/CentOS, Debian/Ubuntu, Archlinux, FreeBSD или OpenBSD. ▪️Ansible-role-gitlab — устанавливает GitLab, внешний интерфейс для Git на основе Ruby, в любой Linux-системе RedHat/CentOS или Debian/Ubuntu. ▪️Ansible-role-postgresql — устанавливает и настраивает сервер PostgreSQL на серверах RHEL/CentOS или Debian/Ubuntu. ▪️Ansible-role-mysql — устанавливает и настраивает сервер MySQL или MariaDB на серверах RHEL/CentOS или Debian/Ubuntu. ▪️Ansible-role-jenkins — устанавливает Jenkins CI на серверы RHEL/CentOS и Debian/Ubuntu. ▪️Ansible-role-rabbitmq — устанавливает RabbitMQ в Linux. ▪️Ansible-role-security — выполняет базовую настройку безопасности в Linux-системах на основе RedHat и Debian.

Открытое исследование «Защита персональных данных 2023» 🔒 За 2022-2023 год ужесточились условия и регулирование по 152-ФЗ. На форумах мы слышим как всё меняется, но лозунги со сцен конференций и обновление ФЗ — это одна сторона медали, а реальная практика и опыт сообщества — совсем другая. Компания Cortel проводит открытое исследование «Защита персональных данных 2023» чтобы выяснить: • Как эксперты на местах смотрят на ситуацию; • Как в действительности обстоят дела с ПДн и их защитой на практике. Пожалуйста поделитесь своим мнением и пройдите короткий опрос на 3 минуты по этой ссылке, вы очень поможете. 🛡 Результатами исследования поделятся осенью в этом канале.

Всем DevOps! 🖖 Хочется порекомендовать отличный блог про инфраструктуру, платформы, Linux, Open Source, DevOps, Kubernetes, контейнеризацию и облака. А еще автор пишет про Python, Go и shell. Начать знакомство можно, например, со статьи «Kubernetes Taints, Tolerations, and Understanding the PreferNoSchedule Effect» — в ней говорится про эффект PreferNoSchedule в Kubernetes и его отличия от NoExecute и NoSchedule. Есть классная схема про принцип работы PreferNoSchedule. Еще автор иногда пишет на смежные темы, например, заметка «12 Tips for Effective Technical Blogging». Вдруг вы ведете блог или просто пишете на Хабр? Будет полезно 😎 P.S. Кстати про технические блоги и Хабр! Может, здесь есть авторы? Расскажите о своих блогах в комментариях :) Почему решили вести блог? А если вы не автор, можете рассказать — что вообще думаете о технических блогах? Почему не хотите писать сами? Ну и, конечно, делитесь — кого читаете?

💥 Коллеги из KazDevOps разыгрывают бесплатную консультацию по DevOps-вопросам с топами компании Core 24/7. 👉 3 победителя смогут задать вопросы техлиду и узнать, почему то или иное решение не работает, как настроить процесс эффективнее и от чего стоит отказаться. Условия конкурса: • Быть подписчиком KazDevOps • Рассказать о своей ситуации вкратце под аналогичным постом в канале KazDevOps — 1-2 предложения о проблеме, задаче или амбициях, связанных с DevOps • Дождаться розыгрыша — победителей объявят 10 августа: проверят условия выше и рандомом определят 3 человек, которые представляют свой бизнес или работают в компании 🤝 Делитесь с коллегами и ожидайте звонка #devops #devsecops #cloud #kubernetes #docker #terraform #giltab @DevOpsKaz

Docker подробно рассказали про атрибут include — он уже сейчас доступен в Docker Compose v2.20.0 и появится в грядущем релизе Docker Desktop 4.22 🅰️ Командная строка docker поддерживает множество флагов для точной настройки контейнера и трудно запомнить их все при репликации среды. Сделать это еще сложнее, когда приложение представляет собой не отдельный контейнер, а комбинацию многих контейнеров с различными отношениями зависимостей. Именно поэтому Docker Compose быстро стал популярным инструментом. Тем не менее, проблема сохраняется для больших приложений, использующих десятки, а может быть, и сотни контейнеров, с распределением прав собственности между несколькими командами. При использовании монорепозиториев команды часто имеют свой собственный “локальный” Docker Compose file для запуска подмножества приложения, но тогда им нужно полагаться на то, что другие команды предоставят справочный файл Compose, который определяет ожидаемый способ запуска их собственного подмножества. Эта проблема не нова и обсуждалась в 2014 году, когда Docker Compose был совсем новым проектом. Теперь мы внедрили возможность “compose compose files” — не прошло и 10 лет! 🅱️ 📌 Спецификация Compose, раздел про include

Как DevOps помог исправить 30 точек операционной неэффективности в промышленности Внедрение DevOps в промышленности началось не вчера, активное применение практик тоже, но говорят об этом по-прежнему немного. Компания Nixys рассказала, как DevOps помог улучшить работу горнодобывающей компании. ➡️ Приятного чтения!

DevOops — одна из крупнейших конференций по инженерным решениям и DevOps-культуре в России. Она объединяет специалистов по разработке и эксплуатации, чтобы все могли релизить чаще, а чинить быстрее и надежнее. В сентябре DevOops 2023 впервые будет идти 4 дня — 2 в онлайне и 2 в офлайне. В онлайне вы сможете сосредоточиться на практико-ориентированных докладах, а в офлайне — познакомиться с коллегами на нетворкинге, отдохнуть от рабочих задач и вживую обсудить со спикерами новые подходы и инструменты. В программе — выступления от постоянных спикеров и новых лиц, чья работа определяет состояние DevOps сегодня. Они расскажут о безопасности K8s, Cloud, SRE, DevOps-культуре и новых подходах к безопасной разработке. На DevOops 2023 есть два типа билетов : ➡️ Персональный: для тех, кто участвует самостоятельно. Промокод devopsfm даст на него скидку 10%. ➡️ Корпоративный: для тех, за кого платит компания. Изучайте расписание, выбирайте билеты и присоединяйтесь к единомышленникам на DevOops 2023.

Всем DevOps! 🖖 Снова скопилось некоторое количество классных статей — с радостью делимся подборкой! ⚙️ «All right then, keep your secrets in Git with SOPS». Из этой статьи вы узнаете, как объединить Helm, Helmfile и SOPS для безопасного хранения ваших секретов в Git. ⚙️ Серия из трех частей про Platform Engineering. В первой части говорится почему вообще Platform Engineering приобрел такое большое значение. Во второй части — что такое этот ваш Platform Engineering и какие цели могут быть у команды платформенных инженеров. В третьей — когда нужна команда платформы и как создать IDP (внутреннюю платформу разработчиков). ⚙️ В Terraform 1.5 появился config-driven import (новость можно найти здесь). Мы уже рекомендовали статью про это новшество, но все-таки порекомендуем еще одну: «Automating alert creation with Terraform config-driven import in Google Cloud». В примере используется Google Cloud, но теория (со схемами :) будет полезна всем. ⚙️ Статья про tefsec — open source инструмент статического анализа, который сканирует код Terraform, выявляет и выделяет пробелы в аспекте безопасности с точки зрения инфраструктуры и IaC. Подробно рассказано про всю работу: от установки до использования. P.S. Для чтения большей части статей требуется VPN, а для некоторых (на Medium) — может быть полезно расширение Bypass Paywalls 😎

🚀Двухскоростное ИТ: связь DevOps, Lean, ITIL и Agile в бизнесе Несмотря на масштабы, гиганты рынка, такие как Facebook и Google, выпускают по несколько релизов в день Чтобы достичь таких результатов без потери качества, компании обращаются к двухскоростному ИТ - подходу от Gartner. Концепция предполагает одновременное управления двумя режимами работы: – Traditional IT ориентирован на снижение рисков и безопасность. – Agile IT — на гибкость. Подробнее о том: ⚡️ как двухскоростное ИТ объединяет скорость и непрерывность; ⚡️ причём здесь DevOps, Lean, ITIL и Agile; ⚡️ как это выглядит в реальности на примере DevOps HP; ⚡️ и чем подход Gartner полезен бизнесу - - рассказали в новом материале