Как развернуть сервер на linux
Перейти к содержимому

Как развернуть сервер на linux

  • автор:

Why create a server at home?

Carlos Piñero

I have been trying several hosting and in the end, all of them have the same limitations, on one hand the price and on the other hand the computer capacity.

That’s why I decided to set up my own web server so as not to depend on third parties.

Requirements

  • Internet connection with IP-Public or IP-Fixed(I don’t think your provider will give it to you)
  • PC or Laptop with Ubuntu 20.04(do not use raspberry, it has limitations when installing python libraries), I recommend 128gb of disk, 8gb of ram and very quite fans.

Get down to it

First you have to make sure you have a public ip.

With this commands you can verify it:

  • to find out your ip
  • to find out the trace

If the trace has 1 single hop, it means you have public IP, if it has 2 hops it means you are in CG-NAT.

If you are within CG-NAT, in my case it was as easy as calling my internet provider and telling them to switch me to public ip, most providers have no objection to switching you to public ip at no extra cost.

Port forwarding

It is important to open ports 80 and 443 for your server to connect to the outside.

In my case the router is accessed through 192.168.1.1, and you have to configure port forwarding in the control panel with the internal IP or your server.

Convert the public ip into a fixed dns with DuckDns

The function of a dynamic DNS service is to facilitate access to a server that has a dynamic public IP.

Therefore, when this public ip changes it will not be important because you will have a DNS that automatically has the public ip of your server updated.

We will access the following URL:

Once inside the URL we will create an account from our Google account, reddit, Github or Twitter. In my case I generate the account using my gmail account.

To create the domain example1.duckdns.org we only have to write example1 in the section domains and then press the button add domain. The domain will be generated automatically.

Now follow the instructions in install for linux cron and you will have your dns fixed.

Now your fixed dns that updates with your public ip every 5 min will be:

Let’s install nginx

nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server.

List the application settings that UFW knows how to work with by typing in the following:

You should get a list of the application profiles:

As shown in the result, there are three profiles available for Nginx:

  • Nginx Full: this profile opens port 80 (normal, unencrypted web traffic) and port 443 (encrypted TLS/SSL traffic)
  • Nginx HTTP: this profile opens only port 80 (normal web traffic, not encrypted)
  • Nginx HTTPS: this profile opens only port 443 (encrypted TLS/SSL traffic)

Now we have to enable the FULL profile:

You can verify the change by writing the following:

The result will indicate the FULL traffic that is allowed:

Checking that everything works

At the end of the installation process, Ubuntu 20.04 starts Nginx. The web server should already be active.

Check with systemd init to make sure the service is running by typing the following:

As confirmed by this result, the service was initiated correctly. However, the best way to check this is to request an Nginx page.

You can use your public ip or example1.duckdns.org that you configured with DuckDns, enter it in the address bar of your browser:

You should get the Nginx landing page as a result:

Note: try it with a different connection than the one the server is connected to, for example with the 4g of your mobile phone.

If you are on this page, your server is running correctly and is ready to be managed.

What’s next

In the following article, I will tell you how to host in this server an interactive dashboard created in python with dash-plotly.

Thanks for reading this post, I hope this information will help you to advance your career or learn something new.

Установка сервера Linux + (Nginx + Apache) + PostgreSQL + PHP на VirtualBox (Ubuntu Server 16.04.3 LTS)

На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера. Решил написать свой рецепт.

Принцип работы следующий:


Статические данные (файлы) отдает Nginx, а динамикой занимается Apache.
Начнем.

Установим VirtualBox

    Запустим установщик VirtualBox.

Установка VirtualBox. Шаг 2

Подготовим VirtualBox к установке Ubuntu Server 16.04.3 LTS
  1. Загрузим образ ubuntu-16.04.3-server-amd64.iso
  2. Создадим виртуальную машину.

VirtualBox
Размер жесткого диска: 15 ГБ
Другие параметры оставим по умолчанию.

VirtualBox
Сменим тип подключения с NAT на Сетевой мост.

Установка Ubuntu Server 16.04.3 LTS

    Выберем загрузочный диск с образом Ubuntu Server 16.04.3 LTS.

Установка Ubuntu Server 16.04.3 LTS (Шаг 3)

Установка Ubuntu Server 16.04.3 LTS (Шаг 22)
Нам нужно изъять диск из привода.
Устройства -> Оптические диски -> Изъять диск из привода

VirtualBox
Продолжаем.
Выбираем полное клонирование.

Установим PuTTY, для доступа через SSH

    Запустим установочный файл.

Установка PuTTY (Шаг 2)

Подключение через SSH к серверу

    Запустим клон нашей машины, что бы узнать ее ip адрес.
    Напишем команду:
    ifconfig

PuTTY
Мы должны наблюдать следующее:

Установка и настройка (Nginx + Apache) + PostgreSQL + PHP

Перейдем в режим суперпользователя
sudo su
Перейдем в корневой каталог
cd /
Добавим репозиторий PostgreSQL
wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O — | sudo apt-key add —

