📌Построение масштабируемой инфраструктуры: стратегии и лучшие практики
1. Понятие масштабируемой инфраструктуры: Обсуждается способность инфраструктуры гибко и эффективно увеличиваться или уменьшаться в зависимости от потребностей, что позволяет современным компаниям быстро адаптироваться к изменяющимся нагрузкам и требованиям пользователей без потери производительности и сдерживания затрат.
2. Немасштабируемые подходы: Рассматриваются традиционные методы управления инфраструктурой, которые могут быть приемлемы для небольших команд или проектов, но становятся неэффективными по мере роста и усложнения системы.
3. Терминалы и изолированные среды: Анализируется проблема консистентности при развертывании инфраструктуры напрямую с терминалов разработчиков, что может приводить к ошибкам и несогласованности в больших командах.
4. Способы создания масштабируемой инфраструктуры: Предлагаются стратегии и инструменты для обеспечения масштабируемости, включая автоматизацию, использование инфраструктуры как кода (IaC) и внедрение CI/CD процессов.
5. Примеры масштабируемой инфраструктуры: Приводятся реальные примеры и сценарии, демонстрирующие успешное внедрение масштабируемых решений в различных организациях.
6. Лучшие практики построения масштабируемой инфраструктуры: Рекомендации по внедрению передовых методов, таких как модульность, автоматическое тестирование, мониторинг и обеспечение безопасности.
7. Управление инфраструктурой в масштабе с помощью Spacelift: Описание возможностей платформы Spacelift для эффективного управления масштабируемой инфраструктурой, включая автоматизацию рабочих процессов, обеспечение соответствия политик и улучшение сотрудничества между командами.
https://spacelift.io/blog/scalable-infrastructure
#devops #девопс
Подпишись 👉@i_DevOps
1. Понятие масштабируемой инфраструктуры: Обсуждается способность инфраструктуры гибко и эффективно увеличиваться или уменьшаться в зависимости от потребностей, что позволяет современным компаниям быстро адаптироваться к изменяющимся нагрузкам и требованиям пользователей без потери производительности и сдерживания затрат.
2. Немасштабируемые подходы: Рассматриваются традиционные методы управления инфраструктурой, которые могут быть приемлемы для небольших команд или проектов, но становятся неэффективными по мере роста и усложнения системы.
3. Терминалы и изолированные среды: Анализируется проблема консистентности при развертывании инфраструктуры напрямую с терминалов разработчиков, что может приводить к ошибкам и несогласованности в больших командах.
4. Способы создания масштабируемой инфраструктуры: Предлагаются стратегии и инструменты для обеспечения масштабируемости, включая автоматизацию, использование инфраструктуры как кода (IaC) и внедрение CI/CD процессов.
5. Примеры масштабируемой инфраструктуры: Приводятся реальные примеры и сценарии, демонстрирующие успешное внедрение масштабируемых решений в различных организациях.
6. Лучшие практики построения масштабируемой инфраструктуры: Рекомендации по внедрению передовых методов, таких как модульность, автоматическое тестирование, мониторинг и обеспечение безопасности.
7. Управление инфраструктурой в масштабе с помощью Spacelift: Описание возможностей платформы Spacelift для эффективного управления масштабируемой инфраструктурой, включая автоматизацию рабочих процессов, обеспечение соответствия политик и улучшение сотрудничества между командами.
https://spacelift.io/blog/scalable-infrastructure
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Как я создал полностью автоматизированное онлайн радио с AI ведущими и музыкой
Однажды мне захотелось изучить Kubernetes и мобильную разработку, но не знал, с чего начать. В то же время меня сильно тревожило отсутствие в интернете новостей без политической повестки и негативного окраса. Отовсюду лился поток манипулятивной информации, и я мечтал о фильтре, который бы отсеивал весь этот информационный шлак.
Это моя небольшая история, как я за месяц написал собственное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI
https://habr.com/ru/articles/884902/
#devops #девопс
Подпишись 👉@i_DevOps
Однажды мне захотелось изучить Kubernetes и мобильную разработку, но не знал, с чего начать. В то же время меня сильно тревожило отсутствие в интернете новостей без политической повестки и негативного окраса. Отовсюду лился поток манипулятивной информации, и я мечтал о фильтре, который бы отсеивал весь этот информационный шлак.
Это моя небольшая история, как я за месяц написал собственное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI
https://habr.com/ru/articles/884902/
#devops #девопс
Подпишись 👉@i_DevOps
👍8🔥4
Media is too big
VIEW IN TELEGRAM
Better Commits — это удобный инструмент для создания понятных и структурированных коммитов в Git. Он помогает следовать лучшим практикам написания сообщений коммитов, автоматически предлагая удобные шаблоны и категории изменений.
📌 Основные возможности:
- Интерактивное руководство по созданию коммитов
- Поддержка различных типов изменений (feat, fix, chore и др.)
- Чистый и удобный интерфейс для быстрого ввода сообщений
- Соответствие рекомендациям Conventional Commits
https://github.com/Everduin94/better-commits
#devops #девопс
Подпишись 👉@i_DevOps
📌 Основные возможности:
- Интерактивное руководство по созданию коммитов
- Поддержка различных типов изменений (feat, fix, chore и др.)
- Чистый и удобный интерфейс для быстрого ввода сообщений
- Соответствие рекомендациям Conventional Commits
https://github.com/Everduin94/better-commits
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Почему observability — это не только Grafana и Prometheus
Вы видите красивые графики в Grafana, алерты настроены, метрики собираются — значит, все под контролем? На самом деле, нет. Когда в продакшене что-то пойдет не так, Prometheus покажет скачок latency, но не объяснит, почему это произошло. Логи могут не содержать нужных данных. Трейсов нет. Итог — часы расследования, хаотичные гипотезы, поиски иголки в стоге сена.
Observability — одно из тех модных слов, которые часто понимают неправильно. Для многих оно сводится к связке Grafana + Prometheus, не более. Однако в реальных системах наблюдаемость (observaбыстроbility) — это больше, чем просто красивые дашборды с метриками. В этой статье разберемся, почему классический стек не покрывает все задачи, какие альтернативы есть на рынке и как построить современный observability-стек.
https://habr.com/ru/companies/selectel/articles/885890/
#devops #девопс
Подпишись 👉@i_DevOps
Вы видите красивые графики в Grafana, алерты настроены, метрики собираются — значит, все под контролем? На самом деле, нет. Когда в продакшене что-то пойдет не так, Prometheus покажет скачок latency, но не объяснит, почему это произошло. Логи могут не содержать нужных данных. Трейсов нет. Итог — часы расследования, хаотичные гипотезы, поиски иголки в стоге сена.
Observability — одно из тех модных слов, которые часто понимают неправильно. Для многих оно сводится к связке Grafana + Prometheus, не более. Однако в реальных системах наблюдаемость (observaбыстроbility) — это больше, чем просто красивые дашборды с метриками. В этой статье разберемся, почему классический стек не покрывает все задачи, какие альтернативы есть на рынке и как построить современный observability-стек.
https://habr.com/ru/companies/selectel/articles/885890/
#devops #девопс
Подпишись 👉@i_DevOps
👍2❤1
Как сделать своё хранилище образов контейнеров
В статье описаны шаги для самостоятельного хостинга container registry. Узнайте, как управлять своими образами, оптимизировать рабочие процессы и защищать свои приложения от внешних рисков.
https://habr.com/ru/companies/flant/articles/882808/
original https://packagemain.tech/p/self-hosting-a-container-registry
#devops #девопс
Подпишись 👉@i_DevOps
В статье описаны шаги для самостоятельного хостинга container registry. Узнайте, как управлять своими образами, оптимизировать рабочие процессы и защищать свои приложения от внешних рисков.
https://habr.com/ru/companies/flant/articles/882808/
original https://packagemain.tech/p/self-hosting-a-container-registry
#devops #девопс
Подпишись 👉@i_DevOps
👍3
• infosec - это один из самых ламповых каналов по информационной безопасности, где говорят об истории ИТ, публикуют актуальные новости и пишут технический материал на разные темы:
- Что из себя представляет официально взломанный iPhone от Apple?
- К чему могла привести опечатка в инфраструктуре платёжной системы MasterCard?
- Авторский материал для ИБ специалистов с закрытого хакерского форума XSS;
- Бесплатный бот, который проверит файлы на предмет угроз более чем 70 антивирусами одновременно.
• А еще у нас часто проходят розыгрыши самых актуальных и новых книг для ИБ специалистов. Так что присоединяйся, у нас интересно!
- Что из себя представляет официально взломанный iPhone от Apple?
- К чему могла привести опечатка в инфраструктуре платёжной системы MasterCard?
- Авторский материал для ИБ специалистов с закрытого хакерского форума XSS;
- Бесплатный бот, который проверит файлы на предмет угроз более чем 70 антивирусами одновременно.
• А еще у нас часто проходят розыгрыши самых актуальных и новых книг для ИБ специалистов. Так что присоединяйся, у нас интересно!
👍1🔥1
Конфигуратор. Связываем хосты в единую инфраструктуру, используя функциональность Ansible inventory
В этой статье пойдет речь о том, как мы конфигурируем установку отдельных развертываемых хостов и их сервисов, а также как связываются сервисы между собой.
https://habr.com/ru/companies/pt/articles/884526/
#devops #девопс
Подпишись 👉@i_DevOps
В этой статье пойдет речь о том, как мы конфигурируем установку отдельных развертываемых хостов и их сервисов, а также как связываются сервисы между собой.
https://habr.com/ru/companies/pt/articles/884526/
#devops #девопс
Подпишись 👉@i_DevOps
👍3
🚀 CI/CD: Как не устроить себе ад 🚀
Автоматизация деплоя – это must-have. Но сколько раз ты видел, как CI/CD ломает прод? Разберём ключевые моменты, чтобы не наступать на грабли.
✅ Грамотный пайплайн
1️⃣ Lint & Code Style – форматируй код перед билдами (Prettier, Black, ESLint).
2️⃣ Тесты – без них CI/CD превращается в русскую рулетку. Покрываем юнит и интеграцией.
3️⃣ Security Checks – SAST, DAST, секреты в коде (Trivy, Snyk, GitLeaks).
4️⃣ Билд образов – минимизируем размер, убираем уязвимости.
5️⃣ Деплой – делаем blue-green или canary, чтобы не убить прод сразу.
✅ Выбор инструментов
- GitHub Actions / GitLab CI – удобно, если уже сидишь на этих платформах.
- ArgoCD / Flux – GitOps для Kubernetes.
- Jenkins – старый, но всё ещё мощный, если его правильно готовить.
- Tekton – если хочешь true cloud-native CI/CD.
✅ Ошибки, которые убьют прод
⚠️ Деплой без тестов – поздравляю, у тебя теперь ручное QA на проде.
⚠️ Хранение секретов в репо – топ-1 причина утечек. Vault, SealedSecrets, Doppler.
⚠️ Отсутствие Rollback – если нет возможности быстро откатиться, ты в опасности.
🔥 Вывод: CI/CD – это не просто кнопка "деплой". Это стратегия, которую надо строить с умом. Инвестируй в тесты, автоматизацию и безопасность, и будет тебе стабильность.
#devops #девопс
Подпишись 👉@i_DevOps
Автоматизация деплоя – это must-have. Но сколько раз ты видел, как CI/CD ломает прод? Разберём ключевые моменты, чтобы не наступать на грабли.
✅ Грамотный пайплайн
1️⃣ Lint & Code Style – форматируй код перед билдами (Prettier, Black, ESLint).
2️⃣ Тесты – без них CI/CD превращается в русскую рулетку. Покрываем юнит и интеграцией.
3️⃣ Security Checks – SAST, DAST, секреты в коде (Trivy, Snyk, GitLeaks).
4️⃣ Билд образов – минимизируем размер, убираем уязвимости.
5️⃣ Деплой – делаем blue-green или canary, чтобы не убить прод сразу.
✅ Выбор инструментов
- GitHub Actions / GitLab CI – удобно, если уже сидишь на этих платформах.
- ArgoCD / Flux – GitOps для Kubernetes.
- Jenkins – старый, но всё ещё мощный, если его правильно готовить.
- Tekton – если хочешь true cloud-native CI/CD.
✅ Ошибки, которые убьют прод
⚠️ Деплой без тестов – поздравляю, у тебя теперь ручное QA на проде.
⚠️ Хранение секретов в репо – топ-1 причина утечек. Vault, SealedSecrets, Doppler.
⚠️ Отсутствие Rollback – если нет возможности быстро откатиться, ты в опасности.
🔥 Вывод: CI/CD – это не просто кнопка "деплой". Это стратегия, которую надо строить с умом. Инвестируй в тесты, автоматизацию и безопасность, и будет тебе стабильность.
#devops #девопс
Подпишись 👉@i_DevOps
⚡3❤2👍1
#вакансия #удалённо #parttime #преподаватель #DevOps #Kubernetes #GitOps
Компания: образовательная платформа OTUS:
Вакансия: преподаватель онлайн-курсов
- Инфраструктурная платформа на основе Kubernetes
- GitOps
Преподавательский опыт не обязателен — у нас есть вводный курс о преподавании и пробные уроки с методистом.
Требуется практический опыт и знания по тематике курса, подробнее в ЛС.
Обязанности:
- Подготовиться к занятиям и провести их
- Формат занятий: онлайн, важно уделять внимание практике. Здесь вы сможете развивать навыки публичных выступлений, работы с аудиторией и подачи обратной связи
- За доплату возможна проверка домашних заданий и проектов
Условия:
✅ Занятия по будням с 20:00 до 21:30, можно оставлять пожелания по расписанию
✅ Оплата: от 3000 до 6000 руб. за вебинар (полтора часа) и 300-400 рублей за проверку 1 домашнего задания, 1000 руб. за проверку 1 проекта
✅ Бонусы: доступ к курсам OTUS, нетворкинг, развитие личного бренда, наши воркшопы и конференции
Обсудить подробнее: @HR_Nikita 📩
Компания: образовательная платформа OTUS:
Вакансия: преподаватель онлайн-курсов
- Инфраструктурная платформа на основе Kubernetes
- GitOps
Преподавательский опыт не обязателен — у нас есть вводный курс о преподавании и пробные уроки с методистом.
Требуется практический опыт и знания по тематике курса, подробнее в ЛС.
Обязанности:
- Подготовиться к занятиям и провести их
- Формат занятий: онлайн, важно уделять внимание практике. Здесь вы сможете развивать навыки публичных выступлений, работы с аудиторией и подачи обратной связи
- За доплату возможна проверка домашних заданий и проектов
Условия:
✅ Занятия по будням с 20:00 до 21:30, можно оставлять пожелания по расписанию
✅ Оплата: от 3000 до 6000 руб. за вебинар (полтора часа) и 300-400 рублей за проверку 1 домашнего задания, 1000 руб. за проверку 1 проекта
✅ Бонусы: доступ к курсам OTUS, нетворкинг, развитие личного бренда, наши воркшопы и конференции
Обсудить подробнее: @HR_Nikita 📩
👍2🔥2
Garnet — это удалённое кэш-хранилище от Microsoft Research, обеспечивающее высокую производительность (пропускную способность и задержку), масштабируемость, хранение, восстановление, шардирование кластера, миграцию ключей и функции репликации. Garnet может работать с существующими клиентами Redis.
Основные возможности:
- Высокая производительность: миллионы операций в секунду с минимальной задержкой.
- Масштабируемость: поддержка горизонтального масштабирования.
- Оптимизация работы с памятью: эффективное использование DRAM и SSD.
Этот проект может стать серьезным конкурентом Redis и Memcached в сфере облачных сервисов.
https://github.com/microsoft/garnet
#devops #девопс
Подпишись 👉@i_DevOps
Основные возможности:
- Высокая производительность: миллионы операций в секунду с минимальной задержкой.
- Масштабируемость: поддержка горизонтального масштабирования.
- Оптимизация работы с памятью: эффективное использование DRAM и SSD.
Этот проект может стать серьезным конкурентом Redis и Memcached в сфере облачных сервисов.
https://github.com/microsoft/garnet
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤1
Kubernetes CPU Limits и их влияние на Go-приложения
Интересный разбор влияния
Ключевые моменты:
-
- Ограничение процессорного времени может вызвать неожиданные задержки в планировании задач, что особенно критично для высоконагруженных сервисов.
- Использование
https://www.ardanlabs.com/blog/2024/02/kubernetes-cpu-limits-go.html
#devops #девопс
Подпишись 👉@i_DevOps
Интересный разбор влияния
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
👍2
👍3
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 и Dockerfile.
Для многих это стандарт, отклонения от которого вызывают недоумение и вопросы. Но даже у всего хорошего есть альтернативы. Одна из них — Nix. Насколько она сопоставима по удобству и скорости с Docker?
Меня зовут Борис Табачников, я разработчик отдела RnD в СберТехе. Кратко расскажу, что такое Nix в целом, зачем вам его использовать и подробно сравню скорость работы Nix и Docker.
Статья будет полезна DevOps‑инженерам и разработчикам, интересующимся контейнеризацией. И особенно — тем, кто ищет альтернативы для Docker и кого заинтересовал Nix, но при этом сферы его использования и применимость для сборки образов недостаточно понятна.
https://habr.com/ru/companies/sberbank/articles/887722/
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Документация как код: принципы, рабочий процесс и вызовы
В современном мире разработки программного обеспечения концепция «Документация как код» (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
В современном мире разработки программного обеспечения концепция «Документация как код» (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
👍2
Выходим за рамки: создание оператора для наблюдения за внешними ресурсами в Kubernetes
В этой статье мы рассмотрим, как создать оператор, который выходит за рамки кластера и взаимодействует с внешним миром. На примере мониторинга HTTP-серверов вы узнаете, как использовать kubebuilder для разработки custom-операторов и как организовать работу с внешними ресурсами. Статья будет полезна разработчикам, желающим расширить возможности своих Kubernetes-кластеров.
https://habr.com/ru/companies/flant/articles/884566/
#devops #девопс
Подпишись 👉@i_DevOps
В этой статье мы рассмотрим, как создать оператор, который выходит за рамки кластера и взаимодействует с внешним миром. На примере мониторинга HTTP-серверов вы узнаете, как использовать kubebuilder для разработки custom-операторов и как организовать работу с внешними ресурсами. Статья будет полезна разработчикам, желающим расширить возможности своих Kubernetes-кластеров.
https://habr.com/ru/companies/flant/articles/884566/
#devops #девопс
Подпишись 👉@i_DevOps
👍1