По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитайте предыдущую статью из цикла про Основы IPv4 Access Control Lists.
Когда вы думаете о месте и направлении ACL, вы, должно быть, уже думаете о том, какие пакеты вы планируете фильтровать (отбрасывать), а какие хотите пропустить. Чтобы сообщить маршрутизатору те же идеи, вы должны настроить маршрутизатор с IP ACL, который соответствует пакетам. Соответствующие пакеты относятся к тому, как настроить команды ACL для просмотра каждого пакета, перечисляя, как определить, какие пакеты следует отбросить, а какие разрешить.
Каждый IP ACL состоит из одной или нескольких команд конфигурации, каждая из которых содержит подробную информацию о значениях, которые нужно искать в заголовках пакетов. Как правило, команда ACL использует такую логику, как "найдите эти значения в заголовке пакета и, если они найдены, отвергните пакет" (вместо этого может быть разрешение пакета, а не его отбрасывание.) В частности, ACL ищет поля заголовка, которые вы уже должны хорошо знать, включая IP-адреса источника и назначения, а также номера портов TCP и UDP.
Давайте сначала рассмотрим пример с рисунка 2, в котором нам необходимо разрешить прохождение пакетов с хоста A на сервер S1, но отбросить пакеты от хоста B, идущие на тот же сервер. Все хосты теперь имеют IP-адреса, а на рисунке показан псевдокод ACL на R2. На рисунке 2 также показано расположение, выбранное для включения ACL: входящий на интерфейсе S0/0/1 R2.
На рисунке 2 показан ACL, состоящий из двух строк в прямоугольнике внизу с простой логикой сопоставления: оба оператора просто ищут совпадение с исходным IP-адресом в пакете. Когда этот параметр включен, R2 просматривает каждый входящий IP-пакет на этом интерфейсе и сравнивает каждый пакет с этими двумя командами ACL. Пакеты, отправленные хостом A (исходный IP-адрес 10.1.1.1), разрешены, а пакеты, отправленные хостом B (исходный IP-адрес 10.1.1.2), отбрасываются.
Принятие мер при возникновении совпадения. При использовании ACL IP для фильтрации пакетов можно выбрать только одно из двух действий. Команды настроек используют ключевые слова deny и allow, и они означают (соответственно) отбросить пакет или разрешить ему продолжать работу, как если бы ACL не существовал.
Здесь основное внимание уделяется использованию ACL для фильтрации пакетов, но IOS использует ACL для многих других функций. Эти функции обычно используют одну и ту же логику сопоставления. Однако в других случаях ключевые слова deny или allow подразумевают другое действие.
Типы ACL IP
Cisco IOS поддерживает ACL IP с первых дней существования маршрутизаторов Cisco. Начиная с исходных стандартных пронумерованных списков контроля доступа IP на заре IOS, которые могли задействовать логику, показанную ранее на рисунке 2, Cisco добавила множество функций ACL, включая следующие:
Стандартные нумерованные списки ACL (1–99)
Расширенные нумерованные ACL (100–199)
Дополнительные номера ACL (1300–1999 стандартные, 2000–2699 расширенные)
Именованные ACL
Улучшенное редактирование с порядковыми номерами
Здесь мы рассматриваем исключительно стандартные пронумерованные списки контроля доступа IP, а в следующей лекции рассмотрим другие три основные категории списков контроля доступа IP. Вкратце, списки управления доступом IP будут либо пронумерованы, либо именованы, так как конфигурация идентифицирует ACL с использованием номера или имени. ACL также будут стандартными или расширенными, при этом расширенные ACL будут иметь гораздо более надежные возможности для сопоставления пакетов. Рисунок 3 суммирует основные идеи, связанные с категориями списков контроля доступа IP.
Стандартные нумерованные списки ACL IPv4
Этот подраздел лекции посвящен типу фильтра Cisco (ACL), который соответствует только исходному IP-адресу пакета (стандарт), настроен для идентификации ACL с использованием чисел, а не имен (пронумерованных), и смотрит на пакеты IPv4.В этой части исследуются особенности стандартных пронумерованных списков контроля доступа IP. Во-первых, он исследует идею о том, что один ACL является списком, и какую логику использует этот список. После этого в тексте подробно рассматривается, как сопоставить поле IP-адреса источника в заголовке пакета, включая синтаксис команд. В конце этой лекции дается полный обзор команд конфигурации и проверки для реализации стандартных ACL.
Логика списка с IP ACL
Один ACL - это одновременно и единый объект, и список одной или нескольких команд конфигурации. Как единый объект, конфигурация включает весь ACL на интерфейсе в определенном направлении, как показано ранее на рисунке 1. В виде списка команд каждая команда имеет различную логику согласования, которую маршрутизатор должен применять к каждому пакету при фильтрации с использованием этого ACL.При обработке ACL маршрутизатор обрабатывает пакет по сравнению с ACL следующим образом: ACL используют логику первого совпадения. Как только пакет соответствует одной строке в ACL, роутер выполняет действие, указанное в этой строке ACL, и прекращает поиск в ACL.Чтобы понять, что это означает, рассмотрим пример, построенный на рисунке 4. На рисунке показан пример ACL 1 с тремя строками псевдокода. В этом примере ACL 1 применяется к входящему интерфейсу S0/0/1 R2 (то же расположение, что и на предыдущем рисунке 2).
Рассмотрим логику ACL первого совпадения для пакета, отправленного хостом A на сервер S1. Исходным IP-адресом будет 10.1.1.1, и он будет маршрутизирован так, чтобы входить в интерфейс S0/0/1 R2, управляя логикой ACL 1 R2. R2 сравнивает этот пакет с ACL, сопоставляя первый элемент в списке с действием разрешения. Таким образом, этот пакет должен быть пропущен, как показано на рисунке 5 слева.
Затем рассмотрим пакет, отправленный хостом B, исходный IP-адрес 10.1.1.2. Когда пакет поступает в интерфейс S0/0/1 R2, R2 сравнивает пакет с первым оператором ACL 1 и не находит соответствия (10.1.1.1 не равно 10.1.1.2). Затем R2 переходит ко второму утверждению, которое требует некоторого пояснения. Псевдокод ACL, показанный на рисунке 4, показывает 10.1.1.x, что означает сокращение того, что в последнем октете может существовать любое значение. Сравнивая только первые три октета, R2 решает, что этот последний пакет действительно имеет IP-адрес источника, который начинается с первых трех октетов 10.1.1, поэтому R2 считает, что это соответствует второму оператору. R2 выполняет указанное действие (запретить), отбрасывая пакет. R2 также останавливает обработку ACL для пакета, игнорируя третью строку в ACL.
Наконец, рассмотрим пакет, отправленный хостом C, снова на сервер S1. Пакет имеет IP-адрес источника 10.3.3.3, поэтому, когда он входит в интерфейс R2 S0/0/1 и управляет обработкой ACL на R2, R2 просматривает первую команду в ACL 1. R2 не соответствует первой команде ACL (10.1.1.1). в команде не совпадает с пакетом 10.3.3.3). R2 просматривает вторую команду, сравнивает первые три октета (10.1.1) с IP-адресом источника пакета (10.3.3) и по-прежнему не находит совпадения. Затем R2 смотрит на третью команду. В этом случае подстановочный знак означает игнорирование последних трех октетов и просто сравнение первого октета (10), чтобы пакет соответствовал. Затем R2 выполняет указанное действие (разрешение), позволяя пакету продолжить работу.
Эта последовательность обработки ACL в виде списка происходит для любого типа IOS ACL: IP, других протоколов, стандартных или расширенных, именованных или пронумерованных. Наконец, если пакет не соответствует ни одному из элементов в ACL, пакет отбрасывается. Причина в том, что каждый IP ACL имеет оператор deny all, подразумеваемый в конце ACL. Его нет в конфигурации, но если маршрутизатор продолжает поиск в списке, и до конца списка не найдено совпадение, IOS считает, что пакет соответствует записи, имеющей действие запрета.
Соответствие логики и синтаксиса команд
Стандартные нумерованные ACL для IP-адресов используют следующую команду:
access-list {1-99 | 1300-1999} {permit | deny} matching-parameters
Каждый стандартный нумерованный ACL имеет одну или несколько команд списка доступа с одинаковым номером, любым числом из диапазонов, показанных в предыдущей строке синтаксиса. IOS относится к каждой строке в ACL как к записи управления доступом (ACE), но многие сетевые администраторы просто называют их операторами ACL.Помимо номера ACL, каждая команда списка доступа также перечисляет действие (разрешить или запрещать), а также логику сопоставления. Остальная часть этой части изучает, как настроить параметры сопоставления, что для стандартных списков ACL означает, что вы можете сопоставить исходный IP-адрес или части исходного IP-адреса только с помощью так называемой обратной маски ACL.
Соответствие точному IP-адресу
Чтобы сопоставить конкретный исходный IP-адрес, весь IP-адрес, все, что вам нужно сделать, это ввести этот IP-адрес в конце команды. Например, в предыдущем примере псевдокод используется для "разрешить, если источник = 10.1.1.1". Следующая команда настраивает эту логику с правильным синтаксисом с использованием ACL номер 1:
access-list 1 permit 10.1.1.1
Сопоставить точный полный IP-адрес очень просто.В более ранних версиях IOS синтаксис включал ключевое слово host. Вместо того, чтобы просто вводить полный IP-адрес, вы сначала набираете ключевое слово host, а затем IP-адрес. Обратите внимание, что в более поздних версиях IOS, если вы используете ключевое слово host, IOS принимает команду, но затем удаляет ключевое слово.
Сопоставление адреса подсети с обратной маской
Часто бизнес-цели, которые вы хотите реализовать с помощью ACL, совпадают не с одним конкретным IP-адресом, а с целым рядом IP-адресов. Возможно, вы хотите сопоставить все IP-адреса в подсети. Возможно, вы хотите сопоставить все IP-адреса в диапазоне подсетей. Несмотря на это, вы хотите проверить наличие нескольких IP-адресов в диапазоне адресов.
IOS позволяет стандартным ACL сопоставлять диапазон адресов с помощью инструмента, называемого обратной маской. Обратите внимание, что это не маска подсети. Обратная маска (сокращенно называют маской WC) дает сетевому администратору способ сказать IOS игнорировать части адреса при проведении сравнений, по существу рассматривая эти части как подстановочные знаки, как если бы они уже совпадали.Вы можете использовать маски WC в десятичном и двоичном виде, и оба имеют свое применение. Для начала можно использовать маски WC в десятичной системе счисления, используя следующие правила:
Десятичное число 0: маршрутизатор должен сравнить этот октет как обычно.
Десятичное число 255: маршрутизатор игнорирует этот октет, считая его уже совпадающим.
Имея в виду эти два правила, рассмотрим рисунок 6, который демонстрирует эту логику с использованием трех различных, но популярных масок WC: одна, которая говорит маршрутизатору игнорировать последний октет, другая, которая говорит маршрутизатору игнорировать последние два октета, и третья, которая говорит маршрутизатору игнорировать последние три октета.
Все три примера во вставках на рисунке 6 показывают два числа, которые явно различаются. Маска WC заставляет IOS сравнивать только некоторые октеты, игнорируя другие октеты. Все три примера приводят к совпадению, поскольку каждая подстановочная маска указывает IOS игнорировать некоторые октеты. В примере слева показана маска WC 0.0.0.255, которая указывает маршрутизатору обрабатывать последний октет как подстановочный знак, по существу игнорируя этот октет для сравнения. Точно так же в среднем примере показана маска WC 0.0.255.255, которая сообщает маршрутизатору игнорировать два октета справа. В крайнем правом случае показана маска WC 0.255.255.255, указывающая маршрутизатору игнорировать последние три октета при сравнении значений.
Чтобы увидеть маску WC в действии, вспомните предыдущий пример, относящийся к рисункам 4 и 5. В ACL псевдокода на этих двух рисунках используется логика, которую можно создать с помощью маски WC. Напомним, что логика ACL псевдокода на этих двух рисунках включает следующее:
Строка 1: Сопоставить и разрешить все пакеты с адресом источника соответствующий строго 10.1.1.1.
Строка 2: Сопоставить и отклонить все пакеты с адресами источника с первыми тремя октетами 10.1.1.
Строка 3: сопоставить и разрешить все адреса с первым одиночным октетом 10.
На рисунке 7 показана обновленная версия рисунка 4, но с завершенным правильным синтаксисом, включая маски WC. В частности, обратите внимание на использование маски WC 0.0.0.255 во второй команде, указывающей R2 игнорировать последний октет числа 10.1.1.0, и маску WC 0.255.255.255 в третьей команде, указывающую R2 игнорировать последние три октеты в значении 10.0.0.0.
Наконец, обратите внимание, что при использовании маски WC свободно определенный параметр источника команды access-list должен иметь значение 0 в любых октетах, где маска WC - 255. IOS будет указывать адрес источника равным 0 для частей, которые будут игнорироваться, даже если были настроены ненулевые значения.
Теперь почитайте про wildcard в ACL: бинарные обратные маски
Профессия Flutter-разработчика набирает популярность. Этот специалист создает кроссплатформенные мобильные приложения для iOS и Android с использованием фреймворка Flutter. Разберемся, какими навыками должен обладать Flutter-разработчик, почему в современном мире они так нужны и с чего начать.
Что такое Flutter и как он работает
Flutter — это open-source
фреймворк
от Google для кросс-платформенных приложений. Его главная особенность — приложения создаются с единой кодовой базой. А это сильно экономит время и ресурсы разработчиков. Flutter использует язык программирования Dart. Он компилируется в машинный код и обеспечивает высокую производительность приложений. Кроме того, у Flutter есть собственный набор виджетов для разработки UI, что делает интерфейсы гибкими и отзывчивыми.
Запуск Flutter: идея кроссплатформенности
История Flutter начинается в 2015 году, когда Google начала работу над новым проектом Sky. Основная идея было в том, чтобы сделать инструмент для разработки приложений с одинаковым пользовательским интерфейсом и для Android, и для iOS. Позже проект трансформировался в нечто большее: Google создала целый фреймворк для работы с единой кодовой базой для нескольких платформ.
Преимущества и недостатки фреймворка
Несмотря на популярность у фреймворка есть преимущества и недостатки, которые важно учитывать при выборе инструмента для разработки.
Преимущества
Недостатки
?Кроссплатформенность: с его помощью можно написать приложения под Android, iOS, Windows, macOS, Linux и даже веб-приложения.
?Высокая производительность: приложения на Flutter работают почти так же быстро, как нативные, благодаря компиляции в машинный код.
?Открытый исходный код: это open-source проект, что означает доступ к коду, постоянные обновления и множество бесплатных инструментов для работы.
?Гибкость интерфейсов: разработчики могут создавать уникальные и сложные пользовательские интерфейсы. Они одинаково хорошо выглядят на разных платформах.
? Поддержка от Google: крупная компания стояла за разработкой и активно продвигала фреймворк.
? Функция Hot Reload: инструмент позволяет Flutter-разработчикам мгновенно видеть изменения в коде без перезапуска приложения. Это ускоряет процесс разработки, тестирования и отладки, так как изменения появляются в реальном времени.
?Большой размер приложений: по сравнению с нативными приложения весят больше. У фреймворка есть собственный рендеринг и необходимые библиотеки, что увеличивает итоговый вес приложения.
? Ограниченная поддержка платформ: поддержка Windows, macOS и Linux все еще находится в стадии активного развития. Это может ограничить использование фреймворка для крупных десктопных проектов.
?Ограниченный доступ к нативным API: некоторые специфические или новые функции могут быть недоступны и требовать написания нативного кода. Это усложняет разработку.
? Относительно молодое сообщество: у фреймворка меньше готовых решений, библиотек и инструментов для решения узкоспециализированных задач.
? Кривые обновления фреймворка: иногда обновления Flutter могут ломать совместимость с существующими плагинами или библиотеками.
? Проблемы с SEO для веб-приложений: для веб-разработки есть ряд ограничений по SEO-оптимизации. Большая часть контента рендерится через JavaScript, что может снизить видимость сайта в поисковых системах.
Язык Dart
Для Flutter был выбран язык программирования Dart, который появился еще в 2011 году. До выхода фреймворка он не пользовался широкой популярностью. Основное преимущество Dart — это его производительность, простота и возможность компиляции в машинный код. Поэтому приложения на Flutter максимально производительные.
Синтаксис у Dart схож с Java, JavaScript и C#. Это делает его интуитивно понятным для разработчиков. Простота и логичность синтаксиса — одно из ключевых преимуществ Dart и облегчает процесс обучения.
Какие навыки нужны, чтобы стать Flutter-разработчиком
Flutter-разработчику нужны навыки, которые помогают эффективно работать с фреймворком и создавать качественные кроссплатформенные приложения. Вот основные из них:
Знание языка программирования Dart. Глубокое понимание синтаксиса и особенностей языка программирования — основа для работы с фреймворком. Важно освоить статистическую и динамическую типизацию, объектно-ориентированное и асинхронное программирование.
Работа с Flutter SDK. Необходимо уверенно работать с различными библиотеками и плагинами приложения, уметь настраивать окружения для Android и iOS
Понимание принципов кроссплатформенной разработки. Важно знать, как оптимизировать код для Android, iOS и веб, особенности пользовательских интерфейсов и UX на каждой платформе и способы работы с нативными функциями и API.
Разработка пользовательских интерфейсов (UI). Flutter-разработчик владеет основными виджетами, понимает концепции программирования UI, работает с Material Design (для Android) и Cupertino (для iOS), настраивает анимацию и сложные интерфейсы.
Оптимизация и работа с производительностью. Чтобы приложения работали быстро, важно понимать основы работы с рендерингом и отрисовкой UI и уметь решать проблемы снижения скорости.
Знание основ мобильной разработки. Полезно иметь знания по архитектуре мобильных приложений, работе с API и сторонними сервисами и пониманию жизненного цикла приложений на Android и iOS.
Работа с базами данных и сетевыми запросами. Многие приложения работают с удалёнными серверами и базами данных. Поэтому важно уметь работать с REST API и JSON, понимать различия SQL и noSQL и использовать библиотеки для сетевых запросов hppt или dio.
Контроль версий Git и командная работа. Для эффективной работы в команде необходимо владеть системой контроля версий Git и знать основы CI/CD (непрерывная интеграция и доставка) для автоматизации процессов сборки и тестирования.
Тестирование. Flutter поддерживает три уровня тестирования: модульное, интеграционное и тестирование пользовательских интерфейсов (UI). Важно уметь писать тесты проверки и настраивать интеграционные тесты.
Сколько зарабатывает Flutter-разработчик
Зарплата разработчика Flutter зависит от этапа карьеры и компании:
junior
может получать от 100 000 рублей,
middle
с опытом от 1 до 3 лет — более 200 000 рублей. Для сеньоров с большим опытом есть вакансии от 300 000 рублей. На хх.ру предложений не так много — по запросу «Flutter» мы нашли 315 вакансий.
Источник:
hh.ru
Кому стоит рассмотреть Flutter-разработку
Flutter — хороший выбор для тех, кто только-только начинает изучать мобильную разработку. Фреймворк интуитивно понятен и имеет огромное количество обучающих ресурсов. Dart легко освоить, особенно если у вас уже есть база из JavaScript или Java.
Фреймворк подойдёт и нативным разработчикам. Если вы имеете опыт работы с Android (Kotlin/Java) или iOS (Swift/Objective-C), то сможете легко освоить Flutter и расширить свои навыки, чтобы создавать приложения для обеих платформ одновременно.
Итак
Flutter-разработка — это перспективное направление для тех, кто хочет создавать кроссплатформенные мобильные приложения. Фреймворк предлагает множество преимуществ. Специалисты, владеющие Flutter имеют отличные перспективы для карьерного роста.
Невозможно реализовать управление контейнерами приложений в требуемом масштабе (особенно в контексте CI/CD или конвейера DevOps) без автоматизации. Примерно 57% компаний имеют от 2 до 8 контейнеров на каждое приложение (31% компаний имеют от 11 до 100 на каждое приложение). Именно поэтому нецелесообразно будет использовать десятки или даже сотни приложений без оркестровки контейнеров, особенно если речь идет о долгосрочной перспективе.
Эта статья является введением в тему оркестровки контейнеров, и она подчеркивает важность того, что при управлении контейнеризованными службами и рабочими нагрузками необходимо избегать трудоемких задач. Я предлагаю прочесть вам эту статью, чтобы узнать, что предлагает вашему вниманию эта стратегия, а также как оркестровка может поспособствовать повышению продуктивности IT-команд и увеличению дохода.
Что такое оркестровка контейнеров?
Оркестровка контейнеров – это стратегия использования автоматизации для управления жизненным циклом контейнеров приложений. Такой подход автоматизирует трудоемкие задачи, такие как (повторное) создание, масштабирование и обновление контейнеров. Таким образом, он избавляет команды от рутинной ручной работы. Оркестровка также помогает в управлении возможностями сети и хранилища.
Контейнеры – это упрощенные исполняемые компоненты приложения, которые содержат все необходимое для надежного запуска программного кода в различных IT-средах. Команды разбивают программное обеспечение на контейнеры с целью упростить запуск, перемещение, обновление и упаковку приложений. Один контейнер содержит:
исходный код приложения;
библиотеки операционной системы (ОС);
зависимости, которые необходимы для того, чтобы запустить программное обеспечение (например, определенные версии сред выполнения языка программирования).
Контейнеры считаются более переносимыми и более эффективными с точки зрения ресурсов в сравнении с виртуальными машинами. Они также являются одной из лучших вычислительных стратегий разработки современного программного обеспечения и архитектуры приложений, оптимизированной для выполнения в облаке. Но есть здесь одно «но» -
чем больше используется контейнеров, тем больше времени и ресурсов разработчики должны тратить на то, чтобы ими управлять.
Представим, что у вас есть 40 контейнеров, которые необходимо обновить. Можно выполнить это вручную, но это займет часы, а то и дни. И вот здесь в игру вступает оркестровка контейнеров – вместо того, чтобы делать все вручную, вы указываете инструменту выполнить 40 обновлений с помощью всего одного YAML-файла.
По данным недавнего опроса, 70% разработчиков, которые работают с контейнерами, используют платформу оркестровки контейнеров. При этом, 75% из них полагаются на полностью управляемую службу оркестровки контейнеров от поставщика облачных услуг. Нет ничего удивительного в том, что самые высокие показатели скорости внедрения оркестровки контейнеров именно в командах DevOps.
Для чего нужна оркестровка контейнеров?
Оркестровка контейнеров автоматизирует многие подвижные части контейнеризованного программного обеспечения. В зависимости от платформы возможности различаются, но большая часть инструментов позволяют автоматизировать следующие задачи:
конфигурация и планирование контейнеров (когда и как контейнеры запускаются и останавливаются, планирование и согласование действий каждого компонента и т.д.);
подготовка к работе и развертывание контейнеров;
масштабирование контейнеров (как в большую сторону, так и в меньшую) для балансировки рабочих нагрузок;
распределение ресурсов и перемещение файлов (например, если один из контейнеров начинает потреблять слишком много оперативной памяти в узле, то платформа перемещает все остальные контейнеры в другой узел);
балансировка нагрузки и маршрутизация трафика;
управление кластерами;
обнаружение служб (как микрослужбы или приложения обнаруживают друг друга в сети);
наблюдение за работоспособностью системы, включая процессы отката и восстановления после отказа (как для контейнеров, так и для хостов);
доступность и резервирование контейнеров;
защита взаимодействий типа контейнер-контейнер и контейнер-хост;
обновления и модификации контейнеров.
Принцип работы оркестровки контейнеров
Большая часть платформ оркестровки поддерживают декларативную модель конфигурации, которая позволяет пользователям определять необходимый результат выполнения, не предоставляя при этом подробных инструкций. Разработчик пишет файл конфигурации (обычно на YAML или JSON), чтобы описать ту конфигурацию, которую он хочет получить, и инструмент работает так, чтобы сделать все возможное для получения необходимого результата. Роль такого файла конфигурации состоит в следующем:
определять, какие образы контейнеров являются частью приложения;
направлять платформу в сторону расположения образов, например, Docker Hub;
обеспечивать контейнеры необходимыми ресурсами (например, хранилищем);
определять и защищать сетевые соединения между контейнерами;
предоставлять инструкции по установке объема памяти и хранению журналов.
Большинство команд разветвляют файлы конфигурации и контролируют их версии. Именно по этой причине инженеры могут развертывать одно и то же приложение в различных средах разработки и тестирования перед тем, как пустить приложение в производство.
После того, как файл конфигурации будет предоставлен, инструмент оркестровки автоматически запланирует развертывание контейнера. Платформа выбирает оптимальный хост, основываясь на доступности процессора, памяти и других условиях, которые указаны в файле конфигурации (например, в зависимости от метаданных или близкого расположения какого-то конкретного хоста). Если не указаны иные основания, то большинство инструментов развертывают копии для того, чтобы обеспечить резервирование контейнеров.
После того, как инструмент развернет контейнер, платформа начнет управлять жизненным циклом контейнеризованного приложения. Сюда входит:
управление масштабируемостью, маршрутизацией трафика и распределением ресурсов между контейнерами;
обеспечение высокого уровня доступности и производительности каждого контейнера;
сбор и хранение данных журналов для контроля за работоспособностью и производительностью приложений;
попытки устранить проблемы и восстановить контейнеры при сбое (оно же самовосстановление).
Оркестровка контейнеров работает в любой среде, которая поддерживает контейнеры – от привычных выделенных серверов до облачного развертывания любого типа.
Что можно сказать об оркестровки мультиоблачных контейнеров?
Мультиоблако – это стратегия облачных вычислений, при которой вы прибегаете к помощи двух или более сторонних поставщиков. Оркестровка мультиоблачных контейнеров – это использование инструмента для управления контейнерами, которые перемещаются в мультиоблачных средах вместо того, чтобы работать в одной инфраструктуре.
Настройка оркестровки контейнеров для разных поставщиков иногда бывает довольно сложной, но если немного постараться, то можно получить множество преимуществ, например,
повышенная производительность инфраструктуры;
возможности для оптимизации расходов на облако;
улучшенная гибкость и переносимость контейнеров;
меньшая возможность появления зависимости от поставщика;
дополнительные возможности масштабирования.
Контейнеры и мультиоблако можно отлично совмещать. Несколько сред поддерживают переносимость контейнеров, которая позволяет «запускать их где угодно», в то время как контейнеризованные приложения раскрывают эффективность использования двух или более облачных предложений на максимум.
Преимущества оркестровки контейнеров
Ниже приведены основные преимущества оркестровки контейнеров:
ускоренное выполнение действия за счет автоматизации
: оркестровка контейнеров экономит невероятное количество времени за счет автоматизации таких задач, как выделение ресурсов для контейнеров, балансировка нагрузки, настройка конфигураций, планирование и оптимизация сетей.
более простое управление
: по своей сути контейнеры существенно усложняют обычные повседневные операции. Одно приложение может иметь сотни, а то и тысячи, контейнеров. Именно по этой причине все очень быстро может выйти из-под контроля, если не использовать платформу оркестровки.
повышение продуктивности сотрудников
: примерно 74% компаний отмечают, что их команды становятся более продуктивными, если не тратят время на рутинные задачи. Команды выпускают новые функции быстрее, что приводит к тому, что продукт будет быстрее выведен на рынок, а также открывается больше возможностей для инновационных разработок с высоким финансовым результатом.
экономия ресурсов и средств
: оркестровка контейнеров придерживается оптимального использования ресурсов обработки и памяти, избегая лишних накладных расходов.
дополнительная безопасность
: оркестровка контейнеров ощутимо сокращает вероятность человеческого фактора, который является основной причиной успешного результата кибератак. Более 73% компаний отмечают улучшения с точки зрения безопасности после того, как они начали использовать оркестровку. Эта стратегия также изолирует процессы приложений и обеспечивает большую наглядность, что снижает количество потенциальных атак.
улучшенное качество приложения
: почти 78% команд отмечают, что, благодаря внедрению оркестровки контейнеров, улучшилось качество приложений. Также 73% компаний заявили, что они повысили уровень удовлетворенности пользователей за счет улучшения приложений.
улучшенные показатели удержания сотрудников
: оркестровка контейнеров освобождает команды от рутинной работы и дает им возможность заниматься более интересными задачами, что повышает уровень удовлетворенности от работы у сотрудников и помогает компании не растерять таланты.
увеличенное время работы служб
: платформа оркестровки контейнеров находит и устраняет такие проблемы, как сбои инфраструктуры, гораздо быстрее, чем если бы это делал человек. Более 72% компаний отмечают, что время простоя служб значительно уменьшилось после того, как была внедрена оркестровка.
Самые популярные инструменты оркестровки контейнеров
Чтобы использовать оркестровку контейнеров, вам потребуется соответствующий инструмент. Давайте взглянем на пять самых популярных инструментов, которые можно сейчас найти на рынке.
Kubernetes
Kubernetes (K8s или Kube) – это инструмент оркестровки контейнеров с открытым исходным кодом для контейнеризованных рабочих нагрузок и служб. В 2015 году Google подарил K8s Фонду облачно-ориентированных вычислений (CNCF - Cloud Native Computing Foundation). После этого он стал самым популярным инструментом оркестровки контейнеров в мире.
По данным исследования CNCF 2021 года, в прошлом году количество инженеров, работающих с Kubernetes, выросло на 67% и достигло рекордной отметки в 3,9 миллиона человек. Популярность К8s послужила толчком к появлению разного рода предложений Kubernetes как услуги (KaaS - Kubernetes-as-a-Service) (они все будут полезны для вас, если вы все-таки решите работать с оркестровкой), в том числе:
Amazon Elastic Container Service (ECS);
Azure Kubernetes Services (AKS);
Google Kubernetes Engine (GKE);
VMwaare Tanzu;
Knative;
Istio;
Cloudify;
Rancher.
Главные причины использовать Kubernetes
Ведущие в отрасли функциональные возможности (обнаружение служб, оркестровка хранилища, автоматическое внедрение и откат, самовосстановление, использование технологии Dual-Stack и т.д.) и набор инструментов поддержки с открытым исходным кодом, который постоянно расширяется.
Дополнительные функции автоматического масштабирования позволяют проводить высокоуровневое масштабирование (HPA - для горизонтального масштабирования, VPA - для вертикального масштабирования, и Cluster Autoscaler - для оптимизации количества узлов).
Поддержка огромного сообщества, которое постоянно добавляет новые функции.
Docker Swarm
Docker Swarm – это платформа оркестровки контейнеров с открытым исходным кодом. Она известна за счет свой простоты в настройке и использовании. Swarm – это режим работы в собственной системе команд Docker (инструмент для контейнеризации), который позволяет пользователям управлять «докеризированными» приложениями.
Главные причины использовать Docker Swarm
Проще с точки зрения настройки и использования в сравнении с Kubernetes (также имеет меньше функций, что делает Swarm более приемлемым вариантом для не очень сложных сценариев использования).
Идеальный вариант для тех пользователей Docker, которые ищут более простой и быстрый способ развертывания контейнеров.
Низкая кривая обучения делает Swarm идеальным вариантом для менее опытных команд и новичков в оркестровке контейнеров.
Nomad
Nomad – это инструмент оркестровки как для контейнеризованных, так и для неконтейнеризованных приложений, который был разработан HashiCorp (компания, которая стоит за Terraform – одним из лучших инструментов инфраструктуры как кода (Infrastructure-as-Code) на рынке). Платформу можно использовать как самостоятельный оркестратор, так и в качестве дополнения к Kubernetes.
Главные причины использовать Nomad
Идеальный вариант, если вы уже используете продукты компании HashiCorp, такие как Terraform, Vault или Consul.
Инструмент занимает мало места (Nomad работает как самостоятельный двоичный файл и работает на всех основных операционных системах).
Гибкий и простой в использовании оркестратор, который поддерживает рабочие нагрузки не только в контейнерах (ПО предыдущих версий, виртуальные машины, рабочие нагрузки Docker и т.д.).
OpenShift
OpenShift от компании Red Hat – это ведущая платформа как услуга (PaaS – Platform-as-a-Service) для создания, развертывания и управления контейнеризованными приложениями. Платформа позволяет расширить функциональные возможности Kubernetes и является популярным вариантом для рабочих процессов непрерывной интеграции за счет встроенного конвейера Jenkins.
Главные причины использовать OpenShift
Различные функции для управления кластерами через пользовательский интерфейс и интерфейс командной строки.
Высокооптимизированная платформа, которая хорошо подходит для развертывания гибридных облачных сред.
Большой выбор шаблонов и готовых образов для создания баз данных, фреймворков и служб.
Apache Mesos (с использованием Marathon)
Mesos – это платформа с открытым исходным кодом для управления кластерами, которая вкупе с собственным фреймворком Marathon становится отличным (пусть даже и немного дорогим) инструментом оркестровки контейнеров.
Несмотря на то, что Mesos не так популярен, как, например, Kubernetes или Docker Swarm, он все же является излюбленным инструментом оркестровки для некоторых известных компаний, таких как Twitter, Yelp, Airbnb, Uber и Paypal.
Главные причины использовать Apache Mesos
Высокомодульная архитектура, которая позволяет пользователям легко масштабировать систему до 10 000 с лишним узлов.
Упрощенная кроссплатформенная платформа оркестровки с свойственной ей гибкостью и масштабируемостью.
API-интерфейсы Mesos поддерживают Java, C++ и Python, а платформа работает на Linux, Windows и OSX.
Kubernetes, Docker Swarm и Apache Mesos пережили так называемую «оркестровую войну» в начале и середине 2010-х годов. Была гонка за право называться отраслевым стандартом для управления контейнерами. 29 ноября 2017 года «победил» K8s. Это произошло, когда AWS анонсировала свое предложение Elastic Container Service для Kubernetes.
Отраслевой стандарт для контейнеризованных приложений
Контейнеры изменили наше представление о том, как надо создавать и сопровождать программное обеспечение. В основу этого процесса эволюции легла оркестровка контейнеров, так как она позволила извлечь максимальную выгоду от использования микрослужб и ощутимо оптимизировать повседневные операции. Эффективное управление контейнерами так и останется приоритетным направлением в будущем, так что настройтесь на то, что оркестровка будет только набирать популярность в мире контейнеризованных приложений.