По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет рассмотрен модуль Asterisk CLI – Command Line Interface, другими словами – консоль Asterisk. Данный инструмент является многоцелевым и может выполнять следующие функции:
Получение информации о системных компонентах Asterisk
Настройка системной конфигурации
Просмотр логов, ошибок и предупреждений в реальном времени
Генерация звонков в целях проведения тестов
Просмотр расширенной документации – для API, приложений, функций, настройки модулей и так далее.
Далее рассмотрим процесс вызова консоли – есть несколько путей.
Через веб-интерфейс FreePBX
Для этого необходимо открыть веб-интерфейс Вашей АТС и далее пройти по следующему пути: Admin –> Asterisk CLI
После этого откроется страница, на которой можно вводить команды.
По SSH
С помощью удаленного доступа – по SSHTelnet с использованием терминала (к примеру, PuTTy). При таком типе подключения необходимо будет ввести логин и пароль, и затем ввести команду:
[root@localhost ~]#asterisk -rvvvv
Примечание: Количество букв «v» означает уровень логирования в CLI. Т.е чем больше букв – тем больше информации будет «сыпаться» на экран.
Как только был получен доступ, возможно будет вывести следующую информацию:
Телефонные звонки
Регистрацию абонентов
Уведомления о появлении новых абонентов
Запросить перезагрузку системных компонентов (экстеншенов, транков и т.д)
Все команды имеют следующий синтаксис:
module name -> action type -> parameters (Название модуля –> Тип действия -> Параметры)
К примеру – команда sip show peers, которая выведет список зарегистрированных chan_sip абонентов.
Если же ваша АТС работает некорректно – к примеру, Asterisk не стартует вообще, стоит попробовать вызвать консоль с другим набором настроек, которые позволят начать специфическую отладку приложений – логирование порядка загрузки, соединения с базой данной, количества попыток регистрации и прочее.
Кроме того, есть возможность запускать команды CLI без непосредственного ввода команд, описанных выше. Для этого необходимо напрямую обратиться к модулю Asterisk:
[root@localhost ~]#asterisk -rx 'reload now'
К примеру, данная команда перезагрузит весь модуль Asterisk.
Самые нужные команды
Ниже будут приведены описания некоторых часто используемых команд:
localhost*CLI>DIALPLAN SHOW \ вывод вашего диалплана (правила маршрутизации вызовов)
localhost*CLI>CORE SHOW TRANSLATION \ вывод таблицы с методами транскодирования кодеков
localhost*CLI>SIP SET DEBUG PEER PHONE_EXT \ запуск отладки определенного экстеншена (с указанием номера экстеншена)
localhost*CLI>SIP SET DEBUG IP PEER_IP \ запуск отладки определенного абонента по его сетевому адресу
localhost*CLI>SIP SET DEBUG OFF \ отключение режима отладки
localhost*CLI>RELOAD \ перезагрузка модуля Asterisk, не всей АТС целиком. Может использоваться после внесения измерений
localhost*CLI>RESTART NOW \ перезагрузка всей системы в целом, может понадобиться если команды reload недостаточно или в целях регулярной плановой перезагрузки.
Главная команда, которую нужно усвоить – help, она выводит все прочие команды. Очень удобный внутренний инструмент.
Невозможно реализовать управление контейнерами приложений в требуемом масштабе (особенно в контексте 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.
Отраслевой стандарт для контейнеризованных приложений
Контейнеры изменили наше представление о том, как надо создавать и сопровождать программное обеспечение. В основу этого процесса эволюции легла оркестровка контейнеров, так как она позволила извлечь максимальную выгоду от использования микрослужб и ощутимо оптимизировать повседневные операции. Эффективное управление контейнерами так и останется приоритетным направлением в будущем, так что настройтесь на то, что оркестровка будет только набирать популярность в мире контейнеризованных приложений.
Пришло время заняться некоторыми более продвинутыми и интересными функциями протокола маршрутизации Open Shortest Path First. Мы начинаем с изучения конфигурации и проверки различных областей OSPF. Это упражнение является не только забавным, но и действительно может закрепить знания о том, как эти области функционируют и почему они существуют.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
OSPF LSA Types
Области (Areas) - это фундаментальная концепция OSPF. Это то, что делает протокол маршрутизации иерархическим, как мы любим говорить.
Существует основная магистральная область (область 0), которая соединяется с нормальными, не магистральными областями. Магистраль может также соединяться с особыми типами областей, которые мы подробно рассмотрим в этой группе статей. Такая иерархическая природа конструкции помогает гарантировать, что протокол является очень масштабируемым. Мы можем легко уменьшить или исключить ненужные потоки трафика маршрутизации и связи между областями, если это необходимо.
Магистральная и не магистральная область (Backbone и Non-Backbone Areas)
Вернемся немного назад к нашим предыдущим сообщениям в статьях об OSPF. На рисунке 1 показана простая многозонная сеть. Сейчас я настрою эту сеть, используя мой любимый подход к конфигурации, команду конфигурации уровня интерфейса ip ospf. Пример 1 показывает конфигурацию всех трех устройств.
Рисунок 1: Магистральная и не магистральная область (Backbone и Non-Backbone Areas)
Пример 1: Настройка магистральных и не магистральных областей
ATL Router:
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#interface fa0/0
ATL(config-if)#ip ospf 1 area 0
ATL(config-if)#interface lo0
ATL(config-if)#ip ospf 1 area 0
ATL(config-if)#end
ATL#
ATL2 Router:
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#interface fa0/0
ATL2 (config-if)#ip ospf 1 area 0
ATL2 (config-if)#interface
*Mar 27 22 :03 :27.815 : %0SPF-5-ADJCHG : Process 1, Nbr 1 .1.1 .1 on
FastEthernet0/0 from LOADING to FULL, Loading Done
ATL2 (config-if)#interface fa1/0
ATL2 (config-if)#ip ospf 1 area 1
ATL2 (config-if)#end
ATL2#
ORL Router:
ORL# conf t
Enter configuration commands, one per line. End with CNTL/Z.
ORL( config )#interface fa1/0
ORL(config-if)#ip ospf 1 area 1
ORL(config-if)#end
ORL#
*Mar 27 22 :04:21.515: %0SPF-5-ADJCHG: Process 1, Nbr 10.23.23.2
on FastEthernet1/0 from LOADING to FULL , Loading Done
Обратите внимание на простоту этой конфигурации, даже если мы настраиваем довольно сложный протокол маршрутизации. Area Border Router (ABR) находится в ATL2 с одним интерфейсом в магистральной и одним в не магистральной области.
Обратите также внимание, как мы получаем некоторые «бонусные» проверки. Когда мы настраиваем интерфейсы, мы можем видеть, что OSPF-соседства формируются между устройствами. Это избавляет нас от необходимости проверять их «вручную» с помощью следующей команды:
ATL2# show ip ospf neighbor
Интересной проверкой для нас здесь является проверка префикса 1.1.1.0/24 с устройства ATL (а также удаленной связи между ATL и ATL2). Мы проверяем это на ORL, чтобы проверить многозональную конфигурацию OSPF. Поскольку это «нормальная» область, все LSA должны быть разрешены в этой области, и мы должны видеть, что префикс появляется как межзонный маршрут OSPF.
show ip route ospf
Хотя это не часто требуется при устранении неполадок, но мы можем изучить базу данных OSPF, чтобы увидеть различные типы LSA.
show ip ospf database
Записи состояния соединения маршрутизатора являются Type 1 LSA. Это конечные точки в нашей локальной области 1. Записи состояния net link-это Type 2 LSA. Здесь мы видим идентификатор маршрутизатора назначенного маршрутизатора (DR). Наконец, суммарные состояния сетевых ссылок — это Type 3 LSA. Это префиксы, которые ABR посылает в нашу область. Конечно же, это loopback (1.1.1.0) и удаленная сеть (10.12.12.0).
Примечание: интерфейс обратной связи (loopback interface) объявлен как хост-маршрут 32-разрядной версии. Чтобы изменить это, вы можете просто использовать команду ip ospf network point-to-point на интерфейсе loopback. Это изменяет тип сети от типа loopback для OSPF и вызывает объявление маски в том виде, в каком она настроена.
Теперь пришло время добавить к этой истории еще и другое. Давайте настроим некоторые внешние префиксы и введем их в домен OSPF. Это просто благодаря loopback interfaces. Мы создадим некоторые из них на маршрутизаторе ATL, запустим EIGRP на них, а затем перераспределим их в OSPF.
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z .
ATL (config)#interface lo10
ATL (config-if)#ip address 192.168.10.1 255.255.255.0
ATL (config-if)#interface loopback 20
ATL (config-if)#ip address 192.168.20.1 255.255.255.0
ATL (config if)#router eigrp 100
ATL (config-router)#network 192 .168.10.1 0.0.0.0
ATL (config-router)#network 192.168.20.1 0.0.0.0
ATL (config-router)#router ospf 1
ATL (config-router)#redistribute eigrp 100 subnets metric 1000
ATL (config-router)#end
ATL#
Теперь у нас есть еще более интересные проверки на устройстве ORL. Во-первых, таблица маршрутизации:
show ip route ospf
Обратите внимание, что удаленные префиксы перечислены как маршруты E2. Это значение по умолчанию для внешних маршрутов OSPF типа 2. Это означает, что метрика остается неизменной, поскольку префикс течет от ASBR (автономного системного пограничного маршрутизатора) к внутреннему спикеру OSPF. Вы можете изменить тип на Type 1, если хотите, когда вы выполняете перераспределение.
Возможно, больший интерес представляет база данных OSPF:
show ip ospf database
Обратите внимание, как мы подбираем Type 4 LSA (summary ASB link state), который является идентификатором маршрутизатора (1.1.1.1) ASBR (ATL). Мы также получаем Type 5 LSA, которые являются внешними префиксами.
На этом мы завершим ПЕРВУЮ часть нашей продвинутой серии блогов OSPF. В следующий раз мы рассмотрим создание stubby areas, totally stubby areas, not so stubby areas (NSSA), и totally NSSA.