Docker uk UA

Docker

ASF is available as docker container. Our docker packages are currently available on ghcr.io as well as Docker Hub.

It's important to note that running ASF in Docker container is considered advanced setup, which is not needed for vast majority of users, and typically gives no advantages over container-less setup. If you're considering Docker as a solution for running ASF as a service, for example making it start automatically with your OS, then you should consider reading management section instead and set up a proper systemd service which will be almost always a better idea than running ASF in a Docker container.

Running ASF in Docker container usually involves several new problems and issues that you'll have to face and resolve yourself. This is why we strongly recommend you to avoid it unless you already have Docker knowledge and don't need help understanding its internals, about which we won't elaborate here on ASF wiki. Цей розділ здебільшого для дійсних випадків дуже складних конструкцій, Наприклад, щодо розширеного мережевого або безпеки поза стандартним пісочником, який ASF поставляється у службі systemd (яка вже забезпечує вищу ізоляцію процесу через дуже просунуті механізми безпеки). Для такої кількості людей ми пояснюємо вам кращі поняття ASF цілком відповідно до Docker, і тільки те, що ви вважаєте, що у вас є адекватні знання Docker, якщо ви вирішите використовувати його разом з ASF.

---

Мітки

ASF is available through 4 main types of tags:

основний

This tag always points to the ASF built from latest commit in main branch, which works the same as grabbing latest artifact directly from our CI pipeline. Як правило, вам слід уникати цього тегу, оскільки це найвищий рівень помилкового програмного забезпечення, присвяченого розробникам та досвідченим користувачам для цілей розробки. The image is being updated with each commit in the main GitHub branch, therefore you can expect very often updates (and stuff being broken). Нам потрібно позначити поточний стан проекту ASF для нас, які не обов'язково гарантуються стабільним або тестовим, так само, як зазначають у нашому циклі випуску. Цей тег не повинен використовуватися у будь-якому робочому середовищі.

відпущено

Very similar to the above, this tag always points to the latest released ASF version, including pre-releases. Compared to main tag, this image is being updated each time a new GitHub tag is pushed. Присвячується просуванням / силовим користувачам, які люблять жити на краю того, що можна одночасно вважати стабільним та свіжим. Це те, що ми рекомендуємо якщо ви не хотіли б використовувати найновіший. На практиці це працює так само, як рухомий тег, який вказує на останній випуск <unk> .C.D під час потягування. Please note that using this tag is equal to using our pre-releases.

останній

This tag in comparison with others, is the only one that includes ASF auto-updates feature and points to the latest stable ASF version. Мета цього тегу - надати добре типовий контейнер Docker, здатний запускати самооновлення, сумісну для ОС. Через це зображення не необхідно оновлювати, як можна часто, коли включена версія ASF завжди може оновлюватись при потребі. Of course, UpdatePeriod can be safely turned off (set to 0), but in this case you should probably use frozen A.B.C.D release instead. Likewise, you can modify default UpdateChannel in order to make auto-updating released tag instead.

Due to the fact that the latest image comes with capability of auto-updates, it includes bare OS with OS-specific linux ASF version, contrary to all other tags that include OS with .NET runtime and generic ASF version. Це тому, що для нових (оновлень) версій ASF також знадобиться новіше середовище виконання, ніж зображення може бути створене разом що в іншому випадку потребує відновлення зображення з нуля, піднесення запланованого використання.

С.Р.

В порівнянні з вище тегами, цей тег повністю заморожений, це означає, що зображення не буде оновлюватися після публікації. Це працює подібно до наших релізів GitHub, які ніколи не торкалися після початкового випуску, що гарантує вам стабільне і заморожене середовище. Typically you should use this tag when you want to use some specific ASF release and you don't want to use any kind of auto-updates (e.g. those offered in latest tag).

---

Яка для мене мітка?

Це залежить від того, що ви шукаєте. Для більшості користувачів, останній тег повинен бути найкращим у тому що він пропонує саме те, що робить настільний ASF, тільки в спеціальному контейнері Docker як сервіс. People that are rebuilding their images quite often and would instead prefer full control with ASF version tied to given release are welcome to use released tag. Якщо замість цього ви хочете використовувати якусь конкретну версію ASF, яка ніколи не буде змінюватися без вашого чіткого наміру, А. .C.D релізи доступні для вас як фіксовані етапи ASF, до яких ви можете повернутися.

Ми зазвичай не заставляємо пробувати основні збірки, тому що ми тут позначимо поточний стан проекту ASF. Ніщо не гарантує, що така держава буде працювати належним чином, але, звичайно, ви більш ніж бажані дати їм спробувати вашу зацікавлену розробку ASF.

