DevOps

🔜Утилита Rsync 3.3.0 для синхронизации данных и не только ⏩Состоялся релиз утилиты для синхронизации файлов и резервного копирования Rsync 3.3.0, позволяющей минимизировать трафик за счёт инкрементального копирования изменений. В качестве транспорта могут быть использованы ssh, rsh или собственный протокол rsync. Поддерживается организация работы анонимных rsync-серверов, оптимально подходящих для обеспечения синхронизации зеркал. Исходный код проекта распространяется под лицензией GPLv3. ⏩Значительное изменение номера версии не связано с функциональными изменениями в нынешнем выпуске, а является отложенной реакцией на изменения в прошлой версии 3.2.7. ⏩В Rsync 3.3.0 в основном выполнено исправление ошибок. Репозиторий проекта на GitHub перенесён из аккуаунта сопровождающего WayneD в отдельную организацию RsyncProject. Также сообщается о формировании новой команды сопровождающих rsync из-за нехватки времени у нынешнего сопровождающего. ⏩Примечательно, что в команду проекта вернулись Эндрю Триджелл (Andrew Tridgell), основатель проектов samba и rsync, а также Пол Маккеррас (Paul Mackerras), один из первых разработчиков rsync, принимавших в 1996 году участие в создании протокола rsync. 📎Ещё некоторые подробности @DevOPSitsec

📌Релиз инструментария Netplan 1.0 5 апреля 2024 года состоялся релиз первой мажорной версии инструментария для конфигурации сети Netplan, развивающего формат для хранения настроек сетевых интерфейсов и связанные с ним утилиты для управления сетевыми конфигурациями. Решение Netplan обеспечивает хранение сетевых параметров в формате YAML и предоставляет бэкенды, абстрагирующие доступ к конфигурации для NetworkManager и systemd-networkd. 🖥 Исходный код проекта написан на языках программирования Python и C и опубликован на GitHub под лицензией GPLv3. 📎Подробнее @DevOPSitsec

💻Kubernetes антипаттерны. Вредные советы для построения твоего мира микросервисов ⏩Держите годный контент, здесь Алексей и Виталий рассуждают о том, как использовать Kubernetes в проде. Поднимают тему антипаттернов и плохих практик, дают полезные рекомендации. 📎Кликабельный план митапа 📎YouTube @DevOPSitsec

🔥Технический стек Netflix @DevOPSitsec

🔥Amazon представила AWS Deadline Cloud для быстрой настройки облачной высокопроизводительной платформы для рендеринга ⏩Amazon представила сервис AWS Deadline Cloud для настройки за несколько минут облачной высокопроизводительной платформы для рендеринга контента на базе Amazon Elastic Compute Cloud (Amazon EC2). ⏩В Amazon пояснили, что графический рендеринг требует значительных вычислительных мощностей, особенно для создания 3D-графики и визуальных эффектов (VFX) с разрешением до 16K для фильмов и телепередач. Это ограничивает количество проектов рендеринга, которые клиенты могут выполнять одновременно. ⏩Чтобы удовлетворить растущий спрос на рендеринг контента с высоким разрешением, многие корпоративные клиенты AWS создавали так называемые «рендер-фермы», которые объединяют мощность сотен или тысяч вычислительных узлов для обработки своих заданий рендеринга. На создание и развёртывание таких «рендер-ферм» ранее уходили недели или даже месяцы, так как этот процесс требовал тщательного планирования и предварительных обязательств по закупке оборудования. ⏩В рамках уменьшения затрат клиентов и минимизации времени на системы управления для облачных «рендер-ферм» в Amazon открыли для всех заказчиков сервис AWS Deadline Cloud со встроенной простой системой управления, которая позволяет производителям контента легко настроить «рендер-ферму» за считанные минуты, масштабировать её для параллельного запуска большего количества проектов и платить только за те ресурсы, которые они используют. ⏩Фактически AWS Deadline Cloud предоставляет веб-портал, позволяющий создавать фермы рендеринга и управлять ими, просматривать текущие рендеринги, просматривать и анализировать журналы рендеринга, а также легко отслеживать все затраты на производство контента. 📎Подробнее @DevOPSitsec

🤓🖥Настраиваем CI/CD с GitHub Actions и werf: инструкция для новичков ⏩В этой статье рассматривается, как настроить пайплайн CI/CD в GitHub: подготовка репозитория, заливание приложения, создание файлов конфигурации GitHub Actions. Деплой проводится с помощью Open Source CLI-утилиты werf. Она помогает организовать полный цикл доставки приложений в Kubernetes и рассматривает Git как единый источник истины для состояния развёрнутого приложения. Статья рассчитана на тех, кто только начинает свой путь в мире облаков и кластеризации, рекомендую) 📎Статья @DevOPSitsec

