DevOps

Практическое руководство по настройке CI/CD для PHP проектов

В этом лонгриде я расскажу немного теории о CI/CD, но в основном это будут практические примеры и советы, в первую очередь полезные для PHP backend разработчиков, однако некоторые инструменты подходят и для других языков, и вы можете уловить общую идею, как писать пайплайны

https://habr.com/ru/articles/889120/

#devops #девопс

Подпишись 👉@i_DevOps

📌Docker

Удаление промежуточных образов без тэгов:
docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

Мягко перезапустить контейнер:
docker kill --signal="USR1" <yourcontainer_name>

Список контейнеров:
docker ps -a

Подключиться к контейнеру:
docker exec -it container_name bash

Остановить все контейнеры:
docker stop $(docker ps -a -q)

Удалить все контейнеры, из которых вышли:
docker rm -v $(docker ps -aq -f status=exited)

Удалить образ:
docker rmi image_name

Создать образ:
docker build -t image_name

Удалить все неиспользуемые тома:
docker volume prune

Подключиться под рутом в контейнер Alpine:
docker exec -it --user root alpine-container bash


#devops #девопс

Подпишись 👉@i_DevOps

Шпаргалка по Kubernetes

1. Основные понятия
• Pod – наименьшая единица развертывания, содержит один или несколько контейнеров.
• Deployment – контроллер, который управляет репликами Pod’ов и их обновлением.
• Service – абстракция, предоставляющая доступ к Pod’ам (ClusterIP, NodePort, LoadBalancer).
• ConfigMap – хранит конфигурационные данные в виде ключ-значение.
• Secret – безопасное хранилище для конфиденциальных данных (пароли, токены).
• PersistentVolume (PV) – абстракция для хранения данных.
• PersistentVolumeClaim (PVC) – запрос на использование хранилища (PV).
• Namespace – логическое разделение ресурсов в кластере.
• Ingress – объект, предоставляющий доступ к сервисам внутри кластера через HTTP/HTTPS.

2. Основные команды kubectl

Работа с контекстом

kubectl config get-contexts # Список контекстов
kubectl config use-context <name> # Переключение контекста
kubectl config set-context <name> --namespace=<namespace> # Установить namespace по умолчанию

Работа с ресурсами

kubectl get pods # Список Pod'ов
kubectl get deployments # Список Deployment'ов
kubectl get services # Список Service'ов
kubectl get nodes # Список узлов
kubectl get namespaces # Список namespace'ов
kubectl get events # Лог событий
kubectl describe pod <pod-name> # Подробная информация о Pod
kubectl logs <pod-name> # Логи Pod
kubectl exec -it <pod-name> -- /bin/sh # Зайти внутрь контейнера

Создание и удаление объектов

kubectl apply -f <file>.yaml # Применить манифест
kubectl delete -f <file>.yaml # Удалить объект
kubectl delete pod <pod-name> # Удалить Pod
kubectl delete deployment <deploy-name> # Удалить Deployment

3. Пример манифестов

Простой Pod

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx
ports:
- containerPort: 80

Service (NodePort)

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
type: NodePort

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80

4. Полезные команды

kubectl top pod # Мониторинг использования CPU/RAM Pod'ов
kubectl top node # Мониторинг узлов
kubectl rollout status deployment <deploy-name> # Статус развертывания
kubectl rollout undo deployment <deploy-name> # Откат изменений
kubectl autoscale deployment <deploy-name> --min=2 --max=10 --cpu-percent=80 # Авто-масштабирование

5. Отладка и устранение проблем

kubectl get pods --all-namespaces # Проверить состояние всех Pod'ов
kubectl describe pod <pod-name> # Подробности о Pod
kubectl logs <pod-name> # Логи контейнера
kubectl logs <pod-name> -p # Логи завершившегося контейнера
kubectl exec -it <pod-name> -- /bin/sh # Подключение внутрь контейнера
kubectl get events --sort-by=.metadata.creationTimestamp # Последние события

#devops #девопс

Подпишись 👉@i_DevOps

10 шагов к созданию оркестратора Terragrunt

1. Определите цели – Четко обозначьте, какие задачи должен решать оркестратор: управление инфраструктурой, стандартизация, масштабируемость.

2. Выберите подходящую структуру каталогов – Используйте рекомендуемые шаблоны Terragrunt (например, live и modules), чтобы упростить поддержку кода.

3. Разделите окружения и компоненты – Используйте отдельные файлы для разных окружений (dev, staging, prod), что обеспечит гибкость и контроль.