sh -c ‘echo «deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main» >> /etc/apt/sources.list.d/pgdg.list’
Добавим репозиторий PHP
add-apt-repository ppa:ondrej/php
Сделаем update
apt-get update
Сделаем upgrade
apt-get upgrade
У меня upgrade длился пять минут.
У становим python, он нам позже понадобится
apt-get install python
Приступим к установке Apache, PHP и PostgreSQL
apt-get install apache2 php7.2 php7.2-cli php7.2-curl php7.2-fpm php7.2-pgsql postgresql postgresql-contrib postgresql-server-dev-10 libapache2-mod-rpaf build-essential apache2-dev
По умолчанию, в PostgreSQL нету однобайтовых и беззнаковых чисел, поэтому мы их установим.
Есть расширение для PostgreSQL, pguint — github.com/petere/pguint
git clone https://github.com/petere/pguint.git /pguint
Перейдем в созданный каталог
cd /pguint
Теперь нам нужно скомпилировать это расширение (тут понадобится python, который мы установили ранее).
make

make install
Теперь, на сервер PostgreSQL, в нужную базу данных, где хотим использовать беззнаковые и однобайтовые числа, отправим:

Вернемся в корневой каталог
cd /
Установим Nginx, но перед этим остановим Apache, дабы он не занимал порт 80, иначе Nginx не установится.
service apache2 stop
Установка Nginx
apt-get install nginx
Отлично, теперь остановим и Nginx
service nginx stop
Настройка Apache
a2dismod mpm_event

a2enconf php7.2-fpm
Сменим порт Apache
nano /etc/apache2/ports.conf
Заменить

127.0.0.1 — означает то, что к Apache можно обратиться только по локальному адресу.
8080 — можете поставить любой свободный порт.
Перейдем в папку с доступными сайтами
cd /etc/apache2/sites-available
Создадим конфигурационный файл нашего сайда
nano domain-name.local.conf
И привести его к такому виду:

Посмотрим, что у нас лежит в /var/www
cd /var/www/

ls -F
Папка html, нам более не нужна, удалим ее вместе с содержимым
rm -R html
Создадим свою папку, со своим сайтом
mkdir domain-name.local/
Перейдем в папку с нашим сайтом
cd domain-name.local/
Создадим документ index.pnp
nano index.php
В него запишем:

С этим пока закончили.
Вернемся в корневой каталог
cd /
В apache стоит rpaf 0.6 и он не передаёт/принимает порт от nginx и не работает правильно, как надо. Поэтому его надо обязательно обновить.
wget -O rpaf_v0.8.4.tar.gz https://github.com/gnif/mod_rpaf/archive/v0.8.4.tar.gz

tar xvf rpaf_v0.8.4.tar

cd mod_rpaf-0.8.4/
Теперь скомпилируем
make

make install
Выходим в корневой каталог
cd /
Хорошо, продолжим настройку Apache.
nano /etc/apache2/apache2.conf
Заменить

Приведем в порядок rpaf.conf
nano /etc/apache2/mods-available/rpaf.conf
Приведем его к такому виду:

Включим наш сайт в Apache.
a2ensite domain-name.local.conf
И запустим наш Apache.
service apache2 start
C Apache закончили.
Настроим Nginx
nano /etc/nginx/sites-available/domain-name.local
Привести к такому виду:

Теперь создадим символьную ссылку на этот файл
ln -s /etc/nginx/sites-available/domain-name.local /etc/nginx/sites-enabled/domain-name.local
Отредактируем /etc/nginx/sites-available/default
nano /etc/nginx/sites-available/default
Уберем default_server.
И вставим перенаправление с www. и ip

Запускаем Nginx.
service nginx start
Отлично, можем проверить как оно работает.
Но перед этим отредактируем файл хоста C:\Windows\System32\drivers\etc
Открыть файл hosts через текстовый редактор, и в самый низ вставить:
192.168.0.101 domain-name.local
192.168.0.101 www.domain-name.local
Заменив ip и домен на свои.
В браузере перейдем по domain-name.local, и если вы делали все по этому рецепту, мы должны увидеть страницу с phpinfo.
Отлично, дело осталось за малым.
Настроим PostgreSQL.
Создадим нового пользователя PostgreSQL
sudo -u postgres createuser —superuser test-user
Войдем в СУБД
sudo -u postgres psql
И сменим новому пользователю пароль
\password test-user
Теперь новому пользователю нужно сменить тип подключения, для этого нам нужно найти pg_hba.conf файл.
Пишем


Покидаем СУБД
\q
И начинаем редактировать /etc/postgresql/10/main/pg_hba.conf
nano /etc/postgresql/10/main/pg_hba.conf
Ищем
# Database administrative login by Unix domain socket
Находим следующее:
# Database administrative login by Unix domain socket
local all postgres peer
Приводим к таком виду:
# Database administrative login by Unix domain socket
local all postgres peer
local all test-user md5
Перезагрузим PostgreSQL
service postgresql restart
Теперь войдем в СУБД через нового пользователя
psql test-user -h 127.0.0.1 -d postgres
Вводим пароль, и попадаем в СУБД.
Создадим тестовую базу данных

И сразу перейдем в нее
\c test_db
Подключим расширение pguint

И создадим тестовую таблицу

Заполним таблицу тестовыми данными

Посмотрим содержимое таблицы test_tb

Теперь попробуем вывести эти данные из php.
Закрываем соединение с СУБД
\q
Откроем /var/www/domain-name.local/index.php
nano /var/www/domain-name.local/index.php
И приведем к следующему виду:

Теперь проверим, и убедимся, что это работает


Отлично, мы настроили (Nginx + Apache) + PostgreSQL + PHP и он исправно работает.

