Туториал Деплой и менеджмент вашего сервера с помощью Docker

Введение
Итак, написать данную статью мне пришла идея после того, как я узнал что многие сервера до сих пор запускают с помощью screen. Если вы читаете данный текст, то знайте, что вы можете забыть об этой утилите как абсолютно бесполезной и вредной для любых (а не только майнкрафт) серверов. Почитав пару гайдов на данном и соседних форумах я заметил что все без исключения форумчане пытаются вручную самостоятельно настраивать сервера, скачивать и настраивать все необходимые утилиты, а ради чего? Чтобы сделать по сути всё тоже самое, что Docker делает за 5 минут.

Что такое Docker?
Docker - в переводе с англ. "грузчик" - это утилита контейнеризации, которая позволяет развёртывать приложения в изолированных окружениях - контейнерах. Краткая справка откуда вообще это взялось. В международной логистике уже давно принято за стандарт перевозить что бы то ни было в специальных контейнерах. Независимо от содержимого, контейнеры с легкостью загружаются на поезда, с поездов на корабли-контейнеровозы, с кораблей в грузовые самолёты и т.д. Такая мера стандартизации позволила значительно ускорить логистику, поскольку рабочим не требуется постоянно "играть в тетрис" на каждом логистическом узле.

Итак, Docker позволяет нам переносить наше приложение (будь то Minecraft сервер или что либо другое) в виде Docker-образа (Docker Image). Затем этот образ развёртывается на сервере в виде контейнера (Docker Container), который в свою очередь является некоторым окружением для нашего приложения. Что такое окружение? Это всё, что требуется для работы нашего приложения: файлы (Docker Volumes), настройки (конфигурации), секреты (Docker Secrets) и многое другое. Если бы мы рассматривали это на примере классического майнкрафт сервера, то образом нашего приложения мы бы назвали Spigot.jar, а окружением всё остальное: server.properties, plugins, world и т.д. Основная идея в том, что мы можем с лёгкостью скачать на наш сервер тот или иной образ с помощью одной простой команды, а затем без всякого труда создать контейнер и сразу же его запустить.

Как устроен Docker Image?
Это очень важная часть нашего туториала, поскольку понимание как устроен образ, даст вам понять почему Docker - это невероятно крутой инструмент. Итак, почти все образы основываются на других образах. Это первое, что нам нужно понять. Если мы посмотрим на один из самых популярных докер-образов для майнкрафт сервера itzg/minecraft-server, то увидим, что по большому счёту данный образ создаётся на основе образа Java, та в свою очередь основывается на образе той или иной ОС (linux/oracle/alpine, windows, или др.). Таким образом, устанавливая образ майнкрафт-сервера, докер сразу же подтащит для него подходящую версию Java и все необходимые библиотеки\инструменты для корректной её работы.

Одна из основных идей устройства образа состоит в том, что все они состоят из слоёв. Слой представляет собой определённый этап сборки образа. Например, мы с вами формируем образ нашего майнкрафт сервера, делается это с помощью Dockerfile:

Код:

FROM ghcr.io/graalvm/graalvm-ce:ol8-java11 AS Java

Здесь мы определили, что наш образ основывается на образе Java (это первый слой).

Код:

ENV TYPE=VANILLA VERSION=LATEST EULA="True"

Устанавливаем переменные окружения, а именно указываем что тип сервера будет ванильный, версия - последний релиз, eula = True. Это второй слой.

Код:

COPY --chmod=644 plugins/ /app/plugins/

Копируем папку с плагинами в наш образ

Код:

ENTRYPOINT [ "/start.sh" ]

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

Инструкции FROM, COPY, ENTRYPOINT и мн. др. - это начало каждого нового слоя. Изюминка в том, что Docker кеширует каждый слой на вашем устройстве и при повторной сборке образа, если тот или иной слой не изменился, то он будет подтянут из кеша. Это делает образ более гибким и менее ресурсоёмким для развёртывания, поскольку если на вашем сервере уже есть образ Java, то при деплое вашего сервера, он не будет скачивать его с hub.docker.com, а возьмёт уже имеющийся.

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

Код:

docker run -d -it -p 25565:25565 -e EULA=TRUE itzg/minecraft-server

Пока не разбираю её, оставим это на десерт.

Я не буду залезать в дебри того как устроен докер, но вы можете довериться профессионалам в вопросе насколько он эффективен так как метод контейнеризации (не только с помощью Docker) уже давно используется всеми крупными компаниями, в том числе такими именитыми как Microsoft, Google и Amazon.

Как устроен Docker Container?
Мы уже успели обсудить что такое контейнер, а также я уже сказал, что контейнер - это окружение для нашего образа. В действительности это не совсем так. Под капотом Docker устроен куда сложнее, но нам с вами понимать это не совсем обязательно. Устройство Docker Container напоминает в каком-то смысле отдельную ОС. Одна из фишек докера как раз в том, что вы можете без особого труда запускать на вашем сервере сразу несколько контейнеров одного и того же образа, например, 2, 3 или 10 контейнеров MySQL или Redis или чего только пожелаете - и всё это будет работать слаженно, без всяких проблем с доступом к ресурсам серверной машины и т.д. При этом, наличие изолированных контейнеров, как раз из-за особенностей устройства докера, не нагружает вашу систему так, как нагружали бы две или три полноценные операционные системы на том же самом сервере.

Контейнер состоит из монтированных папок (Docker Volumes), переменных окружения, секретов (Docker Secrets) и т.д. и т.п. Вся эта "котовасия" нужна нам для корректной работы нашего основного приложения. Однако, стоит отметить, что в большинстве ситуаций Docker Container - это Stateless приложение, то есть зависимое от перезапуска. Это означало бы, что в случае остановки\перезапуска вашего сервера, вся информация о нём (в том числе игровая карта, данные игроков и т.д.) полностью терялись и начиналось бы всё с чистого листа, но нам на помощь приходят Docker Volumes.

Docker Volumes - или в простонародии монтированные папки - это буквально папки (или более корректнее - директории), которые при запуске вашего контейнера докер присоединяет к окружению образа. Таким образом, если вы создадите volume для вашей игровой карты и укажете докеру монтировать его для конкретного контейнера, то Docker предоставит контейнеру доступ к этой папке, а папке - доступ к контейнеру. После остановки вашего контейнера, volume не будет утерян, а вы, например, сможете спокойно скачать эту директорию или каким-либо иным образом взаимодействовать с ней. Проще говоря, все те файлы, которые вы хотите сохранять при перезапуске, следует хранить в volume, а всё то, что вам потребуется только при работе сервера, собирать в образе.

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

Код:

docker run -d -it -p 25565:25565 -e EULA=TRUE itzg/minecraft-server

В данной команде мы сообщаем докеру о желании запустить контейнер в detached (-d) режиме на основе образа itzg/minecraft-server, который ему следует скачать с hub.docker.com, затем мы сообщаем ему о желании установить для нашего контейнера переменную окружения EULA=TRUE. В данном образе эта переменная отвечает за автоматическое подтверждение eula. После чего мы определяем что мы должны слушать порт 25565 извне и направлять всю поступающую по нему информацию в контейнер по порту 25565. То есть, Docker не будет слушать никакие другие порты, кроме тех, что вы сами указали ему слушать (где-то слышится радостный крик желающих выкинуть UFW, поскольку Docker гораздо надёжнее в вопросе защиты сервера, более того Docker настолько "гигачад", что настройки UFW им впринципе игнорируются). Тут важный момент, что если бы вы запустили ваш сервер на другом, отличном от 25565, порту, то вам бы следовало перенаправлять соединения на другой внутренний в контейнере порт, то есть данный аргумент выглядел бы так:

Код:

-p 25565:1000

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

Код:

-p 1000:25565

Теперь ваш сервер доступен по порту 1000, но внутри контейнера соединения проходят по порту 25565.

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

Код:

docker run -d -it -p 25565:25565 -e EULA=TRUE TYPE=PAPER itzg/minecraft-server

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

Код:

docker run -d -it -p 25565:25565 -e EULA=TRUE TYPE=PAPER VERSION=1.20.6 itzg/minecraft-server

В данном образе для монтирования существует mountpoint "data/". Это означает, что наш с вами контейнер внутри для себя так или иначе создаст директорию data/ со всеми важными данными, другой вопрос будет она удалена при остановке сервера или будет подгружена извне с помощью механизма Volume. Для того, чтобы замонтировать папку к нашему контейнеру, её для начала нужно создать:

Код:

mkdir /home/minecraft_server/data/

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

Код:

docker run -d -it -p 25565:25565  -v /home/minecraft_server/data/:/data/ -e EULA=TRUE TYPE=PAPER VERSION=1.20.4 itzg/minecraft-server

В данной команде мы видим аргумент -v, а также два разных пути: один до двоеточия, другой после. Тот, что "до" - это расположение вашей директории на вашем сервере. Тот, что "после" - это куда именно докер должен замонтировать вашу папку в контейнере. Как я уже сказал, данный образ имеет mountpoint /data/, и мы просто монтируем именно туда. Если вы найдёте другой образ майнкрафт сервера, например, только для Spigot, то читайте к нему документацию куда у него идёт монтирование.

Теперь, при запуске нашего контейнера, папка /home/minecraft_server/data/ заполнится важными для нас данными,

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

 

Утилита Docker Compose или докер "на максималках"
Итак, надеюсь вы уже сами понимаете насколько докер могущественный инструмент. Но что если я вам скажу, что всё что было до этого, это лишь прелюдия? А оно так и есть.

Docker Compose это плагин, который поставляется вместе с Docker по умолчанию. Я рекомендую при установке Docker специально проверить, что также устанавливается Compose Plugin. Для чего же он нужен?

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

Чтобы начать работу с docker compose нам нужно создать основной файл конфигурации нашей будущей связки docker-compose.yml. Для нашего сервера он будет выглядеть примерно так:

Код:

version: "3.3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - "25565:25565"
    restart: always
    environment:
      EULA: "true"
      TYPE: "PAPER"
      MOTD: "Some motd"
      TZ: "Europe/Moscow"
      DIFFICULTY: "hard"
      MAX_PLAYERS: 666666
      ENABLE_COMMAND_BLOCK: "false"
      ONLINE_MODE: "true"
      SERVER_NAME: "Some server"
      INIT_MEMORY: '2G'
      MAX_MEMORY: '4G'
      USE_AIKAR_FLAGS: "true"

В данном случае я сразу же привёл примеры настроек. В itzg/minecraft-server вы можете практически управлять всеми настройками server.properties через переменные окружения. Вы также можете сразу же настроить флаги запуска XMS/XMX, а также есть встроенная возможность сразу же использовать флаги от Aikar для запуска сервера.

Первая строчка нашего docker-compose.yml отвечает за версию синтаксиса файла. На самом деле она не сильно важна, можете всегда ставить 3 или 3.3. Далее у нас идёт блок services в котором идут перечисления всех контейнеров, которые будут находиться в нашей связке. В нашем случае у нас будет пока только один сервер. Первая строчка в блоке сервиса mc это image. Думаю тут вы уже и без меня поняли за что она отвечает.

Идём дальше, блок ports отвечает за роутинг портов, я уже объяснял как это работает, но добавлю, что вы можете создавать сразу несколько правил роутинга. Например, если очень сильно захотеть, можно роутить 10 или 20 портов извне в один порт 25565, только не очень понимаю зачем, но можно 0_0.

Следующая строчка restart отвечает за то, по какому условию докер должен перезапускать наш сервер. В основном эта строчка отвечает за то, должен ли докер перезапускать наш сервер, если он вдруг упал по той или иной причине. Для непосредственно майнкрафт сервера, я рекомендую поставить always, это условие означает что докер должен держать контейнер запущенным "во что бы то ни стало". Если вашему хостингу вдруг выключат свет, то докер постарается запустить ваш сервер как только свет восстановят, абсолютно без вашего участия. Таким образом вы можете быть уверены: пока работает докер, ваш сервер будет online. Дальше у нас идут переменные окружения в блоке environment. Здесь уже всё говорил, да и вы сами можете подробнее узнать о них в документации к образу. Однако добавлю, что вместо того, чтобы указывать их прямо в docker-compose, вы можете создать отдельный .env файл и просить докер импортировать переменные из него:

Код:

version: "3.3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - "25565:25565"
    restart: always
    env_file: ".env"

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

Код:

version: "3.3"

services:
  mc:
    image: itzg/minecraft-server
    ports:
      - "25565:25565"
    restart: always
    depends_on:
        - db
    env_file: ".env"
 
  db:
    image: postgres:14-alpine
    env_file: "db.env"
    volumes:
      - "/home/minecraft_server/pgdata:/var/lib/postgresql/data"
    restart: on-failure
    ports:
      - "5434:5434"

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

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

Код:

docker compose up -d

В данном случае я также указываю аргумент -d для запуска в detached режиме, но это необязательно.

Чтобы остановить наш сервер:

Код:

docker compose down

Я рекомендую также указывать аргумент для remove orphans:

Код:

docker compose down --remove-orphans

Данный аргумент отвечает за чистку ненужных volume и образов после остановки сервера.

Новый кейс. Мы поднимаем связку Velocity. Думаю вы вкурсе насколько трудно следить за ней вручную. Добрые люди уже привели пример как создавать связку Velocity в docker-compose: тык (здесь пример с другими образами, но принципиально тут ничего нового)

Одна команда:

Код:

docker compose up -d

и вся наша Velocity связка в полной боевой готовности.

Послесловие
В заключение хочу сказать, что Docker это очень крутая и нужная утилита, с помощью которой можно с легкостью деплоить самые разные сервера\связки серверов. Я рекомендую разобраться для начала с ним, а затем уже начинать разбираться с более продвинутыми инструментами, такими как Docker Swarm и "гигант мысли" Kuberneetes. Это уже инструменты не контейнеризации, а оркестрации, которые позволяют делать куда более сложные и серьезные вещи. Однако, 99% серверам они никогда не понадобятся. Если же ваш проект стоит на достаточно большой связке из более чем 10 серверов + базы данных + всякая другая инфраструктура (сайт, телеграмм\дискорд бот и т.д.), то всё таки ознакомиться с оркестраторами крайне желательно.


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

 

Что ж. Статья довольно интересная. Но, мне вот интересно, а с каких пор следить за связкой Велосити - трудно ?) И, боюсь, Докер не особо пригодится обычным, НЕ крупным серверам. Гораздо легче и привычнее для чего-то маленького использовать screen / tmux. Для чего-то же более масштабного - определённо Docker, Docker Compose & Kubernetes

 

Требуется выполнять огромную кучу действий чтобы поднять и следить за ней. Через docker compose - одна команда.

Что касается screen (tmux), то я в статье написал что его использование является вредным, поскольку он создан совершенно для других задач. В случае, например, если вашему серверу по башке надаёт OOM Killer, ваш сервер просто выключится и вам придётся вручную его поднимать. Помимо этого, screen не умеет адекватно контролировать ресурсы и создавать окружения. Если уж докер, по религиозным причинам, брать не хочется, то крайне рекомендую хотя бы взять systemd.

Абсолютная ложь. Я бы сказал, что докер пригодится в ПЕРВУЮ очередь обычным, не крупным серверам. Почему? Да потому что, как было написано в статье, вам не нужно разбираться со всем зоопарком утилит, а также не нужно разбираться в systemd (и упаси господи использовать screen). Весь запуск и установка - одна команда. Или ещё лучше, то предварительно настраиваем один небольшой yml файл, запускаем сервер с docker compose и всё готово. К тому же докер решает огромную волокиту проблем, в т.ч. с безопасностью, поскольку, напоминаю, образ запускается в изолированном окружении.

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

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

 

Да не сказал бы. Ну лично мне довольно легко поднять)

Позвольте узнать, а для каких целей создан screen / tmux? Интересно) Я не говорю, что докер - что-то плохое, наоборот, согласен что полезная и нужная вещь, но всё же. Касаемо systemd - и так использую его, вполне доволен.

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

Ну, напиши, про Multistage, было бы интересно почитать. В целом тут особо ответить мне нечего, ибо и так знаю эту часть)

 

tmux — свободная консольная утилита-мультиплексор, предоставляющая пользователю доступ к нескольким терминалам в рамках одного экрана.

GNU Screen — свободная консольная утилита-мультиплексор, предоставляющая пользователю доступ к нескольким сессиям в рамках одной сессии.

Ни слова про сервисы. Ни screen, ни tmux не следят за вашим приложением. Это только лишь утилиты по работе с терминалом и сессиями.

Разобраться, конечно, полезно, но в качестве, не знаю, собственного интереса. А если речь о создании и менеджменте сервера, то нет смысла тратить силы и время на то, что и так делается автоматически докером. Я могу понять, если речь идёт о СУБД. Есть много споров о том, вредит контейнеризация базе данных или нет. Но для непосредственно майнкрафт сервера нет ни одной причины чем бы докер был хуже. Он и проще, и безопаснее, и надёжнее, чем делать всё вручную.

 

Ладно, допустим.

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

 

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

Однако

Для меня в первое время было не понятно как сбилдить этот образ, а так же что еще последующее нужно вставлять.
Если кто-то захочет все таки как и я сделать свой образ, я рекомендую ознакомиться с докерфайлом
itzg/minecraft-server на гит-хабе.Там все подробно описывается как работает базовый стандартный докерфайл как указан в туториале. Мне было лично важно создать свой образ, я бы грубо говоря не прикопался бы к создании образа сервера, однако это очень важный элемент если ты хочешь сам создать образ.

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

 

Я понимаю почему вы столкнулись с трудностями в связи с билдом образа, потому что я действительно не предполагал рассмотрение сборки своего собственного образа, а изначально предлагал рассмотреть использование уже готового образа. А всё потому что я планировал сделать ещё один туториал, где уже и планировал рассмотреть как можно с помощью сборки своего образа значительно оптимизировать любой майнкрафт сервер, причём как его Disk usage, так и CPU usage. Но это уже тема более продвинутая, поэтому и осталась за рамками данного вводного туториала.

 

Сижу под screen пятый год и бед не знаю. Что я делаю не так?

 

Попробуете докер, поймёте)

 

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

 

Ну что ж, действительно для небольших серверов докер не даст слишком много пользы, особенно, если ваш сервер не использует никакой инфраструктуры (СУБД, кеш, метрики и пр.). Единственная польза - очень быстрое и простое управление сервером: его поднятием, развёртыванием, перезапуском и так далее.

 

Да, Докер удобен для сетей серверов и метрик.

Кстати, а как сейчас ситуация обстоит с санкциями? Слышал, Докер заблокировали в РФ и РБ

 

Уже все работает. + Есть аналог в виде Podman

 

Заблокировали только docker hub, в любом случае есть много зеркал. Да и то, разблокировали через один день.

 

Годно! Недавно начал вникать в эту тему и всплывали разные сложности! Я ждал вашего тутора) Для новичков советую использовать portainer, там интерфейс по приятнее! В настройках контейнера надо указать консоль "Interactive & TTY", ибо как открывать консоль контейнера напрямую в линексе не разобрался( + Есть вопросик, если открыть расположение файлов сервера data, то нельзя редактировать их как привык, нет доступа! А если прописать себя как владельца файлов через chown, то после перезапуска, или если появятся новые файлы, то доступа к ним не будет( Продвигайте тему, я слежу!

 

docker exec -it <имя контейнера> bash

 

Не ожидал столь скорого ответа, потому продолжал редактировать свое прошлое сообщение, прошу прочитайте еще раз, там есть пару вопросов! Владелец файлов контейнера - рут, а если указать себя, то, понятное дело, не запуститься контейнер. Через судо не удобно редактировать файлы, привычнее через sftp по старинке, а добавлять себя в группу рут - не безопасно. По поводу команды, что вы дали, я пробовал подобное и это не совсем то, что я хотел. Я ожидал увидить привычную консоль сервера как в portainer, а в результате просто строка еще и не рабочая, пока продолжаю пользоваться встроенной консолью portainer. Скрины прилагаються, изивините за глупые вопросы(

 

Нет, вам вообще не нужен Рут для работы докера. Вы должны создать группу docker, и добавить в неë всех пользователей, которым вы хотите дать возможность менеджить докер. Об этом есть много информации в интернете (Rootless docker mode).

По поводу ваших проблем с консолью. Вы вообще не поняли что я имел ввиду. Эта команда, что я написал, она дает возможность зайти в контейнер с помощью bash, но это не консоль сервера. Чтобы получить доступ к непосредственно консоли сервера, вы можете использовать любой rcon клиент.