Apache server: The Apache HTTP Server Project

Веб-сервер Apache

/ АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps: + DevOps + Frontend — Apache web-server | Почерпнуть мудрость | Основная информация | Конфигурирование | Механизм виртуальных хостов + Регулярные выражения + git + Javascript + Perl + Python + Ruby + Rust + Полезности в Windows + Linux GAMING БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ

Веб-сервер Apache

last update: 17-09-2022, 16:25 UTC

Почерпнуть мудрость

• https://ru.wikipedia.org/wiki/Apache_HTTP_Server
• https://devdocs.io/apache_http_server/ — guides, docs
• https://apache.org/
• Настройка HTTP/2 на примере Apache 2.4, PHP 7 и Ubuntu 18.04 LTS

Основная информация

Apache HTTP-сервер — свободный веб-сервер. позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPv6.

Веб-сервер

Установка: sudo apt-get install apache2

Конфигурирование

• Конфигурация сервера (httpd.conf)
  …
• Конфигурация уровня директории (.htaccess)
  25 правил .htaccess, которые должен знать каждый web-разработчик
  …
• Часть модулей использует в своей работе конфигурационные файлы операционной системы (например /etc/passwd и /etc/hosts)
  …

Механизм виртуальных хостов

Apache имеет встроенный механизм виртуальных хостов. Он позволяет полноценно обслуживать на одном IP-адресе множество сайтов (доменных имён), отображая для каждого из них собственное содержимое.

Для каждого виртуального хоста можно указать собственные настройки ядра и модулей, ограничить доступ ко всему сайту или отдельным файлам. Некоторые MPM, например Apache-ITK позволяют запускать процесс httpd для каждого виртуального хоста с отдельными идентификаторами uid и guid.

Примитивный пример.

1. Создать файл с конфигурацией Apache для хоста проектаsudo nano /etc/apache2/sites-available/project.confстроки: <VirtualHost *:80> ServerName project.dev ServerAdmin webmaster@localhost DocumentRoot /home/username/project <Directory /home/username/project > AllowOverride all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>
2. Создать файл с конфигурацией Apache для хоста другого проектаsudo nano /etc/apache2/sites-available/project2.confстроки:<VirtualHost *:80> ServerName project2.dev ServerAdmin webmaster@localhost DocumentRoot /home/username/projectother <Directory /home/username/projectother > AllowOverride all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access. log combined </VirtualHost>
3. Добавить в список хостов sudo nano /etc/hosts строки: 127.0.0.1 project.dev
   127.0.0.1 project2.dev
4. Активация (enable) созданных конфигураций Apache для наших проектовsudo a2ensite project
   sudo a2ensite project2 Примечание: деактивация делается командой a2dissite
5. Перезапуск Apachesudo /etc/init.d/apache2 restart
6. Всё, теперь мы можем заходить на project.dev/ и project2.dev/ с локалки.
   Примечание: если хотим дать возможность заходить к нам на машину извне — то в файл .conf нужно добавить строку Listen 80, например.

Проксирование серверных приложений Atlassian с помощью HTTP-сервера Apache (mod_proxy_http)

Приложения Atlassian позволяют использовать обратные прокси с нашими продуктами, однако Atlassian Support не предоставляет помощь для их настройки. Следовательно, Atlassian не может гарантировать поддержку для них.

Если требуется помощь в настройке, задайте вопрос об ответах Atlassian.

На этой странице объясняется, как установить топологию сети, в которой Apache HTTP Server действует как обратный прокси-сервер для серверных приложений Atlassian. Страница написана как рецепт успеха — мы рекомендуем вам следовать ей шаг за шагом.

Вы можете использовать обратный прокси-сервер, если хотите, чтобы пользователи обращались к приложениям Atlassian:

• в своих собственных доменах, таких как http: // my <atlassianapp> .com /
• в поддоменах другого домена, например http: // my <atlassianapp> .ourcompany.com /
• в контекстных путях либо в домене, либо в поддомене, например, http://ourcompany.com/my <atlassianapp>
• на разных HTTP-портах, таких как 9800, 9850 и т. д.