Настроим FTP доступ к сайту
  1. listen=YES
  2. listen_ipv6=NO
  3. local_enable=YES
  4. write_enable=YES
  5. chroot_local_user=YES
  6. pam_service_name=ftp


Все хорошо, попробуем создать каталог.


Работает.
Настроим защищенное FTP соединение.
Остановим vsftpd
service vsftpd stop
Сгенерируем сертификат
openssl req -x509 -nodes -days 720 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.key -out /etc/ssl/private/vsftpd.pem
Тут вводим все, что вшей душе угодно

Простой сервер

Пишешь свою игру с поддержкой сети? Планируешь свой сайт или веб-сервис? Бот для телеграмма или навык Яндекс Алисы?

Всему этому нужен backend. А backend’у нужна инфраструктура.

Поднимаем свой сервер со своим доменом в интернете на Ubuntu Linux, настраиваем стек Nginx + Gunicorn + Flask, защищаем все соединения при помощи SSL.

Дисклеймер (Disclaimer)

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

Знатоков того самого единственного правильного рецепта я попрошу сегодня не беспокоится.

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

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

Что мы в итоге получим

Работающий на сервер.

На входе мы установим веб-сервер Nginx, который и будет принимать входящие запросы по http (80 порт) и https (443 порт) и передавать (проксировать) их серверу приложений gunicorn. Который в свою очередь запустит экземпляр python приложения, написанного с использованием микро-фреймворка flask, и передаст запрос туда. И именно там, в python коде и произойдет обработка входящего запроса, ответ на который заберет gunicorn и передаст в nginx, который уже вернет результаты пользователю.

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

