DevOps Star (Звезда Девопса)

❓ Вы в курсе, что можно автоматизировать инфраструктуру как код с помощью Terraform и GitLab? ⏰ На открытом уроке 3 апреля в 20:00 мск Вячеслав Федосеев расскажет, как настроить CI/CD-пайплайны для работы с Terraform, разграничивать окружения и эффективно управлять конфигурацией. Вячеслав — эксперт в IT с 2006 года, от первых Linux-серверов до масштабных DevOps-решений. Автор и ментор курсов по DevOps и CI/CD. Если вы DevOps-специалист, архитектор или инженер, стремящийся оптимизировать процессы и автоматизировать инфраструктуру, этот урок для вас. Повышайте свою квалификацию, изучив лучшие практики IaC, и получайте навыки, востребованные на рынке. 🎁 Все участники вебинара получат скидку на полный курс по CI/CD на основе Gitlab. 👉 Для участия зарегистрируйтесь https://vk.cc/cKdzMF Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Освоение командной строки curl с Дэниелом Стенбергом 0:00 Mastering the curl command line 0:16 Daniel Stenberg 0:36 curl support by wolfSSL 0:56 setup 02:20 questions 02:52 agenda 05:25 The project 05:42 take-off 07:42 name 09:17 main products 10:48 open source ................. 3:15:50 HTTP/2 3:17:20 HTTP/3 3:18:44 HTTP/3 racing 3:20:57 HTTP alt-svc 3:22:50 HTTP HSTS 3:24:39 FTP 3:25:42 FTP(S) is not SFTP 3:26:17 FTP uses two connections 3:28:43 FTP authentication 3:29:06 FTP directory listing 3:30:24 FTP upload 3:31:16 FTPS is FTP with TLS 3:32:43 Future 3:33:01 How to dig deeper 3:35:18 Going next? 3:38:07 You can help! 3:38:14 Questions источник 👉 @devops_star

Watchtower: лучший способ автоматически обновлять Docker контейнеры В этом видео мы рассмотрим, как использовать Docker Watchtower для автоматического обновления контейнеров Docker. Watchtower - это удобный инструмент, который может существенно упростить процесс обновления контейнеров Docker. Мы покажем, как настроить Watchtower для автоматического обновления ваших контейнеров и расскажем о преимуществах этого подхода. источник 👉 @devops_star

Учимся использовать разные типы переменных в Ansible Переменные Ansible — это динамические значения, которые используются в плейбуках и ролях Ansible для настройки и возможности повторного использования конфигураций. Они очень похожи на переменные в языках программирования и помогают эффективно управлять сложными задачами. Они позволяют применять один и тот же сценарий или роль в разных средах, системах или контекстах без необходимости хардкодинга конкретной информации. Представляем перевод статьи, где подробно рассматриваются переменные Ansible. https://habr.com/ru/companies/southbridge/articles/755266/ 👉 @devops_star

Kubectx + Kubens: Power tools for kubectl kubectx - инструмент для более быстрого переключения между контекстами (кластерами) на kubectl kubens - инструмент, позволяющий легко переключаться между пространствами имен Kubernetes (и настраивать их для kubectl) https://github.com/ahmetb/kubectx Пример # switch to another cluster that's in kubeconfig $ kubectx minikube Switched to context "minikube". # switch back to previous cluster $ kubectx - Switched to context "oregon". # rename context $ kubectx dublin=gke_ahmetb_europe-west1-b_dublin Context "gke_ahmetb_europe-west1-b_dublin" renamed to "dublin". # change the active namespace on kubectl $ kubens kube-system Context "test" set. Active namespace is "kube-system". # go back to the previous namespace $ kubens - Context "test" set. Active namespace is "default". 👉 @devops_star

💻 Новый путь: из госслужбы в DevOps Когда работа в госкомпании перестала вдохновлять, Леонид не стал ждать, когда «всё само собой наладится». Чтобы двигаться вперёд, он решил стать DevOps-инженером и полностью погрузился в обучение. Учёба оказалась насыщенной: вебинары, практика, самостоятельные разборы тем. Пришлось выкладываться на 100%, но результат стоил того. «Домашние задания занимали практически все свободное время», — делится Леонид. Но такая усердная подготовка помогла: после собеседований и технического интервью он получил офер и теперь работает DevOps-инженером в компании, которая разрабатывает высокотехнологичное оборудование. Хотите так же? Приходите на курс Нетологии «DevOps-инженер». Используйте промокод DEVOPS10 и получите скидку 10 000 ₽ на обучение Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5x7gQ56