Для более сложных сценариев вы можете обратиться к документации сервера HTTP Apache, проконсультироваться с специалистом Apache в вашей организации, задать вопрос об ответах Atlassian или связаться с одним из наших экспертов Atlassian.

Инструкции на этой странице относятся к следующим серверным приложениям Atlassian:

• Серверные приложения JIRA (JIRA Software Server, JIRA Core, JIRA Service Desk)
• Confluence Server (в этом руководстве приведены некоторые дополнительные шаги и примеры для Confluence 6.0 и более поздних версий)
• Сервер Bamboo
• Сервер Bitbucket
• FishEye
• Crucible
• Crowd

В следующих примерах на этой странице <atlassianapp> ссылается на имя любого из приложений сервера Atlassian  выше.

Серверные приложения Atlassian объединяют веб-сервер, который позволяет им запускаться без использования прокси-сервера. Для большинства атласских приложений связанным веб-сервером является Apache Tomcat (FishEye и Crucible использующего — Jetty). Следовательно, вам необходимо настроить Tomcat (или Jetty при использовании FishEye или Crucible) и Apache HTTP Server при проксировании приложения Atlassian.

На этой странице

Предпосылки

Вам понадобится следующее:

Установленная версия 2.

Возможно, вам будет полезно обратиться к документации по серверу HTTP Apache, в которой описывается, как вы можете управлять HTTP-сервером Apache, редактируя файл httpd.conf.

Раздел модуля Apache mod_proxy особенно важен. Обратите внимание, что любые изменения, внесенные вами в файл httpd.conf, будут эффективны только после перезапуска Apache HTTP Server. (Приложения, использующие Synchrony, например Confluence 6.0, должны использовать Apache 2.4.10 и выше.)

Записи DNS и настройки для ваших доменов

Вы должны проверить, возможно, с вашим системным администратором или сетевым администратором, нужны  ли изменения в текущей конфигурации DNS для вашей организации  для поддержки топологии прокси, которую вы хотите настроить.

Приложения Atlassian установлены и доступны через веб-браузер

Установите приложения Atlassian обычным способом.

Часть A. Настройка атласских приложений

1. Остановить применение Atlassian

Остановка приложения также останавливает Tomcat.

2.Задайте путь контекста

Этот шаг требуется только в том случае, если вы хотите, чтобы приложение было доступно для доступа к контексту, например, http://ourcompany.com/ <contextpath>. Если это не требуется, вы можете пропустить этот шаг.

FishEye  и Crucible

Если вы проксимируете FishEye или Crucible, настройте  контекстный  веб-путь для Jetty из области администрирования. См. Настройка веб-сервера FishEye.

Приложения JIRA, Confluence, Bitbucket Server, Bamboo

Если вы проксируете любое из этих серверных приложений Atlassian, настройте путь контекста в файле Tomcat server.xml следующим образом.

Местоположение файла server.xml зависит от вашего приложения, операционной системы и места установки.

Обычными местами установки по умолчанию для приложений Atlassian являются:

Linux: / opt / atlassian / <имя-приложения>

Windows: C: \ Program Files \ Atlassian \ <имя-приложения>

Windows: C: \ Atlassian \ <имя-приложения>

Расположение в структуре папок приложения Atlassian:

<install-path> обозначает, где приложение было установлено в вашей системе.

Если вы настраиваете Bitbucket Server 5.0

Начиная с Bitbucket Server 5.0, вы не можете напрямую конфигурировать коннекторы Tomcat, поэтому конфигурации в этом разделе применимы только для сервера Bitbucket 4.14 или ранее.

Конфигурации server.xml были заменены на <Bitbucket home directory> /shared/bitbucket.properties

Прочитайте Перемещение сервера Bitbucket на другой контекстный путь  для Bitbucket Server 5.0 и более поздние конкретные инструкции.

В файле конфигурации Tomcat server.xml для всех приложений, кроме Crowd, найдите директиву Context, которая выглядит так:

Context path="" docBase="${catalina.home}/atlassian-<atlassianapp>" reloadable="false" useHttpOnly="true">

Измените директиву, чтобы добавить новый контекстный путь:

<Context path="/<contextpath>" docBase="${catalina.home}/atlassian-<atlassianapp>" reloadable="false" useHttpOnly="true">

