Разное

Функции локального сервера: Функции сервера локальной сети: определение, возможности

11.05.2023

Содержание

Функции сервера локальной сети: определение, возможности

Главная » Интернет

Интернет

На чтение 3 мин. Просмотров 4.1k. Опубликовано

Использование ЛВС (локальные вычислительные сети) уже давно стало стандартом организации работы современного офиса. Но для более продуктивной организации целесообразно использование специальных служб или отдельных компьютеров для выполнения задач обслуживания пользователей, и упрощения обмена данными между ними. Такие компьютеры получили название — сервер. Попробуем разобраться для чего это нужно и каковы функции сервера локальной сети. Использование серверов и централизованное управление LAN позволяет более четко управлять пользователями, увеличить безопасность, уменьшить время простоя работы при сбоях оборудования, и др.

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

  • Управление пользователями. Для обеспечения доступа к определенным ресурсам применяются технологии LDAP или Active Directory. Такой подход позволяет ограничить права каждого отдельного работника к системе хранения данных, организовывать карточки и политику доступа к тому или иному ресурсу. Для примера можно взять разделение по отделам или департаментам предприятия.
  • Обслуживание файлового хранилища. Очень часто используемые функции локальной сети. Удобно, когда файлы хранятся не на локальной машине, а на удаленном компьютере, к которому можно обратиться в любой момент времени. Сейчас это называется «облачное хранилище», и многие провайдеры предоставляют такой доступ даже на уровне интернета. Это удобно еще и с той точки зрения, что нет необходимости использовать на компьютерах жесткие диски большого размера. Основными протоколами являются Samba и NFS.
  • Единый шлюз для выхода в интернет. Нет необходимости проводить и дополнительно оплачивать несколько каналов от провайдера интернет. Все будут получать доступ через единый шлюз не зависимо от их количества и схемы организации ЛВС. Обычно совместно с сервисом управления пользователями идет разграничение: одни юзеры имеют доступ к шлюзу, другие могут иметь доступ только к определенным ресурсам, а некоторые вообще не могут пользоваться интернетом. Увеличивается безопасность корпоративной (локальной) сети, можно вести контроль трафика и следить за действиями сотрудников. Все решается политикой компании, а администратор только выставляет необходимые права.
  • Единая почтовая служба для переписки сотрудников внутри сети или через сеть интернет. Организация такой службы позволяет отделить фирму от других использованием своего уникального префикса, а не префикса бесплатных почтовых служб.
  • Организация печати позволяет использовать всего нескольких принтеров для обеспечения необходимости в печатной продукции всего офиса. Нет необходимости ставить принтер на каждое рабочее место.
  • Централизованные сетевые службы, такие как, DHCP (динамическая раздача адресов), NTP (синхронизация времени на всех компьютерах), DNS (преобразование адресов в понятные имена), и другие.
  • Сервера, обслуживающие приложения. Многие организации используют специализированное программное обеспечение для которого требуется локальная или глобальная сеть, например продукция фирмы 1С, системы электронного документооборота (IBM Lotus Notes) и прочие подобные программы.
  • Единый центр обновлений позволяет производить обновления операционной системы или антивирусных программ, и значительно сокращает нагрузку на интернет трафик.
  • Хранилище баз данных для структуризации и быстрого доступа к корпоративной информации.

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

Локальный сервер для разработки (dns, nginx & git) / Хабр

В итоге мы получим домашний сервер с фейковым доменом, на поддомене которого мы развернём GitLab и настроим работу gitlab-runner’а для деплоя наших веб-проектов.

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

В качестве основной системы используется Ubuntu Server.

DNSMasq & NGINX

Ставим DNSMasq и NGINX.

sudo apt update
sudo apt install nginx, dnsmasq, dnsutils

Узнаём название нашего контроллера с помощью команды (тут — enp1s0):

ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d8:9e:f3:92:aa:a8 brd ff:ff:ff:ff:ff:ff
    inet 10.13.9.242/24 metric 100 brd 10.13.9.255 scope global dynamic enp1s0
       valid_lft 45713sec preferred_lft 45713sec
    inet6 fe80::da9e:f3ff:fe92:aaa8/64 scope link 
       valid_lft forever preferred_lft forever

Настраиваем конфиг DNSMasq `/etc/dnsmasq. d/<имя_нашего_конфига>`. В качестве имени, можно использовать название нашего главного домена, чтобы было удобнее.
Открываем файл и исправляем наш конфиг по образу и подобию:

no-dhcp-interface=<controller> # Не перенастраиваем DHCP, а слушаем наш контроллер
bogus-priv # Запретить пересылать адреса в немаршрутизированные адресные пространства
domain=<domain> # Название домена
expand-hosts # Включаем поддомены
local=/<domain>/ # Локальное название домена
domain-needed # Использовать только полное доменное имя (FQDN)
address=/<domain>/<local_ip> # Запуск функции кеширования для ip-адресов локальных интерфейсов. Если этой опции нет, то для всех
no-resolv # Запрет в чтении файла /etc/resolv.conf или др.файла выполняющего его функцию.
no-poll # Тоже, что и no-resolv
no-hosts # Не использовать файл /etc/hosts для формирования таблицы адресов
# Отдельно стоит поговорить про эти строки,
# тк если ваша рабочая машина использует VPN,
# то у вас могут возникнуть небольшие сложности с подключением.
 
 
 
# Всё решается дополнительной настройкой DNS в вашем VPN-клиенте
server=8.8.8.8 # DNS-сервера для домена
server=8.8.4.4 # DNS-сервера для домена

Перезагружаем DNSMasq service:

sudo systemctl restart dnsmasq.service

Теперь вам нужно настроить использование нашего локального DNS на вашем компьютере. Я покажу, как это сделать для Debian 11.
Достаточно изменить два файла: `/etc/resolv.conf` и `/etc/NetworkManager/NetworkManager.conf`.

sudo nano /etc/resolv.conf
...
# Ваш локальный DNS должен идти самым первым в списке
nameserver <local_dns_ip>
nameserver 127.0.0.1
...
sudo nano /etc/NetworkManager/NetworkManager.conf
...
[main]
dns=none
...

Теперь настроим NGINX, чтобы он принимал наш новый домен. Для этого достаточно создать новый файл конфигурации в папке `/etc/nginx/sites-available`, проверить его, переместить в `/etc/nginx/sites-enabled` и перезапустить NGINX. Приступим!

Создаём новый файл конфигурации `<ваш_домен>. conf`. Да, весьма простая конфигурация, но нам больше и не нужно.

server {
 listen 80;
 listen [::]:80;
 server_name <ваш_домен> www.<ваш_домен>;
}

Переносим (создаём symlink на) файл.

чтож…
 
ln -s /etc/nginx/sites-available/<ваш_домен>.conf /etc/nginx/sites-enabled/

Проверяем корректность файла:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Перезапускаем NGINX:

sudo systemctl reload nginx

Теперь, если вы перейдёте в своём браузере по адресу http://<ваш_домен>, вы увидите стартовую страницу NGINX.

GitLab

Добавляем репозиторий в систему:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

Устанавливаем GitLab:

sudo apt install gitlab-ee

Настраиваем базовую конфигурацию `/`:

external_url 'example.domain' -> external_url 'http://gitlab. <ваш_домен>'
web_server['external_users'] = [] -> web_server['external_users'] = ['www-data']
nginx['enable'] = true -> nginx['enable'] = false

Скачиваем файл конфигурации GitLab для NGINX. Помещаем его в папку `/etc/nginx/sites-enabled`. В этом файле нужно поправить только строки:

listen 0.0.0.0:80 default_server; -> listen 0.0.0.0:7001;
listen [::]:80 default_server; -> listen [::]:7001;
server_name YOURSERVER_FQDN -> server_name www.<ваш_домен> <ваш_домен>;

Добавляем самые простые строки в базовый конфиг NGINX. (можно и не в него, а в отдельный файл в `/etc/nginx/sites-enabled`).

server {
  listen 80;
  client_max_body_size 50m;
  server_name gitlab.<ваш_домен> www.gitlab.<ваш_домен>;
  location / {
    proxy_pass http://127.0.0.1:7001;
  }
}

Реконфигурируем GitLab:

sudo gitlab-ctl reconfigure

Обновляем NGINX:

sudo systemctl reload nginx

Находим первичный root-пароль в файле `/etc/gitlab/initial_root_password`.

Заходим на нашу страницу, вводим логин root и пароль, который мы нашли до этого, и настраиваем аккаунт администратора.

GitLab Runner

Для начала нам нужно установить Runner. Добавляем репозиторий.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

Устанавливаем пакет.

sudo apt install gitlab-runner

Теперь получаем регистрационный токен для нашего runner’а. Заходим в админ-панель GitLab через аккаунт администратора в раздел Overview -> Runners и нажимаем Register an instance runner. Копируем токен.

Начинаем процесс регистрации runner’а. Вводим команду:

sudo gitlab-runner register

  1. Вводим url-адрес нашего gitlab’a.

  2. Вводим наш токен.

  3. Вводим краткое описание.

  4. Вводим тэги. Тут я советую создать два runner’a с разными тэгами: один с тэгом shell, который будет выполнять все операции, связанные с терминальными командами, и второй с тэгом docker, который будет отвечать за наши docker-контейнеры. Остальные тэги можно посмотреть в официальной документации.