Код для облака: Освоение DevOps с помощью Python, Terraform и Kubernetes на AWS Как инженер DevOps, я обычно связан с конвейерами, автоматизацией и облачными сервисами. Однако мне всегда было интересно узнать о другой стороне технологического мира - разработке приложений. Поэтому я подумал, почему бы не разнообразить мир? Так я пришел к созданию финансового приложения на Python, дополненного REST API. В этом блоге я рассказываю о разработке и развертывании моего финансового приложения с нуля, от кода начального приложения до его развертывания на AWS с помощью Docker, Kubernetes (EKS), Terraform и Ansible. И знаете что? Я автоматизировал весь процесс - каждый его кусочек! https://medium.com/@sophnel/coding-to-cloud-mastering-devops-with-python-terraform-and-kubernetes-on-aws-6251a910511f 👉 @devops_star

Service-Hub JovianX Service Hub - это инструмент, обеспечивающий самообслуживание для внутренних заинтересованных сторон. Он предоставляет каталог инфраструктурных сервисов по требованию (например, базы данных, s3 buckets, выполнение рабочих процессов Airflow, сервисы с предварительно настроенными или предварительно загруженными наборами данных и т. д.) через простой пользовательский интерфейс самообслуживания и CLI. https://github.com/JovianX/Service-Hub 👉 @devops_star

Constellation Это первый конфиденциальный Kubernetes. Constellation защищает целые кластеры Kubernetes от (облачной) инфраструктуры с помощью конфиденциальных вычислений. Constellation - это движок Kubernetes, который призван обеспечить максимальную безопасность данных. Он оборачивает ваш кластер K8s в единый конфиденциальный контекст, защищенный от базовой облачной инфраструктуры. Все внутри всегда зашифровано, в том числе во время выполнения в памяти. Для этого Constellation использует конфиденциальные вычисления (см. технический обзор) и, в частности, конфиденциальные виртуальные машины. С точки зрения безопасности Constellation разработан таким образом, чтобы все данные всегда были зашифрованы и чтобы предотвратить доступ с уровня инфраструктуры (т. е. удалить инфраструктуру из TCB). Это включает доступ сотрудников ЦОД, привилегированных администраторов облака и злоумышленников, проникающих через инфраструктуру (например, злонамеренных соарендаторов, повышающих свои привилегии). С точки зрения DevOps, Constellation спроектирован так, как вы ожидаете от современного движка K8s. https://github.com/edgelesssys/constellation 👉 @devops_star

🔥 Как ускорить деплой в Kubernetes? Медленный деплой в Kubernetes — боль любого DevOps-инженера. Ожидание завершения обновления может растягиваться на минуты, а иногда и дольше. Давайте разберёмся, как ускорить этот процесс! 1️⃣ Используем kubectl rollout restart вместо полного пересоздания подов Вместо kubectl delete pod лучше использовать:

kubectl rollout restart deployment my-app

Так Kubernetes обновит поды поочередно, не убивая их сразу. 2️⃣ Минимизируем образ контейнера Чем меньше образ, тем быстрее он загружается. Используйте минимальные базовые образы, например: - alpine - distroless - scratch 3️⃣ Включаем сжатие в Docker При docker push можно сжать слои с помощью:

export DOCKER_BUILDKIT=1
docker build --compress -t my-app .

Это ускорит загрузку образа в реестр. 4️⃣ Используем kustomize или Helm для ускорения шаблонизации Kustomize позволяет изменять манифесты без дублирования, а Helm хранит шаблоны, минимизируя изменения в values.yaml. 5️⃣ Подключаем imagePullPolicy: IfNotPresent Если образ уже есть на ноде, Kubernetes не будет скачивать его заново. Включаем в деплойменте:

containers:
  - name: my-app
    image: my-registry/my-app:latest
    imagePullPolicy: IfNotPresent