Используйте свое значение для <contextpath>. Как правило, каждое приложение будет использовать другой контекстный путь .

Важно, что значение пути имеет ведущую косую черту (/), такую как path = «/ <contextpath>», а не path = «<contextpath>».

Используйте эти инструкции для удаления контекста «crowd» из URL-адреса приложения

3. Настройте директиву коннектора

Если вы используете FishEye или Crucible, настройте прокси-хост, прокси-схему и прокси-порт из области администрирования. См. Настройка веб-сервера FishEye.

Если вы настраиваете Bitbucket Server 5.0

Начиная с Bitbucket Server 5.0, вы не можете напрямую конфигурировать коннекторы Tomcat, поэтому конфигурации в этом разделе применимы только для сервера Bitbucket 4.14 или ранее.

Конфигурации server.xml были заменены на <Bitbucket home directory> /shared/bitbucket.properties

Прочтите Мигрирование настроек  server.xml в bitbucket.properties, чтобы проверить соответствующие свойства и перевести приведенную ниже конфигурацию. По завершении сопоставления с bitbucket.properties перейдите в раздел B. «Настройка HTTP-сервера Apache».

Если вы используете какие-либо другие серверные приложения Atlassian, настройте директиву Connector следующим образом.

Для каждого приложения найдите нормальную (не SSL) директиву Коннектора в файле Tomcat server.xml и добавьте атрибуты схемы,  proxyName и proxyPort в директиве Connector, как показано ниже. Используйте значения по умолчанию для других атрибутов, в том числе для порта, если у вас нет особых причин для их изменения, и используйте собственное доменное имя для значения proxyName:

<Connector port=<default>
maxThreads=<default>
minSpareThreads=<default>
connectionTimeout=<default>
enableLookups=<default>
maxHttpHeaderSize=<default>
protocol=<default>
useBodyEncodingForURI=<default>
redirectPort=<default>
acceptCount=<default>
disableUploadTimeout=<default>
proxyName="<subdomain>. <domain>.com"
proxyPort="80"
scheme="http"/>;

Обратите внимание, что для параметра proxyName должно быть установлено полное доменное имя (Fully Qualified Domain Name — «полностью определённое имя домена»), которое будет настроено для HTTP-сервера Apache. Это адрес, который пользователь вводит в свой браузер для доступа к приложению. Например:

• используйте <atlassianapp> .ourcompany.com для доступа к приложению в поддомене, например http: // <atlassianapp> .ourcompany.com
• используйте ourcompany.com для доступа к приложению в контексте пути, например http://ourcompany.com/ <atlassianapp>. В этом случае путь контекста не должен включаться в параметр proxyName, и вы уже установили директиву Context на шаге 2 выше.

Для получения дополнительной информации о настройке коннектора Tomcat см. Ссылку HTTP-коннектора Apache Tomcat 7.0.

Часть B. Настройка HTTP-сервера Apache

Atlassian рекомендует использовать модуль mod_proxy, который реализует прокси, шлюз или кеш для Apache, а также позволяет быть нескольким виртуальным хостам на одном клиенте.

Для получения дополнительной информации о mod_proxy см:

• На сайте mod_proxy_html есть документация и примеры.
• Учебник Apache Week, в котором описывается сложная ситуация с двумя приложениями и ProxyHTMLURLMap.

1. Включите модули mod_proxy в Apache

Если необходимо, включите необходимые модули в Apache следующим образом:

Распределения Debian и Ubuntu относятся к Apache как «Apache2», а файл конфигурации apache2.conf хранится в каталоге / etc / apache2 /.

Вы можете включить mod_proxy и поддерживающие модули из командной строки следующим образом:

$ sudo a2enmod proxy_http
Рассмотрение зависимостей прокси-сервера для proxy_http:
Включение прокси-сервера модуля.
Включение модуля proxy_http.
Чтобы активировать новую конфигурацию, вам необходимо запустить:
service apache2 restart

Fedora и CentOS 7 ссылаются на Apache как «httpd» и включают модули mod_proxy по умолчанию. При необходимости вы можете найти файлы конфигурации в каталогах / etc / httpd / conf /, /etc/httpd/conf. d/ и /etc/httpd/conf.modules.d/.

