По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Nginx - это веб-сервер на базе Linux и прокси-приложение. Nginx - это мощный инструмент для перенаправления и управления веб-трафиком. Его можно легко настроить для перенаправления незашифрованного веб-трафика HTTP на зашифрованный HTTPS-сервер. Это руководство покажет вам, как перенаправить HTTP на HTTPS с помощью Nginx. Что нам потребуется Сервер Linux под управлением Nginx Учетная запись пользователя с привилегиями sudo Удаленный вход на веб-сервер (необязательно, требуется только в том случае, если вы не работаете непосредственно с веб-сервером) Доступ к терминалу/командной строке (Ctrl-Alt-T или Ctrl-Alt-F2) Редирект с HTTP на HTTPS Для принудительного перенаправления HTTP на HTTPS вам необходимо отредактировать файл конфигурации Nginx. В большинстве случаев вы можете найти этот файл в каталоге /etc/nginx/sites-available. Если не найдено, найдите его здесь: /etc/nginx/nginx.conf, /usr/local/nginx/conf или /usr/local/etc/nginx. Найдя файл конфигурации Nginx, откройте его в текстовом редакторе с помощью команды: sudo nano /etc/nginx/sites-available/server.conf Замените местоположение фактическим местоположением и именем вашего файла конфигурации. Когда файл конфигурации будет открыт для редактирования, вставьте один из блоков кода ниже. Как только вы закончите редактирование, сохраните файл и выйдите. Затем перезапустите службу Nginx с помощью следующей команды: sudo service nginx restart Перенаправить весь HTTP-трафик на HTTPS Откройте файл конфигурации Nginx для редактирования, затем вставьте следующий код: server { listen 80 default_server; server_name _; return 301 https://$host$request_uri; } Вот разбивка команд: Listen 80: Это дает команду системе перехватывать весь HTTP-трафик через порт 80 Server_name _ ;: Это будет соответствовать любому имени хоста Return 301: Это говорит браузеру и поисковым системам, что это постоянное перенаправление https://$host$request_uri: Это короткий код для указания версии HTTPS того, что набрал пользователь После редактирования весь трафик сервера HTTP по умолчанию перенаправляется на HTTPS. Примечание: Это должен быть единственный блок сервера, прослушивающий порт 80. Блок сервера - это единица кода конфигурации в Nginx. Он помечен именем и фигурными скобками. Перенаправить определенный сайт У вас может быть несколько серверов, но только некоторые из них могут требовать HTTPS. Укажите имя сервера в блоке сервера для перенаправления выбранного трафика: server { listen 80 default_server; server_name my_app.com; return 301 https://my_app.com$request_uri; } Замените имя my_app.com на имя сервера, который вы собираетесь перенаправить. Вы также можете добавить дополнительные сайты, добавив еще один блок сервера. Просто скопируйте код и измените имя сервера. Принимать только SSL-соединения Добавьте этот код, чтобы убедиться, что сервер будет принимать только SSL-соединения через порт 443: server { listen 443 ssl default_server; server_name my_app.com; } server { listen 443 ssl; server_name my_website.com; } Этот блок кода настроит два веб-сайта, my_app.com и my_website.com, на прием только SSL-соединений. Вы можете добавить дополнительные сайты, используя дополнительные блоки серверов. Редирект страниц Вы можете использовать rewrite для быстрого управления 301 (постоянным) или 302 (временным) перенаправлением: Location /index.html { rewrite ^/oldURL$ https://www.your_domain.com/newURL redirect; } В большинстве случаев это будет index.html, но вы можете указать любой путь или шаблон. Обратите внимание, что команда rewrite должна использоваться только с перенаправлениями 301 или 302. Как перенаправить домен с помощью Nginx Это полезно, если вы сменили домен (например с .org на .com). Nginx также можно использовать для перенаправления со старого доменного имени на новое доменное имя. server { listen 80; listen 443 ssl; server_name www.old_company.com; return 301 $scheme://www.new_company.com$request_uri; } В большинстве случаев команда return предпочтительнее команды rewrite. Редирект с сайта www на сайт без www Этот процесс аналогичен стандартному перенаправлению страницы: server { server_name www.new_company.com; return 301 $scheme://new_company.com$request_uri; } Причины для перенаправления трафика Есть несколько причин для перенаправления HTTP-трафика на HTTPS: Принудительное установление более безопасного зашифрованного соединения. Сохранение страницы с хорошим SEO-рейтингом, но перенаправление своего трафика на новую страницу. Уведомлять и временно отправлять трафик на страницу «на обслуживании». Постоянно отправлять трафик с одного сайта на другой, например после корпоративного слияния. Заключение Теперь вы знаете, как перенаправить HTTP на HTTPS в Nginx. Редактируя файл конфигурации, вы можете отправлять трафик из определенного места назначения на другой сайт и принудительно использовать сертификаты SSL. Это поможет вам безопасно управлять изменениями на вашем сайте, не нарушая пользовательский опыт.
img
Наверняка кто-то из вас хоть раз в жизни получал SMS после звонка в определенную компанию. Обычно, это просьба оценить работу операторов. Так, например, это сделано у GSM операторов. Также это может быть SMS с благодарностью за обращение от компании или же об актуальных акциях и предложениях. Сегодня я хотел бы рассказать о том, как Вы можете реализовать подобную функцию с использованием FreePBX Статья написана по мотивам существующей на данном ресурсе публикации "Оценка оператора после звонка" У данного метода есть один недостаток - для его работы нужен chan_dongle и тариф с безлимитными SMS. Для тех, у кого нет пресловутого chan_dоngle, есть другой метод, который я постараюсь объяснить. Для особо нетерпеливых прошу Вас заглянуть в контакты, возможно, я уже там появился :) В данном методе мы не будем ломать диалплан FreePBX и использовать тяжелую артиллерию в виде MySQL. Итак, приступим. Для начала открываем конфигурационные файлы, а именно: /etc/asterisk/extensions_custom.conf Вносим в него такой кусочек диалплана. В коде я дал комментарии зачем нужны некоторые части: [send-sms] exten => _.,1,NoOp(Start sms) exten => _.,n,DIAL(SIP/${EXTEN},,trg) ;опция g позволяет "проваливаться вниз". ВНИМАНИЕ агент должен использовать вашу технологию (sip или pjsip) exten => _X.,n,GotoIf($[${DIALSTATUS}=BUSY]?busy:answered) //проверяем, был ли отвечен вызов, вот здесь мы или пропускаем клиента дальше если с ним уже говорили или нет. exten => _X.,n(busy),Hangup() exten => _X.,n(answered),Goto(sms,${EXTEN},1) [sms] exten => _X.,1,NoOp(Statrt SendSms) exten => _X.,n,Answer() same => n,Set(COUNT=1); установка счетчика. По идее, он тут не нужен, но сделан на всякий аварийный случай. Вдруг заклинит и клиента заспамит смс? :) same => n,Set(RECIVER=Имя донгла в системе); если используете донгл same => n,Set(RECIPIENT=${CALLERID(num)}) same => n,Set(TEXT="Спасибо что обратились в нашу компанию Рога и копыта"); текст смс same => n,GotoIf($["${RECIPIENT:0:2}" != "79"]?end); это проверка на принадлежность к мобильным номерам. Уточните формат входящих CALLERID(num) на вашей АТС - с 7 или 8? same => n,System(/usr/sbin/asterisk -rx 'dongle sms ${RECIVER} 7${RECIPIENT:1} ${TEXT}'); тут отправка с донгла. same => n,Set(COUNT=$[${COUNT} + 1]); увеличение счетчика (который не нужен, а вдруг) same => n,GotoIf($["${COUNT}" > "1"]?end); проверка и отправка на завершение exten => _X.,n(end),Goto(macro-hangupcall,s,1); Конец Обратите внимание на пометки в диалплане. В частности, Агент должен использовать вашу технологию подключения. Входящие форматы на ваши транки, 7 или 8. Если он еще не унифицирован, то рекомендую это сделать и привести в норму стандарта E164. Если входящие у вас содержат + то, вместо ${RECIPIENT:0:2} сделайте ${RECIPIENT:0:3} На этом, настройка конфигурационного файла extensions_custom.conf закончена. Теперь открываем файл queues_post_custom.conf и вставляем туда такую строку: member=Local/4015781@send-sms/n,0,4015781,hint:4015781@ext-local Где 4015781 номер существующего Агента в очереди. После этого, закрываем файл, перезагружаем диалплан командой dialplan reload и тестируем. Применять можно, например, для отправки благодарности клиенту с напоминанием времени работы или адреса компании. Чтобы не огорчить тех, кто не использует донглы или использует GoIP или другие Gsm шлюзы, на мой взгляд, есть более "красивый" метод: Идем в один из множества веб сервисов для SMS рассылок (названия писать не буду), регистрируемся у них и берем их готовые библиотеки для доступа к API. Я покажу на примере PHP API одной известной компании: #!/usr/bin/php -q <?php #парсим данные из AGI require(′phpagi.php′); $agi = new AGI(); $phone = $agi->request[′agi_arg_1′]; text = $agi->request[′agi_arg_2′]; $sender = ′INFORM′; // !!! Замените API-ключ на свой. $apikey = ′XXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZ′; $url = ′https://smspilot.ru/api.php′ ′?send=′.urlencode( $text ) .′&to=′.urlencode( $phone ) .′&from=′.$sender .′&apikey=′.$apikey .′&format=json′; $json = file_get_contents( $url ); echo $json.′′; $j = json_decode( $json ); if ( !isset($j->error)) { echo ′SMS успешно отправлена server_id=′.$j->send[0]->server_id; } else { trigger_error( $j->description_ru, E_USER_WARNING ); } Используем AGI. И в представленном диалплане меняем одну строку, а именно: same => n,System(/usr/sbin/asterisk -rx 'dongle sms ${RECIVER} ${TEXT}'); тут отправка с донгла. на: same => n,AGI(sendsms.php, 7${RECIPIENT:1}, "${TEXT}") И на этом - все. Чем данный способ лучше? Могу точно сказать, что в подобных сервисах для компаний есть возможность в качестве отправителя зарегистрировать название организации – это явно плюс в копилку лояльности клиента :) Это значит, что не нужен донг и SMS клиенту приходит не с безликих цифр, а от имени вашей компании в поле отправитель. Это, безусловно, повышает доверие и лояльность получателя SMS. Надеюсь, что данный метод будет полезен и найдёт применение в ваших бизнес-процессах. Удачи!
img
Kubernetes и Red Hat OpenShift сегодня являются двумя ведущими инструментами оркестрации контейнеров на рынке. В этой статье мы обсудим эти инструменты и различия между ними. Большинство производственных сред начали использовать контейнеры, поскольку они легко масштабируемы, экономичны, лучше, чем виртуальные машины, и быстрее развертываются. Конечно, проще работать с 10-20 контейнерами, но представьте, если ваша производственная среда кластера Kubernetes имеет сотни контейнеров. Управление жизненным циклом контейнера с параллельным запуском нескольких контейнеров становится сложной задачей. Поэтому для управления всем автоматизированным развертыванием, масштабированием, организацией и управлением контейнерами необходима платформа/инструмент для управления контейнерами. Сравнение Kubernetes с OpenShift было бы несправедливым, поскольку эти инструменты оркестровки контейнеров представляют собой два разных проекта. Kubernetes - проект с открытым исходным кодом, в то время как OpenShift - продукт предлагаемый Red Hat. Сравнивать Kubernetes с OpenShift - все равно что сравнивать двигатель автомобиля с автомобилем. Это связано с тем, что сам Kubernetes является основной частью общей архитектуры OpenShift. Сначала кратко разберемся, что такое Kubernetes и OpenShift. Что такое Kubernetes? В настоящее время Kubernetes является наиболее популярным инструментом оркестровки контейнеров с открытым исходным кодом и широко используется для автоматического развертывания и масштабирования контейнеров. Этот инструмент с открытым исходным кодом был создан в 2014 году компанией Google и разработан облачным вычислительным фондом с использованием языка программирования Go. Kubernetes имеет архитектуру master-slave, в кластере Kubernetes есть главный узел и множество рабочих узлов. Внутри каждого рабочего узла будет работать несколько деталей, которые представляют собой не что иное, как группу контейнеров, объединенных как рабочая единица. Kubernetes использует YAML для определения ресурсов, отправляемых на сервер API для создания самого приложения. Преимущества Kubernetes Поскольку Kubernetes имеет открытый исходный код, он может свободно использоваться для любой платформы Имеет огромное активное сообщество разработчиков и инженеров, что помогает непрерывно разрабатывать новые функции Для избегания простоев вы можете легко выполнить откат или новое развертывание Для распределения сетевого трафика он предлагает возможности балансировки нагрузки Он поддерживает различные языки и структуры программирования, что обеспечивает гибкость для разработчиков и администраторов Kubernetes помогает очень эффективно использовать ресурсы инфраструктуры и сокращать общие затраты Она поставляется с панелью мониторинга по умолчанию, которая предлагает кучу информации, достаточной, чтобы следить за состоянием кластера. Red Hat OpenShift OpenShift - контейнерная платформа корпоративного уровня, разработанная Red Hat. Написан на языках программирования Go и AngularJS, а первоначальный релиз вышел в 2011 году. Red Hat OpenShift можно использовать как для облачных, так и для традиционных приложений. За кулисами Red Hat OpenShift работает Kubernetes, что позволяет запускать приложения внутри контейнеров. OpenShift поставляется с панелью веб-интерфейса и CLI, которая помогает разработчикам и программистам создавать свои коды приложений. Это также позволяет инженерам DevOps управлять и контролировать кластер Kubernetes. Преимущества Red Hat OpenShift: Поддерживает инициативу открытых контейнеров (OCI - open container initiative) для размещения контейнеров и среды выполнения Содержит множество исправлений проблем безопасности, дефектов и производительности Может быстро и гибко создавать и развертывать приложения Легко интегрировать со многими другими инструментами DevOps Проверяет несколько подключаемых модулей сторонних производителей для каждой версии Использование унифицированной консоли на Red Hat позволяет быстро внедрять и применять политики Поддерживает Prometheus и Grafana, что помогает в мониторинге кластера Его можно легко использовать с любым поставщиком облачных технологий или в локальной среде. OpenShift против Kubernetes 1. Открытый исходный код по сравнению с коммерческим Наиболее фундаментальное отличие Kubernetes от OpenShift заключается в том, что Kubernetes - проект с открытым исходным кодом, а OpenShift - коммерческий продукт корпоративного уровня. Это означает, что Kubernetes является самоподдерживаемым инструментом. В случае, если в этом инструменте выявлена какая-либо проблема или ошибка, люди обращаются к сообществу Kubernetes, которое состоит из многих разработчиков, администраторов, архитекторов и т. д. В то время как в OpenShift вы получаете хороший платный вариант поддержки для устранения любой проблемы с этой подпиской на продукт Red Hat. Подписка OpenShift позволяет управлять общедоступной, частной и виртуальной инфраструктурой с помощью Red Hat CloudForms. 2. Развертывание Развертывание приложения в производственной среде является решающим этапом процесса DevOps, и OpenShift делает его очень простым. Он автоматически выполняет каждый шаг от разработки до развертывания, поэтому вам не нужно беспокоиться о каждом шаге в конвейере CI/CD, чтобы сделать все вручную. Даже будучи новичком, вы будете чувствовать себя очень комфортно, используя OpenShift при конвеерном развертывания приложений. В OpenShift развертывание выполняется с помощью команды DeploymentConfig. С другой стороны, развертывание в Kubernetes сложнее и часто выполняется только экспертом. Необходимо настроить каждый шаг конвейера для развертывания приложения вручную. В случае развертывания приложений в Kubernetes используются объекты развертывания и могут обрабатывать несколько параллельных обновлений. 3. Управление В Kubernetes можно управлять кластером с помощью панели мониторинга по умолчанию. Но из-за его ограниченных возможностей и базового пользовательского интерфейса, по мере роста размера кластера, чтобы легко управлять кластером вам придется добавить более расширенные инструменты, такие как Istio, Prometheus, Grafana. Red Hat OpenShift предоставляет удобную панель управления кластером. Веб-консоль OpenShift предоставляет возможности для выполнения некоторых расширенных операций в кластере для улучшения управления. OpenShift также предлагает интегрировать кластер со стеком EFK и Istio. И, наконец, доступные в OpenShift плейбуки Ansible и установщик помогают плавно управлять кластером. 4. Масштабируемость Независимо от того, является ли кластер виртуализированным или он развернут на голом железе, в нем будет несколько виртуальных машин. В Kubernetes добавление виртуальных машин занимает много времени. Он требует от разработчиков создания для него сценариев YAML. Тогда как в OpenShift масштабирование выполняется без особых усилий. OpenShift позволяет быстрее выводить виртуальные машины в кластер с помощью доступных установщиков и плейбуков Ansible. Кроме того, процесс масштабирования в OpenShift тоже прост. 5. Гибкость Kubernetes поставляется с большой гибкостью, так как нет фиксированного способа работы с ним. Для запуска Kubernetes можно использовать любую операционную систему с большими ограничениями. Kubernetes помогла многим организациям выйти из устаревших архитектур, поскольку они не отвечали текущим потребностям рынка. При работе с OpenShift нельзя использовать все операционные системы. В OpenShift можно использовать только дистрибутивы Red Hat, FedoraOS и CentOS. 6. Безопасность Политики безопасности в OpenShift строже по сравнению с Kubernetes. Например, OpenShift не позволяет запускать контейнеры как корневые. Это также ограничивает использование пользователями многих официальных образов, представленных на DockerHub. Итак, во время работы с OpenShift сначала нужно будет узнать о его политиках безопасности. Но из-за этих ограничений, возможности аутентификации и авторизации в OpenShift более надежны, чем Kubernetes. В то время как в Kubernetes настройка надлежащей возможности аутентификации и авторизации потребует много усилий. В отличие от OpenShift, кластеры Kubernetes могут иметь много уязвимых образов, если в кластер не интегрированы средства сканирования контейнеров. Kubernetes предлагает функции управления доступом на основе ролей (RBAC - role-based access control), но этого недостаточно для расширенного уровня безопасности, необходимого в производственных средах. Так, по сравнению с OpenShift, в Kubernetes ещё предстоит сделать много улучшений в плане безопасности. 7. Веб-интерфейс Для выполнения всей работы по администрированию кластера необходим подходящий и простой в использовании веб-интерфейс, что и предлагает OpenShift. У него есть простая форма аутентификации для каждого пользователя. После входа пользователь получает полную визуализацию кластера, которую очень легко прочитать и понять. OpenShift имеет удобную веб-консоль, которая позволяет инженерам DevOps выполнять задачи Kubernetes, а операционным группам - комфортно контролировать приложение. Элемент управления имеет несколько возможностей типа построения, развертывания, обновления, масштабирования, раскрытия и т.д., которые могут быть реализованы одним нажатием кнопки. Kubernetes поставляется с базовой панелью управления, которая может помочь только с основными задачами. Кроме того, панель мониторинга не очень удобна для пользователей по сравнению с другими панелями мониторинга, доступными на рынке. Именно поэтому инженеры DevOps предпочли бы интегрировать инструментальную панель Kubernetes по умолчанию с другими инструментами визуализации, такими как Prometheus и Grafana. Подводя итог, приведем таблицу различий между Red Hat OpenShift и Kubernetes: ОтличияKubernetesOpenShiftРазработчикCloud-Native Computing FoundationRed Hat SoftwareДата первого релиза7 июня 20144 мая 2011Язык программированияGoGo, Angular, JSУправлениеСложное управления контейнерамиИспользование ImageStreams для упрощения управления несколькими контейнерамиРазвертываниеПоддерживает все облачные и Linux платформыПоддерживает только дистрибутивы на базе RedHat: CentOS и FedoraГибкостьС открытым исходным кодом, соответственно гибкийОграниченная гибкостьБезопасностьМожно легко управлять уровнем безопасностиСтрогие политики безопасностиСетевая поддержкаЕму не хватает хорошего сетевого решения, но он позволяет добавлять сетевые плагины сторонних производителей.Поставляется с собственным сетевым решениемОбучениеСложен для начинающих, больше подходит для профессиональных DevOpsПодходит для начинающих Заключение Все дело было в Kubernetes, OpenShift и их различиях. Обе платформы оркестрации контейнеров востребованы в ИТ-отрасли. Таким образом, в зависимости от ваших требований, вы можете выбрать наиболее подходящую платформу оркестрации контейнеров для вашей организации. Если вам нужна гибкость с вашими проектами, то скорее всего должны выбрать Kubernetes. Но если вы можете следовать определенному подходу и хотите использовать платформу оркестрации контейнеров с простотой развертывания и управления, OpenShift - лучший выбор. Так же если вы уже опытный DevOps и хотите попробовать что-то новое, то можно попытаться перейти на Kubernetes. Если же делаете первые шаги на поприще DevOps, выберите OpenShift, так как он сделает большую часть дел за вас.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59