Что такое kubernetes и зачем он нужен

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

Kubernetes – это портативная расширяемая платформа для управления контейнерами на серверах. Она поставляется с открытым кодом, поэтому на рынке достаточно сервисов и инструментов для декларативной настройки и автоматизации процессов.

NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.

Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.

Основные компоненты архитектуры

Несмотря на удобство и простоту фреймворка Kubernetes, перед его использованием, при разработке или развертывании приложений, необходимо разобраться в архитектуре. Например, понять, как соединяются между собой контейнеры (через интерфейс API), и узнать, почему компоненты разделены на две основные группы – Master Node и Worker Node.

1. Nodes – виртуальная (физическая) машина, на мощностях которой запущены контейнеры.
2. Pods – базовые модули управления приложениями, состоящие из одного или нескольких контейнеров.
3. Volume – ресурс, позволяющий одновременно запускать несколько контейнеров.
4. Kube-Proxy – комплекс из прокси-сервера и модуля балансировки нагрузки, позволяющий маршрутизировать входящий трафик под конкретный контейнер Pods.
5. Kubelet – транслятор статусов Pods на узле и контроллер корректности работы контейнера и образа в целом.

Перечисленные компоненты устанавливаются автоматически при помощи сторонних инструментов или вручную, по отдельности. Они составляют модуль под названием Master Node, где собраны все управляющие и контролирующие функции. Через API они связываются с контейнерами, считывают их показатели, дают команду на запуск, штатную остановку или принудительное закрытие.

Что такое хостинг и как он связан с доменом

Хостинг — это услуга, при которой клиент арендует у хостинг-провайдера часть мощностей или весь сервер. Там будут храниться файлы сайта — картинки, текст, видео, таблицы и все, что видно в браузере. Также компания-хостер помогает клиентам настроить хостинг, защищает файлы от кибератак, а физические носители — от пожаров или других происшествий. В общем, без хостинга не заработает ни один сайт.

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

Если хостинг предоставляет пространство для файлов сайта, то домен — это имя и адрес, по которому его найдут в интернете. Домен состоит минимум из двух уровней: первый указывает географию сайта («.ru» для российских сайтов, «.com» для международных), а второй — показывает название сайта («yandex.», «google.»). Домены второго уровня уникальны, поэтому нельзя зарегистрировать два сайта по одному адресу. Хостинг подключается после регистрации домена.

Почему архитектура всё же важна?

Одна из фундаментальных основ любого Unix-приложения — это процесс или поток (с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в разделении адресного пространства). Процесс или поток — это самодостаточный набор инструкций, который операционная система может запланировать для выполнения на ядре процессора. Большинство сложных приложений параллельно запускают множество процессов или потоков по двум причинам:

• Чтобы одновременно задействовать больше вычислительных ядер;
• Процессы и потоки позволяют проще выполнять параллельные операции (например обрабатывать множество соединений одновременно).

Процессы и потоки сами по себе расходуют дополнительные ресурсы. Каждый такой процесс или поток потребляет некоторое количество памяти, а кроме того они постоянно подменяют друг друга на процессоре (т. н. переключение контекста). Современные серверы могут справляться с сотнями активных процессов и потоков, но производительность сильно страдает, как только заканчивается память или огромное количество операций ввода-вывода приводит к слишком частой смене контекста.

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

• 28 апр 2022

Подкаст «Люди и код», выпуск № 16: Кирилл Буев и Ксения Ваганова.

8 бесплатных хостингов для сайта

ЭКСКЛЮЗИВЫ ⚡️
Читайте только в блоге
Unisender

Настройка Kubernetes

Сначала указывается сервер, на который был инсталлирован Kubernetes. Он становится первичным, где будут запускаться остальные операции. Инициализация выполняется при помощи команды:

kubeadm init --pod-network-cidr=10.244.0.0/16

В результате создается адрес виртуальной сети Pods (цифры выбираются по желанию пользователя). По умолчанию используется указанный IP. При правильной обработке команды на дисплее будет отображаться команда для присоединения остальных Nods-кластеров к первичному серверу, чтобы создать в итоге рабочую систему.

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

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Теперь можно настраивать Container Network Interface (CNI, сетевой интерфейс контейнера). Чтобы избавить себя от рутины ручного ввода команд, рекомендуется установить плагин Flannel или ему подобный (Weave Net, Calico). Первый устанавливается так:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

После ввода команды на экране отображаются имена всех созданных ресурсов.

Теперь пользователь добавляет Nods в существующий кластер. Для этого требуется подключение к серверу через SSH, установка модулей Docker, Kubelet, Kubeadm (вопрос рассматривался выше). Выполнение команды:

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

Остается получить токен авторизации кластера. Если подключение SSH еще не прервано, повторно заходить на сервер не нужно. Токен выдается после ввода команды:

kubeadm token list

По умолчанию он действует 24 часа. Если поставлена задача добавить новый узел по завершении периода, новый создается командой:

kubeadm token create

Вывод выглядит примерно так:

5didvk.d09sbcov8ph2amjw

На этом все. Система готова к эксплуатации. Дальнейшие действия пользователя зависят от стоящих задач и опыта.

Устройство конечного автомата

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

Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.

Блокирующийся конечный автомат

Вспомните наше определение процесса или потока, как самодостаточного набора инструкций, выполнение которых операционная система может назначать на конкретное ядро процессора. Большинство веб-серверов и веб-приложений используют модель, в которой для «игры в шахматы» приходится по одному процессу или потоку на соединение. Каждый процесс или поток содержит инструкции, чтобы сыграть одну партию до конца. Все это время процесс, выполняясь на сервере, проводит большую часть времени заблокированным в ожидании следующего хода от клиента.

1. Процесс веб-сервера ожидает новых соединений (новых партий инициированных клиентами) на слушающих сокетах.
2. Получив новое соединение, он играет партию, блокируясь после каждого хода в ожидании ответа от клиента.
3. Когда партия сыграна, процесс веб-сервера может находиться в ожидании желания клиента начать следующую партию (это соответствует долгоживущим keepalive-соединениям). Если соединение закрыто (клиент ушел или наступил таймаут), процесс возвращается к встрече новых клиентов на слушающих сокетах.

Важный момент, который стоит отметить, заключается в том, что каждое активное HTTP-соединение (каждая партия) требует отдельного процесса или потока (гроссмейстера). Такая архитектура проста и легко расширяема с помощью сторонних модулей (новых «правил»). Однако, в ней существует огромный дисбаланс: достаточно легкое HTTP-соединение, представленное в виде файлового дескриптора и небольшого объема памяти, соотносится с отдельным процессом или потоком, достаточно тяжелым объектом в операционной системе. Это удобно для программирования, но весьма расточительно.

NGINX, как настоящий Гроссмейстер

Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?

Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.

Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните — обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.

1. Рабочий процесс ожидает событий на слушающих сокетах и сокетах соединений.
2. На сокетах происходят события и процесс их обрабатывает:
   • Событие на слушающем сокете означает, что пришел новый клиент для начала игры. Рабочий процесс создает новый сокет соединения.
   • Событие на сокете соединений сигнализирует, что клиент сделал ход. Рабочий процесс ему мгновенно отвечает.

Рабочий процесс, обрабатывая сетевой трафик, никогда не блокируется, ожидая очередного хода от оппонента (клиента). После того как процесс сделал свой ход, он немедленно переходит к другим доскам, на которых игроки ожидают хода, или встречает новых у двери.

Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?

Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.

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

Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.

С адекватной настройкой системы, NGINX прекрасно масштабируется до многих сотен тысяч параллельных HTTP cоединений на каждый рабочий процесс и уверенно поглощает всплески трафика (толпы новых игроков).

Назначение Kubernetes