Для получения дополнительной информации о том, как обрабатываются файлы конфигурации, см.

• Fedora: https://docs.fedoraproject.org/en-US/Fedora/23/html/System_Administrator…
• CentOS 7: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7… (обратите внимание, что документация CentOS 7 недоступна.)

Если вы используете Confluence 6.0 или более позднюю версию с Synchrony (требуется для совместного редактирования), вам нужно будет использовать Apache 2.4.10 или новее, а также убедитесь, что модули mod_proxy_wstunnel и mod_rewrite включены.

Windows относится к Apache как «httpd», с конфигурационным файлом, хранящимся в папке \ conf \ httpd.conf.

Включите mod_proxy и поддерживающие модули в конфигурационном файле Apache httpd.conf, раскомментируя (то есть удалите ведущие «#») следующие строки, если необходимо:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect. so
LoadModule proxy_http_module modules/mod_proxy_http.so

Если эти строки не существуют в файле конфигурации, просто добавьте их.

Если вы используете Confluence 6.0 или более позднюю версию с Synchrony (требуется для совместного редактирования), вам нужно будет использовать Apache 2.4.10 или новее, а также включить модули mod_proxy_wstunnel и mod_rewrite.

2. Настройка виртуальных хостов с помощью mod_proxy

Если вы используете одно приложение Atlassian за обратным прокси-сервером Apache, используйте виртуальный хост-блок со следующими директивами:

<VirtualHost *:80>
    ServerName <subdomain>.<domain>.com
     
    ProxyRequests Off
    ProxyVia Off
     
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /<contextpath> http://<internal_domain>:<port>/<contextpath>
    ProxyPassReverse /<contextpath> http://<internal_domain>:<port>/<contextpath>
</VirtualHost>

• Обратите внимание, что для CentOS предпочтительным подходом является добавление блока виртуального хоста в отдельный файл конфигурации для каждого приложения в /etc/httpd/conf. d/, например, с именем confluence-vhost.conf и jira-vhost.conf.
• Обратите внимание, что для Debian предпочтительный подход заключается в добавлении блока виртуального хоста в отдельный файл конфигурации для каждого приложения в / etc / apache2 / sites-available / <site>, например, с именем confluence.conf и / или jira.conf. Они должны основываться на шаблоне по умолчанию, 000-default.conf.

Если у вас несколько приложений, работающих за одним и тем же прокси-сервером, вы можете использовать виртуальные хосты на основе имени:

• Используйте один виртуальный хост на основе имени, если приложения Atlassian находятся в одном домене, но имеют разные пути контекста. Например:

<VirtualHost *:80>
    ServerName mycompany.com
     
    ProxyRequests Off
    ProxyVia Off
     
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /jira http://<internal_domain>:8080/jira
    ProxyPassReverse /jira http://<internal_domain>:8080/jira
 
    ProxyPass /bitbucket http://<internal_domain>:7990/bitbucket
    ProxyPassReverse /bitbucket http://<internal_domain>:7990/bitbucket
</VirtualHost>

• Используйте несколько виртуальных хостов на основе имени, если каждое приложение находится в другом домене. Например:

<VirtualHost *:80>
    ServerName myjira.com
     
    ProxyRequests Off
    ProxyVia Off
     
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /jira http://<internal_domain>:8080/jira
    ProxyPassReverse /jira http://<internal_domain>:8080/jira
</VirtualHost>
 
<VirtualHost *:80>
    ServerName mybitbucket.com
     
    ProxyRequests Off
    ProxyVia Off
     
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /bitbucket http://<internal_domain>:7990/bitbucket
    ProxyPassReverse /bitbucket http://<internal_domain>:7990/bitbucket
</VirtualHost>

If you’re using Confluence 6.0 or later with Synchrony (which is required for collaborative editing),  you’ll need to use Apache 2.4.10 or later…

Используйте следующие директивы и блоки местоположения в блоке виртуального хоста:

Используйте директивы / местоположения в точном порядке, указанном ниже. WebSocket$ [NC] RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC] RewriteRule .* ws://<internal_domain>:8091%{REQUEST_URI} [P] </Location> ProxyPass / http://<internal_domain>:8090/ ProxyPassReverse / http://<internal_domain>:8090/ <Location /> Require all granted </Location> </VirtualHost>

