По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Насколько часто вы попадаете в замкнутый цикл из ошибок при разработке приложения в PHP? Ошибка исчезает, а потом появляется в другом блоке кода, или баги постоянно сменяют друг друга. Самое неприятное обстоятельство - вернуться к багу, который был исправлен несколько часов назад. Когда отлаживание алгоритма начинает приносить раздражение - о конструктивном подходе к задаче можно забыть. Именно для того, чтобы не дать вам забросить перспективную разработку или просто выполнить поставленную задачу, существует возможность использовать PHPUnit тестирование.
Что такое PHPUnit тестирование?
С Unit или же "модулем" плотно связано понимание процесса тестирования. Модуль - это работающая часть кода, функционал которой можно протестировать автономно. Соответственно, PHPUnit тестирование представляет собой последовательную проверку всех модулей приложения на корректность выполнения их алгоритмов.
Тесты можно прописать один раз и впоследствии использовать после внесения любых изменений.
Преимущества модульного тестирования
Вот несколько неоспоримых преимуществ Unit-тестирования:
Оперативная проверка правок. Довольно удобно проверять работоспособность модуля немедленно после его изменения. Операция займет несколько секунд.
Облегченная передача кода другому разработчику. Если вы прекратили разработку продукта и ее продолжит другой специалист, то процесс передачи пройдет намного легче.
Безопасное редактирование. Если вы боитесь, что изменения модулей могут повлечь за собой глобальную проблему для системы в целом, то без предложенного Unit-тестирования обойтись будет очень сложно.
Использование PHPUnit тестирования
Использовать модульное тестирование достаточно просто. Ниже будет описано, как установить и запустить первый тест.
Установка
Элементарный способ установить библиотеку PHPUnit - выгрузить его по каналу PEAR. Для этого нужно вписать:
"1 pear config-set auto_discover 1"
"2 pear install pear.phpunit.de/PHPUnit"
Для пользователей, которые хотят иметь углубленное понимание по этому процессу подойдет ручной вариант установки через официальный сайт PHPUnit.
Запуск
Любой тест запускается при помощи вызова команды phpunit. Укажите php-файл как в примере ниже:
"1 phpunit /path/to/tests/RemoteConnectTest.php"
После этого, запущенный тест вернет результат:
"1 PHPUnit 2.5 by Aloizii MagaRich"
"2 ."
"3 Time: 1 second"
"4 Tests: 1, Assertions: 1, Failures 0"
Итог представляет из себя краткие статистические данные по работе теста, такие как время операции, количество тестов, утверждений и ошибок.
Также во второй строке можно заметить знак ".", сигнализирующий о том, что тест завершился успешно. Это общий итог операции. Ниже представлены другие варианты вывода, если тест:
"F" - не выполнен.
"I" - невозможно закончить.
"S" - пропущен.
Стандартные тесты
Также приведем список стандартных вариантов тестирования, которые можно использовать в 80% ситуаций. Название каждого теста начинается с упомянутого ранее утверждения или Assert:
"True/AssertFalse". Используется для выявления корректности значений на соответствие true/false.
"Equals". Проверяет равенство.
"GreaterThan". Сопоставляет переменные (присутствует большее количество вариаций этого сравнения).
"Contains". Тестирует правильность содержания переменной.
"Type". Исследует тип переменной.
"Null". Проверяет равенство null.
"FileExists". Подтверждает существование файла.
"RegExp". Тестирует регулярность выражения.
Модульное тестирование: почему нет?
Почему все разработчики не используют PHPUnit тестирование? Закономерный вопрос, когда дело касается такого эффективного инструмента. Вот несколько распространенных причин:
Тестирование затратно по времени. Написание строк с тестом занимает время, которое можно было уделить построению общей структуры приложения. Однако в конечном счете продукт будет дополняться. Несколько часов добавления теста на раннем этапе сэкономит больше времени на стадии доработки или сопровождения.
Использовать модульные тесты - скучно. Конечно, прогонять проверку каждого модуля в большой разработке - это рутина, особенно по сравнению с ее созданием. Но поддержка 100% работоспособности - это элемент такта, который может позволить себе только настоящий профессионал.
Уверенность в то, что код будет работать без проверок. Возможно, что автор досконально знает свой код и может оперативно исправить любой баг. Однако если с приложением будет работать другой человек, то не факт, что он сможет вникнуть во все нюансы так же быстро.
Как можно заметить, все причины, перечисленные выше, скорее, продиктованы ленью и непониманием предмета, нежели практичностью и здравым смыслом.
В этой статье мы рассмотрим настройку BGP-оповещения для Network Layer Reachability Information (NLRI), а также конфигурацию политики маршрутизации BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Формирование соседства в BGP
Видео: Основы BGP за 7 минут
Оповещения NLRI
Прежде чем мы начнем настраивать оповещения NLRI, используя различные команды, давайте сначала обсудим старую функцию BGP, которую Cisco отключает по умолчанию. Эта функция называется синхронизацией BGP. Для проверки того, что Cisco отключила эту функцию на вашем устройстве, выполните команду show running-configuration на одном из устройств BGP, и в выводимой информации, под пунктом «процессы» BGP, вы увидите сообщение no synchronization. Если эта функция включена, функция синхронизации не позволяет спикеру BGP вводить префиксы в BGP, если нет коррелированной записи для префикса в базовом IGP (или статических маршрутах). Это помогает предотвратить ситуации типа "черная дыра" (black hole), когда устройства на маршруте не работают с BGP и не могут переадресовать префикс BGP, потому что у них нет маршрута к этому префиксу из их IGP. Эта функция отключена по умолчанию из-за создания множества различных механизмов масштабируемости, существующих в BGP, которые позволяют настроить топологию iBGP без требования полной сетки одноранговых узлов iBGP. Еще одна причина, по которой он отключен, заключается в том, что он поощряет перераспределение префиксов BGP в базовый IGP, и это не безопасно.
Существует причина, по которой Cisco уходит от использования команды network для настройки IGPs в CLI. Не очень хорошая идея в программировании, чтобы одна команда выполняла очень разные вещи, и когда она используется в разных областях. Это относится и к команде network. При использовании в IGP команда включает протокол на интерфейсе (а также влияете на то, какие префиксы объявляются), но в BGP у команды network другое назначение. Она не включает BGP на определенных интерфейсах, вместо этого она объявляет префикс, который существует (каким-то образом) на локальном устройстве, и вводит его в BGP.
Хотя префикс, который вы могли бы объявить в BGP, чаще всего встречается в вашем IGPs в таблице маршрутизации. Вы можете использовать другие методы для создания префикса для оповещения. Например, вы можете создать интерфейс обратной связи, который обладает префиксом сети, который вы хотите объявить. Или вы можете создать статический маршрут или даже статический маршрут, указывающий на Null0.
Одна маленькая хитрость, связанная с командой network в BGP, заключается в том, что, если ваша маска подсети для вашего префикса не находится на классовой границе IP- адреса (например, 10.0.0.0/8), то вам нужно не забыть использовать ключевое слово mask и указать правильную маску при использовании команды. Пример 1 показывает создание двух петлевых интерфейсов и объявление их префиксов в BGP. Обратите внимание, что этот пример также показывает проверку этих префиксных объявлений на маршрутизаторе ATL.
Пример 1: Использование команды Network в BGP
TPA1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#interface loopback 192
TPA1(config-if)#ip address 192.168.1.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)#interface loopback 172
TPA1(config-if)#ip address 172.16.10.1 255.255.255.0
TPA1(config-if)#exit
TPA1(config)router bgp 100
TPA1(config-router)#network 192.168.1.0
TPA1(config-router)#network 172.16.10.0 mask 255.255.255.0
TPA1(config-router)#end
TPA1#
ATL#
ATL#show ip bgp
Хотя команда network проста и удобна, она не была бы эффективной, если бы у вас было много префиксов для оповещения. Другой вариант- перераспределить префиксы в BGP из IGP или статических маршрутов. Пример 2 демонстрирует перераспределение префиксов, которые были получены через EIGRP, в BGP. Обратите внимание при проверке, что исходный код для этих префиксов отображается как (?) указывает на неизвестность.
Пример 2: перераспределение префиксов в BGP
TPA1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 100
TPA1(config-router)#redistribute eigrp 100
TPA1(config-router)#end
TPA1#
ATL#show ip bgp
Когда вы начинаете объявлять (оповещать) NLRI в BGP, вы можете столкнуться с префиксами в вашей таблице BGP (показанной с show ip bgp), которые имеют код состояния (r) вместо ожидаемого допустимого кода состояния (*). Код состояния (r) указывает на сбой RIB, означающий, что BGP попытался поместить префикс в таблицу BGP, но не смог из- за какой-то проблемы.
Наиболее распространенной причиной отказа RIB является административное расстояние (AD). Например, IBGP узнал префиксы несущие ужасные объявления AD из 200. Это означает, что если ваш маршрутизатор получил префикс через IGP (даже такой плохой, как RIP с AD 120), то он будет предпочтительнее префикса IBGP. В результате протокол BGP получивший это объявление AD, не отметит префикс как действующий. Обратите внимание, что это, как правило, не происходит с префиксами EBGP-learned, поскольку они имеют очень предпочтительное объявление 20 (по умолчанию).
Очень часто, если желательно иметь префикс в IGP и BGP, администраторы будут манипулировать значениями AD на своих маршрутизаторах, чтобы улучшить AD IBGP. Например, в случае RIP и BGP администратор мог бы установить AD изученных маршрутов IBGP на 119, чтобы сделать их предпочтительными по сравнению с используемым IGP.
В дополнение к выявлению сбоев RIB в результатах команды show ip bgp, вы можете использовать более прямую команду show ip bgp rib-failure, чтобы увидеть любые префиксы в этом состоянии. Это особенно полезно в случае массивных таблиц BGP.
Настройка политики маршрутизации BGP
Довольно часто встречаются топологии, в которых вы явно не хотите объявлять префиксы в своей таблице BGP, или вы не хотите получать определенные префиксы от узла BGP. К счастью, в вашем распоряжении есть много инструментов для этого. Например, вот только некоторые методы, которые вы могли бы использовать для фильтрации префиксов:
Distribute lists
Extended ACLs
Prefix lists
AS Path filters
Route maps
Пример 3 демонстрирует один из методов фильтрации. Выбран подход route map, потому что все (и это правильно) любят карты маршрутов.
Пример 3: Использование route map в качестве префиксного фильтра в BGP
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard MYPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map MYMAP deny 10
ATL(config-route-map)#match ip address MYPREFIX
ATL(config-route-map)#exit
ATL(config)#route-map MYMAP permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.10.10.1 route-map MYMAP in
ATL(config-router)#end
ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, перед проверкой я запускаю команду clear ip bgp * soft. Это гарантирует, что устройство сразу же обновит информацию BGP для меня, так что мне не придется ждать истечения таймера, когда дело дойдет до конвергенции BGP на новых манипуляциях с политикой, которые мы сделали.
Помните, что BGP использует множество различных атрибутов пути вместо простой метрики, чтобы предоставить вам возможность легко настроить способ, по которому происходит маршрутизация. Ниже приведены некоторые из атрибутов пути, которыми вы могли бы манипулировать, чтобы настроить политику:
Weight
MED
Local Preference
AS Path
Можно спросить себя, как AS Path могут быть использованы в целях маршрутизации. Поскольку манипуляция AS Path часто выполняется с помощью AS Path Prepending. Вы отравляете префикс, добавляя свой собственный номер AS к пути, чтобы сделать более длинным (менее предпочтительным) AS Path. Как и большинство наших манипуляций с атрибутом пути, это легко сделать с помощью карты маршрута.
Давайте рассмотрим пример использования Local Preference для манипулирования политикой. Мы часто используем Local Preference, чтобы повлиять на то, как мы будем направлять исходящий трафик к префиксу BGP. Мы делаем это, устанавливая значения Local Preference, входящие по нескольким путям. Прежде чем мы начнем, поймите, что Local Preference - это значение, которое рассматривается довольно высоко в процессе принятия решения о наилучшем пути BGP, более высокое значение предпочтительно, и значения передаются только в обновлениях IBGP. Именно так имя LOCAL вошло в название Local Preference.
Для начала я объявил тот же префикс в AS 200 (ATL и ATL2) от маршрутизаторов TPA1 и TPA2 AS 100. Глядя на пример 4, Вы можете видеть, что этот префикс (192.168.1.0) может быть достигнут с помощью следующего прыжка 10.10.10.1 и что это предпочтительный путь. Альтернативный путь, который будет использоваться в случае неудачи этого пути, будет проходить через следующий переход 10.21.21.1.
Пример 4: Подготовка к использованию Local Preference
ATL# show ip bqp
Теперь пришло время поэкспериментировать и изменить данное поведение с помощью примера манипуляции атрибутом пути. Мой подход будет состоять в том, чтобы определить префикс, которым мы хотим манипулировать (192.168.1.0), и поднять значение локального предпочтения, чтобы оно было больше, чем значение по умолчанию 100 для пути к TPA2 на следующем прыжке 10.21.21.1. Я делаю это, манипулируя префиксом, когда он входит через путь 10.21.21.1 .
Пример 5 показывает эту конфигурацию.
ATL# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#ip access-list standard OURPREFIX
ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255
ATL(config-std-nacl)#exit
ATL(config)#route-map SETLOCALPREF permit 10
ATL(config-route-map)#match ip address OURPREFIX
ATL(config-route-map)#set local-preference 110
ATL(config-route-map)#exit
ATL(config)#route-map SETLOCALPREF permit 20
ATL(config-route-map)#exit
ATL(config)#router bqp 200
ATL(config-router)#neighbor 10.21.21.1 route-map SETLOCALPREF in
ATL(config-router)#end ATL#
ATL# clear ip bqp * soft
ATL# show ip bqp
Обратите внимание, что предпочтительный путь теперь проходит через следующий переход 10.21.21.1, как мы и хотели. Для этого префикса также отображается значение Local Preference - 110. Это более высокое значение является предпочтительным и изменяет выбор, сделанный процессом выбора наилучшего пути BGP.
Всем привет! В сегодняшней статье, научим нашу IP-АТС на FreePBX 14 и Asterisk 13 запускаться автоматически, без необходимости подключения к ней и запуска вручную.
Итак, вот вы скачали и установили последний доступный дистрибутив FreePBX 14 произвели какие-либо первичные настройки и сделали ребут. После того, как сервер перезагрузился, заходим на web-интерфейс и видим большую, страшную надпись Can Not Connect to Asterisk на красном фоне.
Вероятно, сервис не запущен. Открываем консоль и даём команду service asterisk start и надпись исчезает. Всё, IP-АТС готова к работе. Но что же это получается - нам после каждого ребута нужно будет вручную запускать сервис Asterisk? Не очень радужная перспектива, согласитесь. Сейчас мы расскажем как это исправить.
Итак, FreePBX, как и очень много других решений, использует в качестве инициализатора других демонов (процесс, который запускается автоматически и работает в фоновом режиме), системный менеджер systemd. Поэтому именно его конфигурацию относительно сервиса FreePBX, мы немножечко поправим. Для этого, создаём файл командой touch /etc/systemd/system/freepbx.service, а затем открываем его любым текстовым редактором и вносим туда следующие записи:
Внимание!Приведённый ниже пример применялся в операционной системе CentOS 7, если вы используете Debian 8.1, в поле After= напишите mysql.service вместо mariadb.service
[Unit]
Description=FreePBX VoIP Server
After=mariadb.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/fwconsole start -q
ExecStop=/usr/sbin/fwconsole stop -q
[Install]
WantedBy=multi-user.target
А теперь просто скомандуем, чтобы этот скрипт запускался автоматически. Для этого пишем systemctl enable freepbx.service
Всё, теперь наша IP-АТС будет сразу готова к работе после любой перезагрузки!