Контейнеры упрощают блочную разработку продуктов и их последующую сборку перед запуском. Такой подход дает возможность дорабатывать отдельные модули без влияния на работу остальных функций, и все это происходит на платформе фреймворка Kubernetes. Она обрабатывает ошибки в приложениях, занимается масштабированием, содержит шаблоны развертывания и пр.

1. Обнаружение контейнера происходит по имени DNS или IP-адресу.
2. Система самостоятельно балансирует нагрузку и распределяет трафик в сети.
3. Подключение выбранного типа хранилища происходит в автоматическом режиме.
4. Платформа перезапускает отказавшие контейнеры или блокирует к ним доступ.
5. Конфиденциальная информация хранится изолированно от других данных.

Развертывание или откат изменений происходит по заданному сценарию, без участия пользователя. То же относится к резервированию аппаратных ресурсов, количеству процессорных ядер, оперативной памяти (на каждый отдельно взятый контейнер). Единственное ограничение Kubernetes заключается в отсутствие встроенных компонентов вроде базы данных, модуля обработки данных и организации кэша.

Как же работает NGINX?

NGINX использует модель с фиксированным числом процессов, которая наиболее эффективно задействует доступные ресурсы системы:

• Единственный мастер-процесс выполняет операции, которые требуют повышенных прав, такие, как чтение конфигурации и открытие портов, а затем порождает небольшое число дочерних процессов (следующие три типа).
• Загрузчик кэша запускается на старте чтобы загрузить данные кэша, расположенные на диске, в оперативную память, а затем завершается. Его работа спланирована так, чтобы не потреблять много ресурсов.
• Кэш-менеджер просыпается периодически и удаляет объекты кэша с жесткого диска, чтобы поддерживать его объем в рамках заданного ограничения.
• Рабочие процессы выполняют всю работу. Они обрабатывают сетевые соединения, читают данные с диска и пишут на диск, общаются с бэкенд-серверами.

Документация NGINX рекомендует в большинстве случаев настраивать число рабочих процессов равное количеству ядер процессора, что позволяет использовать системные ресурсы максимально эффективно. Вы можете задать такой режим с помощью директивы worker_processes auto в конфигурационном файле:

worker_processes auto;

Когда NGINX находится под нагрузкой, то в основном заняты рабочие процессы. Каждый из них обрабатывает множество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.

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

Процесс установки Kubernetes

При выборе автоматической установки вникать в детали не понадобится, но требуется выделить достаточное количество системных ресурсов, чтобы платформа работала бесперебойно. Например, при небольшом количестве контейнеров и простой взаимосвязи достаточно 1-2 процессорных ядер, 2-4 Гб оперативки и двух виртуальных машин, выполняющих функции Master и Worker Node.

Инсталляция на Ubuntu

Проще всего воспользоваться одной из готовых реализаций – Minikube или Kubespray. Если нужно установить Kubernetes на сервер с операционной системой Ubuntu вручную, понадобятся права суперпользователя. Начнем с установки Docker для узла. Перечень команд для этого выглядит следующим образом:

apt-get update
apt-get install -y docker.io

При необходимости организовать создание контейнеров более новых версий перечень команд будет несколько иным:

apt-get update
apt-get install -y \
apt-transport-https \
ca-certificates \
curl \
software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add –

add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \ $(lsb_release -cs) \ stable"
apt-get update

apt-get install -y docker-ce docker-ce-cli containerd.io

Docker для одного узла установлен. Следующий шаг – установка модулей kubeadm (создание и настройка кластеров), kubelet (их запуск на хостах), kubectl (настройка компонентов, входящих в кластер). Для этого вводятся следующие команды:

apt-get update && apt-get install -y apt-transport-https software-properties-common
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
add-apt-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
apt-get update
apt-get install -y kubelet kubeadm kubectl
systemctl enable kubelet && systemctl start kubelet

Инсталляция на CentOS