Это базовый пример, когда доступ к Confluence осуществляется без контекстного пути и не использует внутренний прокси Confluence. См. «Администрирование совместного редактирования» для других параметров конфигурации прокси.

Для получения дополнительной информации о виртуальных хостах см. https://httpd.apache.org/docs/2.4/vhosts/.

Эти директивы внутри блока виртуального хоста выполняют следующие функции:

<VirtualHost *:80>

ServerName <subdomain>.<domain>.com

ProxyRequests Off

ProxyVia Off

<Прокси *>
Require all granted (Требовать все предоставленные)
</ Proxy>

<Прокси *>
Order Deny,Allow (Отменить заказ, разрешить) Allow from all  (Разрешить от всех) </ Proxy>

ProxyPass /<contextpath> http://<domain>:<port>/<contextpath>
ProxyPassReverse /<contextpath> http://<domain>:<port>/<contextpath>

ProxyPass        /<contextpath> http://example:8080/<contextpath>
ProxyPassReverse /<contextpath> http://example:8080/<contextpath>

ProxyPass        /<contextpath> http://private.example.com:9900/<contextpath>
ProxyPassReverse /<contextpath> http://private.example.com:9900/<contextpath>

3. Перезапустите Apache

Debian и Ubuntu

Перезапустите Apache из командной строки, используя:

$ sudo service apache2 restart

Fedora and CentOS

Перезапустите Apache из командной строки, используя:

$ sudo apachectl graceful

Вы также можете использовать systemd для перезапуска Apache. Например, в CentOS используйте:

$ sudo systemctl restart httpd.service

Windows

Вы можете остановить и запустить службу Apache, выбрав «Панель управления»> «Администрирование»> «Службы», найдите «Apache2» и выберите его. Теперь в строке меню выберите кнопку остановки (квадрат) и дождитесь, пока статус службы изменится на «Остановлен». Как только служба остановилась, выберите кнопку запуска (треугольник) и дождитесь, пока статус изменится на «Начать».

Для CentOS политика SELinux блокирует подключение httpd к сети по умолчанию. В этом случае вы увидите сообщение об отказе в доступе в httpd error_log, подобное этому:

[Sat Mar 19 00:29:45.722758 2016] [proxy:error] [pid 5958] (13)Permission denied: AH00957: HTTP: attempt to connect to 127.0.0.1:8090 (localhost) failed

Вам необходимо вручную изменить политику SELinux для процесса httpd, используя следующую команду:

$ sudo /usr/sbin/setsebool -P httpd_can_network_connect 1

5. Включите заголовок X-Forwarded-For

Это необязательный шаг, который гарантирует, что исходный IP-адрес (т.е. пользователь, подключающийся к прокси-серверу) отправляется в приложение Atlassian, а не через прокси-IP. Это полезно для отслеживания того, кто отправляет запросы, так как в противном случае обратный прокси-сервер может маскировать свой IP-адрес. Если это изменение будет выполнено, журналы доступа будут записывать IP-адрес клиента, а также прокси-сервер, а не только прокси-сервер. Для этого:

1. Включить модуль mod_remoteip.
2. Добавьте ниже соответствующий виртуальный хост:

RemoteIPHeader X-Forwarded-For

3. Перезапустите / перезагрузите Apache.

Часть C. Окончательная конфигурация

Перезапустите каждое приложение

Теперь перезапустите каждое приложение и убедитесь, что вы можете получить к ним доступ с использованием новых URL-адресов. См. Инструкции по остановке и запуску выше.

Задайте базовый URL приложения