4. Оптимизируйте конфигурации – Настройте Terragrunt, чтобы минимизировать дублирование кода с помощью наследования (include).

5. Создайте систему автоматизации – Интегрируйте оркестратор в CI/CD-пайплайны для автоматизированного развертывания.

6. Реализуйте контроль доступа – Используйте IAM-роли и политики, чтобы ограничить доступ к инфраструктуре.

7. Настройте работу с зависимостями – Определите порядок применения модулей и настройте зависимости между ними.

8. Добавьте мониторинг и логи – Внедрите системы логирования (например, AWS CloudWatch) для отслеживания изменений.

9. Проводите тестирование инфраструктуры – Используйте инструменты вроде terraform validate, terragrunt plan и checkov для проверки конфигураций.

10. Документируйте процессы – Поддерживайте актуальную документацию, чтобы упростить онбординг новых членов команды.


https://nordcloud.com/tech-community/10-steps-to-building-terragrunt-orchestrator/

#devops #девопс

Подпишись 👉@i_DevOps

Pipeline CI/CD, объясненный простыми словами

Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.

Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.

Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.

Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене

#devops #девопс

Подпишись 👉@i_DevOps

🔥 Как снизить Latency в Kubernetes? 🔥

Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!

🚀 1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:

kubectl edit configmap -n kube-system kube-proxy

Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.

🚀 2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:

helm install cilium cilium/cilium --namespace kube-system

🚀 3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:

kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yaml

Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов.

🚀 4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Эти параметры помогут лучше обрабатывать соединения и снижать задержку.

🚀 5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.

#devops #девопс

Подпишись 👉@i_DevOps

Какой код сигнала будет выполнен при исполнении команды kill <PID>?

Сигнал SIGTERM (код 15) — это сигнал по-умолчанию отправляемый при вызове команды kill. Это указывает процессу на завершение работы и обычно считается сигналом для использования при чистом завершении работы.

#devops #девопс

Подпишись 👉@i_DevOps

Выходим за рамки: создание оператора для наблюдения за внешними ресурсами в Kubernetes

В этой статье мы рассмотрим, как создать оператор, который выходит за рамки кластера и взаимодействует с внешним миром. На примере мониторинга HTTP-серверов вы узнаете, как использовать kubebuilder для разработки custom-операторов и как организовать работу с внешними ресурсами. Статья будет полезна разработчикам, желающим расширить возможности своих Kubernetes-кластеров.

https://habr.com/ru/companies/flant/articles/884566/

#devops #девопс

Подпишись 👉@i_DevOps

Документация как код: принципы, рабочий процесс и вызовы

В современном мире разработки программного обеспечения концепция «Документация как код» (Documentation as Code, DaC) становится все более популярной. Этот подход использует инструменты и практики разработки программного обеспечения для написания, хранения и управления документацией.

🔹 Основные принципы

1. Хранение в системе контроля версий
Документация хранится в репозитории вместе с кодом, что позволяет отслеживать изменения, откатываться к предыдущим версиям и сотрудничать в команде.

2. Использование текстовых форматов (Markdown, AsciiDoc, reStructuredText и др.)
Вместо сложных редакторов документация пишется в простых текстовых форматах, что облегчает интеграцию с инструментами CI/CD.

3. Автоматизация сборки и публикации
Документация может автоматически обновляться и развертываться при каждом изменении кода.

4. Документирование в процессе разработки
Документация пишется параллельно с кодом, а не после него, что делает её актуальной.

5. Использование инструментов рецензирования
Pull Request'ы, ревью и линтеры помогают поддерживать качество документации.

🔹 Рабочий процесс

1. Создание документации – разработчик или технический писатель пишет документацию в виде кода.
2. Рецензирование – команда проводит код-ревью документации.
3. Автоматическая проверка – линтеры и тесты проверяют синтаксис, ссылки и структуру.
4. Сборка и развертывание – система CI/CD публикует документацию в нужном формате.
5. Обновление и поддержка – документация развивается вместе с кодом.

🔹 Вызовы и сложности

🔸 Сопротивление со стороны команды – не все привыкли писать документацию в таком формате.
🔸 Необходимость в новых инструментах – Markdown или AsciiDoc, системы рендеринга (MkDocs, Docusaurus).
🔸 Поддержание актуальности – требуется дисциплина, чтобы обновлять документацию вместе с кодом.
🔸 Интеграция в CI/CD – настройка автоматического развертывания требует времени.

https://www.tabnine.com/blog/documentation-as-code-principles-workflow-and-challenges/