Но будь осторожен — это работает только при версионных тегах! 6️⃣ Настраиваем readinessProbe Иногда поды стартуют, но ещё не готовы принимать трафик. Добавляем readinessProbe, чтобы сервис не направлял запросы на неподготовленные поды:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 2
  periodSeconds: 5

Это ускоряет переключение на новые версии. 7️⃣ Параллельный rollout (maxSurge/maxUnavailable) Позволяет обновлять несколько подов сразу:

strategy:
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 1
  type: RollingUpdate

Так Kubernetes создаст новые поды раньше, чем удалит старые. 8️⃣ Используем --cache-from для кэширования слоёв Docker Если билдите образ в CI/CD, кэшируйте слои:

docker build --cache-from=my-registry/my-app:latest -t my-app .

Это ускорит сборку. 9️⃣ Оптимизируем CI/CD пайплайн - Используем kaniko для сборки образов без Docker Daemon - Включаем параллельные шаги - Отключаем ненужные тесты в pre-prod стадиях 👉 @devops_star

Kyverno Управление нативными политиками Kubernetes Kyverno - это движок политик, разработанный для инженерных команд платформы Kubernetes. Он обеспечивает безопасность, автоматизацию, соответствие и управление с помощью политик как кода. Kyverno может проверять, изменять, генерировать и очищать конфигурации с помощью средств контроля допуска Kubernetes, фонового сканирования и сканирования репозитория исходного кода. Политики Kyverno могут управляться как ресурсы Kubernetes и не требуют изучения нового языка. Kyverno спроектирован таким образом, чтобы хорошо работать с уже используемыми вами инструментами, такими как kubectl, kustomize и Git. https://github.com/kyverno/kyverno 👉 @devops_star

Как разработчику «влиться» в тему DevOps Сегодня мы решили взглянуть на ситуацию с Java- и Python-разработчиком, который задумался о «погружении» в тему DevOps в тот момент, когда он начал все больше отдаляться от привычных инструментов в пользу работы с Oracle Weblogic и shell-скриптами. Он решил совместить свой опыт в области разработки с новым опытом в работе с процессами. Мы посмотрели на основные советы экспертов в области DevOps на Quora и дополнили рассказ примерами из опыта команды 1cloud. https://habr.com/ru/companies/1cloud/articles/277369/ 👉 @devops_star

TFTUI - The Terraform textual UI С помощью последней версии вы можете легко визуализировать полное дерево состояний, получая более глубокое представление о текущей конфигурации вашей инфраструктуры. Кроме того, возможность поиска по дереву и просмотра отдельных состояний ресурсов позволяет сосредоточиться на конкретных деталях для более эффективного анализа и управления. Также можно выбрать конкретные ресурсы и выполнить такие действия, как удаление. Наконец, теперь вы можете создавать и применять планы прямо из пользовательского интерфейса. Ключевые особенности Комплексное отображение всего дерева состояний Terraform Удобный просмотр и навигация по состоянию одного ресурса Поиск по дереву состояний и определениям ресурсов Создавайте планы, отображайте их в полном объеме и применяйте их непосредственно из интерфейса TUI Выбор одного/нескольких ресурсов Операции над ресурсами: восстановление, очистка, удаление, уничтожение Поддержка Terraform (например, terragrunt) https://github.com/idoavrah/terraform-tui 👉 @devops_star

🔥 Автоматическое удаление старых логов в Linux 🔥 Если у вас на сервере быстро разрастаются логи, можно настроить автоматическое удаление старых файлов с помощью простого скрипта на Bash. 📌 Скрипт для удаления логов старше 7 дней:

#!/bin/bash

LOG_DIR="/var/log"    # Директория с логами
DAYS=7                # Количество дней хранения

find "$LOG_DIR" -type f -name "*.log" -mtime +$DAYS -exec rm -f {} \;

echo "Старые логи удалены!"

🔹 Можно добавить этот скрипт в cron для автоматического запуска, например, каждый день в 3 часа ночи:

0 3 * * * /path/to/script.sh

✅ Преимущества: - Освобождает место на сервере 🧹 - Автоматизирует рутину ⏳ - Предотвращает переполнение диска 🛑 Используйте с умом и не забывайте проверять важные логи перед удалением! 👉 @devops_star

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_star

