По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Хотим показать два простых способа для ограничения набора платных номеров (международных и междугородних направлений) на Asterisk. Зачем это нужно? Часто в компаниях есть определённый тип пользователей, которым, для выполнения своих служебных обязанностей, не требуется совершать исходящие звонки на внешние направления. Они принимают входящие вызовы от внешних абонентов и могут пользоваться внутрикорпоративной связью. Именно такую задачу мы решим.
Будем считать, что ограничить набор номеров платных направлений нужно для внутренних номеров маской 3XX.
Способ 1
Для решения вышеописанной задачи первым способом будем пользоваться графическим интерфейсом FreePBX 13 и уже знакомым нам модулем Custom Context.
Открываем вкладку Connectivity → Custom Context и нажимаем Add Context:
Задаём новому контексту название и понятное описание и жмём Submit, после чего перед нами открывается список правил, которыми мы будем манипулировать, чтобы запретить доступ к исходящим направлениям.
Дальнейшие действия рекомендуем воспроизводить в точности по следующему порядку:
Выбираем опцию Allow напротив строки Set All To;
Выбираем опцию Deny Rules напротив строки ENTIRE Basic Internal Dialplan;
В окне Deny Rules указываем шаблон (dial pattern) внешних номеров, которые хотим запретить. В нашем случае это - 810Z. – международный и 8495XXXXXXX, 8499XXXXXXX, 89XXXXXXXX - звонки по городу и мобильные номера. Узнайте как принимает номер ваш провайдер, чтобы указать правильный шаблон.
Должно получиться вот так:
4. Далее прокручиваем данное меню вниз и напротив строки ALL OUTBOUND ROUTES также выбираем Deny Rules, после чего жмём Submit и Apply Config
Теперь осталось только применить созданное правило на нужных Extension’ах. Для этого открываем модуль Extensions ищем внутренний номер, которому необходимо запретить совершать международные и междугородние звонки (например 310), открываем вкладку Other и напротив строки Custom Context выбираем наш новый контекст.
Нажимаем Submit, Apply Config и готово теперь с данного внутреннего номера “наружу” не позвонить.
Если таких внутренних номеров много, то можно выгрузить csv файл со всеми их настройками с помощью модуля Bulk Handler и указать так контекст вручную, а затем импортировать новый файл.
Способ 2
Для решения задачи вторым способом, нам придётся немного изменить правила в конфигурационных файлах. Для этого открываем /etc/asterisk/extensions_custom.conf любым редактором, ищем контекст [from-internal-custom] и вносим туда следующую запись:
[from-internal-custom]
exten => _8X./3XX,1,NoOp("${CALLERID} long-distance call detected")
exten => _8X./3XX,n,Playback(feature-not-avail-line,noanswer)
exten => _8X./3XX,n,Hangup()
Таким образом, мы запретили набор номеров междугородних и международных направлений с выходом через 8 для всех внутренних номеров с маской 3XX.
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье
Кстати! Еще у нас есть статья по сравнению Apache против IIS. Welcome 🤓
Краткий обзор Apache
Apache был разработан для доставки веб-контента, доступ к которому осуществляется через Интернет. Он известен тем, что играл ключевую роль в начальном росте интернета. Apache - это программное обеспечение с открытым исходным кодом, разработанное и поддерживаемое открытым сообществом разработчиков и работающее в самых разных операционных системах. Архитектура включает в себя ядро Apache и модули. Основной компонент предоставляет базовую серверную функцию, поэтому он принимает соединения и управляет параллелизмом. Различные модули соответствуют различным функциям, которые выполняются по каждому запросу. Конкретное развертывание Apache может быть сконфигурировано для включения различных модулей, таких как функции безопасности, управление динамическим контентом или для базовой обработки HTTP-запросов.
Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась.
Краткий обзор Nginx
Nginx был разработан специально для устранения ограничений производительности веб-серверов Apache. Производительность и масштабируемость Nginx обусловлены архитектурой, управляемой событиями. Он значительно отличается от подхода Apache. В Nginx каждый рабочий процесс может одновременно обрабатывать тысячи HTTP-соединений. Следовательно, Nginx - это легковесная, масштабируемая и высокопроизводительная реализация. Эта архитектура делает обработку больших и флуктуирующих нагрузок на данные гораздо более предсказуемой с точки зрения использования ОЗУ, использования ЦП и задержки.
Nginx также имеет богатый набор функций и может выполнять различные роли сервера:
Обратный прокси-сервер для протоколов HTTP, HTTPS, SMTP, POP3 и IMAP
Балансировщик нагрузки и HTTP-кеш
Интерфейсный прокси для Apache и других веб-серверов, сочетающий гибкость Apache с хорошей производительностью статического контента Nginx
Apache против Nginx: сравнение их богатых наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу.
Статический контент
Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором.
Динамический контент
Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей.
Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это.
Nginx Plus (Nginx Plus - это программный балансировщик нагрузки, веб-сервер и кэш контента, построенный на основе открытого исходного кода Nginx) также использует модульную архитектуру. Новые функции и возможности могут быть добавлены с программными модулями, которые могут быть подключены к работающему экземпляру Nginx Plus по требованию. Динамические модули добавляют в Nginx Plus такие функции, как геолокация пользователей по IP-адресу, изменение размеров изображений и встраивание сценариев Lua в модель обработки событий Nginx Plus. Модули создаются как Nginx, Inc., так и сторонними разработчиками.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя.
Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен.
В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц.
Ngnix против Apache: Сравнение лицом к лицу
Подводя итог, вот табличное представление наборов функций:
ОсобенностьApacheNginxПростотаЛегко разрабатывать и внедрять инновации благодаря своей модели «одно соединение на процесс»Сложный в разработке, поскольку он имеет сложную архитектуру для одновременной обработки нескольких соединений.Производительность - Статический контентМедленно в отображении статического контентаВ 2,5 раза быстрее чем Apache и потребляет меньше памятиПроизводительность - Динамический контентОтличная производительность для динамического контентаОтличная производительность для динамического контентаПоддержка операционной системыПоддерживает все ОС - Unix, как и WindowsПоддерживает все ОС - как Unix, так и Windows, однако производительность в Windows сравнительно менее стабильна.БезопасностьЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныГибкостьМожно настроить, добавив модули. Apache имел динамическую загрузку модулей дольше всего.Nginx версии 1.11.5 и Nginx Plus Release R11 представили совместимость для динамических модулей.Поддержка и документацияОтличная поддержка и документация доступны, как это было на рынке в течение очень долгого времени.Несмотря на слабое начало поддержки и документации для Nginx, он быстро рос, поэтому теперь у него есть отличная поддержка ресурсов и доступная документация.
Nginx и Apache - Совместная работа
Для многих приложений Nginx и Apache хорошо дополняют друг друга. Очень распространенным начальным шаблоном является развертывание программного обеспечения Nginx с открытым исходным кодом в качестве прокси-сервера (или Nginx Plus в качестве платформы доставки приложений) перед веб-приложением на основе Apache. Nginx выполняет тяжелую работу, связанную с HTTP - обслуживает статические файлы, кэширует содержимое и разряжает медленные HTTP-соединения - так что сервер Apache может выполнять код приложения в безопасной и защищенной среде.
Итак, что выберите? Apache или Nginx?
Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
Использование REST API является полезной функцией для реализации ваших сценариев. Вы можете получить доступ к новым функциям, а также расширить возможности создания новых, более продвинутых сценариев.
Опыт многих пользователей показывает, что, когда начинаешь использовать REST API в скриптах, то чувствуешь себя довольно неуклюже и непривычно. В этой заметке мы обсудим:
Что такое REST API
Как читать документацию
Как использовать API REST с PowerShell
Некоторые советы и подсказки, как облегчить и улучшить практику
Что такое "REST"?
REST, или RESTful API, это API, который использует HTTP запросы для получения, добавления, удаления или манипулирования данными в различных сервисах.
Как правило, то, что нужно сделать с данными, решается тем, какой HTTP-метод вы используете. Вот краткий список методов HTTP и их применение в REST API:
GET-Read
POST-Create
PATCH-Partial update/modify
PUT-Update/replace
DELETE-Remove
Данные, которые возвращает API REST, обычно представляются в формате JSON.
Теперь давайте начнём с нашего первого API запроса!
Что такое API
Работа с документацией
Для использования различных API REST необходимо научиться читать и интерпретировать документацию. К счастью, если вы знаете, как читать один тип документации, вы сможете быстро научиться читать другие.
В этой статье мы используем petstore.swagger.io, так как он использует популярный фреймворк Swagger, который довольно часто используется в разработке.
На предыдущем рисунке показана наиболее важная информация о конечных точках REST API:
HTTP-метод-GET/POST/DELETE и т.д.
URL-адрес, связанный с конечной точкой REST API (Базовый URL, как правило, представлен в верхней части страницы документации)
Краткое описание
Подробности
Первая страница документации просто замечательная, и, как правило, с помощью этой информации можно выполнить большинство запросов, требующих использования метода HTTP GET. Но такие методы, как POST и SET, обычно требуют, чтобы вы щелкнули и развернули строку, чтобы получить больше информации.
Если вы нажмете на одну из строк, то получите информацию, которая выглядит так:
Здесь мы представили конечную точку REST, которая может создать новый объект pet. Здесь указывается, как должен выглядеть JSON, предоставленный в теле POST, и какой тип контента он принимает. Другие конечные точки REST указывают, что это за параметры, каким типом данных они должны быть и т.д.
Это основы для чтения документации. Теперь, когда общие принцип более-менее ясны, пора начать использовать REST API с PowerShell.
Получение первых данных (GET)
Используя REST API с PowerShell обычно довольно просто, используется встроенные командлеты, таким образом, нет необходимости в дополнительных модулях. Мы собираемся извлечь данные с помощью метода GET в конечной точке /pet/{ petId}.
Если развернуть конечную точку /pet/{ petId} в документации, можно увидеть, что {petId} на самом деле является параметром, который принимает целое число.
Это делает URL-адрес для выборки объекта pet с идентификатором 1: https://petstore.swagger.io/v2/pet/1
В документации SWAGGER REST API обычно отображается базовый URL-адрес в верхней части страницы.
Теперь начнем с PowerShell. Откройте окно терминала и введите:
PS51 > Invoke-RestMethod -Method GET -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
id : 1
category : @{id=0; name=string}
name : doggie
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Поскольку в ответе от сервера возвращается тип содержимого "application/json" используется метод Invoke-RestMethod, который автоматически преобразует возвращаемый JSON в объект.
Ошибка 404 Not found, как правило, означает, что объект не найден или URL-адрес введен неправильно.
Итак, мы выполнили первый вызов REST API. Но возможности метода GET для получения данных довольно ограничены, так что давайте создадим что-нибудь с помощью метода POST.
Создание объекта методом POST
Метод POST чаще всего используется для создания, например, пользователей или записей и т.д. Запрос POST отправляет BODY, содержащий информацию, конечной точке REST, обычно в формате JSON, но он также может быть в виде формы с кодировкой URL.
Вы узнаете, как создать объект JSON, который можно отправить в конечную точку/pet.
Можно увидеть, как должен выглядеть JSON, если развернуть строку POST/pet в документации.
Начнем с создания хэштаблицы, который можно преобразовать в объект JSON. Raw JSON следует избегать в скриптах PowerShell, поскольку он ограничивает его возможности.
$Body = @{
id = 19
category = @{
id = 45
name = "Whatever"
}
name = "Dawg"
photoUrls = @(
"string"
)
tags = @(
@{
id = 0
name = "string"
}
)
status = "available"
}
Если вам трудно создать хештаблицу, который преобразуется в нужный JSON, установите модуль PsdKit и используйте команду $ JsonString | ThreadTo-Psd
Теперь имеется хэш-таблица, которую можно преобразовать в строку JSON и POST в конечную точку/pet:
$JsonBody = $Body | ConvertTo-Json
$Uri = "https://petstore.swagger.io/v2/pet"
Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method Post -Body $JsonBody
id : 19
category : @{id=45; name=Whatever}
name : Dawg
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
При создании объекта он обычно получает созданный для подтверждения объект. Использование DELETE. Метод DELETE используется для удаления данных, а применение очень схоже с методом GET.
PS51 > Invoke-RestMethod -Method DELETE -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
Только убедитесь, что не удалите ничего важного
Использование PUT
Метод PUT используется для обновления данных. Это делается аналогично методу POST путем представления полного или частичного объекта JSON:
PS51> $Body = [PSCustomObject]@{
id = 19
name = "Dawg with a new name"
}
PS51> $JsonBody = $Body | ConvertTo-Json
PS51> $Uri = "https://petstore.swagger.io/v2/pet"
PS51> Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method PUT -Body $JsonBody
id name photoUrls tags
-- ---- --------- ----
19 Dawg with a new name {} {}
Обычно API REST возвращает объект JSON с использованными и/или обновленными данными. Можно увидеть, что объект был обновлен с помощью метода GET:
PS 51> Invoke-RestMethod -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/19"
id : 19
category : @{id=45; name=Whatever}
name : Dawg with a new name
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Создание функций
Писать эти команды каждый раз вручную может стать довольно утомительным и на самом деле не масштабируемым. Если мы вызываем конечную точку несколько раз, то лучше создать для нее функцию. Это довольно просто и нужно написать всего несколько строк:
Function Get-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipeline)]
[int]$Id
)
Begin{}
Process{
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/$Id"
ContentType = "application/json"
Method = "GET"
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
После создания функции ее можно вызвать в сценарии:
PS51> Get-PetstorePet -Id 1
id name photoUrls tags
-- ---- --------- ----
1 Doggie {http://picture.url} {}
Это можно сделать и для метода POST для создания нового объекта pet в Petstore:
Function Add-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$Id,
# Name of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Name,
# Status of the pet (available, sold etc)
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Status,
# Id of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$CategoryId,
# Name of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$CategoryName,
# URLs to photos of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string[]]$PhotoUrls,
# Tags of the pets as hashtable array: @{Id=1;Name="Dog"}
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[Hashtable[]]$Tags
)
Begin{}
Process{
$Body = @{
id = $Id
category = @{
id = $CategoryId
name = $CategoryName
}
name = $Name
photoUrls = $PhotoUrls
tags = $Tags
status = $Status
}
$BodyJson = $Body | ConvertTo-Json
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/"
ContentType = "application/json"
Method = "Post"
Body = $BodyJson
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
И вызов этой функции PowerShell намного упрощает задачу:
PS51> $AddPetStorePetsParams = @{
Id = 44
Name = "Birdie"
Status = "available"
CategoryId = 50
CategoryName = "Hawks"
PhotoUrls = "https://images.contoso.com/hawk.jpg"
Tags = @(
@{
Id=10
Name="Not eagles"
}
)
}
PS51> Add-PetStorePet @AddPetStorePetsParams
id : 44
category : @{id=50; name=Hawks}
name : Birdie
photoUrls : {https://images.domain.com/hawk.jpg}
tags : {@{id=0}}
status : available
Возможно, что многие модули, которые вы ежедневно используете, состоят из функций, который за кулисами используют REST API.
Заключение
Обучение работы с REST API, главным образом основано на чтении документации. Мы использовали документацию на основе SWAGGER в этом посте, так как она представляет, как могут выглядеть другие стили документации.
Кроме того, преобразование вызовов API в функцию может сэкономить много времени, упростить работу и очистить сценарии.