#devops #девопс

Подпишись 👉@i_DevOps

Nix: насколько хороша альтернатива Dockerfile?

Современная бэкенд‑разработка не обходится без средств контейнеризации. Самому простому приложению, скорее всего, будет нужна хотя бы база данных или пучок дополнительных зависимостей из веб‑серверов, балансировщиков, сборщиков логов и метрик. Для быстрого их развёртывания и настройки используются кастомные или готовые образы и контейнеры. И когда разговор заходит о контейнерах, первое, что приходит на ум, — это Docker и Dockerfile.

Для многих это стандарт, отклонения от которого вызывают недоумение и вопросы. Но даже у всего хорошего есть альтернативы. Одна из них — Nix. Насколько она сопоставима по удобству и скорости с Docker?

Меня зовут Борис Табачников, я разработчик отдела RnD в СберТехе. Кратко расскажу, что такое Nix в целом, зачем вам его использовать и подробно сравню скорость работы Nix и Docker.

Статья будет полезна DevOps‑инженерам и разработчикам, интересующимся контейнеризацией. И особенно — тем, кто ищет альтернативы для Docker и кого заинтересовал Nix, но при этом сферы его использования и применимость для сборки образов недостаточно понятна.

https://habr.com/ru/companies/sberbank/articles/887722/

#devops #девопс

Подпишись 👉@i_DevOps

Docker

Traefik в docker-compose
Быстрый старт с Docker Swarm
DOCKER COMPOSE и как работает сеть в ДОКЕРЕ
Запуск веб сервера Nginx в Docker
Docker Swarm & Gitlab - быстрый деплой для любого проекта
Docker. Основы - Сборка образов и сеть
Основы DOCKER с нуля

источник

#devops #девопс

Подпишись 👉@i_DevOps

Kubernetes CPU Limits и их влияние на Go-приложения

Интересный разбор влияния CPU Limits в Kubernetes на производительность Go-приложений. В статье рассматривается, как ограничение CPU может привести к проблемам с планировщиком Go, вызывая значительные задержки из-за принудительного троттлинга.

Ключевые моменты:
- CPU Limits могут привести к увеличению времени работы GOMAXPROCS, что негативно сказывается на обработке горутин.
- Ограничение процессорного времени может вызвать неожиданные задержки в планировании задач, что особенно критично для высоконагруженных сервисов.
- Использование CPU Requests вместо жестких ограничений помогает избежать этих проблем, позволяя Kubernetes корректно распределять ресурсы.

https://www.ardanlabs.com/blog/2024/02/kubernetes-cpu-limits-go.html

#devops #девопс

Подпишись 👉@i_DevOps

Garnet — это удалённое кэш-хранилище от Microsoft Research, обеспечивающее высокую производительность (пропускную способность и задержку), масштабируемость, хранение, восстановление, шардирование кластера, миграцию ключей и функции репликации. Garnet может работать с существующими клиентами Redis.

Основные возможности:
- Высокая производительность: миллионы операций в секунду с минимальной задержкой.
- Масштабируемость: поддержка горизонтального масштабирования.
- Оптимизация работы с памятью: эффективное использование DRAM и SSD.

Этот проект может стать серьезным конкурентом Redis и Memcached в сфере облачных сервисов.

https://github.com/microsoft/garnet

#devops #девопс

Подпишись 👉@i_DevOps

#вакансия #удалённо #parttime #преподаватель #DevOps #Kubernetes #GitOps

Компания: образовательная платформа OTUS:

Вакансия: преподаватель онлайн-курсов
- Инфраструктурная платформа на основе Kubernetes
- GitOps

Преподавательский опыт не обязателен — у нас есть вводный курс о преподавании и пробные уроки с методистом.

Требуется практический опыт и знания по тематике курса, подробнее в ЛС.

Обязанности:
- Подготовиться к занятиям и провести их
- Формат занятий: онлайн, важно уделять внимание практике. Здесь вы сможете развивать навыки публичных выступлений, работы с аудиторией и подачи обратной связи
- За доплату возможна проверка домашних заданий и проектов

Условия:
✅ Занятия по будням с 20:00 до 21:30, можно оставлять пожелания по расписанию
✅ Оплата: от 3000 до 6000 руб. за вебинар (полтора часа) и 300-400 рублей за проверку 1 домашнего задания, 1000 руб. за проверку 1 проекта
✅ Бонусы: доступ к курсам OTUS, нетворкинг, развитие личного бренда, наши воркшопы и конференции

Обсудить подробнее: @HR_Nikita 📩