Как именно Netflix реализует код до перехода к облаку? Частично мы рассказывали эту историю раньше, но теперь пришло время добавить к ней больше деталей.
В этом посте мы опишем инструменты и методы, которые позволили нам перейти от исходного кода к развернутому сервису, позволяющему более чем 75 миллионам подписчиков со всего мира наслаждаться фильмами и сериалами.
Схема выше является отсылкой к предыдущему посту.
представляющий спинакер , наша глобальная комплексная платформа данных.
Но прежде чем строка кода попадет в Спинакер, ей нужно пройти несколько этапов:
- Код должен быть написан и протестирован локально с помощью плагинов.
- Изменения переносятся в центральный репозиторий git;
- Дженкинс управляет Nebula, которая создает, тестирует и подготавливает приложения для облака;
- Сборки «запекаются» в Amazon Machine Image;
- Спинакер помогает разблокировать и активировать модифицированный код.
Организационная культура, облака и микросервисы
Прежде чем мы углубимся в процесс кодирования Netflix, нам необходимо обрисовать ключевые факторы, влияющие на наши решения: нашу организационную культуру, облако и микросервисы.Культура Netflix расширяет возможности инженеров использовать любые, по их мнению, подходящие инструменты для решения поставленных задач.
По нашему опыту, чтобы решение получило широкое признание, оно должно быть обоснованным, полезным и снижать когнитивную нагрузку на большинство инженеров Netflix. Команды свободны выбирать, как решать проблемы, но они платят за это дополнительной ответственностью за поддержку этих решений.
Предложения центральных команд Netflix начинают рассматриваться как часть асфальтированной дороги.
Сейчас именно это находится в центре нашего внимания и поддерживается нашими специалистами.
Кроме того, в 2008 году Netflix начал движение потоковая передача данных в AWS и перевести монолитный центр обработки данных на базе Java-приложений на облачные микросервисы Java. Их архитектура позволяет командам Netflix быть свободно связанными друг с другом, что позволяет им создавать и продвигать решения проблем в своем собственном темпе.
Разработка
Думаю, никого не удивит тот факт, что прежде чем развернуть сервис или приложение, его необходимо сначала разработать.Мы создали Nebula — набор плагинов системы сборки для Градл для решения основных проблем развития.
Gradle — первоклассный инструмент для разработки, тестирования и подготовки Java-приложений к развертыванию.
потому что он покрывает основные потребности наш код. Он был выбран потому, что было легко писать тестируемые плагины, минимизируя полученный файл.
Таким образом, Nebula с помощью Gradle с его набором доступных плагинов для управления связями, релизами, развертываниями и многими другими инструментами обеспечивает надежную автоматизированную функциональность.
Простое Java-приложение.
файл build.gradle Приведенный выше файл build.gradle является примером сборки обычного Java-приложения на Netflix. В теле этого проекта мы видим команды Java и четыре плагина Gradle, три из которых являются либо частью Nebula, либо внутренними настройками, связанными с его плагинами.
Плагин «nebula» — это часть Gradle, которая обеспечивает соединения и настройки, необходимые для интеграции с нашей инфраструктурой.
Плагин «nebula.dependent-lock» позволяет проекту создавать файл a.lock, который создает варьируемые и повторяемые зависимости.
Плагин netflix.ospackage-tomcat и блок ospackage будут обсуждаться ниже.
С помощью Nebula мы пытаемся предоставить многоразовые и совместимые функции сборки с целью сокращения количества шаблонов в каждом файле приложения.
В следующем посте мы более подробно обсудим Nebula и ее различные функции с открытым исходным кодом.
А пока вы можете пойти в Сайт Небулы .
Интеграция
После локального тестирования кода с помощью Nebula мы можем перейти к интеграции и развертыванию.Для начала нам нужно запустить обновленный исходный код в репозитории Git, чтобы команды могли легко найти его рабочий процесс при необходимости.
Как только изменение будет подтверждено, сработает функция Jenkins. Наше использование Jenkins для непрерывной интеграции развивалось с годами.
В нашем центре обработки данных мы начали с одного огромного мастера Jenkins, но в результате в AWS было использовано 25 главных Jenkins. Netflix использует его для большое количество автоматизированных задач , которые более сложны, чем простая непрерывная интеграция.
Задача Дженкинса — вызывать Nebula для создания, тестирования и подготовки кода приложения к развертыванию.
Если репозиторий становится библиотекой, Nebula опубликует *.
jar в нашем репозитории.
Если репозиторием является приложение, Nebula запустит плагин ospackage. Плагин ospackage («пакет операционной системы») представляет сгенерированный артефакт приложения как пакет Debian или RPM, содержимое которого определяется с помощью простого DSL на основе Gradle. Затем Nebula опубликует файл Debian в репозитории пакетов, где он будет доступен для следующего шага: запекания.
«Пекарня»
Примечание: в разделах «выпечка» и «хлебобулочные изделия».подразумевается аналогия с процессом выпечки в реальной жизни: рецептура, последовательность, соблюдение необходимых условий.
Автору оригинала очень нравится эта фраза, и он будет часто использовать ее в будущем.
К сожалению, я не нашел русскоязычного аналога смысла, вложенного в эти слова.
Наша стратегия развертывания сосредоточена вокруг неизменность шаблона сервера .
Чтобы снизить вероятность смещения конфигурации и гарантировать, что дублирующиеся развертывания происходят из одного и того же источника, изменение файлов вручную крайне не рекомендуется.
Каждое развертывание в Netflix начинается с создания нового AMI ( Изображение машины Amazon ).
Чтобы генерировать файлы AMI непосредственно из источника, мы создали «Пекарню».
Bakery создает API, который невероятно упрощает создание AMI. Затем API-интерфейсы Bakery Service планируют «подготовку» заданий для рабочих узлов, которые используют Animator для создания изображений.
Для вызова функции «запекания» пользователю необходимо объявить установку нужного пакета и базовый образ, на который этот пакет будет установлен.
Это (базовый AMI) предоставляет среду Linux, настроенную с общими конвекциями, службами и инструментами, необходимыми для полной интеграции с большей частью экосистемы Netflix. Когда Jenkins успешно завершает свою часть работы, он обычно вызывает « Спинакерный трубопровод «.
Они могут быть вызваны действиями Дженкинса или фиксациями Git. Spinnaker прочитает пакет операционной системы, сгенерированный Nebula, и вызовет API Bakery, чтобы начать работу.
Приложение
После завершения «выпекания» Spinnaker может развернуть полученный AMI в десятках, сотнях или даже тысячах экземпляров.Один и тот же AMI можно использовать в нескольких средах, в то время как Spinnaker обнаруживает среду выполнения для конкретного экземпляра, позволяя приложениям настраивать время выполнения.
Успешная «выпечка» запустит следующий этап «конвейера спинакера» — развертывание в тестовой среде.
Здесь команды начинают развертывание, используя целую «батарею» автоматизированных интеграционных тестов.
С этого момента специфика «конвейера» делает процесс развертывания зависимым от людей, обладающих возможностью тонкой настройки.
Команды используют «Spinnaker» для управления развертываниями с несколькими областями, красными/черными развертываниями и т. д. Достаточно сказать, что конвейеры Spinnaker предоставляют командам гибкие инструменты для контроля развертывания кода.
Дорога впереди
В целом эти инструменты обеспечивают высокий уровень производительности и автоматизации.Например, требуется всего 16 минут, чтобы " Обезьяна-дворник «Наша облачная служба обеспечения устойчивости и обслуживания прошла путь от окна регистрации до развертывания в нескольких регионах.
Спинакер испечет и развернет конвейер, названный Дженкинсом.
Это означает, что мы всегда ищем способы улучшить опыт разработчиков и постоянно ставим перед собой задачу работать лучше, быстрее и проще.
Нас часто спрашивают, как мы в Netflix справляемся с бинарными зависимостями.
Nebula предоставляет нам инструменты, предназначенные для облегчения зависимостей Java. Например, давайте возьмем плагин блокировки зависимостей, который помогает приложениям вычислять все свои графики двоичных зависимостей и создает файл переменной a.lock. Плагин" правила разрешения » for Nebula позволяет создавать правила зависимостей для всего проекта, которые влияют на все его части.
Эти инструменты помогают упростить управление бинарными зависимостями, но при этом не снижают показатели до приемлемого уровня.
Также мы работаем над сокращением времени «выпекания».
Не так давно 16 минут развертывания казались мечтой, но по мере того, как другие части системы стали быстрее, эта мечта стала потенциальным препятствием.
В качестве примера возьмем развертывание Обезьяньей армии: процесс запекания занял 7 минут, что составляет 44% от всего процесса запекания и развертывания.
Мы обнаружили, что основными факторами (по времени) процесса выпечки были установка пакета (включая разрешение зависимостей) и сам процесс копирования AWS. По мере роста и развития Netflix растет спрос на его инструменты сборки и развертывания, обеспечивающие первоклассную поддержку JavaScript/Node.js, Python, Ruby и Go без виртуальной машины.
Сейчас для этих языков можно порекомендовать плагин Nebula ospackage, который позволяет получить пакет Debian для последующего «запекания», оставив сборку и тестирование инженерам и инструментам используемой платформы.
Это решение пока работает для нас, но мы пытаемся расширить наш инструментарий, чтобы уменьшить зависимость от конкретных языков.
Контейнеры представляют собой интересное решение последних двух проблем.
В настоящее время мы изучаем, как контейнеры могут помочь улучшить процессы сборки, запекания и развертывания.
Если мы сможем создать локальную контейнерную среду, которая точно имитирует нашу облачную среду, мы потенциально сможем сократить время «запекания», необходимое для циклов разработки и тестирования, тем самым повысив производительность разработчиков и ускорив общий процесс разработки продукта.
Наличие контейнера, который можно развернуть локально «из коробки», снижает когнитивную нагрузку и позволяет нашим инженерам сосредоточиться на решении проблем и инновациях, а не на проверке наличия ошибок из-за различных сред. Теги: #netflix #разработка #код #стриминг #услуги #разработка сайтов #программирование
-
Рекламу Яндекс.такси Покажут По Телевидению
19 Oct, 24 -
Простое Объяснение Теоремы Байеса
19 Oct, 24 -
32 Мая Или 3 Дня С Нод
19 Oct, 24 -
Номер
19 Oct, 24 -
Даже У Функций Есть Предел...
19 Oct, 24 -
Подкаст Службы Новостей Cnews От 28.01.08
19 Oct, 24