Проверить наш runner можно на той же странице в админ-панели.

Теперь, чтобы runner мог участвовать в развёртывании веб-проектов на NGINX сервер, нужно сделать лишь пару штрихов: дать ему права на вызов NGINX под sudo и выдать доступ к папкам `sites-available` и `sites-enabled`.

Права выдаются путём создания дополнительного файла в папке `/etc/sudoers.d`, в ней создадим файл `gitlabrunner` и впишем такую строчку:

%gitlab-runner ALL=(ALL:ALL) NOPASSWD: /usr/sbin/nginx

Выдача прав вызова NGINX под sudo нужна, чтобы делать проверку конфигурации файлов при деплое. Вызов `nginx -t` возможен, но он будет заканчиваться всегда с ошибкой.

Далее прописываем команду, чтобы runner имел возможность взаимодействовать с файлами в папках NGINX:

sudo chown root:gitlab-runner -R /etc/nginx/sites-available /etc/nginx/sites-enabled

Вот и всё. Теперь у нас есть полноценная локальная среда разработки.

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

Для тех, кому интересно, что там с GitLab wiki

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

UPD: Оказывается, чтобы GitLab wiki проекта работала корректно, всегда должна присутствовать home страница (а мы начали с красивых заголовков)…

Дополнительно могу сделать небольшую статью, как вся эта система работает на примере небольшого проекта на Django, где в качестве WSGI будет использоваться Gunicorn.

Здесь нужен симлинк.

Местное развитие | Документация по облачным функциям

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

Варианты использования

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

Локальное тестирование

Многие парадигмы разработки зависят от возможности тестировать ваш код относительно быстро.

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

Примечание: для получения дополнительной информации о стратегиях тестирования см. Страница обзора тестирования.

Ограничения местоположения данных

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

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

Мультиоблачные развертывания

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

Варианты реализации

Прежде чем вы сможете настроить свою собственную среду размещения функций, есть два ключевых момента: выбор, который вам нужно будет сделать:

  • Какой уровень абстракции вы хотите использовать.
  • Какой тип функции вы будете использовать.

Уровни абстракции

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

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

На приведенной ниже диаграмме показана типичная схема развертывания функций в облаке. Functions, Cloud Run и другие платформы на основе контейнеров:

.

Типы событий

Облачные функции имеют два основных типа функций:

  • Функции HTTP
  • Функции, управляемые событиями

HTTP-функции могут запускаться произвольными HTTP-запросами, такими как веб-перехватчики, тогда как функции, управляемые событиями, получают события, созданные другие продукты Google Cloud Platform.

Выбор уровня абстракции

Вы можете запускать функции локально, используя либо Фреймворки функций или Сборочные пакеты Cloud Native.

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

Сборочные пакеты Cloud Native используются для переноса служб HTTP. созданные функциональными фреймворками, и встраивайте их в исполняемые Контейнеры Docker, которые затем запускаются в Cloud Functions. контейнерная архитектура.

Оба варианта имеют свои преимущества и недостатки:

  • Функции Среды на основе фреймворков часто требуют меньше ресурсов
  • Functions Frameworks не требуют базового программного обеспечения контейнеризации (такого как как Докер)
  • Функции Среды на основе фреймворков требуют базового языка инфраструктура (например, менеджеры пакетов и языковые среды выполнения)

В общем, мы рекомендуем использовать Frameworks Functions, если только переносимость и/или особенно желательна контейнеризация.

Локальный запуск функций

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

Как локально разработать и протестировать функцию Google Cloud | by Saed Hussain

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

Фото Томаса Собека на Unsplash

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

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

Модель машинного обучения как бессерверная конечная точка с использованием облачных функций Google

Итак, вы создали модель и хотите внедрить ее в качестве бессерверного решения на облачной платформе Google (GCP). Позвольте мне…

в направлении datascience.com

Убрав этот крюк с дороги, давайте вернемся к тому, почему мы здесь.

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

Единственная разница в том, что выполнение этого локально позволяет нам быстро отлаживать и выполнять итерации, вместо того, чтобы ждать целую вечность, пока он будет развернут, а затем выяснять, есть ли ошибка! И да, для развертывания требуются годы! 😅

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

Как известно, для облачных функций требуется 2 файла:

  • main.py: где основной код функции.
  • requirements.txt: список всех библиотек, которые необходимо установить для работы функции.

Создание виртуальной среды позволит нам легко создать файл требований , как только наша функция будет готова к работе. Например, в виртуальной среде conda я могу запустить следующее, чтобы сгенерировать файл требований: pip list --format=freeze > requirements.txt

Разобравшись со всем этим, давайте начнем с кода. 💻