Все это будет защищено сертификатом от Let`s Encrypt и встроенным файрволом. А управление, настройка и обновление — через подключение по SSH .

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

Регистрация доменного имени. Я для этой цели воспользовался сервисом регистрации от AWS — Route 53. Просто потому, что я давно им пользуюсь, и это не первый домен который я у них регистрирую, вы же, повторюсь, можете воспользоваться услугами абсолютно любого регистратора.

Да, возможно кто то скажет — ну зачем я буду тратить лишние 10-20 долларов на доменное имя, если можно ходить на сервер просто по IP? И да, и нет. Современные правила работы предполагают использование зашифрованного соединения с нашим сервером, а сервисы предоставляющие сертификаты требуют именно зарегистрированное доменное имя, а не IP адрес. Без использования шифрования пользователь, в лучшем случае будет получать постоянные сообщения браузера об угрозе безопасности, а в худшем вообще не сможет подключится.

Итак, я только зарегистрировал имя blueoctopus.cc, и на текущий момент на нем ни одной записи.

Саму виртуальную машину мы сделаем в Yandex Cloud. (Да, я все понимаю, но прошу не осуждать меня).

Ключи доступа.

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

Итак, откроем консоль кликнув на соответствующую иконку, либо нажав комбинацию клавиш Ctrl + Alt + T (Command (⌘) + T) и перейдем в каталог назначенный по умолчанию для хранения ключей.

Если такой папки нет, то ее необходимо создать

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

Если при попытке выполнить указанные выше действия вы столкнулись с ошибками, то вероятно вы используете ОС Wndows на своем ПК. Насколько мне известно, на Windows 10 c 2018 позволяет использовать SSH, только его необходимо отдельно установить. Официальный сайт Microsoft говорит, что:

  1. Откройте приложение Параметры, выберите элементы Приложения > Приложения и возможности, щелкните Дополнительные возможности.
  2. Просмотрите этот список и определите, установлено ли средство OpenSSH. Если нет, выберите пункт Добавить компонент в верхней части страницы и сделайте следующее:
    • Найдите Клиент OpenSSH и щелкните Установить.

Далее проблем с подключением у пользователей Windows быть не должно.

Продолжим. Напомню, у нас открыт терминал и мы находимся в папке .ssh

Напечатаем простую команду:

Генератор предложит вам указать уникальное название ключа, защитить его дополнительно паролем, и вроде бы будет еще пара вопросов, которые никто не читает.

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

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

Выведем содержимое публичного ключа и скопируем его в буфер обмена.

Для удобства, большой точности и безопасности копирования в буфер можно воспользоваться утилитами xclip для Linux и pbcopy для MacOS.

Виртуальная машина в Yandex Cloud

Теперь откроем консоль Yandex Cloud. Если у вас нет аккаунта, то его придется создать, думаю, что с регистрацией на Яндекс проблем возникнуть не должно.

Далее в меню слева выбираем раздел Compute Cloud и нажимаем кнопку Создать ВМ. Я специально решил делать этот пример на сервисах яндекса, поскольку у них есть подробное описание каждого пункта меню на русском языке.

Большинство параметров в этом примере мы оставим по умолчанию, либо выберем минимальные, поскольку при возникновении потребности в дальнейшем увеличить их не составит труда.

Давайте быстро пройдемся по пунктам:

Имя и описание — все понятно, уникальное название и некоторые подробности, что бы вы сами не забыли что это за виртуалка крутится у вас в облаке.

Зона доступности — мне яндекс предложил ru-central-b, так и оставлю.

Операционная система — Ubuntu 20.04

Диск — HDD на 13 Gb

Платформа — Intel Ice Lake

vCPU — 2 (Количество ядер процессора, наверное хватило бы и одного, но яндекс так уже не предлагает)

Гарантированная доля vCPU — 20% (Минимальная гарантированная доля производительности. По моему опыту, при настройке загрузка ЦП не превышает 1-2%, так что этой доли нам более чем достаточно не только для настройки сервера, но и для небольших сервисов развернутых на нем.)

RAM — Очевидно оперативная память. Выбирайте минимум 2 GB

Прерываемая — самый спорный пункт. Его выбор делает большую скидку на ВМ, однако это дает право яндексу остановить ее в любой момент. Сервер будет остановлен корректно, так что за сохранность данных переживать не стоит, но включать его обратно прийдется “вручную”. Для этого урока я этот пункт включу, но если настраиваемый вами сервер планируется в дальнейшем использовать в рабочем режиме, то выбирать этот пункт точно не стоит.

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

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

В любом случае, когда вы выберите пункт “список”, то скорее всего получите сообщение о том, что в вашем облаке нет свободных статических IP-адресов. В конце этого сообщения будет ссылка с названием “список адресов”, смело нажимаем на нее и попадаем в раздел Virtual Private Cloud.

Выбираем в меню слева пункт “IP-адреса”, и потом жмем на кнопку “Зарезервировать адрес”, тут главное проследить что бы зона доступности, где резервируется адрес была той же, где создается сервер. Если все правильно — нажимаем “Зарезервировать” и возвращаемся к конфигурированию нашей ВМ.

Теперь при настройке публичного адреса в пункте список будет доступен наш зарезервированный IP. Выберем его и перейдем к настройке доступа.

Сервисный аккаунт — нужен если вы планируете получать доступ с виртуальной машины к другим ресурсам облака. (Например к серверу базы данных). В данном случае в нем нет необходимости.

Логин — имя пользователя в на сервере. Тут все просто, главное не выбирайте root или www-data. Я укажу просто max.

SSH-ключ — содержимое того самого server_key.pub, которое мы скопировали в буфер обмена. Просто вставьте его сюда.

Доступ к серийной консоли не включаем. Считайте это аварийным режимом, при штатной работе сервера он должен быть отключен.

Ну вот, теперь внимательно смотрим на правую колонку, и если цена нас устраивает — жмем на кнопку Создать ВМ внизу страницы.

Подключение к серверу

Наша виртуальна машина готова. Поскольку мы еще не строили доменное имя, то давайте подключимся по IP

Тут все просто: login@ip-adress

Login — Логин, который мы указали при конфигурации.

ip-adress — Зарезервированный за ВМ статический адрес.

Если вы создали пароль к своему ключу, то после нажатия enter вам предложат его ввести. Если все сделано правильно, то увидим подобное сообщение:

Все в порядке, так и должно быть, это сервер присылает отпечаток ключа для проверки. Просто напечатаем yes и нажмем enter еще раз.

Все, теперь мы видим приглашение командной строки нашей виртуальной машины.

Установка утилит

Давайте для начала обновим данные о репозиториях:

И, при необходимости, обновим сами пакеты:

Жмем (Y)es и немного подождем.

Кстати, пока идет обновление, обращу ваше внимание, что мы использовали sudo, для временного повышения полномочий, но пароль запрошен не был. Это странная особенность ВМ, и если вас это беспокоит — напишите, расскажу как это исправить.

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

Опять же жмем (Y)es и немного подождем.

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

mc — Midnight Commander, консольный двух-панельный файловый менеджер. Большинство операций, я выполняю через него.

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

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

wget — качает файлы по ссылке. Можно конечно качать и с помощью curl, но эта мне как то привычнее.

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

zip и unzip — очевидно архиваторы zip. Родные архиваторы bzip2 и gzip как правило есть всегда, а эти бывает, что и не установлены на старте.

Сервер SSH

Следующим шагом пройдемся по параметрам сервера SSH, который отвечает за обработку нашего подключения.

Для этого откроем файл с настройками параметров.

Это можно сделать напечатав в командной строке:

Либо запустив midnight commander, найти, выделить файл и нажать F4. При первом запуске МС попросить выбрать предпочитаемый редактор, рекомендую выбрать nano

И да, большую часть команд и правок мы будем вносить используя sudo, (Substitute User and do, дословно «подменить пользователя и выполнить»). Это необходимо для повышения наших полномочий до уровня root

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

Пройдемся по файлу сверху вниз, и первый параметр который нам нужен выглядит так:

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

Раскомментируем строку и ставим значение в no:

Никаких удаленных авторизаций и входов для root

Следующий параметр отвечает за возможность авторизации по SSH ключу. Мы именно таким способом и зашли на наш сервер.

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

Дальше будет длинная строка с параметрами отделенными табуляцией:

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

И последний обязательный пункт:

Удаляем символ комментария и устанавливаем параметр в no. Никаких парольных идентификаций, только файлы ключей.

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

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

Все. Теперь нажимаем Ctrl + X и подтверждаем запись файла.

Если вы использовали midnight commander то нажмите Ctrl + O, это скроет панели, отобразив терминал, но не закроет сам MC, так же как и не прервет сессию sudo. Повторное нажатие вернет панели обратно.

Перезапустим наш сервис SSH, что бы применить внесенные изменения.

Можно отключится напечатав exit, и подключится опять, для проверки работоспособности, он это необязательно.

Устанавливаем Nginx

Именно он будет отвечать за прием входящих запросов и проксированием их в глубь нашего сервера.

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

И стразу же проверим его статус:

Работает. Да, мы еще не настроили доменное имя, но если мы откроем браузер и введем там внешний IP нашей виртуальной машины, то мы увидим стандартную страницу приветствия Nginx. Так же можно воспользоваться утилитой curl, не зря же мы ее ставили.

178.154.219.150 — вам следует заменить на свой.

Стандартный HTML лежит в папке /var/www/html, при желании можете его заменить на любой другой. Мы в рамках данной инструкции делать этого не будем, поскольку использование данной папки в дальнейшем не планируется, а стандартная конфигурация домена будет отключена.

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

Что бы не возвращаться к этому в дальнейшем — давайте сразу расскажу про основные команды которые необходимо знать при работе с Nginx:

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

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

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

Эта команда целиком остановит и запустит заново все службу, разорвав все текущие соединения, что не всегда хорошо. Точнее всегда не хорошо.

Вы можете сказать, а какая разница, ну нажмет пользователь обновить страницу, а многие может и вообще не заметят этих секунд перезагрузки. Опять же верно, но отчасти. А представьте, что у нас на базе этого сервера работает приложение, которое пишет игровую статистику вашей же разработанной игры? Например получает json файл с новым пользовательским рекордом, и готовится записать его в базу данных. А тут раз, и все потухло. Рекорд не записан, игра напрасно ждет ответа от сервера о статусе операции, пользователь страдает. Или у нас работает бек-энд бота для телеграма или навыка Яндекс Алисы, а там вообще время ожидания 2 и 3 секунды. Получится, что пользователь спросил что то у колонки, а в ответ тишина, Яндекс ждет 2 секунды и отключает сеанс с навыком. Так с пользователями приличные разработчики не поступают.

В общем, используйте этот метод только в том случае, когда точно понимаете зачем это делать.

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

Либо воспользоваться внутренней командой самого Nginx:

(Да и официальная документация рекомендует именно ее).

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

Ну и давайте убедимся, что наш веб-сервер будет запущен при старте операционной системы:

Если все в порядке — двигаемся дальше, если нет, то добавим его в автозагрузку:

Некий промежуточный итог

Наш сервер работает.

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

Например, нет необходимости активировать файрвол, если планируется использование специальных групп безопасности (security groups) работающих на уровне инстанса ВМ. Либо нет смысла настраивать защищенное соединение по 443 порту, если сервер будет работать где то во внутреннем кластере, получая трафик только вышестоящего nginx, выполняющего роль балансировщика нагрузки.

Но давайте продолжим двигаться к нашей цели, а именно сервер для Flask приложения.

Настройка UFW

Не смотря на свое название Uncomplicated FireWall, это все таки не файрвол, а оболочка для стандартного для Linux брандмауэра iptables. А вот то, что он действительно Uncomplicated (несложный, незапутанный) это правда.

Начнем сначала. Проверим наличие ufw:

Если получили сведения о состоянии, например неактивен, то все в порядке, двигаемся дальше. Если нет — то его необходимо установить:

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

Поскольку в планах включить поддержку IPV6 на нашем веб-сервере, то нам нужно убедится, что в нашем файрволе она включена:

Для этого откроем файл с конфигурацией:

Нас интересует первый же параметр. Убедитесь, что и у вас он имеет значение yes:

Сохраняем и закрываем файл. Если вы как и я используете редактор nano, то просто нажмите Ctrl+x

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

Нас это не устраивает, поскольку необходимо разрешить как минимум доступ по SSH, HTTP и HTTPS.

Не торопитесь открывать файл конфигурации, он более нам не нужен. Мы сделаем это по другому.

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

Список доступных приложений можно посмотреть так:

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

Сами файлы лежат в отдельном каталоге, давайте посмотрим его содержимое:

(Либо просто откройте его через MC)

Мы опять же видим два файла nginx и openssh-server, которые созданы автоматически при обнаружении, и содержание которых перечислила нам предыдущая команда.

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

[Nginx HTTP] — Название раздела. Это то, что нам покажет команда sudo ufw app list title= — Заголовок description= — Описание раздела ports= — Порты, которые необходимо открыть для сервиса

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

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

Итак, создадим пустой файл:

И наполним его таким содержимым:

Сохраняем, выходим. И давайте еще раз посмотрим на список приложений:

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

Но следует помнить, что добавление приложения в эти файла, не включает доступ к нему автоматически, это делается отдельной командой:

Так что давайте включим некоторые правила на нашем сервере:

Первое и самое важное, повторюсь — без него, при активации UFW мы потерям возможность удаленного доступа.

Далее разрешим порты веб-сервера:

И наш тестовый Flask

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

Вот теперь мы можем включить наш файрволл:

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

Удаляется правило аналогично:

Либо можно получить нумерованный список правил:

И удалить его по номеру:

Целиком UFW можно отключить:

В качестве бонуса.

Если не уверены в команде, добавьте добавьте этот ключ.

–dry-run

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

A — Запись

Или самая главная главная запись.

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

Тут все просто, открываете панель управления у вашего доменного регистратора, выбираете домен и жмете что то типа “добавить запись”, тип записи — А, значение — публичный IP. Убедитесь, что сделали его постоянным, иначе при следующем подключении вам его сменят.

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

Flask
И pyhon

Для тех кто не в курсе немного википедии:

Python — Высокоуровневый язык программирования общего назначения с динамической строгой типизацией и автоматическим управлением памятью… и т.д.

Flask — Фреймворк для создания веб-приложений на языке программирования Python, использующий набор инструментов Werkzeug, а также шаблонизатор Jinja2. Относится к категории так называемых микрофреймворков — минималистичных каркасов веб-приложений, сознательно предоставляющих лишь самые базовые возможности.

В общем Flask, это то, во что мы обернем нашу Python программу для доступности ее из сети. Или правильнее, это каркас, на котором мы и построим нашу программу.

Давайте для начала проверим, вдруг на вашей ВМ не установлен python:

(А так вообще бывает?)

Если ответ будет: Python 3.x.xx — все в порядке, иначе его нужно установить:

Так же нам понадобится менеджер пакетов:

Работает он по принципу apt, которым пользуемся для установки приложений на этом сервере, только внутри python. Синтаксис так же аналогичен. Не волнуйтесь, дальше все покажу.

Теперь нужно установить несколько инструментов для разработки:

(Точнее я уверен, что они уже стоят, но проверить это необходимо. Как я уже писал ранее, если пакет уже есть в системе — apt просто пропустит этот шаг.)

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

build-essential — информационный список пакетов необходимых для dpkg

libssl-dev — пакет для работы с SSL и TLS

libffi-dev — интерфейс чужеродных функций. Позволит вызывать функции написанные на других языках.

python-dev — содержит все необходимое для компиляции модулей расширения

setuptools – стандартный способ создавать пакеты в Python.

Ну и поскольку лучшей практикой считается запуск приложения в изолированном (виртуальном) окружении, то давайте так же установим его:

Проект будет располагаться в домашней директории. (/home/’имя пользователя’), поэтому переймем туда и создадим папку для него:

(Если используете МС — просто нажмите F7.)

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

Зайдем в созданный каталог

И создадим виртуальное окружение:

Через ключ -m мы вызвали модуль venv, который создал для нас изолированное окружение с именем octopusenv

И при помощи системной команды source загрузим его переменные. (Активируем виртуальное окружение)

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

На случай, если вам понадобится прерваться — отключить окружение можно командой:

Только не забудьте его снова включить для продолжения настройки.

Для начала установим средство распаковки пакетов python:

Дальше ставим Flask, и еще один элемент, без которого нам не обойтись:

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

WSGI (расшифровывается как Web Server Gateway Interface — интерфейс шлюза Web-сервера) — это простой и универсальный интерфейс взаимодействия между Web-сервером и Web-приложением, впервые описанный в PEP-333

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

В итоге, цепочка прохождения запроса будет выглядеть как то так:

Интернет -> Nginx -> Gunicorn -> Flask + Python, и обратно.

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

Конечно писать код прямо так, на сервере не сама лучшая затея, лучше воспользоваться предназначенными для этого IDE средствами доставки, но небольшой файлик-заглушку давайте сделаем.

И пишем следующий код:

Почти готово, остался index.html, которая должна быть показана пользователю при обращении на главную страницу сайта. По умолчанию Flask будет искать его в папке templates своей директории.

И средствами SSH можно скопировать в нее любой статичный index.html

Если уж совсем никак не найти вам такой, то:

И вставьте в него код ниже, должно сработать.

По умолчаниюFlask использует, доступ к которому мы с вами уже открыли при настройке UFW, поэтому просто запустим его:

И если мы видим что то похожее на это:

То мы все сделали правильно и наше приложение работает. Если сейчас открыть главную страницу нашего сайта, то мы увидим наш index.html, а перейдя в раздел /api2 — красиво отрисованный json ответ.

Думаю стоит сделать некоторое уточнение. Я тут при записи видео столкнулся с тем, что точно не помню как передать порт в адресной строке 🙂

Приложение запущено в режиме отладки на 5000 порту, и соответственно обратится к серверу мы должны с его указанием. Если явно не указать порт, то мы получит ответ по порту 80, который “слушает” наш Nginx

У нас нет еще настроенного сертификата шифрования, и поэтому во многих браузерах это нужно указать явно.

Запросы в адресной строке в моем случае буду выглядеть так:

http://blueoctopus.cc:5000 — Индексная страница, с генерацией стандартного HTML ответа

http://blueoctopus.cc:5000/api2 — Тест ответа JSON

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

Gunicorn

По сути, это еще один веб сервер.

Где то выше я уже писал о предполагаемой схеме работы:

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

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

Если вы вышли из виртуального окружения нашего сервиса, то необходимо его опять активировать:

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

И конечно давайте запустим наш сервер приложения:

Именно здесь мы передали хост и порт, которые должен “слушать” Guicorn. Мы ему как бы сказали: При поступлении запроса с любого интерфейса на 5000 порт запустить приложение app и передать его туда.

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

Все в порядке, остановим сервер — ctrl+x и закроем виртуальное окружение.

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

Инициализацией и управлением службами на нашем сервере занимается давно ставшая стандартом подсистема systemd, именно для нее мы писали команды начинающиеся на systemctl.

Systemd запускает сервисы, которые описаны в его файлах конфигурации, которые называют юниты, расположены на в разных местах системы, в зависимости от метода установки. Нас интересует папка /etc/systemd/system/, куда помещают файлы созданные пользователем. (Ну хорошо, системным администратором).

Создадим такой файл:

Думаю, вас уже не удивит, если я скажу, что файл имеет такой синтаксис:

Стандартный юнит должен содержать минимум три секции: [Unit], [Service], [Install], поэтому давайте их и опишем для нашего сервиса:

/home/max/blueoctopus/octopusenv/bin/gunicorn — Полный путь к исполняемому файлу.

–workers 2 — Количество процессов запускаемых сервером, я поставил два, по количеству ядер процессора на нашем сервере.

–bind unix:flaskproject.sock — поскольку все в Linux представляется как файлы, то и точку взаимодействия между Nginx и gunicorn мы опишем как специальный тип файла .sock (Вообще через этот файл кто угодно может взаимодействовать с сервером приложений, но в нашем случает это будет именно Nginx).

-m 007 — маска прав доступа к создаваемому файлу написанная по стандарту umask. В данном случае дает полный доступ указанному пользователю и группе, и запрещает всем остальным (u=rwx,g=rwx,o=)

wsgi:app — ну и наконец код, который должен запустить gunicorn. Это приложение app импортированное в файле wsgi.py

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

Команды управления стандартные для systemd:

И вот теперь мы добавим его в автозагрузку:

Nginx proxy config

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

Напомню, что мы создали unit — файл для gunicorn, в котором указали некой точкой связи с nginx служебный файл gunicorn.sock. Теперь он при старте системы автоматически загружается и ожидает появления в нем входящих запросов.

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

Либо, традиционно открыть расположение используя Midnight Commander (mc)

sudo можно не использовать, поскольку пока никаких правок вносить не планируется. Давайте просто убедимся, что в конце модуля http есть такие строки:

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

будут подставленный файлы из папки sites-available, на которые ссылаются ярлыки из папки sites-enabled. Но поскольку эта часть предполагает настройку нескольких доменов на одном сервере, чего не предполагает этот проект — мы ее использовать не будем, и даже удалим единственный ярлык @default из sites-enabled.

Нас интересует часть со строкой:

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

В этом есть еще один плюс — что бы вернуть систему в дефолтное состояние достаточно будет просто удалить файл из conf.d директории.

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

Установка Ubuntu Server 20.04

В апреле 2020-го года команда разработчиков Canonical выпустила долгожданный LTS-дистрибутив Ubuntu 20.04 (Focal Fossa). Поддержка данной версии планируется в течении последующих пяти лет. «Focal» переводится как «центральный» или как «фокусный». Fossa (если переводить дословно) — самое крупное хищное млекопитающее, обитающее на острове Мадагаскар.

Однако, если внимательно глянуть на слово «Fossa», можно предположить, что корень этого слова — «Foss» — наводит также и на мысль об аббревиатуре — «Free and Open Source Software». В этой статье мы рассмотрим как выполняется установка Ubuntu Server 20.04, а также что нового нам подготовили разработчики.

Что нового в Ubuntu 20.04 LTS Server?

Из значимых обновлений в Ubuntu 20.04 LTS Server (Focal Fossa) хочется прежде всего отметить LTS-ядро версии 5.4, что означает появление ряда нововведений, улучшений безопасности, повышение производительности и добавление новых возможностей.

Например: применён алгоритм сжатия ядра без потерь LZ4, что заметно сократило загрузку ОС; появилась поддержка по умолчанию файловой системы от Microsoft exFAT; задействован режим блокировки ядра Linux Lockdown Kernel, предотвращающий выполнение произвольного кода от UID даже с правами root.

Кроме того, реализована полнофункциональная поддержка Кubernetes 1.18. Продолжается внедрение нового формата установочных пактов SNAP. Полностью прекращена поддержка 32-разрядных версий. Даже если у вас сейчас 32-разрядная Ubuntu 18.04, обновиться до версии 20.04 уже не получится.

Минимальные требования к аппаратуре

По данным с официальной страницы Canonical:

  • Процессор: одноядерный, 2 ГГц.
  • ОЗУ: 2 Гб.
  • Жёсткий диск: 10 Гб.

Рекомендуемые характеристики для получения среды с приемлемым уровнем комфорта по производительности:

  • Процессор: двухъядерный, 2 ГГц.
  • ОЗУ: 4 Гб.
  • Жёсткий диск: 25 Гб.

Установка Ubuntu 20.04 LTS Server (Focal Fossa)

Шаг 1. Загрузка образа

На официальном сайте нужно скачать необходимый образ дистрибутива. На выбор предлагается два варианта: Desktop image — с возможностью попробовать его без установки на компьютер в режиме LiveCD и Server install image — для установки сразу:

В данном случае скачиваем вариант Server install image.

Шаг 2. Запись образа флешку

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

Шаг 3. Запуск установщика образа

Настоятельно рекомендуется иметь проводное подключение к Интернет на сервере, на котором вы будете устанавливать Ubuntu. Это позволит оперативно обновить программное обеспечение непосредственно в процессе инсталляции.

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

Шаг 4. Выбор языка

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

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

Шаг 5. Обновление загрузчика

На момент написания статьи вышло обновление загрузчика Ubuntu. Установщик автоматически предложит скачать обновление с внешнего репозитория:

Соглашаемся обновить установщик — выбираем пункт меню Update to the new installer.

Шаг 6. Выбор языка раскладки клавиатуры

В ходе дальнейшей установки будет предложено выбрать раскладку клавиатуры:

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

Подтверждаем, выбрав пункт меню Done, и продолжаем.

Шаг 7. Настройка сети

Далее будет предложено настроить сетевые подключения. В данном конкретном случае интерфейс автоматически подхватил IP-адрес с DHCP-сервера (10.0.2.15/24):

Выбрав требуемый сетевой интерфейс, можно настроить его вручную, задать статический IP-адрес для IPv4 или IPv6, создать VLAN или просто посмотреть детальную информацию о текущем состоянии подключения:

Помимо прочего, если у нас имеется несколько активных сетевых интерфейсов, можно уже на этапе установки объединить их между собой для увеличения пропускной способности и большей надёжности, сделав так называемый bonding. Для этого необходимо выбрать пункт Create bond:

Далее остаётся лишь отметить активные сетевые интерфейсы (Devices), установить режим балансировки (Bond mode) и другие параметры.

Шаг 8. Настройка прокси

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

В данном случае этот режим нам не нужен. Подтверждаем, выбрав пункт меню Done и оставив поле Proxy address пустым.

Шаг 9. Выбор зеркала

Серверы репозиториев — зеркала с установочными пакетами Ubuntu, расположенные по всему миру (список можно посмотреть на официальном сайте). Установщик сам определяет наиболее близко расположенное к нему зеркало для обеспечения лучшей скорости и стабильности скачивания необходимых компонентов. Однако иногда стоит указать URL-адрес зеркала вручную, заполнив поле Mirror address:

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

Шаг 10. Разметка дисков

Самый простой способ разметки диска, подходящий новичкам — предоставление установщику всего диска в распоряжение по умолчанию (Use an entire disk):

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

Отмечаем клавишей Пробел флажок Custom storage layout и подтверждаем, выбрав пункт меню Done.

Выбираем из списка AVAILABLE DEVICES диск, который будем использовать:

В контекстном меню выбираем пункт Add GPT Partition:

Для начала создадим SWAP-раздел, выполняющий ту же роль, что и файл подкачки в Windows. Обычно задают размер, вдвое больший объёма оперативной памяти компьютера. Размер указывается в гигабайтах. В нашем случае ОЗУ — 4 Гб, соответственно, SWAP будет 8 Гб.

Указываем выбранный размер в поле Size. В раскрывающемся списке Format выбираем тип SWAP и далее выбираем пункт меню Create:

Раздел SWAP успешно создан. Объём свободного места на диске, на котором он был создан, соответственно уменьшился:

Продолжая разметку, повторим действия с выбором диска. По умолчанию будет предложена точка монтирования (Mount), распространяемая на весь корневой раздел /. Согласимся с этим.

Также предлагается выбрать тип файловой системы в раскрывающемся списке Format. По умолчанию это файловая система Ext4, выберем её. В поле Size можно указать требуемый размер, но мы будем использовать всё незанятое пространство, поэтому просто оставим это поле пустым. Далее нажимаем на пункт меню Create:

Как видим, у нас готовы для создания SWAP-раздел и том с используемой для него файловой системой Ext4 и точкой монтирования /. Выбираем пункт меню Done.

Внимание! Производимые изменения на диске, на который устанавливается Ubuntu 20.04 LTS Server (Focal Fossa), станут необратимыми, вся информация на нём будет затёрта.

Продолжаем установку, выбираем пункт меню Continue:

Шаг 11. Создание пользователя и настройка имени сервера

В следующем окне установщика необходимо указать имя пользователя в поле Your Name, имя сервера в поле Your server’s name, логин для входа в систему в поле Pick a username и дважды ввести пароль учётной записи в поля Choose a password и Confirm your password:

Шаг 12. Установка OpenSSH-сервера

Для удалённого управления сервером Linux используется специальный защищённый SSH-протокол (Secure Shell).

Если вы не планируете все операции по настройке сервера делать локально, настоятельно рекомендуем установить OpenSSH. Отмечаем клавишей Пробел флажок Install OpenSSH Server:

Опционально в этом же окне для авторизации по протоколу SSH можно добавить SSL-ключи.

Однако пока оставим всё по умолчанию, ключи можно создать или импортировать после установки.

Шаг 13. Выбор и установка приложений

В следующем окне можно сразу же установить популярные серверные окружения и приложения: Docker, Kubernetes, различного рода бенчмарки или инструменты для взаимодействия с облачными провайдерами (aws-cli, google-cloud-sdk и др.):

Пока не будем устанавливать,. при необходимости это можно сделать после. Для продолжения выбираем пункт меню Done.

Шаг 14. Установка системы

В следующем окне мы будем наблюдать за процессом установки ОС и выбранных нами пакетов программ:

Шаг 15. Завершение установки

После того, как ОС и все пакеты будут проинсталлированы, появится окно с сообщением Installation Complete!

Выбираем пункт меню Reboot для выполнения перезагрузки компьютера, параллельно извлекаем носитель с дистрибутивом Ubuntu 20.04 LTS Server (Focal Fossa).

Шаг 16. Проверка версии Ubuntu Server

После перезагрузки попадаем в стандартную консоль управления Linux-сервером. Авторизуемся в системе, вводя логин и пароль. Для того, чтобы проверить версию Ubuntu Server, следует ввести команду:

Как видим, в строке Description указано: Ubuntu 20.04 LTS.

Выводы

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

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

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

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