---

Архітектури

ASF docker image is currently built on linux platform targetting 3 architectures - x64, arm and arm64. You can read more about them in compatibility section.

Наші теги використовують багатоплатформний маніфест, що значить, що Docker встановлений на вашому комп’ютері автоматично вибере правильне зображення для Вашої платформи при потягуванні зображення. If by any chance you'd like to pull a specific platform image which doesn't match the one you're currently running, you can do that through --platform switch in appropriate docker commands, such as docker run. See docker documentation on image manifest for more info.

---

Використання

Для повного посилання ви повинні використовувати офіційну документацію docker, ми покриваємо базові використання в цьому посібнику, вас привітають до занурення у нього.

Hello ASF!

По-перше, ми повинні перевірити, чи наш докер працює навіть правильно, це буде обслуговувати як наш ASF "Привіт світ":

docker запускає - name asf --pull завжди --rm justarchi/archisteamfarm

docker запускає новий контейнер для docker ASF і запускає його на передньому плані (-it). --pull always ensures that up-to-date image will be pulled first, and --rm ensures that our container will be purged once stopped, since we're just testing if everything works fine for now.

Якщо все закінчилося успішно, після натягування всіх шарів та початкового контейнера, ви повинні відмітити, що ASF запущено та повідомив нас, що немає визначених ботів, добре - ми перевірили, що ASF в док-станції працює належним чином. Hit CTRL+C to terminate the ASF process and therefore also the container.

If you take a closer look at the command then you'll notice that we didn't declare any tag, which automatically defaulted to latest one. If you want to use other tag than latest, for example released, then you should declare it explicitly:

docker запустити - воно --name asf --pull завжди --rm justarchi/archisteamfarm:випущено

---

Використовується гучність

Якщо ви користуєтеся ASF у контейнері для докеру, то очевидно, що вам потрібно налаштувати саму програму. Ви можете робити це різними способами, але рекомендовано було б створити директорію ASF config на локальному комп'ютері, а потім монтувати його як спільний об'єм у контейнері ASF.

For example, we'll assume that your ASF config folder is in /home/archi/ASF/config directory. Цей каталог містить ядерний ASF.json та також ботів, які ми хочемо запустити. Now all we need to do is simply attaching that directory as shared volume in our docker container, where ASF expects its config directory (/app/config).

docker запустив -it -v /home/archi/ASF/config:/app/config --name asf --pull завжди justarchi/archisteamfarm

Саме так, тепер контейнер ASF docker буде використовувати спільний каталог вашого комп'ютера з режимом читання запису, це все, що потрібно для налаштування ASF. Аналогічним чином ви можете монтувати інші гучності, якими ви хотіли б поділитися з ASF, наприклад /app/logs or /app/plugins.

Звичайно, це лише один конкретний спосіб досягти того, чого ми хочемо, нічого не зупиняє вас, наприклад, створення власного Dockerfile яке скопіює ваші конфігураційні файли в каталог " /app/config у контейнері ASF. Ми обробляємо базове використання цього посібника.

Права на рівень гучності

ASF контейнер за замовчуванням ініціалізований за замовчуванням root користувач, це дає змогу обробляти речі з внутрішніми дозволами, а потім зрештою перейти до asf (UID 1000) користувача для решти частини основного процесу. While this should be satisfying for the vast majority of users, it does affect the shared volume as newly-generated files will be normally owned by asf user, which may not be desired situation if you'd like some other user for your shared volume.

Є два шляхи, як ви можете змінити користувача ASF працює. Рекомендується оголосити ASF_USER змінну середовища з цільовим UID, який ви хочете запустити. Second, alternative one, is to pass --user flag, which is directly supported by docker.

Наприклад, ви можете перевірити uid наприклад за допомогою команди id -u а потім оголосити його зазначеним вище. Наприклад, якщо ваш цільовий користувач має uid в 1001:

docker запустив -it -e ASF_USER=1001 -v /home/archi/ASF/config:/app/config --name asf --pull завжди justarchi/archisteamfarm

# Або якщо ви розумієте обмеження нижче
докер запускайте -it -u 1001 -v /home/archi/ASF/config:/app/config --name asf --pull завжди justarchi/archisteamfarm

