Строим CI/CD. Что такое Continuous integration, Continuous delivery, Continuous deployment

Что такое Continuous integration, Continuous delivery, Continuous deployment? Непрерывная интеграция, непрерывная доставка и непрерывное развертывание? Эти вопросы часто задают на собеседованиях DevOps. Эта практика применима в SRE. Да и чтобы построить идеальный CI/CD без теории никуда.

00:00 - Continuous integration и Continuous delivery
01:01 - Акции и розыгрыши от FirstVDS
02:53 - О чем CI/CD?
03:19 - Основные принципы CI/CD
04:29 - Этапы разработки CI/CD
05:46 - Чем отличается непрерывная интеграция, непрерывная доставка и непрерывное развертывание?
07:11 - Рассмотрим CI/CD на простом примере

источник

👉 @devops_star

Kubernetes: 5 продакшен-настроек, которые спасут ваши нервы

Продакшен в Kubernetes — это всегда проверка на прочность. Ошибки в базовых настройках могут стоить простоев, потерь данных и бессонных ночей. Рассказываю, что обязательно учесть, чтобы спать спокойно.

1. Настройте PodDisruptionBudget (PDB)
Без PDB кластер-автоапдейты или масштабирование могут случайно снести все поды вашего сервиса. Обязательно задайте minAvailable или maxUnavailable, чтобы контролировать, сколько подов можно уронить.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: my-app


2. Лимитируйте ресурсы подов (requests и limits)
Без лимитов одно неудачное приложение может заддосить весь нод. Обязательно указывайте resources в манифестах.

resources:
requests:
cpu: "200m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"


3. Включите livenessProbe и readinessProbe
Без них Kubernetes не сможет корректно понимать, когда приложение мертво или еще не готово к трафику. Лишние 10 строк YAML могут спасти тысячи пользователей.

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 3


4. Логируйте правильно
Никогда не пишите логи в файл внутри контейнера! Используйте stdout/stderr, чтобы всё шло через стандартные механизмы логирования кластера (например, через Fluentd или Loki).

5. Сетевые политики (NetworkPolicy)
Открытый по умолчанию трафик внутри кластера — угроза безопасности. Настройте NetworkPolicy, чтобы явно разрешать трафик между подами.

Вывод:
Эти пять практик — обязательная база для продакшена в Kubernetes. Они минимизируют неожиданные падения, повышают безопасность и делают поддержку сервисов гораздо проще. Самая частая ошибка — полагать, что “и так сойдет” на старте. Не экономьте время на правильных настройках — потом сэкономите недели на устранении последствий.

👉 @devops_star

Что такое платформенная инженерия: как она связана с DevOps и SRE?

Появление новых ролей и обязанностей в IT и разработке сильно повлияло на работу современных компаний. Одно из направлений, которое с каждым годом становится популярнее, — платформенная инженерия. В этой статье разберемся, что это такое, почему важность ПИ растет и какое отношение она имеет к DevOps и SRE (Site Reliability Engineering).

https://habr.com/ru/companies/agima/articles/793922/

original https://www.harrisonclarke.com/blog/what-is-platform-engineering-how-does-it-compare-with-devops-and-sre

👉 @devops_star

Как мы управляем инфраструктурой на более 1000 серверов при помощи Ansible

Мы системные инженеры X5 Tech — Алексей Кузнецов и Борис Мурашин. У нас за плечами больше 15 лет опыта, в том числе поддержка сервисов Rapida, CyberPlat, TeleTrade, сопровождение стека BigData и внедрение кластеров Hadoop.

В этой статье мы расскажем, как выбирали систему управления конфигурациями, какими критериями руководствовались, что в итоге выбрали, с какими проблемами столкнулись и как их решали.

Рассматривать вопрос, зачем вообще нужна система управления конфигурацией, не будем. Потому что считаем, что если у вас больше одного сервера, она уже необходима. Перейдём сразу к тому, почему мы выбрали именно Ansible.

https://habr.com/ru/companies/oleg-bunin/articles/788552/

👉 @devops_star

CKS

Открытая платформа для изучения kubernetes и aws eks и подготовки к экзаменам Certified Kubernetes Specialist (CKA , CKS , CKAD)