Для каждого приложения Atlassian установите базовый URL-адрес для адреса, который вы настроили в прокси-сервере, который является URL-адресом, который будет обслуживать HTTP-сервер Apache (например, http://www.example.com/<atlassianapp>).

Отключить HTTP-сжатие

Запуск сжатия как для прокси, так и для Tomcat может вызвать проблемы при интеграции одного приложения Atlassian с другим. Мы рекомендуем отключить HTTP-сжатие для приложений JIRA и Confluence:

• Приложения JIRA — см. Настройка параметров приложения Jira.
• Confluence — см. «Сжатие HTTP-ответа в Confluence».

Что такое HTTP-сервер Apache и для чего он используется? — Видеоруководство по Apache

Из курса: Веб-сервер Apache: Администрирование

Что такое HTTP-сервер Apache и для чего он используется?

“

Существует ряд причин, по которым вы можете захотеть узнать об Apache. Например, ваша должностная обязанность может только что измениться, и внезапно от вас ожидают, что вы будете знать, как управлять веб-сервером. Может быть, вы обнаружили пыльный компьютер, работающий в шкафу, с приклеенной к нему запиской: «Не отключайте его от сети, иначе веб-сайт перестанет работать». Вы можете просто захотеть узнать больше об администрировании веб-сервера. Пути к обучению разнообразны, и нет неправильной причины. Цель этого курса — научить вас исследовать существующий веб-сервер Apache, чтобы узнать, как он настроен и как им управлять. Apache — это большая тема, поскольку это сложная система со множеством нюансов и конфигураций. И я не собираюсь исследовать каждый аспект. Вместо этого я собираюсь сосредоточиться на создании фундамента, на котором будут строиться знания. В этом курсе будут представлены практические прикладные методы работы с сервером, а не мелочи. Начиная с этой главы, мы собираемся изучить, что такое HTTP-сервер Apache и для чего он используется, а также общие способы установки Apache. И, наконец, как управлять самой службой. Начнем с самого начала. Что такое Апач? Apache HTTP Server — это приложение веб-сервера. Веб-сервер предоставляет контент, к которому можно получить доступ через Интернет. Сюда входят HTML-документы, мультимедиа, такие как изображения, таблицы стилей CSS и сценарии на стороне клиента, такие как JavaScript. Apache HTTP Server имеет открытый исходный код, что означает, что исходный исходный код находится в свободном доступе для совместной работы. Многие руки делают легкую работу, и сотни, если не тысячи, внесли свой вклад в код. Разрабатывается с 1995, Apache был основной технологией, ответственной за первоначальный рост всемирной паутины. Сегодня Apache обслуживает более 54% всех веб-сайтов, и на то есть веские причины. Он очень надежный, то есть может обрабатывать большие объемы трафика на одном сервере. Apache также может обслуживать множество различных типов контента с минимальной конфигурацией. Он действительно хорошо масштабируется. Таким образом, одно и то же предложение курса может обслуживать крошечные статические сайты с парой запросов в час для крупных корпоративных приложений с сотнями тысяч, если не миллионами посещений в день. Тот факт, что его можно использовать бесплатно, также положительно повлиял на его принятие. Apache — это модульная система, что означает, что функциональность может быть легко добавлена ​​к основному приложению. Модули инкапсулируют определенную группу функций, включая поддержку криптографических протоколов, таких как SSL, поддержку языков программирования на стороне сервера, таких как PHP, и балансировку нагрузки между несколькими серверами для обработки больших объемов трафика. Apache прошел через ряд основных версий. Важно знать, какая версия Apache используется, поскольку в разных версиях различаются как включенные функции, так и методы настройки. Версия 1.3 выпускалась с 1998 до 2010 года, когда он был снят с производства. Версия 2.0 была запущена в 2000 году и окончательно закрыта в 2013 году. Два пункта два были доступны с 2005 года и до сих пор поддерживаются. Два целых четыре десятых — это текущая основная версия, и она существует с 2009 года. Достаточно предыстории. Давайте посмотрим, с чем мы работаем. Первым шагом является включение виртуального устройства. Если он еще не запущен, откройте диспетчер виртуальных ящиков. Выберите Apache и нажмите «Пуск». Через мгновение или два сервер будет запущен и запущен. Давайте посмотрим на Apache в действии, переключившись на браузер. Перейдите к http локальному порту хоста 8080. Аккуратно. Нам подали классику Льюиса Кэрролла «Приключения Алисы в стране чудес», предоставленную Project Gutenberg. Мы знаем, что Apache работает, что является хорошим началом. Как узнать, как он был установлен?

Содержание

Advanced Load Balancer, веб-сервер и обратный прокси-сервер

Перейти к содержимому

class=»inner-wrap»>

Полное пошаговое руководство по построению эффективной архитектуры микросервисов, дополненное O’Reilly Media и NGINX.

Узнать больше

Эта бесплатная электронная книга O’Reilly с новыми и обновленными рецептами на 2022 год стала лучше, чем когда-либо. Получите образцы конфигураций NGINX для балансировки нагрузки, облачного развертывания, автоматизации, контейнеров и микросервисов, сервисной сетки, безопасности и многого другого.

Узнать больше

NGINX Sprint — это бесплатное виртуальное мероприятие, призванное вдохновить разработчиков, архитекторов и других лиц, стремящихся разрабатывать и выпускать современные приложения в больших масштабах.

Узнать больше

Повышение производительности, надежности и безопасности ваших приложений

• Доставка приложений

• Кубернетес

• API-соединение

• Безопасность приложений и API

Чтобы завершить миграцию в облако и закрыть устаревший центр обработки данных, Modern Hire должна была удовлетворить потребности финансового клиента в расширенной безопасности, включая разгрузку SSL, поддерживаемую аппаратным модулем безопасности (HSM), несмотря на зависимость от серверного программного обеспечения, не поддерживаемого его облаком. поставщик услуг HSM.

Узнайте, как компания Modern Hire использовала решение NGINX App Delivery для быстрого внедрения, снижения сложности и получения более детальной информации.

Центр компетенции Audi в области Kubernetes разработал Kubika O как независимую от облака платформу Kubernetes, функционирующую как бесшовная среда приложений. Большой проблемой перед запуском было решить, как все обезопасить. Audi требовалось проверенное решение WAF с сертифицированной функциональной совместимостью Red Hat OpenShift, а также надежная круглосуточная техническая поддержка.

Узнайте, как Audi использовала решение NGINX Kubernetes для обеспечения будущего своего технического видения Kubernetes и инноваций в приложениях.

Узнайте, как развернуть NGINX в любом облаке, устранить привязку к поставщику и снизить сложность. Цифровые компании полагаются на внутренние и внешние API, чтобы конкурировать. Доверьте NGINX Plus и NGINX Controller управление критически важными для бизнеса API и их защиту.

Узнайте, как Distil Networks предотвращает нарушения безопасности и ограничивает вредоносный трафик с помощью NGINX Plus и NGINX ModSecurity WAF. Сократите количество нарушений безопасности и ограничьте уязвимость вашей компании для злоумышленников с помощью NGINX Plus и NGINX App Protect.

Масштабируйте современные приложения с помощью F5 NGINX

Развертывайте приложения и API быстрее и с большей уверенностью, чем когда-либо прежде.

NGINX с открытым исходным кодом

Веб-сервер с открытым исходным кодом, на котором работает более 400 миллионов веб-сайтов.

NGINX Plus

Универсальный балансировщик нагрузки, обратный прокси-сервер, веб-сервер, кэш контента и шлюз API.

NGINX Management Suite

Видимость и контроль над экземплярами NGINX, службами доставки приложений, рабочими процессами управления API и решениями безопасности.

NGINX App Protect

Современный WAF и отказ в обслуживании для защиты приложений и API.

Контроллер входящего трафика NGINX

Управление трафиком Kubernetes с помощью шлюза API, функций идентификации и наблюдения.

NGINX Service Mesh

Удобное для разработчиков решение для обеспечения безопасности между сервисами, оркестровки, наблюдения и управления трафиком.

Модуль NGINX

Веб-сервер и сервер приложений с открытым исходным кодом.

NGINX Amplify

Мониторинг SaaS и статический анализ для NGINX Open Source и NGINX Plus.

Доверяют большему количеству самых загруженных сайтов в мире, чем любому другому серверу

Читать истории успеха

Новое из блога F5 NGINX

Блог

Архитектура безопасности с нулевым доверием для приложений Kubernetes с помощью NGINX

Защитите своих пользователей, распределенные приложения, микросервисы и API в любом масштабе и комплексно в любой среде — локальной, гибридной и мультиоблачной.