При установке на операционную систему CentOS любой версии нужно выполнить ряд требований. Так, понадобится минимум 3 машины (1 главный, 2 рабочих узла), которые подключены к общей сети или интернету. Здесь также вся работа проводится в учетной записи sudo или root. Процедура проводится, как и в случае с Ubuntu, через консоль.

Команды для установки Docker:

yum install -y docker
systemctl enable docker && systemctl start docker

Компоненты Kubernetes (kubeadm, kubelet, kubectl) инсталлируются так:

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
setenforce 0
yum install -y kubelet kubeadm kubectl
systemctl enable kubelet && systemctl start kubelet

После ввода команд (при отсутствии ошибок) можно приступать к настройке платформы. Процесс включает инициализацию кластера, создание CNI, добавление узлов Nodes и получение токена для авторизации.

Внутри рабочего процесса

Каждый рабочий процесс NGINX инициализируется с заданной конфигурацией и набором слушающих сокетов, унаследованных от мастер-процесса.

Рабочие процессы начинают с ожидания событий на слушающих сокетах (см. также accept_mutex и разделяемые сокеты). События извещают о новых соединениях. Эти соединения попадают в конечный автомат — наиболее часто используемый предназначен для обработки HTTP, но NGINX также содержит конечные автоматы для обработки потоков TCP трафика (модуль stream) и целого ряда протоколов электронной почты (SMTP, IMAP и POP3).

Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.

Обновление конфигурации и исполняемого кода

Архитектура NGINX с малым количеством рабочих процессов позволяет достаточно эффективно обновлять конфигурацию и даже его собственный исполняемый код на лету.

Обновление конфигурации NGINX — очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.

Когда рабочий процесс получает SIGHUP, он производит несколько операций:

1. Перезагружает конфигурацию и порождает новый набор рабочих процессов. Эти новые рабочие процессы сразу начинают принимать соединения и обрабатывать трафик (используя новые настройки).
2. Сигнализирует старые рабочие процессы о плавном завершении. Они перестают принимать новые соединения. Как только завершается обработка текущих HTTP-запросов, соединения закрываются (никаких затянувшихся keep-alive соединений). Как только все соединения закрыты, рабочий процесс завершается.

Данная процедура может вызвать небольшой всплеск нагрузки на процессор и память, но в общем это практически незаметно на фоне затрат на обработку активных соединений. Вы можете перезагружать конфигурацию несколько раз в секунду (и есть немало пользователей NGINX, кто так делает). В редких случаях могут возникнуть проблемы, когда слишком много поколений рабочих процессов NGINX ожидают закрытия соединений, но они быстро разрешаются.

Обновление исполняемого кода NGINX — это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.

Процесс обновления исполняемого кода использует схожий с перезагрузкой конфигурации подход. Новый мастер-процесс NGINX запускается параллельно со старым и получает от него дескрипторы слушающих сокетов. Оба процесса загружены и их рабочие процессы обрабатывают трафик. Затем вы можете отдать команду старому мастер-процессу на плавное завершение.

Вся процедура подробно описана в документации.

Какие бывают хостинги

Часто названия «хостинг» и «сервер» употребляются как синонимы. Но это разные понятия: хостинг подразумевает аренду мощностей компьютера, а сервер — это и есть компьютер.

Обычно хостинги разделяют на четыре типа. Они отличаются ценой, выделенными мощностями для клиента и дополнительными настройками.

Общий или виртуальный хостинг

Самая дешевая и простая услуга для содержания сайтов. Компания предоставляет один физический сервер для нескольких клиентов и распределяет между ними скорость входящего и исходящего интернет-трафика. Если один из сайтов на таком хостинге одновременно посетят тысячи пользователей, то остальные сайты будут загружаться медленнее. Поэтому такой тип хостингов подойдет для веб-ресурсов с небольшой посещаемостью.

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

VPS (Virtual Private Server) и VDS (Virtual Dedicated Server) хостинги

