По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Docker и Kubernetes - два ведущих инструмента, используемых в индустрии облачных вычислений. В то время как Docker - это компьютерное приложение, использующее концепцию контейнеризации, а Kubernetes - это система оркестровки контейнеров. Как правило, Docker и Kubernetes используются совместно друг с другом. Тем не менее, сравнение Kubernetes и Docker является чрезвычайно популярной темой в сообществе облачных вычислений. Прежде чем сравнивать две наиболее важные технологии облачных вычислений, давайте сначала кратко расскажем о каждой из них. Kubernetes Впервые выпущенный в июне 2014 года, Kubernetes был изначально разработан Google. За дальнейшую разработку и обслуживание системы оркестровки контейнеров с открытым исходным кодом отвечает Cloud Native Computing Foundation. Согласно официальному сайту, Kubernetes является «системой с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями». Используя технологию контейнеризации, Kubernetes позволяет запускать контейнеры на нескольких вычислительных узлах, которые могут быть простыми серверами или виртуальными машинами. Перед использованием Kubernetes нужно перепроверить несколько вещей. Одним из них является обеспечение того, чтобы все участвующие вычислительные узлы были надежно связаны друг с другом. Docker Разработанная Docker, Inc., Docker была впервые выпущена в марте 2013 года. Это компьютерная программа, способная выполнять виртуализацию на уровне операционной системы, широко известную как контейнерная упаковка. Docker можно рассматривать в двух разных сторон. С первого взгляда контейнеры Docker - это действительно легкие виртуальные машины, а со второй точки зрения Docker - это платформа для упаковки и доставки программного обеспечения. Последний аспект в первую очередь ответственен за огромную популярность технологии контейнеризации Docker и ее широкое распространение в индустрии облачных вычислений. Можно ли сравнивать Docker и Kubernetes? Сравнивать Docker с Kubernetes - все равно что сравнивать Солнце с Луной. Конечно, оба небесных тела, но сравнение между ними не звучит правильно! Это потому, что, хотя оба сияют, один - звезда, а другой - естественный спутник. Хотя Docker может работать без Kubernetes, а Kubernetes может функционировать в полной мере без Docker, использование обоих в совместной работе улучшает функциональность друг друга. Docker может быть установлен на компьютере для запуска контейнерных приложений. Подход контейнеризации означает запуск приложений в операционной системе таким образом, чтобы они были изолированы от остальной части системы. Приложение будет чувствовать, что оно имеет свою собственную выделенную ОС. Несколько приложений могут работать в одной ОС, как если бы у каждого из них был свой экземпляр операционной системы. Каждое приложение находится внутри контейнера. Docker позволяет создавать, управлять и запускать контейнеры в одной операционной системе. Теперь, когда у вас установлен Docker на нескольких хостах, то есть на операционных системах, вы можете воспользоваться Kubernetes. В таком случае мы называем эти хосты узлами или узлами Docker, которые могут быть серверами с открытым исходным кодом или виртуальными машинами. Прелесть использования Kubernetes с Docker заключается в том, что он помогает автоматизировать балансировку нагрузки контейнера, создание сетей, выделение ресурсов, масштабирование и безопасность на всех хостах Docker с помощью отдельной панели мониторинга или интерфейса командной строки. Повышение масштабируемости приложений и повышение надежности инфраструктуры - две лучшие причины выбора нескольких узлов. Коллекция узлов, управляемых отдельным экземпляром Kubernetes, называется кластером Kubernetes. Kubernetes vs Docker Docker Swarm, про настройку которого можно прочитать тут - это платформа оркестрации контейнеров с открытым исходным кодом. Это собственный механизм кластеризации для Docker, и поэтому он использует ту же командную строку, что и Docker. Ниже приведены различные важные различия между Swarm и Kubernetes. Развертывание приложений Приложение развертывается в Kubernetes с использованием комбинации модулей и служб (или микросервисов). В Docker Swarm развертывание приложения происходит просто в виде микросервисов или сервисов в кластере Swarm. Docker Swarm поставляется с Docker Compose, который помогает в установке приложения. Для идентификации нескольких контейнеров в Docker Swarm есть файлы YAML (YAML Ain’t Markup Language). Настройка контейнера Хотя Docker Swarm API не поддерживает все команды Docker, он предлагает почти все лучшие функциональные возможности Docker. Итак, Docker Swarm поддерживает большинство инструментов, доступных для Docker. Однако, если Docker API не способен выполнять некоторые необходимые операции, не существует простого обходного пути для их использования в Docker Swarm. Как и Docker Swarm, Kubernetes имеет свою собственную версию API, определения клиентов и YAML. Тем не менее, они отличаются от их коллег Docker. Следовательно, нет возможности использовать Docker CLI или Docker Compose для определения контейнеров в Kubernetes. В случаях, когда необходимо переключить платформу, команды и определения YAML необходимо переписать. Балансировка нагрузки Как правило, Ingress используется для балансировки нагрузки в Kubernetes. Тем не менее, есть и другой способ, в котором модуль в Kubernetes выставляется через сервис и его можно использовать в качестве балансировщика нагрузки в кластере, к которому он принадлежит. Docker Swarm имеет DNS-элемент, который можно использовать для распределения входящих запросов по определенному имени службы. Для балансировки нагрузки службы могут быть назначены автоматически или настроены для работы на указанных пользователем портах. Сеть Kubernetes использует плоскую сетевую модель. Таким образом, все модули могут взаимодействовать друг с другом. Как будет происходить взаимодействие между модулями, определяется сетевыми политиками. Обычно модель плоской сети реализована в виде наложения. Модель плоской сети в Kubernetes требует две CIDR (Classless Inter-Domain Routing): один для сервисов, а другой - от которого модули получают IP-адрес. В Docker Swarm узел, присоединяющийся к кластеру Swarm, отвечает за генерацию оверлейной сети для сервисов, охватывающей каждый хост в кластере, и сети мостов Docker только для хостов для контейнеров. Docker Swarm дает пользователям возможность шифровать трафик контейнерных данных при создании оверлейной сети. Масштабируемость Kubernetes - это комплексная структура для распределенных систем. Поскольку он предлагает унифицированный набор API и надежные гарантии состояния кластера, Kubernetes является сложной системой. Эти способности отвечают за замедление развертывания и масштабирования контейнера. По сравнению с Kubernetes, Docker Swarm может развертывать контейнеры на гораздо более высокой скорости. Следовательно, это позволяет быстрее реагировать на масштабирование системы в соответствии с требованиями. Синергия между Docker и Kubernetes Kubernetes способен работать в тандеме с любой технологией контейнеризации. RKT и Docker являются двумя наиболее популярными опциями для механизма оркестровки контейнеров с открытым исходным кодом. Однако последний предпочтительнее, чем первый. Из-за большего предпочтения использования Docker с Kubernetes было приложено много усилий для совершенствования сотрудничества между этими двумя технологиями. Хотя Docker имеет свой собственный механизм оркестровки контейнеров в форме Docker Swarm, склонность к использованию Kubernetes с Docker нельзя не заметить. Это видно из того факта, что Docker for Desktop поставляется с собственным дистрибутивом Kubernetes. Следовательно, совершенно очевидно, что обе технологии, Docker и Kubernetes, объединили свои усилия и также извлекли большую пользу из этого сотрудничества.
img
Сегодня рассказываем про стандартный набор сервисных кодов в FreePBX 13. Спросите, почему стандартный? Потому что ваша сборка FreePBX может иметь более широкий от стандартного диапазона набор модулей, каждый из которых будет иметь свой собственный набор сервисных кодов (Feature Codes). Ну что же, давайте начнем разбираться. Для того, чтобы найти все сервисные коды на вашей IP - АТС Asterisk, перейдите в вкладку Admin -> Feature Codes Коды создания черного списка Ранее мы рассказывали про настройку черного списка в FreePBX 13 и поведали о возможностях его настройки. Вот как его настроить с помощью сервисных кодов: Название Код Описание Blacklist a number *30 Добавить новый номер в черный список. Все звонящие с заблокированных номеров будут слышать соответствующую аудио – запись. Blacklist the last caller *32 Добавить последнего звонящего на IP – АТС в черный список Remove a number from the blacklist *31 Удаление номера из черного списка. Номер вводится вручную Коды перенаправления вызова Название Код Описание Call Forward All Activate *72 Перенаправлять все поступающие на внутренний номер на другой номер. Call Forward All Deactivate *73 Выключить перенаправление вызовов. Call Forward All Prompting Activate *93 Запрашивает у звонящего ввести номер, на котором необходимо включить перенаправление вызовов. Call Forward All Prompting Deactivate *74 Запрашивает у звонящего ввести номер, на котором необходимо отключить перенаправление вызовов Call Forward Busy Activate *90 Включает функцию перенаправления вызовов, если вызываемый номер занят. Call Forward Busy Deactivate *91 Отключает функцию перенаправления вызовов, если вызываемый номер занят. Call Forward Busy Prompting Activate *94 Запрашивает ввести номер, на котором необходимо включить перенаправление вызов по результату «Занято» Call Forward Busy Prompting Deactivate *92 Запрашивает ввести номер, на котором необходимо отключить перенаправление вызов по результату «Занято» Call Forward No Answer/Unavailable Activate *52 Активирует перенаправление вызовов в случае, если пользователь недоступен или не отвечает на вызов Call Forward No Answer/Unavailable Deactivate *53 Деактивирует перенаправление вызовов в случае, если пользователь недоступен или не отвечает на вызов Call Forward No Answer/Unavailable Prompting Activate *95 Запрашивает ввести номер, на котором необходимо подключить перенаправление вызовов по не ответу или недоступности Call Forward Toggle *96 Включает или выключает режим перенаправления вызовов. Первый вызов на *96 выключит функцию, а второй включит. И так далее. Коды ожидания вызова Название Код Описание Call Waiting - Activate *70 Данная функция позволяет настроить прием вызова, даже если абонент уже находится в состоянии разговора. Данная опция поддерживается только на телефонных аппаратах, на которых есть возможность принятия нескольких вызовов. Call Waiting - Deactivate *71 Отключает указанный ваше функционал Коды ядра системы (core) Название Код Описание Asterisk General Call Pickup *8 Наберите данные сервисных код чтобы перехватить вызов, звонящий на другом телефоне Чтобы данная функция сработала, убедитесь: - На звонящем телефоне должен быть настроен Call Group в настройках внутреннего номера. - На номере, с которого вы хотите перехватить вызов, должно быть настроено поле Pickup Group в настройках номера. ChanSpy 555 Очень – очень удобная функция ? Позволяет слушать разговоры сотрудников, при этом, давая подсказки абоненту своей сети, которые не услышит звонящий из города. Это удобно, если вы обучаете нового сотрудника, и, при его общении с клиентом хотите подсказать ему какие-то нюансы в режиме реального времени Directed Call Pickup ** Наберите сервисных код данной функции, а затем внутренний номер, с которого вы хотите перехватить вызов. Функция позволяет перехватывать вызовы с даже номеров, у которых не настроены общие Call Group и Pickup Group In-Call Asterisk Attended Transfer *2 Данная фича позволяет совершить консультативный трансфер вызова, т.е трансфер, при котором оператор изначально дозванивается до абонента, на которого необходимо перевести вызов, говорит с ним, а затем уже соединяет звонящего с этим абонентом. In-Call Asterisk Blind Transfer ## Наберите данный код, чтобы осуществить «слепой», то трансфер, без предварительной консультации. In-Call Asterisk Disconnect Code ** Моментальный сброс входящего звонка. In-Call Asterisk Toggle Call Recording *1 По факту, данный сервисный код активирует запись звонка «по требованию». В мире, данный вид записи известен как On Demand или Prerecording. Запись по требованию означает то, что по умолчанию, вызов не записывается, но, если появляется необходимость записать разговор, достаточно просто нажать указанный сервисный код. Simulate Incoming Call 7777 IP – АТС Asterisk производит тестовый входящий вызов на внутренний номер User Logoff *12 Этот код позволяет разлогиниваться пользователю с телефона. Данная опция доступна только если АТС настроена для использования Device & User Mode. User Logon *11 Позволяет произвести логин пользователю в случае, который описан выше ZapBarge 888 Данный код позволяет пользователю мониторить аудио на драйверах интерфейса Е1, то есть на Zaptel или Dahdi драйверах. Коды управления режимом «Не беспокоить (DND)» Название Код Описание DND Activate *78 Данный сервисный код ставит внутренний номер в состояние «Не беспокоить» (Do Not Disturb). Это означает, что все звонящие на номер абоненты будут либо слышать сигнал занято, либо будут отправлены на голосовую почту. DND Deactivate *79 Выключает режим DND на номере DND Toggle *76 Включает/выключает возможность активации DND для внутреннего номера Прочие коды Call Flow Control Данный код позволяет управлять настройками в модуле Call Flow Control Dictate Название Код Описание Email completed dictation *35 Данный код позволяет записать сообщение и отправить его в виде вложения на электронную почту, следуя подсказкам автоинформатора. Perform dictation *34 Запись голоса, затем ввод имени для файла и сохранение его в файловой структуре IP - АТС Follow Me Название Код Описание Findme Follow Toggle *21 Код позволяет включать или выключать настройки Follow Me для внутреннего номера. Информационные сервисы Название Код Описание Call Trace *69 Система озвучивает CallerID последнего звонящего на данный внутренний номер. Echo Test *43 Данная функция используется для проверки качества связи, в том числе микрофона, динамика аппарата и так далее. Speak Your Exten Number *65 Система произносит настроенный на используемом телефонном аппарате внутренний номер. Speaking Clock *60 Система произносит текущее серверное время. Функции Paging (пейджинга) и Intercom (интеркома) Название Код Описание Intercom prefix *80 Данная функция необходимо для того, чтобы вместо обычного набора на номер, вы не дожидались гудков, а с помощью громкоговорителя произнесли сообщение. Вот пример, как это работает: Пользователь набирает данный сервисный код, а следом за ним внутренний номер. Далее, все последующие звонки на этот номер будут сразу приниматься без участия вызываемого абонента и по громкой связи звонящий сможет произнести свое сообщение. User Intercom Allow *54 Включить прием сообщений по интеркому (громкая связь, как описано выше). User Intercom Disallow *55 Отключает указанную выше функцию. Парковка вызова Название Код Описание Pickup ParkedCall Prefix *85 Когда администратор сконфигурировал слот для «парковки» (Parking) вызова, пользователь может «припарковать» этот вызов путем трансфера на номер паркинга – по умолчанию, это номер 70. Даже если данный слот занят, в настройка модуля Parking можно обозначить количество возможных слотов. Система автоматически запаркует вызов на доступный слот и произнесет его номер. Данный сервисный код как раз и отвечает за поднятие вызова с парковочного слота. Очереди Название Код Описание Allow Dynamic Members of a Queue to login or logout. See the Queues Module for how to assign a Dynamic Member to a Queue. *45 Данная опция позволяет динамическим участниками очередь подключаться и отключаться от нее Playback Queue Caller Count *47 Проговорить количество человек, находящихся в очереди Queue Pause Toggle *46 Взять паузу в очереди и не принимать вызовы. Повторная активация вернет пользователя в очередь. Временные условия (Time Conditions) Указанный сервисный код, а по умолчанию это *27 позволяет управлять настройками временного условия. В рамках системы для каждого нового Time Condition генерируется собственный сервисный код, который имеет формат *27X, где X – это номер временного условия. Голосовая почта (Voicemail) Название Код Описание Dial Voicemail *98 Набрав этот сервисный код будет предложено ввести номер голосового ящика и прослушать его. My Voicemail *97 Доступ к голосовому ящику, который относится к номера, с которого данный код набран (прослушивание собственных записей)
img
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа. Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из AS1 в AS2, а затем AS2 объявлял тот же самый маршрут обратно в AS1, как показано на рисунке. Хорошая новость заключается в том, что с настройками по умолчанию, скорее всего не будет проблем. Например, на приведенном выше рисунке роутер CTR2 узнал бы два способа добраться до Сети A. Один из способов — это через OSPF, к которому он подключен. Другой путь был бы через EIGRP AS, через роутер CTR1 и обратно в OSPF AS. Обычно, когда роутер знает, как добраться до сети через два протокола маршрутизации, он сравнивает значения административного расстояния (AD) протоколов маршрутизации и доверяет протоколу маршрутизации с более низким AD. В этом примере, хотя EIGRP AD обычно составляет 90, что более правдоподобно, чем OSPF AD 110, AD EIGRP External route (т. е. маршрута, который возник в другом AS) составляет 170. В результате OSPF-изученный маршрут CTR2 к сети A имеет более низкую AD (т. е. 110), чем AD (т. е. 170) EIGRP-изученного маршрута к сети A. Что в итоге? CTR2 отправляет трафик в Сеть A, отправляя этот трафик в OSPF AS, без необходимости передавать EIGRP AS. Время от времени, однако, нам потребуется произвести настройки некоторых не дефолтных параметров AD, или же нам понадобятся creative metrics, применяемые к перераспределенным маршрутам. В таких случаях мы подвергаемся риску развития событий, описанных на предыдущем рисунке. Давайте обсудим, как бороться с такой проблемой. Рассмотрим следующую топологию. В этой топологии у нас есть две автономные системы, одна из которых работает под управлением OSPF, а другая- под управлением EIGRP. Роутеры CTR1 и CTR2 в настоящее время настроены для выполнения взаимного перераспределения маршрутов между OSPF и EIGRP. Давайте взглянем на таблицы IP-маршрутизации этих магистральных роутеров. Обратите внимание, в приведенном выше примере, что с точки зрения роутера CTR2, лучший способ добраться до Сети 192.0.2.0 / 30 — это next-hop на следующий IP-адрес 192.0.2.5 (который является роутером OFF1). Это означает, что если бы роутер CTR2 хотел отправить трафик в сеть 192.0.2.0 /30, то этот трафик остался бы в пределах OSPF AS. Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в EIGRP AS, но этот маршрут считается EIGRP External route. Поскольку EIGRP External route AD 170 больше, чем OSPF AD 110, в OSPF маршрут прописывается в таблице IP-маршрутизации роутера CTR2. Именно так обычно работает Route redistribution, когда у нас есть несколько роутеров, выполняющих перераспределение маршрутов между двумя автономными системами. Однако, что мы можем сделать, если что-то идет не так, как ожидалось (или как мы хотели)? Как мы можем предотвратить перераспределение маршрута, перераспределенного в AS, из этого AS и обратно в исходное AS, например, в примере, показанном на следующем рисунке. В приведенном выше примере роутер OFF1 объявляет сеть 192.168.1.0 / 24 роутеру CTR1, который перераспределяет этот маршрут из AS1 в AS2. Роутер OFF2 получает объявление маршрута от роутера CTR1 и отправляет объявление для этого маршрута вниз к роутеру CTR2. Роутер CTR2 затем берет этот недавно изученный маршрут и перераспределяет его от AS2 к AS1, откуда он пришел. Мы, скорее всего, не хотим, чтобы это произошло, потому что это создает неоптимальный маршрут. Общий подход к решению такой проблемы заключается в использовании route map в сочетании с tag (тегом). В частности, когда маршрут перераспределяется из одного AS в другой, мы можем установить тег на этом маршруте. Затем мы можем настроить все роутеры, выполняющие перераспределение, чтобы блокировать маршрут с этим тегом от перераспределения обратно в его исходный AS, как показано на следующем рисунке. Обратите внимание, что в приведенной выше топологии, когда маршрут перераспределяется от AS1 к AS2, он получает тег 10. Кроме того, роутер CTR2 имеет инструкцию (настроенную в карте маршрутов), чтобы не перераспределять любые маршруты из AS2 в AS1, которые имеют тег 10. В результате маршрут, первоначально объявленный роутером OFF1 в AS1, никогда не перераспределяется обратно в AS1, тем самым потенциально избегая неоптимального маршрута. Далее давайте еще раз рассмотрим, как мы можем настроить этот подход к тегированию, используя следующую топологию. В частности, на роутерах CTR1 и CTR2 давайте установим тег 10 на любом маршруте, перераспределяемом из OSPF в EIGRP. Затем, на тех же самых роутерах, мы предотвратим любой маршрут с тегом 10 от перераспределения из EIGRP обратно в OSPF. Для начала на роутере CTR1 мы создаем карту маршрутов, целью которой является присвоение тегу значения 10. CTR1 # conf term CTR1 (config) # route-map TAG10 CTR1 (config-route-map) # set tag 10 CTR1 (config-route-map) #exit CTR1 (config) # Обратите внимание, что мы не указали permit как часть инструкции route-map, и мы не указали порядковый номер. Причина в том, что permit — это действие по умолчанию, и карта маршрута TAG10 имела только одну запись. Далее мы перейдем к роутеру CTR2 и создадим карту маршрутов, которая предотвратит перераспределение любых маршрутов с тегом 10 в OSPF. Кроме того, мы хотим, чтобы роутер CTR2 маркировал маршруты, которые он перераспределяет из OSPF в EIGRP со значением тега 10. Это означает, что мы хотим, чтобы роутер CTR1 предотвратил перераспределение этих маршрутов (со значением тега 10) обратно в OSPF. Итак, пока мы находимся здесь на роутере CTR1, давайте настроим route-map, которая предотвратит Route redistribution со значением тега 10 в OSPF. CTR1 (config) # route-map DENYTAG10 deny 10 CTR1 (config-route-map) # match tag 10 CTR1 (config-route-map) # exit CTR1 (config) # route-map DENYTAG10 permit 20 CTR1 (config-route-map) # end CTR1 # Эта недавно созданная route-map (DENYTAG10) использует ключевые слова permit и deny, и у нее есть порядковые номера. Порядковый номер 10 используется для запрещения маршрутов с тегом 10. Затем имеем следующий порядковый номер (который мы пронумеровали 20), чтобы разрешить перераспределение всех других маршрутов. Теперь, когда мы создали наши две карты маршрутов, давайте применим TAG10 route map к команде EIGRP redistribute (к тегу routes, перераспределяемому в EIGRP со значением 10). Кроме того, мы хотим применить DENYTAG10 route map к команде OSPF redistribute (чтобы предотвратить перераспределение маршрутов, помеченных значением 10, обратно в OSPF AS). CTR1 # conf term CTR1 (config) # router eigrp 100 CTR1 (config-router) # redistribute ospf 1 route-map TAG10 CTR1 (config-router) # router ospf 1 CTR1 (config-router) # redistribute eigrp 100 subnets route-map DENYTAG10 CTR1 (config-router) # end CTR1 # Теперь нам нужно ввести зеркальную конфигурацию на роутере CTR2. CTR2#conf term CTR2(config)#route-map TAG10 CTR2(config-route-map) # set tag 10 CTR2(config-route-map) # exit CTR2(config)#route-map DENYTAG10 deny 10 CTR2(config-route-map) # match tag 10 CTR2(config-route-map) # exit CTR2(config) # route-map DENYTAG10 permit 20 CTR2(config-route-map) # exit CTR2(config) # router eigrp 100 CTR2(config-router) # redistribute ospf 1 route-map TAG10 CTR2(config-router) # router ospf 1 CTR2(config-router) # redistribute eigrp 100 subnets route-map DENYTAG10 CTR2(config-router) # end CTR2# Просто чтобы убедиться, что наши маршруты помечены, давайте проверим таблицу топологии EIGRP роутера OFF2. Обратите внимание, что все маршруты, перераспределенные в EIGRP из OSPF, теперь имеют тег 10, и мы сказали роутерам CTR1 и CTR2 не перераспределять эти маршруты обратно в OSPF. Именно так мы можем решить некоторые потенциальные проблемы, возникающие при перераспределении маршрутов. Дело за малым - прочитайте нашу статью про route redistribution с помощью IPv6.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59