The difference between ASF_USER and --user flag is subtle, but important. ASF_USER - це користувацький механізм, який підтримується ASF, у цьому сценарії контейнер docker все ще запускається як root, а потім запуск сценарію ASF починається з основного виконуваного файлу в ASF_USER. When using --user flag, you're starting whole process, including ASF startup script as given user. Перша опція дозволяє запуску сценарію запуску ASF для роботи з дозволами та іншими матеріалами автоматично для вас, вирішення деяких загальних проблем, які ви мабуть спричинили, Наприклад, це гарантує, що директорії /app і /asf фактично належать ASF_USER. У другому сценарії, оскільки ми не виконуємо як root, ми не можемо цього зробити, і очікується, що ви впоралися з усім цим і заздалегідь.

If you've decided to use --user flag, you need to change ownership of all ASF files from default asf to your new custom user. Це можна зробити, виконавши наступну команду:

# Виконати тільки якщо ви не використовуєте ASF_USER
docker - u root asf створіння -hR 1001 /app /asf

Це потрібно виконати лише один раз після створення контейнера з докер запускаєтьсяі тільки якщо ви вирішили використовувати користувацького користувача через --user docker. Також не забудьте змінити аргумент 1001 у команді вище на UID ви насправді бажаєте запустити ASF under.

Гучність з SELinux

If you're using SELinux in enforced state on your OS, which is the default for example on RHEL-based distros, then you should mount the volume appending :Z option, which will set correct SELinux context for it.

docker запустив -it -v /home/archi/ASF/config:/app/config:Z --name asf --pull завжди justarchi/archisteamfarm

Це дозволить ASF створити файли, які посилаються на об'єм всередині контейнерів для docker.

---

Синхронізація декількох екземплярів

ASF includes support for multiple instances synchronization, as stated in management section. Під час запуску ASF у контейнері ви можете опціонально виконати "opt-in" у процесі, у випадку, якщо ви запускаєте декілька контейнерів із ASF і ви бажаєте щоб вони працювали один з одним.

За замовчуванням, кожен ASF працює у контейнері для докерок, це означає, що синхронізація не відбуватиметься. In order to enable synchronization between them, you must bind /tmp/ASF path in every ASF container that you want to synchronize, to one, shared path on your docker host, in read-write mode. Це досягається так само, як пов'язувати об'єм, який було описано вище, з різними шляхами:

mkdir -p /tmp/ASF-g1
docker запустити -v /tmp/ASF-g1:/tmp/ASF -/home/archi/config/config:/app/config --name asf1 --pull archi/archisteamfarm
docker run -v /tmp/ASF-g1mp/home/joF/configapp/config --name asf2 --pull завжди just/archisteamfarm
І так далі, і це, усі ASF контейнери синхронізовані один з одним

Ми рекомендуємо пов'язати /tmp/ASF директорію тимчасового /tmp на вашому пристрої, але звичайно, ви вільні обирати будь-яку іншу інформацію, яка задовільняє вашому використанню. Кожен контейнер ASF, який потрібно синхронізувати з каталогом /tmp/ASF спільно з іншими контейнерами, які беруть участь у тому ж процесі синхронізації.

Як ви ймовірно здогадалися з прикладу вище, також можливо створити дві або більше "груп синхронізації", приєднуючись до різних шляхів хоста docker в /tmp/ASF.

Монтування /tmp/ASF не рекомендується, якщо ви явно не хочете синхронізувати два або більше контейнерів ASF. Ми не рекомендуємо монтувати /tmp/ASF для одноконтейнерів, оскільки він не дає абсолютно жодних переваг, якщо ви очікуєте запустити лише один контейнер ASF, і це дійсно може викликати проблеми, яких можна було б уникнути в іншому випадку.

---

Аргументи командного рядка

ASF дозволяє вам передати аргументи командного рядка у контейнері docker через змінні середовища. Для підтримуваних перемикачів слід використовувати конкретні змінні середовища і ASF_ARGS для решти. Це можна досягти за допомогою -e перемикач, доданий в docker запустіть, наприклад:

docker запустив -it -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--no-config-migrate" --name asf --pull завжди justarchi/archisteamfarm

This will properly pass your --cryptkey argument to ASF process being run inside docker container, as well as other args. Звичайно, якщо ви досвідчений користувач, ви також можете змінити ENTRYPOINT або додати CMD і передати ваші аргументи самостійно.

Якщо ви не хочете вказати користувацький ключ шифрування або інші додаткові параметри, зазвичай не потрібно включати жодних спеціальних змінних середовища, оскільки наші контейнери docker вже налаштовані для запуску з розумними очікуваними опціями --no-restart --system-requiredтак що ці прапори не потрібно вказувати явно в ASF_ARGS.

---

IPC