Более дорогая услуга. Из одного физического сервера выделяется часть мощностей только для одного клиента. У него нет «соседей» по хостингу — поэтому никто не сможет перетянуть на себя часть памяти или трафика.

Сайт клиента будет загружаться медленнее только в том случае, если нагрузка придется именно на него: например, придет большое количество пользователей или администратор загрузит слишком тяжелые файлы.

VPS- и VDS-хостинги отличаются тем, как именно виртуализируются мощности сервера:

1. В VPS виртуализируется ОС (операционная система) — клиент может настраивать ее: например, добавить нового пользователя, который тоже получит доступ к хостингу. При этом клиент не может сменить ОС.
2. VDS-хостинг виртуализирует часть физического сервера — поэтому клиент может поменять ОС, если она его не устраивает. Например, он может заменить платную Windows Server на бесплатную Ubuntu.

Облачный хостинг

Он распределяет файлы между несколькими физическими серверами. Поэтому клиент платит только за те ресурсы, которые использует в конкретный момент. Если на сайт придет много пользователей, то хостер увеличит мощность — придется переплатить. А если пользователей будет мало, то можно сэкономить и уменьшить мощность.

Обычно у облачных хостингов меньше настроек, чем у VPS серверов. Хостеры сами настраивают ОС и не дают доступ к корневым файлам. При этом клиент может выбрать операционную систему — для серверов используются:

• Windows Server,
• Ubuntu,
• Debian,
• CentOS.

Выделенный сервер

Самая дорогая услуга — она дает больше всего мощностей для клиента. Он арендует физический сервер целиком и все ресурсы будут принадлежать только ему. Еще одно преимущество — максимальная защищенность файлов, ведь все данные физически хранятся в одном месте. Такая услуга подойдет для крупных интернет-магазинов, социальных сетей и других сложных проектов.

На выделенный сервер можно самому поставить программу или операционную систему — никаких ограничений нет. Но для таких целей нужно знать, как управлять сервером. Если таких навыков нет, то придется научиться самому или нанять администратора.

Как загрузить сайт на хостинг

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

Обычно в панели управления хостинга есть раздел «Домены» в виде вкладки или кнопки. Там появится поле, куда можно скопировать домен.

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

Теперь нужно указать DNS-адреса хостинга для домена: их можно найти в разделе с помощью. Они могут выглядеть так:

• ns1.cloud.ru
• ns2.cloud.ru
• ns3.cloud.pro
• ns4.cloud.pro

Затем переходим на сайт, где зарегистрирован домен. В личном кабинете выбираем раздел с DNS-адресами и указываем все адреса, что были на сайте хостинга. Обновление DNS-данных занимает от нескольких часов до пары дней.

Осталось загрузить файлы для сайта. В панели управления хостинга нужно снова зайти в раздел «Домены», выбрать загруженный адрес и открыть файловый менеджер. В интерфейсе он может отображаться в виде значка с папкой.

В файловом менеджере нужно открыть папку с названием сайта (например, «freetravel.ru»), а затем папку «www». В нее загружаются файлы сайта: их можно сохранить в zip-архив, чтобы не копировать по одному.

Как выбрать хостинг

Выбирать тариф у хостера можно по нескольким критериям.

Платный или бесплатный

Цена тарифа зависит от мощностей серверов и дополнительных услуг. Есть и бесплатные хостинги — они дают самые низкие мощности и размещают на сайтах рекламу. Поэтому бесплатный хостинг лучше использовать для тестовых проектов. Если нужно запустить интернет-магазин, то лучше сразу выбрать платную услугу: VPS, облачный хостинг или выделенный сервер.

Формат жесткого диска

Сейчас хостеры предлагают два формата: HDD и SSD. Первый из них стоит дешевле, но с него медленнее загружаются файлы. SSD стоят дороже, но они грузят файлы в несколько раз быстрее.

Физическая память