💻Запуск проекта в Kubernetes за 60 минут: инструменты, GitLab, Terraform ⏩В этой статье детально рассматривается пример CI/CD-пайплайна, который собирает разбитое на 2 микросервиса CRUD-приложение, пушится в платформенный реджистри и деплоится в Kubernetes. ⏩Подробно рассматриваются все шаги поднятия: создание кластера и базы данных, настройка абстракций Kubernetes вроде Service, Ingress, Deployment и т. д. и установка платформенных аддонов в кластер. А также поднятие инфраструктуры стенда при помощи подхода Infrastructure-as-a-code. 🖥 Все файлы Terraform и Kubernetes, код приложения и сокращённая пошаговая инструкция доступны в репозитории Полезная статья, рекомендую) 📎Статья @DevOPSitsec

🖥Как использовать Node.js с Docker ⏩Как мы знаем Node.js позволяет создавать быстрые и масштабируемые веб-приложения, используя JavaScript и на сервере, и на клиенте. Ну и для того, что приложение предсказуемо работало и там, и там, мы используем Docker, конечно же. ⏩Эта статья поможет структурировать знания о сборке контейнеров с помощью Docker, поможет освежить азы основы с образами и не только. Уверен, будет полезно, держите 📎Статья @DevOPSitsec

📌Лучшие практики по безопасности при использовании Docker Держите рекомендации по безопасной работе с образами и контейнерами ⏩PDF @DevOPSitsec

🖥5 советов, как ускорить сборку образа Docker ⏩Совет 1. Можно ли избежать создания образов? Использование Docker не обязательно должно быть принципом «все или ничего». Вы можете использовать Docker для развертывания и создания образов для продакшн, но вам не обязательно использовать его в разработке. ⏩Совет 2. Структурируйте инструкции Dockerfile как перевернутую пирамиду. Каждая инструкция в вашем Dockerfile приводит к созданию слоя изображения. Docker использует слои для повторного использования работы. Слои кэшируются и их не нужно пересобирать, если: — Все предыдущие слои не изменяются. — В случае инструкции COPY: файлы/папки не изменяются. — В случае всех остальных инструкций: текст команды не изменяется. ⏩Совет 3. Копируйте только те файлы, которые необходимы для следующего шага. Представьте, что у нас есть следующий фрагмент Dockerfile: RUN mkdir /code COPY code code/ RUN pip install code/requirements.txt Каждый раз, когда что-либо в каталоге кода меняется, вторую строку необходимо запускать заново, а также каждую последующую строку. Вот как мы могли бы избежать повторного запуска этапа установки при каждом изменении кода: RUN mkdir /code COPY code/requirements.txt code/ RUN pip install code/requirements.txt COPY code /code ⏩Совет 4. Скачивайте меньше файлов. Во-первых, проверьте, не загружаете ли вы зависимости разработки, которые вообще не нужны вашему образу. Ещё нужно помнить про поведение менеджера пакетов на уровне ОС. Например, `apt`который используется в Ubuntu и Debian, по умолчанию устанавливает «рекомендуемые» пакеты. Вы можете избежать этого, добавив к apt-get install флаг --no-install-recommends ⏩Совет 5. Используйте BuildKit с новой функцией монтирования кэша. BuildKit — это новый механизм сборки образов, который можно использовать вместо стандартного Docker. С ним вы получаете больше параллелизма и эффективности кэширования, плюс новые интересные функции 📎Читать подробнее @DevOPSitsec

⚡️ИИ-самоучитель Learn Anything - новый идеальный инструмент для освоения любых навыков. Нейронная сеть преобразует абстрактные желания в структурированный учебный план, предоставляя статьи, руководства и видеоуроки. ▪Github @DevOPSitsec

🖥Как работает сеть в контейнерах: Docker Bridge с нуля Временами работа с контейнерами может казаться чем-то непостижимым и удивительным. В хорошем смысле для тех, кто понимает как устроено внутри, и в ужасающем - для тех, кто этого не понимает. Если вы уже Docker-гуру, то знаете, что контейнеры - это просто изолированные и ограниченные процессы Linux, что образы на самом деле не нужны для запуска контейнеров, и что, наоборот, для создания образа нам, возможно, потребуется запускать контейнеры. Также неплохо бы разобраться с работой сети в контейнерах. Для этого в статье освещаются такие вопросы: ⏩Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды? ⏩Как превратить контейнеры в дружелюбных соседей и научить общаться друг с другом? ⏩Как выйти во внешний мир (например, в Интернет) изнутри контейнера? ⏩Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира? ⏩Как реализовать публикацию портов, подобную Docker? Параллельно в статье строится контейнерная сеть с одним хостом с нуля при помощи стандартных инструментов Linux. В общем, отличная статья, рекомендую) 📎Статья @DevOPSitsec