SRE Learning Platform - это центр с открытым исходным кодом, призванный помочь ИТ-инженерам эффективно подготовиться к экзаменам CKA (Certified Kubernetes Administrator), CKS (Certified Kubernetes Security Specialist) и CKAD (Certified Kubernetes Application Developer). Кроме того, данная платформа предлагает бесценный практический опыт работы с AWS EKS (Elastic Kubernetes Service), что позволяет пользователям получить практические знания для применения в реальных условиях. Если вы хотите подтвердить свои навыки, повысить карьерные перспективы в области администрирования Kubernetes, безопасности, разработки приложений или углубиться в изучение AWS EKS, эта платформа предоставляет практические лабораторные работы, практические тесты и рекомендации экспертов для успешного прохождения сертификации.

Подготовка к экзамену CKA: Certified Kubernetes Administrator
Повысьте свои навыки для экзамена CKS: Certified Kubernetes Security Specialist
Превосходно подготовиться к экзамену CKAD: Certified Kubernetes Application Developer Exam

https://github.com/ViktorUJ/cks

👉 @devops_star

Пять инструментов Helm для улучшения качества жизни Kubernetes

После многих лет работы с беспорядочными, непоследовательными yaml-файлами для Kubernetes я перешел на Helm пять с лишним лет назад и с тех пор не оглядывался назад. Все, кто взаимодействует с Kubernetes, уже должны знать о Helm. Это инструмент, который автоматизирует создание, упаковку, настройку и развертывание приложений на базе Kubernetes. Объединяя ваши конфигурационные файлы в единый пакет многоразового использования, он делает развертывание более последовательным, повторяемым и надежным, устраняя при этом множество человеческих ошибок.

https://home.robusta.dev/blog/top-five-helm-addon-tools-for-kubernetes

👉 @devops_star

4 важных отличия DevOps от SRE

Если вы знаете, что такое Site Reliability Engineering, вам может быть интересно, как эти практики связаны с DevOps. Важно сразу оговориться, что мы не ставим между ними слово «против». Хотя у этих подходов есть некоторые отличия в том, как лучше делать и быстрее доставлять программное обеспечение. В этом посте разберём каждый подход и выясним, чем отличаются DevOps и SRE. Вы заметите, что у подхода SRE есть своё мнение по поводу запуска производственных систем, в то время как DevOps больше фокусируется на людях, процессах и инструментах — именно в этом порядке.

Rus https://habr.com/ru/companies/southbridge/articles/747780/

Eng https://dev.to/scalyr/devops-vs-sre-4-important-differences-1fa2

👉 @devops_star

Xeol

Cканер образов контейнеров, SBOM и файловых систем на проверку пакетов на end-of-life (EOL)

https://github.com/xeol-io/xeol

👉 @devops_star

Что такое GitOps. Улучшенный DevOps?

00:00 Что такое GitOps
00:18 Нетология - DevOps инженер
01:20 Кратко о DevOps
02:00 IoC инфраструктура как код
03:45 Важность системы контроля версий
05:28 Где кончается DevOps
06:57 Код приложения и инфраструктуры вместе
07:55 Автоматизация
09:20 Важность обозреваемости системы
09:49 Зачем GitOps?

источник

👉 @devops_star

База данных на Kubernetes

Введение в развертывание базы данных на Kubernetes

С ростом внедрения DevOps все больше приложений контейнеризируется, а инструменты для управления этими контейнерами, такие как Kubernetes, становятся все более популярными. Этот рост миграции приложений на Kubernetes (K8s) также отражается на приложениях с поддержкой состояния (например, системах баз данных).

Для начала давайте разберемся в основах:

Для развертывания любого приложения на K8s наиболее предпочтительным является декларативный способ, при котором мы объявляем желаемое состояние приложения (например, образ, который должен использоваться для запуска подов, масштабирование подов для управления нагрузкой и т.д.) в YAML-файле, который известен как файл развертывания.

https://chetak.hashnode.dev/database-on-kubernetes

👉 @devops_star

Архитектура кластеров Kubernetes - выбор размера рабочего узла

Стоит ли создавать кластер Kubernetes с меньшим количеством крупных узлов или с большим количеством мелких узлов? В этой статье мы рассмотрим все плюсы и минусы.

Когда вы создаете кластер Kubernetes, одним из первых вопросов, который у вас может возникнуть, является: "Какой тип рабочих узлов я должен использовать и сколько их нужно?".

Если вы создаете локальный кластер, стоит ли заказывать серверы последнего поколения или использовать дюжину или около того старых машин, которые валяются в вашем центре обработки данных?

Или если вы используете управляемый сервис Kubernetes, например Google Kubernetes Engine (GKE), следует ли вам использовать восемь экземпляров n1-standard-1 или два экземпляра n1-standard-4 для достижения желаемой вычислительной мощности?

https://learnk8s.io/kubernetes-node-size

👉 @devops_star