Assuming you didn't change the default value for IPC global configuration property, it's already enabled. Однак ви повинні зробити дві додаткові речі, щоб IPC працював у контейнері Docker. По-перше, ви повинні використовувати IPCPassword або змінити значення за замовчуванням KnownNetworks в користувацькому IPC. onfig що дозволяє вам підключатися ззовні не використовуючи одного. Якщо ви не знаєте, що ви робите, просто використовуйте IPCPassword. По-друге, необхідно змінити типову адресу прослуховування localhost, оскільки докер не може прямувати поза мережею і петлі інтерфейсу. An example of a setting that will listen on all interfaces would be http://*:1242. Звичайно, можна також використовувати більш обмежуючі з'єднання, такі як локальна мережа LAN або VPN. але це повинен бути маршрут назовні - localhost не буде робити, оскільки маршрут проходить вже не в гостьовій машині.

For doing the above you should use custom IPC config such as the one below:

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

Як тільки ми налаштуємо IPC на не-циклічному інтерфейсі, нам потрібно повідомити docker для відображення 1242/tcp порт -P або -p switch.

Наприклад, ця команда викриє інтерфейс IPC ASF на хостинг-сервер (лише ):

docker запустив -it -p 127.0.0.1:1242:1242 -p [:1]:1242:1242 --name asf --pull завжди justarchi/archisteamfarm

If you set everything properly, docker run command above will make IPC interface work from your host machine, on standard localhost:1242 route that is now properly redirected to your guest machine. Також приємно відзначити, що ми не досліджуємо цей маршрут, так що з'єднання можна зробити тільки в хваті на стані, і, і, таким чином, зберігати його у безпеці. Звичайно, ви можете встановити маршрут далі, якщо ви знаєте, що ви робите і забезпечити відповідні заходи безпеки.

---

Повний приклад

Поєднання цілих знань вище, приклад повної установки буде виглядати наступним чином:

docker запустив -p 127.0.0.1:1242:1242 -p [:1]:1242:1242 -v /home/archi/ASF/config:/app/config -v /home/archi/ASF/plugins:/app/plugins --name asf --pull завжди justarchi/archisteamfarm

This assumes that you'll use a single ASF container, with all ASF config files in /home/archi/ASF/config. Ви повинні змінити шлях конфігурації до тієї, яка відповідає вашому комп’ютеру. It's also possible to provide custom plugins for ASF, which you can put in /home/archi/ASF/plugins. Ці налаштування також готові до додаткового використання IPC, якщо ви вирішили включити IPC. конфігурація у вашому каталозі налаштувань з вмістом нижче, як тут:

{
    "Kestrel": {
        "Endpoints": {
            "HTTP": {
                "Url": "http://*:1242"
            }
        }
    }
}

---

Pro tips

Коли у вас вже є табір контейнерів ASF, вам не потрібно використовувати докер працювати кожного разу. Ви можете легко зупинити/запустити контейнер для docker ASF за допомогою docker зупинити asf і docker запустити asf. Keep in mind that if you're not using latest tag then using up-to-date ASF will still require from you to docker stop, docker rm and docker run again. Це тому, що вам потрібно перебудувати ваш контейнер зі свіжого зображення docker ASF кожен раз, коли ви бажаєте використовувати версію ASF включені в це зображення. В останній тег , ASF включив функцію автоматичного оновлення так що повторне створення зображення не є необхідним для використання оновленого ASF (але для цього корисно робити це час від часу до того, щоб використовувати свіже. Залежності під час виконання ET та базової ОС, які можуть бути потрібні при переході через основні оновлення ASF).

As hinted by above, ASF in tag other than latest won't automatically update itself, which means that you are in charge of using up-to-date justarchi/archisteamfarm repo. Це має багато переваг, як, зазвичай, додаток не повинен торкатися власного коду при запуску, але ми також розуміємо зручність, бо не потрібно турбуватися про версію ASF у вашому контейнері. If you care about good practices and proper docker usage, released tag is what we'd suggest instead of latest, but if you can't be bothered with it and you just want to make ASF both work and auto-update itself, then latest will do.

Ви зазвичай повинні запустити ASF у контейнері з заголовками: true глобальний параметр. Це явно скаже ASF, що ви знаходитесь не у наданні відсутніх відомостей, і це не має запитувати їх. Of course, for initial setup you should consider leaving that option at false so you can easily set up things, but in long-run you're typically not attached to ASF console, therefore it'd make sense to inform ASF about that and use input command if need arises. Таким чином, ASF не буде змушений чекати безкінечну кількість вхідних даних, які не будуть відбуватися (і витрачають ресурси, які це роблять). Це також дозволить ASF запустити у неінтерактивному режимі всередині контейнера, який необхідно використовувати, наприклад у відношенні до пересилання сигналів, що дозволяє ASF граційно закрити докер зупинити asf запиту.