Faasd Это переосмысленный OpenFaaS, но без стоимости и сложности Kubernetes. Он работает на одном хосте с очень скромными требованиями, что делает его быстрым и простым в управлении. Под капотом он использует containerd и Container Networking Interface (CNI) вместе с теми же основными компонентами OpenFaaS из основного проекта. https://github.com/openfaas/faasd 👉 @devops_star

GMonit приглашает на технический вебинар 🗓 Когда: 13 марта, 17:00 (Мск) 🔗 Регистрация по ссылке О чем поговорим: 1️⃣ Как работают head-based и tail-based сэмплирование — плюсы и подводные камни. 2️⃣ Какие алгоритмы помогают снижать нагрузку на инфраструктуру. 3️⃣ Когда оптимизация данных экономит деньги, а когда — создает проблемы. В финале — разбор реальных сценариев и демонстрация сэмплирования в GMonit + QA-сессия. Если ваши системы генерируют тонны логов, метрик и трейсинга — этот вебинар поможет держать их под контролем. 😉

🔧 DevOps и искусственный интеллект: будущее уже здесь? В последние годы AI все больше проникает в сферу DevOps, автоматизируя рутинные процессы, улучшая мониторинг и повышая скорость разработки. Но насколько он реально полезен? 🔥 Где уже используют AI в DevOps? ✅ Автоматизация CI/CD – умные алгоритмы анализируют код и предсказывают потенциальные ошибки. ✅ Мониторинг и алерты – ML-модели анализируют логи, предсказывают сбои и уменьшают количество фальшивых тревог. ✅ Оптимизация инфраструктуры – AI помогает уменьшить затраты, предсказывая пиковые нагрузки и распределяя ресурсы. ✅ Чат-боты для SRE – автоматический разбор инцидентов и предложение решений. 🚀 Будущее DevOps с AI В ближайшие годы AI в DevOps станет не просто помощником, а полноценным участником команды. Автоматическая коррекция инфраструктуры, автогенерация конфигураций и даже self-healing системы – всё это уже не фантастика. 👉 @devops_star

Притормози! Глубокое погружение в ограничение скорости В этом посте мы обсудим важность и реализацию механизмов ограничения скорости для повышения надежности API. Что такое ограничение скорости? Это механизм контроля, определяющий, как часто пользователь может обращаться к вашему API в течение определенного времени. Итак, почему вас должно волновать ограничение скорости? Рассмотрим ситуацию, когда к вашему API поступает огромное количество запросов за короткий промежуток времени. Это может быть связано с резким увеличением трафика пользователей, сбоем, вызывающим повторные запросы, или даже попыткой перегрузить вашу систему с помощью DDOS-атаки. Без ограничения скорости ваша система может быть перегружена, что приведет к медленным ответам или, что еще хуже, к полному отказу в обслуживании. Но преимущества ограничения скорости выходят за рамки просто защиты вашей системы. Это также инструмент для управления использованием сервиса. Оно помогает применять политики использования API, контролировать квоты API и даже предлагать клиентам многоуровневые планы использования. Проще говоря, ограничение скорости - это ключевой игрок в эффективном управлении API. https://www.codereliant.io/rate-limiting-deep-dive/ 👉 @devops_star

Пробки в облаке: Перегрузки снижают надежность ваших приложений? Представьте себе оживленную систему автомагистралей - сложную сеть дорог, мостов, туннелей и перекрестков, каждая из которых рассчитана на определенный объем движения. А теперь подумайте о событиях, которые приводят к пробкам: авариях, дорожных работах или внезапном наплыве автомобилей. Эти происшествия вызывают заторы на дорогах, и часто затор на одном участке шоссе вызывает затор на другом. Например, затор на мосту может привести к затору на дороге, ведущей к нему. Заторы создают множество проблем, начиная от задержек и увеличения времени в пути и заканчивая раздражением водителей из-за потерянного времени и слишком большого количества сожженного топлива. Такие сбои в работе наносят ущерб не только водителям, но и всей экономике. Задерживаются товары, нарушается предоставление услуг, поскольку сотрудники приходят на работу с опозданием (и в раздражении). https://blog.fluxninja.com/blog/traffic-jams-in-the-cloud-unveiling-the-true-enemy-of-reliability 👉 @devops_star