DevOps

⚡️ Cloudflare выпустила первый публичный релиз Pingora v0.1.0

5 апреля 2024 года Cloudflare представила первый публичный релиз открытого проекта Pingora v0.1.0 (уже v0.1.1). Это асинхронный многопоточный фреймворк на Rust, который помогает создавать прокси-сервисы HTTP. Проект используется для создания сервисов, обеспечивающих значительную часть трафика в Cloudflare (вместо применения Nginx).

Pingora предоставляет библиотеки и API для создания сервисов поверх HTTP/1 и HTTP/2, TLS или просто TCP/UDP. В качестве прокси-сервера он поддерживает сквозное проксирование HTTP/1 и HTTP/2, gRPC и WebSocket. (Поддержка HTTP/3 — в планах). Pingora также включает в себя настраиваемые стратегии балансировки нагрузки и аварийного переключения. Чтобы соответствовать требованиям и безопасности он поддерживает как широко используемые библиотеки OpenSSL, так и BoringSSL, которые соответствуют требованиям FIPS (федеральных стандартов обработки информации США) и пост-квантового шифрования.

🖥 Исходный код Pingora опубликован на GitHub под лицензией Apache 2.0.
📎 Подробнее

@DevOPSitsec

📌Установка GitLab с использованием Docker Compose

Эта статья предназначена для тех, кто искал подробное и понятное руководство о том, как установить GitLab с использованием Docker Compose.
В этом руководстве мы будем рассматривать тот случай, когда у вас уже есть сервер с установленной на нем операционной системой Ubuntu Server 22.04 LTS.
Также на сервере должен быть установлен Docker Engine и Docker Compose.

📎 Туториал
🖥 Примеры кода из туториала

@DevOPSitsec

💻 Миграция проекта в Kubernetes: из каких этапов состоит и сколько времени занимает

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

Вот 11 этапов миграции:
⏩Аудит и документирование текущей серверной инфраструктуры проекта. Определяем, какие приложения и на каких серверах запускаются, какой стек технологий используется.

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

⏩Подготовка приложения к запуску в кластере Kubernetes.

⏩Контейнеризация каждого приложения. Создаём Docker-контейнеры.

⏩Проектирование и внедрение системы сбора логов и мониторинга приложений и кластера.

⏩Автоматизация CI/CD. Она необходима, чтобы разработчики могли писать код приложений, который, по мере изменений, будет оперативно доставляться в кластер.

⏩Подготовка сред и миграции, создание манифестов Kubernetes. На данном этапе выполняется настройка кластера Kubernetes, настройка необходимых для работы приложения СУБД, ПО для очередей и другого ПО.

⏩Тестирование под нагрузкой, тестирование в случае сбоев. Выдерживает ли текущая инфраструктура необходимую нагрузку/количество обращений?

⏩Миграция приложений и запуск. Выполняется актуализация сервисов путем запуска деплоев для последних версий сервисов, актуализируются данные в СУБД и файлы во внешних хранилищах.

⏩Финальное тестирование после запуска. После запуска приложения на основном домене, тестировщики проводят полноценное тестирование его функционала с целью поиска ошибок и дальнейшего их устранения.

⏩Мониторинг и поддержка кластера Kubernetes. Мониторинг — регулярная проверка работоспособности всех компонентов кластера Kubernetes.

📎 Статья

@DevOPSitsec

🔜 Утилита 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