Выполните следующие шаги для локальной разработки и тестирования облачной функции:

Шаг 0: Каталог и виртуальная среда

Создайте виртуальную среду и каталог для проекта облачной функции. Я использую conda для виртуальной среды как часть установки Anaconda.

  • На компьютере с Windows введите mkdir YOUR_DIRECTORY_NAME в командной строке, чтобы создать каталог.
  • Для виртуальной среды квартиры используйте conda create --name YOUR_ENV_NAME python=3.8 , чтобы создать виртуальную среду с помощью Python версии 3.8.
  • Чтобы активировать среду, используйте conda активировать YOUR_ENV_NAME .

⚠️ Примечание: Пропустите шаг 0, если вас не волнуют виртуальные среды и разделение между проектами. Шаг 1 — это то, с чего начинается импорт!

Шаг 1. Установите Functions Framework

Установите инфраструктуру функций, используя следующее:

pip install functions-framework

Шаг 2. Основной файл кода функции вы бы нормально. Для целей этой статьи я создал образец файла main.py .

Все, что он делает, это проверяет, была ли отправлена ​​какая-либо полезная нагрузка JSON, и пытается извлечь имя, отправленное как часть полезной нагрузки. Затем он отвечает приветствием имени.

Облачная функция, которая отвечает на полезную нагрузку JSON приветствием. (источник: автор)

Шаг 3: Раскрутить локальный сервер разработки

В том же каталоге, что и файл main.py , запустите в командной строке/терминале следующее, чтобы раскрутить сервер разработки, обслуживающий вашу облачную функцию: functions_framework --target=say_hello

Приведенный выше код загружает файл main.py на сервер разработки и указывает на say_hello в качестве функции точки входа.

Теперь вы сможете вызывать эту функцию, которая доступна на вашем локальном хосте, скорее всего, на порту 8080. (http://localhost:8080)

Облачная функция, работающая на локальном компьютере. Использование виртуальной среды (func_local). (источник: автор)

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

Например, я точно знаю, что в моем виртуальном окружении у меня не установлена ​​библиотека XGBoost. Если я сейчас отредактирую main.py , чтобы добавить import xgboost , сохранить файл и перезапустить сервер, повторно запустив приведенный выше код, он должен выдать ошибку. Мне нужно установить эту библиотеку в моей виртуальной среде для успешного локального развертывания.

Ошибка при попытке снова запустить сервер после редактирования файла main.py для импорта XGBoost. (источник: автор)

ОК, теперь, когда у нас запущен сервер разработки, нам нужно вызвать эту функцию.

Шаг 4. Вызов локально развернутой функции

Вызов функции аналогичен тому, что вы делаете обычно. Все, что вам нужно сделать, это указать правильную конечную точку HTTP. В этом случае конечная точка находится на локальном хосте. Вы можете использовать cURL или библиотеку запросов в python для вызова функции.

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

Когда вы запускаете приведенный выше код ( > python local_func_invoker.py ), вы должны увидеть, что он печатает hello saed , что является ответом от локально развернутой облачной функции.

Вызов локально развернутой облачной функции и печать ее ответа. (источник: автор) Сервер разработки фреймворка функционирует, отвечая на входящий запрос. (источник: автор)

И вуаля! Теперь вы знаете все, что вам нужно для локальной разработки и тестирования функции Google Cloud.

⚠️ Примечание: Если вы создаете файл requirments.txt из виртуальной среды с помощью метода, упомянутого ранее, обязательно удалите библиотеку functions_framework, так как нам не нужно устанавливать ее в рабочей среде. Продукт Google Cloud Functions создан на основе этой платформы! 😄

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

Существует множество способов настройки Functions Framework, которые я не рассматривал для краткости. Я настоятельно рекомендую проверить эту страницу о фреймворке и этот репозиторий GitHub для версии фреймворка для Python.

Мы кратко коснулись лучших практик использования виртуальной среды для любой локальной разработки. Это очень полезно, особенно для создания файла requirements.txt , который необходим в производстве.

Поздравляем!! Теперь вы знаете, как разрабатывать и тестировать свои облачные функции Google локально, а также сэкономить много времени и усилий при переходе к рабочей среде. 🎊

🚀 Надеюсь, эта статья была вам полезна. Если вы хотите поддержать меня, рассмотрите возможность присоединиться к среде, используя мою реферальную ссылку .

Это даст вам доступ ко всем моим статьям и другим статьям других замечательных авторов на этой платформе! 😄

Другие статьи, которые могут вам понравиться:

Как извлечь и преобразовать таблицы из PDF-файлов в Pandas Dataframe?

Итак, у вас есть несколько файлов PDF с таблицами, и вы хотите прочитать их во фрейме данных pandas.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *