Таблица лидеров

Делалось для себя. Но думаю многим пригодится. Куча изменений. Можно копировать элементы, перетаскивать, сохраняет в xml можно скопировать элемент и вставить в текстовый редактор- отредактировать как нужно и скопировав в текстовике вновь вставить в xdatEditor. Нет UNK в интерлюде. Исправлены многие ошибки. Пароль на архив

Исходники были взяты Acis 390, в планах полный перевод aCis на русский язык. (как в шаре будут 391 будет обновлено до актуальной). Ранее когда-то брался за это дело, но далее тестового не пошло... Сейчас появилось желание, доделать начатое дело, в старой версии имеется множество исправлений и доработок, которые будем переносить сюда (ибо код поменялся). Сейчас выкладываю сборку, в которой уже имеется небольшое количество исправлений (описывать нет смысла), в версии #2 постараюсь добавить больше интересного. Насчет исходного кода пока не уверен, но скорее всего будет публиковать вместе со сборкой. Развитие сборки будет: Low (с добавлением всего функционала). Добавляю тестовую сборку (в ней уже имеются некоторые фиксы, о которых будет описано уже непосредственно перед публикацией первой ревизии). Обновление с актуальными исходниками aCis, так же будут присутствовать. Сайт: https://rusacis.com/

Первым делом, еще раз оговорюсь, что рациональней перепилить это дело под полноценный экшен, я же делал байпассом. Потому первым делом в ядре стоит запилить что-то такое: (!)Обратите внимание на мои условия, мне нужны были в таргете только монстры, для своих целей перепишите соответствующим образом. (да, у меня такой синтаксис что игроки это мобы, а мобы - это игроки, все в порядке) Так же заметьте, я ограничиваю максимальную дальность 1200, Вы можете этого не делать, либо задать свою. Я бы советовал ограничить максимальную дальность именно в ядре, ибо зная байпасс с интерфейса можно будет творить чудеса. Так же вопрос: нужно ли принудительно обновлять хп/мп таргета, если Вы уже шлете пакет MyTargetSelected? - На адекватных сборках может и нет, а вот у меня были проблемы пока так не сделал. Так же Вы можете добавить проверку на видимость целей, что-то вроде: GeoData.getInstance().canSeeTarget(activeChar, nextMob) Почему я такую не добавил? Об этом в следующей кулстори расскажу. Теперь в интерфейсе прикрутим в функцию OnLoad() следующее: (здесь тоже довольно извращенная и чрезмерно нагроможденная конструкция, опять же скорее для наглядности, адекватно на это посмотреть и переписать нормально, а не копировать): nrage(int(class'UIAPI_EDITBOX'.static.GetString("тут адрес нашего окна"))); Сама функция nrage: function nrage(int valueX) { if ( valueX < 400) { NTrange = 400; } if ( valueX > 1200) { NTrange = 1200; } else { NTrange = valueX; } } И наш отправляемый байпас: RequestBypassToServer("наш байпасс посылаемый с интерфейса "$ NTrange); Дальше (очень логично и последовательно, идя от конца к началу) оформим сам эдит бокс, с которого только что считывали дальность нашего некст таргета. Я его храню в другом классе, потому у Вас все может быть проще и красивее, в который раз повторюсь, что эта информация больше подходит для ознакомления, а не копипаста, хоть и будет работать и в таком виде. И так, прежде всего: var EditBoxHandle e_autoMacroRange; var MacroListWnd* script_mc; ..... e_autoMacroRange = GetEditBoxHandle("Ваше окно"); script_mc = MacroListWnd(GetScript("MacroListWnd")); *на всякий случай: это я тяну с другого класса скрипт, и напомню, что Вы можете без проблем обойтись и без этого Я сохраняю настройки по клику кнопки, потому нужен хендлер OnClickButton, и в нем наша кнопка: case "btnApply": OnApplyBtn(); break; .... сама функция кнопки (уже вне хендлера ,если что, наверное, это и так очевидно, но мне бы такая пометка жизнь спасти могла) function OnApplyBtn() { local int valueX if (e_autoMacroRange.GetString() != "") { valueX = int(e_autoMacroRange.GetString()); if (valueX >= 400 && valueX <= 1200) { SetINIInt("MacroSettings", "AutoMacroRange", valueX, "PatchSettings"); script_mc.nrage(valueX); } } } Для загрузки наших данных о дальности нексттаргета из файла: function LoadINISets() .... GetINIString("MacroSettings", "AutoMacroRange", valueS, "PatchSettings"); if (e_autoMacroRange.GetString() == "") { valueS = "750"; } e_autoMacroRange.SetString(valueS); И вот сейчас был спорный момент, ибо раз уже замешано ядро - то зачем хранить эти данные в интерфейсе и почему бы не запихивать их куда-то на сервер сайде? Для себя я ответил: чтобы в эдитбоксе выводить актуальную дистанцию и не создавать лишних запросов в БД, а свой ответ Вы можете поискать сами, либо засунуть инфу на серверсайд.

Приветсвтую, в данной инструкции рассмотрим возможность сборки ява сервера в докер образ и последующем запуске в контейнере. В данном примере будет вариант с использованием 3-х образов, логин-сервер, гейм-сервер и образ для инсталяции базы данных, запускать будем через docker-compose Введение Данная инструкция не предусматривает рассказ о том что такое контейнеризация, отличия от виртуализации, что такое docker и т.д. В интеренте достаточно информации на эту тему, с учетом того что docker с каждым днем продолжает набирать популярность. Так, что предлагаю перед прочтением этого мануала ознакомиться с общимим материалами на тему "docker и контенеризация приложений" О докере можно почитать на официальном сайте https://docs.docker.com/get-started/overview/ Окружение Дев-машина: Windows 10, установленный docker desktop for windows, работает через hyper-v. С информацией по установке можно ознакомиться по ссылке https://docs.docker.com/docker-for-windows/install/ В этом мануале не будет рассматриваться какая-то конкретная сборка, их огромное количество со своими сходствами и отличиями, по этому прдеположим что у нас есть скомпилированый ява сервер с такой структурой L2Server ├─── loginserver (файлы логин-сервера, конфиг файлы, файл запуска java процесса StartLoginServer.sh) ├─── gameserver (файлы гейм-сервера, конфиг файлы, файл запуска java процесса StartGameServer.sh) ├─── libs (необходимые библиотеки) ├─── install (файлы установки базы данных) ├─── login (sql файлы установки базы логин-сервера, файл запуска установки install-login.sh) ├─── game (sql файлы установки базы гейм-сервера, файл запуска установки install-game.sh) Dockerfile'ы Для того чтобы сбилдить докер-образ необходимо создать файл Dockerfile (название файла, без расширения), в котором прописываються необхходимые инструции билдера. С синтаксисом можно ознакоиться здесь https://docs.docker.com/get-started/overview/ Один образ - один докерфайл, следовательно у нас будет 3 образа и 3 докерфайла. Докерфайл для логин сервера разполагаем в папке loginserver, для гейм-сервера в папке gameserver, для установищка бд в папке install В итоге получаем следующую структуру L2Server ├─── loginserver ├─── Dockerfile ├─── gameserver ├─── Dockerfile ├─── libs ├─── install ├─── Dockerfile Dockerfile для loginserver #исходнй образ который взят за основу FROM adoptopenjdk/openjdk8:jdk8u292-b10-centos #рабочая папка внутри контейнера WORKDIR /server #копируем файлы логин-сервера в контейнер COPY ["loginserver", "/server/loginserver"] #копируем библиотеки COPY ["libs", "/server/libs"] #порты которые пробрасываються в контейнер EXPOSE 2106 9014 #добавляем права на испольнение sh файла RUN chmod +x /server/loginserver/StartLoginServer.sh RUN chmod +x /server/loginserver/UpdateHosts.sh #команда которая выполниться при запуске контейнера CMD ["/bin/bash", "-c", "cd /server/loginserver/ && sh UpdateHosts.sh && sh StartLoginServer.sh"] Примичание: что такое UpdateHosts.sh и зачем он нужен будет рассмотрено ниже. Dockerfile для gameserver #исходный образ который взят за основу FROM adoptopenjdk/openjdk8:jdk8u292-b10-centos #рабочая папка внутри контейнера WORKDIR /server #копируем файлы логин-сервера в контейнер COPY ["gameserver", "/server/gameserver"] #копируем библиотеки COPY ["libs", "/server/libs"] #порты которые пробрасываються в контейнер EXPOSE 7777 #добавляем права на испольнение sh файла RUN chmod +x /server/gameserver/StartGameServer.sh RUN chmod +x /server/gameserver/UpdateHosts.sh CMD ["/bin/bash", "-c", "cd /server/gameserver/ && sh UpdateHosts.sh && sh StartGameServer.sh"] Примичание: что такое UpdateHosts.sh и зачем он нужен будет рассмотрено ниже. Dockerfile для инсталлера базы данных #исходные образ который взять за основу (alpine - легкий дестрибутив linux) FROM alpine:latest WORKDIR /db-install #копируем файлы установки COPY ["install/login", "/db-install/login"] COPY ["install/game", "/db-install/game"] #устаналиваем необходимые пакеты #mysql client RUN apk update && apk add --no-cache mysql-client && apk add --no-cache bash #добавляем права на испольнение sh файлов RUN chmod +x /db-install/login/install-login.sh RUN chmod +x /db-install/game/install-game.sh #команда которая выполниться при запуске контейнера CMD ["/bin/bash", "-c", "cd /db-install/login && sh install-login.sh && cd /db-install/game && sh install-game.sh"] Файл UpdateHosts.sh Образ представляет собой готовый к запуску артефакт, т.е при сборке в него копируються файлы в том состоянии в котором они есть на момент сборки, следовательно для того чтобы изменить конфиг нужно каждый раз пересобирать образ. Одной из самых основных настроек логин и гейм сервера - настройки сети, а конкретнее хосты к которым биндиться сокет. Самым простым вариантом как управлять этими настройками без ребилда образа - передать нужные значения через переменные окружения (environment variables). К примеру, в данном случае, команды заменяющие настройки в конфиге вынесены в отдельный файл для удобства Для loginserver #!/bin/bash echo "Updating LoginserverHostname with $LOGINSERVER_HOST" sed -ir "s/^[#]*\s*LoginserverHostname = .*/LoginserverHostname = $LOGINSERVER_HOST/" /server/logibserver/config/server.ini Для gameserver #!/bin/bash echo "Updating ExternalHostname with $GAMESERVER_EXTERNAL_HOST" sed -ir "s/^[#]*\s*ExternalHostname = .*/ExternalHostname = $GAMESERVER_EXTERNAL_HOST/" /server/gameserver/config/server.ini echo "Updating InternalHostname with $GAMESERVER_INTERNAL_HOST" sed -ir "s/^[#]*\s*InternalHostname = .*/InternalHostname = $GAMESERVER_INTERNAL_HOST/" /server/gameserver/config/server.ini Таким образом можете вынести любые необходимые настройки, которые нужно часто менять "на лету" К томуже переменные окружения удобно использовать для установки памяти требуемой для запуска в вашем sh файле, например StartLoginServer.sh java -Xmx$JAVA_MAX_MEMORY l2p.loginserver.LoginServer 2>&1 | tee /server/logs/loginserver-stdout.log В переменную можно передать $JAVA_MAX_MEMORY можно передать значение "256m", "1G" и тд Сборка образов Контейнер собираеться командой docker build (https://docs.docker.com/engine/reference/commandline/build/) В данном случае выполняем команду из рут папки с сервером (L2Server) с указанием докерфайла, для того чтобы сохранить контекст, т.к по умолчанию билдер не имеет доступа к родительским деррикториям Билд образа логинсервера docker build -t server:loginserver -f ./loginserver/Dockerfile . Билд образа геймсервера docker build -t server:gameserver -f ./gameserver/Dockerfile . Билд образа инсталятора docker build -t server:db-install -f ./install/Dockerfile . На данном этапе из этих образов уже можно запустить конйтенер с помощью команды docker run (https://docs.docker.com/engine/reference/run/) и получить работоспособные логин и гейм серверы, но мы идем дальше Примичание: В данным момент нобходимо передать переменные окружения если они используються для обновления конфигурации. База данных Сервер базы данных так же можно запустить в отдельном контейнере, например запуск mariadb docker run --name mariadbtest -e MYSQL_ROOT_PASSWORD=root -p 3306:3306 -d docker.io/library/mariadb:10.3 Больше информации о работе с бд будет далее, когда мы будем обьеденять контейнеры в одно окружение. Примичание: MYSQL_ROOT_PASSWORD - переменная окружения которую использует mariadb, подобно тому как выше было описан способ обновления конфигурации docker-compose По отдельности собраные выше образы и запущенные из них контейнеры мало чем полезны, запускать их по очереди не совсем удобно, по этому соберем стак контейнеров в одно окружение с помощью docker-compose https://docs.docker.com/compose/ docker-compose позволяет одновременно запускать и управлять несколькими контейнерами, настраивать внутренее изолированноее окружение, сеть между контейнерами, зависимости, порядки запуска и так далее. docker-compose'у нужен свой файл с инструкциями, который парситься из YAML файла. По умолчания ожидаеться файл с одноименный названием docker-compose.yml Подробнее о синтаксисе: https://docs.docker.com/compose/compose-file/ Создаем файл, помещяем его корневую папку с нашим сервером, в итоге получаем следующую стркутуру L2Server ├─── docker-compose.yml ├─── loginserver ├─── Dockerfile ├─── gameserver ├─── Dockerfile ├─── libs ├─── install ├─── Dockerfile Содержимое docker-compose.yml #версия парсера файла, влияет на доступность некоторых фич, более подробное описание на официальном сайта version: "3.9" #контейнеры, которые буду запускаться в docker-compose, их принято называть сервисами services: #сервис базы данных, будем использовать mariadb mysql: image: mariadb restart: always environment: #рут пароль MYSQL_ROOT_PASSWORD: root #при необходимости при запуске конейтенра сразу будет создана база MYSQL_DATABASE: lvldev #при необходимости при запуске контейнера сразу будет создан допонительный пользователь MYSQL_USER: localnetwork MYSQL_PASSWORD: localnetwork ports: - 3306:3306 #внешняя дериктория для сохранения данных volumes: - D:\docker\mysql:/var/lib/mysql healthcheck: test: "/usr/bin/mysql --user=root --password=root --execute \"SHOW DATABASES;\"" interval: 10s timeout: 20s retries: 10 #инсталятор базы данных db-install: container_name: db-install image: db-install #сборка образа инсталятора из докерфайла build: context: . dockerfile: ./install/Dockerfile depends_on: mysql: condition: service_healthy profiles: - db-install #сервис логинсервера authserver: container_name: authserver image: loginserver restart: on-failure #сборка образа логинсервера из докерфайла build: context: . dockerfile: ./loginserver/Dockerfile ports: - 2106:2106 environment: #переменная окружения в которую передаем память выделяему для процесса логинсервера JAVA_MAX_MEMORY: 256m #переменная окружения для обновления конфига адреса биндинга для логинсервера LOGINSERVER_HOST: "*" depends_on: mysql: condition: service_healthy healthcheck: test: "netstat -an | grep 9014 > /dev/null; if [ 0 == $$? ]; then echo 1; fi;" interval: 10s timeout: 1s retries: 10 #внешняя дериктория для сохранения данных volumes: - D:\docker\logs:/server/logs profiles: - server #сервис геймсервера gameserver: container_name: gameserver image: gameserver restart: on-failure #сборка образа геймсервера из докерфайла build: context: . dockerfile: ./gameserver/Dockerfile ports: - 7777:7777 environment: #переменная окружения в которую передаем память выделяему для процесса логинсервера JAVA_MAX_MEMORY: 5G #переменная окружения для обновления конфига внешнего хоста геймсервера GAMESERVER_EXTERNAL_HOST: "ВАШ ВНЕШНИЙ ИП ТУТ" #переменная окружения для обновления конфига внутренего хоста геймсервера GAMESERVER_INTERNAL_HOST: "127.0.0.1" depends_on: mysql: condition: service_healthy authserver: condition: service_healthy #внешняя дериктория для сохранения данных volumes: - D:\docker\logs:/server/logs profiles: - server Теперь стоит вспомнить о конфигурационных файлах логин и гейм серверов, как написано выше - docker-compose строит внутреннюю сеть между контейнерами, в которой они могут между собой общаться с помощью именовоного хостнейма которое являеться именем сервиса в yml файле. Например для того чтобы из java приложения в контейнере loginserver подключиться к базе данных в контейнере mysql можно использовать адресс mysql:3306, а чтобы из конейтенра gameserver подключиться к конйтенру loginserver можно использовать адресс loginserver:9104 и т.д (смысл думаю понятен) Меняем настройки подключения к бд в конфигах логинсервера и геймсервера, например в моем случае получилось следующее /gameserver/config/server.ini /loginserver/config/server.ini dataSource.url = jdbc:mariadb://mysql:3306/l2server?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true dataSource.user = localnetwork dataSource.password = localnetwork Также меняем настройки подключения геймсервера к логинсерверу Например в моем случае /gameserver/config/server.ini LoginPort = 9014 #имя сервиса в docker-compose.yml LoginHost = loginserver Так же на забываем менять настройки в вашем инсталяторе базы данных Обратите внимание на настройки в секции environment, здесь можно настроить параметры переменных окружения, которые будут переданны в контейнер при запуске, выше был описан момент обновления настроек с помощью енв-варов на лету. Персистентность данных Контейнер имеет своую виртуальную фаловую систему, при удалении контейнера так же удаляться все данные, в том числе и база данных сервера, соответсвенно база должна храниться гдето на хост машине. Смотрим на настройки volumes, с помощью этой инструкции можно смонтировать папку на хост машине как виртуальную в контейнере. ОСОБОЕ ВНИМАНИЕ пршу обратить на сервис mysql, в который смонтирована папка на хосте как /var/lib/mysql Эта директория используеться ядром mysql для сохранения данных, следовательно все данные остануться на хост машине (в момем случае в D:\docker\mysql) Так же, к примеру в логин и гейм серверы смонтирована папка на моем пк для записи логов D:\docker\logs как /server/logs Запуск в docker-compose Запустить стек контейнеров можно с помощью команды docker-compose up https://docs.docker.com/compose/reference/up/ С помощью настроек в docker-compose.yml файлы мы определили т.н профили запуска (с.м выще содержание файла, секцию profiles) Это нужно для того, чтобы запускать определенный сервисы, при этом пропускать другие, например при запуске профиля db-install запуститься только сервис mysql и инсталятор базы данных (нам ведь нужно запустить его лишь один раз, не так ли?), а при запуске профиля server запустятся сервисы mysql, loginserver, authserver, минуя инсталятор Запуск инсталятора docker-compose --profile db-install up --build --force-recreate Примичание: флаг --build используеться для того чтобы зафорсить ребилд контейнера, флаг опционален, удобно для дев окружения Примичание 2: флаг --force-recreate ипользуеться для того чтобы пересоздать контейнер (если он ранее был создан), флаг оционален, удобно для дев окружения Запуск логин и гейм сервера без инсталятора docker-compose --profile server up --build --force-recreate Так же с помощью docker-compose можно билдить образы без запуска, удобно docker-compose build --no-cache db-install docker-compose build --no-cache loginserver docker-compose build --no-cache gameserver Для того чтобы оставить все контейнеры используется команда docker-compose stop https://docs.docker.com/compose/reference/stop/ Для того чтобы остановить и удалить все контейнеры используется команда docker-compose- down https://docs.docker.com/compose/reference/down/ Продакшн Получилось собрать и запустить все на локальной дев машине? Отлично! Что дальше? У нас есть готовые образы, их нужно как-то передать на продакшн сервер, для этого используеться так называемый Docker реестр (Docker Registry). Реестр может быть свой, (вопрос запуска собственного реестра это отдельная тема, которая требует отдельного манула) либо один из доступных платных или безплатных в олаке. У docker есть собственный реестр - Docker Hub https://hub.docker.com/ который предоставляет один безплатный приватный репозиторий (и неограниченное количествао публичных), его и будем использовать в рамках данного мануала В докер хабе создаем рпозиторий, например его название будет "server". Для того чтобы отправить образы в свой репозиторий они должны называться по принцину "ИМЯ_ПОЛЬЗОВАТЕЛЯ/ИМЯ_РЕПОЗИТОРИЯ". В моем случае образы должны именоваться "lvlkoo/server". Можно ли загрузить несколько образом с одним именем? Нет. НО, на выручку приходят теги, у каждого образа может быть тег, и их может быть неограничение количество. Более подробнее о тегах можно почитать на официальном сайте, в основном они используеться для вариации похожих образов или версионирования Тег образу проставляеться через двоеточие "ИМЯ_ОБРАЗА:ТЕГ". Сопоставив это с именованием образов для загрузки в репозиторий получаем следующие имена образов Геймсервер: lvlkoo/server:gameserver Логин-сервер: lvlkoo/server:loginserver Инсталятор: lvlkoo/server:db-install Подобный образом можно к примеру собирать несколько разных вариаций сборки, к примеру server:gameserver-x-1200, server:gameserver-x-100 и так далее Перименовуем название образов в docker-compose.yml файлах (поле image). Например для инсталятора. Остальное по аналогии image: lvlkoo/server:db-install Ребилдим образы и пушим их в реестр с помощью команды docker push https://docs.docker.com/engine/reference/commandline/push/ или с помощью docker-compose push https://docs.docker.com/compose/reference/push/ Собираем docker-compose.yml файл для продакшн окружения. В чем отличия? Самое очевидное это то, что там будут передаваться различные переменные окружения с настройками (ип адресс хоста, итд) Второй момент - это то, что на продакшне мы не будем билдить образы, а будем скачивать из докер реестра, если Вы посмотрите на текущий docker-compose.yml там будет секция build с указанием контекста и докерфайла, она не нужна. Создаем файл docker-compose.prod.yml version: "3.9" services: mysql: image: mariadb restart: always environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: l2server MYSQL_USER: localnetwork MYSQL_PASSWORD: localnetwork ports: - 3306:3306 volumes: - /home/server/mysql:/var/lib/mysql healthcheck: test: "/usr/bin/mysql --user=root --password=root --execute \"SHOW DATABASES;\"" interval: 10s timeout: 20s retries: 10 db-install: container_name: db-install image: lvlkoo/server:db-install depends_on: mysql: condition: service_healthy profiles: - db-install authserver: container_name: loginserver image: lvlkoo/server:loginserver restart: on-failure ports: - 2106:2106 environment: JAVA_MAX_MEMORY: 256m LOGINSERVER_HOST: "*" depends_on: mysql: condition: service_healthy healthcheck: test: "netstat -an | grep 9014 > /dev/null; if [ 0 == $$? ]; then echo 1; fi;" interval: 10s timeout: 1s retries: 10 volumes: - /home/server/logs:/server/logs profiles: - server gameserver: container_name: gameserver image: lvlkoo/server:gameserver restart: on-failure ports: - 7777:7777 environment: JAVA_MAX_MEMORY: 4G GAMESERVER_EXTERNAL_HOST: "ИП ХОСТИНГ МАШИНИ ТУТ" GAMESERVER_INTERNAL_HOST: "127.0.0.1" depends_on: mysql: condition: service_healthy authserver: condition: service_healthy volumes: - /home/server/logs:/server/logs profiles: - server Важный момент по поводу имени файла: все команды docker-compose изначально ожидают что файл будет называться docker-compose.yml, без лишних приставок, но можно дополнительно передать конкретный файл с помощью флага -f например запуска инсталятора docker-compose -f docker-compose.prod.yml --profile db-install up В таком случае можно иметь по друкой несколько compose файлов, например docker-compose.dev.yml, docker-compose.prod.yml, docker-compose.prod-server=2.yml и т.д Запуск на продакшене Собственно кульминация истории и зачем все это нужно Окружение: только-что купленная хостинг машина с centos на борту, без дополнительно установленного софта. 1. Устанавливаем docker https://docs.docker.com/engine/install/centos/ 2. Устанвливаем docker-compose https://docs.docker.com/compose/install/ 3. Создаем паки /home/server/logs и /home/server/mysql 4. Копируем файл docker-compose.prod.yml в /home/server (при этом сделав нужные изменения в переменных окружения) 5. Запускаем инсталятор docker-compose -f docker-compose.prod.yml --profile db-install up 6. Вырубаем инсталятор, запускаем сервер docker-compose -f docker-compose.prod.yml --profile server up Несколько моментов о которых стоит упомянуть - Для того, чтобы посмотреть список запущенных контейнеров используется команда docker ps https://docs.docker.com/engine/reference/commandline/ps/ либо docker-compose ps https://docs.docker.com/compose/reference/ps/ - При запуске контенера (ов) вы окажитесь в т.н attached режие, в котором весь консольный ввод передаеться напрямую контейнеру, для запуска в deatached режиме нужно передать флаг -d Чтобы приатачиться обратно можно использовать команду docker attach https://docs.docker.com/engine/reference/commandline/attach/ - Для того чтобы выполнить какую-нибудь команду в контейнер без аттача можно использовать команду docker exec https://docs.docker.com/engine/reference/commandline/exec/ или docker-compose exec https://docs.docker.com/compose/reference/exec/ - Для просмотра стдаута приложения можно воспользоваться командой docker logs https://docs.docker.com/engine/reference/commandline/logs/ или docker-compose logs https://docs.docker.com/compose/reference/logs/ - После того как сделали какие-то изменения в файлах сервера контейнер нужно пересобрать (с.м выше про сборку образов), и перезалить в реестр (с.м выше про пуш образов) а дальше перезагрузить на продакшн сервере Запулить нужный образ заного можно командой docker-compose pull https://docs.docker.com/compose/reference/pull/ Например docker-compose -f docker-compose.prod.yml pull authserver -При частой локальной пересборки будеи накапливаться мусор из старых образов. Очистить образы можно командой docker image prune https://docs.docker.com/engine/reference/commandline/image_prune/ - Тему можно развивать и настроить авматические билды и пуши образов из репозитория, с тегированием по номеру билда или ревизией (возможно будет полезно командам разработчиков) Послеловие Данная статья не претендует на научность или хау-ту, а лишь передает мой личный опыт. В основном я работаю с докером в другой сфере и в этом материале лишь описывается некоторый подход который возможно кому-то будет полезен. Спасибо всем кто дочитал до конца.