От объема основной памяти зависит, сколько файлов сможет поддерживать сайт. При этом в тарифе бывают ограничения на медиафайлы. Например, из 20 ГБ памяти клиент может загружать фото и видео только на 5 ГБ. Другое ограничение — индексные дескрипторы (inodes): они определяют количество файлов и папок, которые можно создать на диске.

Оперативная память и процессор

Чем больше памяти, ядер и чем выше частоту процессора предоставляет хостинг, тем быстрее будет грузиться сайт. Но и дороже будет стоить тариф.

Поддержка CMS

Content management system, или система управления контентом — это интерфейс, который позволяет загружать картинки, видео, текст, менять его верстку веб-страниц.

Самые популярные CMS:

• WordPress,
• Joomla,
• Битрикс,
• OpenCart.

О поддержке CMS обычно указано в тарифе. Если хостинг поддерживает MySQL, то на нем точно будет работать WordPress.

Законодательные ограничения

Некоторые сайты собирают персональные данные пользователей: имена, адреса электронной почты, номера телефонов. Владельцы этих сайтов считаются операторами персональных данных — они должны хранить файлы на российских серверах. В противном случае владельца сайта может оштрафовать Роскомнадзор.

Поэтому даже у российских хостингов (Reg.ru, Timeweb, Sprinthost и других) нужно проверять, где находятся сервера: на территории страны или за рубежом. Об этом пишут в описании тарифа или в договоре.

Если сайт не собирает персональные данные, его можно разместить на иностранном хостинге — например, Bluehost или Hostgator.

Дополнительные услуги

К ним относятся:

• защита от DDoS-атак,
• проверка почты на спам и вирусы,
• веб-интерфейс для почты,
• доступ к сайту по FTP,
• резервное копирование файлов и другие услуги.

Допуслуги предоставляют все типы хостингов, кроме общих.

Модель NGINX процессов

Чтобы лучше представлять устройство, сперва необходимо понять как NGINX запускается. У NGINX есть один мастер-процесс (который от имени суперпользователя выполняет такие операции, как чтение конфигурации и открытие портов), а также некоторое количество рабочих и вспомогательных процессов.

# service nginx restart
* Restarting nginx
# ps -ef --forest | grep nginx
root 32475 1 0 13:36 ? 00:00:00 nginx: master process /usr/sbin/nginx \ -c /etc/nginx/nginx.conf
nginx 32476 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32477 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32479 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32480 32475 0 13:36 ? 00:00:00 \_ nginx: worker process
nginx 32481 32475 0 13:36 ? 00:00:00 \_ nginx: cache manager process
nginx 32482 32475 0 13:36 ? 00:00:00 \_ nginx: cache loader process

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

Зачем нужен Kubernetes

Платформа создавалась с учетом наработок в управлении удаленными проектами с масштабными рабочими нагрузками. Поэтому изначально в ней применяются продвинутые технологии, которые давно заменили принципы физического и даже виртуального развертывания систем. Контейнерное построение считается «облегченным» вариантом виртуальных машин.

Причины популярности Kubernetes:

1. Развертываемые приложения отделены от инфраструктуры для повышения безопасности.
2. Разработка и тестирование работают одинаково на локальном компьютере и в облаке.
3. Контейнеры свободно переносятся между Ubuntu, CoreOS, RHEL и другими системами.
4. Происходит изоляция ресурсов с прогнозированием производительности.

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Подведем итоги

Мы дали поверхностный обзор того, как функционирует NGINX. Под этими простыми описаниями скрывается более чем десятилетний опыт разработки и оптимизации, который позволяет NGINX демонстрировать выдающуюся производительность на широком спектре оборудования и реальных задачах, оставаясь надежным и безопасным, как того требуют современные веб-приложения.

• Installing and Tuning NGINX for Performance (вебинар; слайды на Speaker Deck)
• Tuning NGINX for Performance
• The Architecture of Open Source Applications – NGINX
• Множественные сокеты в NGINX 1.9.1 (использование опции SO_REUSEPORT)