Docker zh HK
ๅพ็ๆฌ3.0.3.2 ้ๅง, ASF ็พๅจไนๅฏไฝฟ็จ docker containerใ Running ASF in docker container typically has no advantages for casual users, but it could be an excellent way of making use of ASF on servers, ensuring that ASF is being run in sandboxed environment separated from all other apps. Our docker packages are currently available on ghcr.io as well as Docker Hub.
ASF ๆฏๆด4็จฎไธป่ฆ้กๅ็** ๆจ็ฑค **๏ผ
This tag always points to the ASF built from latest commit in master branch, which works the same as experimental AppVeyor build described in our release cycle. ้ๅธธ๏ผๆจๆ่ฉฒ้ฟๅ ไฝฟ็จๆญคๆจ่จ๏ผๅ ็บๅฎไปฅ้็ผ็บ็ฎ็๏ผๅฐ้ๆไพ็ตฆ้็ผไบบๅกๅ้ซ็ด็จๆถ๏ผๅฏ่ฝๆๅคง้ๆผๆดใ The image is being updated with each commit in the master GitHub branch, therefore you can expect very often updates (and stuff being broken), just like in our AppVeyor build. ๆๅๅจๆญคๆจ่จASF้ ็ฎ็็พๆ็ๆ ๏ผไธไธๅฎไฟ่ญ็ฉฉๅฎๆๆธฌ่ฉฆ๏ผๅฐฑๅๅจๆๅ็็ผๅธ้ฑๆไธญๆๅบ็้ฃๆจฃใ ๆญคๆจ่จไธๆๅจไปปไฝ็็ข็ฐๅขไธญไฝฟ็จใ
่ไธ้ข้กไผผ็ๆฏ๏ผๆญคๆจ่จๅง็ตๆๅ**ๆๆฐ็ผไฝ็ASF็ๆฌ**๏ผๅ
ๆฌ้ ็ผไฝ็ๆฌใ ่masterๆจ่จ็ธๆฏ๏ผๆฏๆฌกๆไธๆฐ็GitHubๆจ่จๆๆญคๅๅ้ฝๆๆดๆฐใ Dedicated to advanced/power users that love to live on the edge of what can be considered stable and fresh at the same time. ๅฆๆๆจไธๆณไฝฟ็จ ๆๆฐ ๆจ่จ๏ผๆๅๅปบ่ญฐๆจไฝฟ็จๆญค้ธ้
ใ ่ซๆณจๆ๏ผไฝฟ็จๆญคๆจ็ฑค็ญๆผไฝฟ็จๆๅ็ ้ ็ผไฝ็ๆฌใ
This tag in comparison with others, is the only one that includes ASF auto-updates feature and points to the latest stable ASF version. The objective of this tag is to provide a sane default Docker container that is capable of running self-updating, OS-specific build of ASF. Because of that, the image doesn't have to be updated as often as possible, as included ASF version will always be capable of updating itself if needed. 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 ASF version, contrary to all other tags that include OS with .NET Core runtime and generic ASF version. This is because newer (updated) ASF version might also require newer runtime than the one the image could possibly be built with, which would otherwise require image to be re-built from scratch, nullifying the planned use-case.
In comparison with above tags, this tag is completely frozen, which means that the image won't be updated once published. This works similar to our GitHub releases that are never touched after the initial release, which guarantees you stable and frozen environment. Typically you should use this tag when you want to use some specific ASF release (older than latest) and you don't want to use any kind of auto-updates (e.g. those offered in latest tag).
้ๅๆฑบๆผๆจ้่ฆไป้บผใ For majority of users, latest tag should be the best one as it offers exactly what desktop ASF does, just in special Docker container as a service. People that are rebuilding their images quite often and would instead prefer to have ASF version tied to given release are welcome to use released tag. If you instead want to use some specific frozen ASF version that will never change without your clear intention, A.B.C.D releases are available for you as fixed ASF milestones you can always fall back to.
ๆๅ้ๅธธไธ้ผๅตๅ่ฉฆmasterๆงๅปบ๏ผๅฐฑๅ่ชๅAppVeyorๆงๅปบไธๆจฃโโ้ๅๆงๅปบๅจ้่ฃๆฏ็บไบๆจ่จASF้
็ฎ็็พๆ็ๆ
ใ Nothing guarantees that such state will work properly, but of course you're more than welcome to give them a try if you're interested in ASF development.
ASF docker image is currently built on linux platform with 3 architectures - x64, arm and arm64. You can read more about them in compatibility section.
Since ASF version V5.0.2.2, our tags are using multi-platform manifest, which means that Docker installed on your machine will automatically select the proper image for your platform when pulling the image. 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 pull. See docker documentation on image manifest for more info.
For complete reference you should use official docker documentation, we'll cover only basic usage in this guide, you're more than welcome to dig deeper.
Firstly we should verify if our docker is even working correctly, this will serve as our ASF "hello world":
docker pull justarchi/archisteamfarm
docker run -it --name asf --rm justarchi/archisteamfarmdocker pull command ensures that you're using up-to-date justarchi/archisteamfarm image, just in case you had outdated local copy in your cache. docker run creates a new ASF docker container for you and runs it in the foreground (-it). --rm ensures that our container will be purged once stopped, since we're just testing if everything works fine for now.
If everything ended successfully, after pulling all layers and starting container, you should notice that ASF properly started and informed us that there are no defined bots, which is good - we verified that ASF in docker works properly. Hit CTRL+P then CTRL+Q in order to quit foreground docker container, then stop ASF container with docker stop asf.
ๅฆๆๆจไป็ดฐๆฅ็่ฉฒๅฝไปค๏ผ้ฃ้บผๆจๆๆณจๆๅฐๆๅๆฒๆ่ฒๆไปปไฝๆจ่จ๏ผ่ฉฒๆจ่จ่ชๅ้ ่จญ็บlatestใ If you want to use other tag than latest, for example released, then you should declare it explicitly:
docker pull justarchi/archisteamfarm:released
docker run -it --name asf --rm justarchi/archisteamfarm:released้กฏ่ๆ่ฆ๏ผๅฆๆๆจๅจdockerๅฎนๅจไธญไฝฟ็จASF๏ผๆจ้่ฆ่ชๅทฑ้
็ฝฎ็จๅบใ You can do it in various different ways, but the recommended one would be to create ASF config directory on local machine, then mount it as a shared volume in ASF docker container.
ไพๅฆ๏ผๆๅๅ่จญๆจ็ASF้
็ฝฎ่ณๆๅคพไฝๆผ /home/archi/ASF/config็ฎ้ไธญใ This directory contains core ASF.json as well as bots that we want to run. 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 pull justarchi/archisteamfarm
docker run -it -v /home/archi/ASF/config:/app/config --name asf justarchi/archisteamfarmๅฐฑๆฏ้ๆจฃ๏ผ็พๅจๆจ็ASF dockerๅฎนๅจๅฐๅจ่ฎๅฏซๆจกๅผไธไฝฟ็จ่ๆฌๅฐ่จ็ฎๆฉ็ๅ
ฑไบซ็ฎ้๏ผ้ๆฏ้
็ฝฎASFๆ้็ไธๅใ In similar way you can mount other volumes that you'd like to share with ASF, such as /app/logs or /app/plugins.
Of course, this is just one specific way to achieve what we want, nothing is stopping you from e.g. creating your own Dockerfile that will copy your config files into /app/config directory inside ASF docker container. ๆญคๆๅๅ
ๆถต่ๅบๆฌ็จๆณใ
้ ่จญๆ
ๆณไธ๏ผASFๅจๅฎนๅจๅ
งไฝฟ็จroot็จๆถ้่กใ This is not a problem security-wise, since we're already inside Docker container, but it does affect the shared volume as newly-generated files will be normally owned by root, which may not be desired situation when using a shared volume.
Docker allows you to pass --user flag to docker run command which will define default user that ASF will run under. You can check your uid and gid for example with id command, then pass it to the rest of the command. ไพๅฆ๏ผๅฆๆ็ฎๆจ็จๆถ็uidๅgid็บ1000๏ผ
docker pull justarchi/archisteamfarm
docker run -it -u 1000:1000 -v /home/archi/ASF/config:/app/config --name asf justarchi/archisteamfarm่ซ่จไฝ๏ผ้ ่จญๆ
ๆณไธ๏ผASFไฝฟ็จ็/ app็ฎ้ไปๆญธrootๆๆใ ๅฆๆๆจๅจ่ช่จ็จๆถไธ้่กASF๏ผๅASF้ฒ็จๅฐ็กๆฌๅฐๅ
ถ่ชๅทฑ็ๆชๆก้ฒ่กๅฏซ่จชๅใ ้็จฎๅญๅๆฌ้ๅฐๆผๆไฝไธๆฏๅผทๅถๆง็๏ผไฝๅฎๆฏ่ณ้้่ฆ็๏ผไพๅฆ็จๆผ่ชๅๆดๆฐๅ่ฝใ ็บไบ่งฃๆฑบ้ๅๅ้ก๏ผๅช้ๅฐๆๆASFๆไปถ็ๆๆๆฌๅพ้ป่ช็rootๆดๆน็บๆฐ็่ช่จ็จๆถๅณๅฏใ
docker exec -u root asf chown -hR 1000:1000 /appThis has to be done only once after you created your container with docker run, and only if you decided to use custom user for ASF process. Also don't forget to change 1000:1000 argument in both commands above to the uid and gid you actually want to run ASF under.
ASF includes support for multiple instances synchronization, as stated in compatibility section. When running ASF in docker container, you can optionally "opt-in" into the process, in case you're running multiple containers with ASF and you'd like for them to synchronize with each other.
By default, each ASF running inside a docker container is standalone, which means that no synchronization takes place. 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. This is achieved exactly the same as binding a volume which was described above, just with different paths:
mkdir -p /tmp/ASF-g1
docker pull justarchi/archisteamfarm
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/archi/ASF/config:/app/config --name asf1 justarchi/archisteamfarm
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/john/ASF/config:/app/config --name asf2 justarchi/archisteamfarm
# And so on, all ASF containers are now synchronized with each otherWe recommend to bind ASF's /tmp/ASF directory also to a temporary /tmp directory on your machine, but of course you're free to choose any other one that satisfies your usage. Each ASF container that is expected to be synchronized should have its /tmp/ASF directory shared with other containers that are taking part in the same synchronization process.
As you've probably guessed from example above, it's also possible to create two or more "synchronization groups", by binding different docker host paths into ASF's /tmp/ASF.
Mounting /tmp/ASF is completely optional and actually not recommended, unless you explicitly want to synchronize two or more ASF containers. We do not recommend mounting /tmp/ASF for single-container usage, as it brings absolutely no benefits if you expect to run just one ASF container, and it might actually cause issues that could otherwise be avoided.
ASF allows you to pass command-line arguments in docker container through environment variables. You should use specific environment variables for supported switches, and ASF_ARGS for the rest. This can be achieved with -e switch added to docker run, for example:
docker pull justarchi/archisteamfarm
docker run -it -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--process-required" --name asf justarchi/archisteamfarmThis will properly pass your --cryptkey argument to ASF process being run inside docker container, as well as other args. Of course, if you're advanced user then you can also modify ENTRYPOINT or add CMD and pass your custom arguments yourself.
Unless you want to provide custom encryption key or other advanced options, usually you don't need to include any special environment variables, as our docker containers are already configured to run with a sane expected default options of --no-restart --process-required --system-required, so as you can see our ASF_ARGS above are redundant in this case, and only ASF_CRYPTKEY is relevant.
For using IPC, firstly you should switch IPC global configuration property to true. In addition to that, you must modify default listening address of localhost, as docker can't route outside traffic to loopback interface. An example of a setting that will listen on all interfaces would be http://*:1242. Of course, you can also use more restrictive bindings, such as local LAN or VPN network only, but it has to be a route accessible from the outside - localhost won't do, as the route is entirely within guest machine.
For doing the above you should use custom IPC config such as the one below:
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}Once we set up IPC on non-loopback interface, we need to tell docker to map ASF's 1242/tcp port either with -P or -p switch.
ไพๅฆ๏ผๆญคๅฝไปค๏ผๅ ๏ผๆๅฐASF IPCๆฅๅฃๆด้ฒ็ตฆไธปๆฉ๏ผ
docker pull justarchi/archisteamfarm
docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 --name asf justarchi/archisteamfarmIf 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ไธปๆฉไธญ้ฒ่ก้ฃๆฅ๏ผๅพ่ไฟ่ญๅ
ถๅฎๅ
จใ Of course, you can expose the route further if you know what you're doing and ensure appropriate security measures.
็ถไธๆ่ฟฐ๏ผๅฎๆด่จญ็ฝฎ็็ฏไพๅฆไธๆ็คบ๏ผ
docker pull justarchi/archisteamfarm
docker run -it -p 127.0.0.1:1242:1242 -p [::1]:1242:1242 -v /home/archi/asf:/app/config --name asf justarchi/archisteamfarmThis assumes that you'll use a single ASF container, with all ASF config files in /home/archi/asf. You should modify the config path to the one that matches your machine. This setup is also ready for optional IPC usage if you've decided to include IPC.config in your config directory with a content like below:
{
"Kestrel": {
"Endpoints": {
"HTTP": {
"Url": "http://*:1242"
}
}
}
}When you already have your ASF docker container ready, you don't have to use docker run every time. You can easily stop/start ASF docker container with docker stop asf and docker start asf. Keep in mind that if you're not using latest tag then updating ASF will still require from you to docker stop, docker rm, docker pull and docker run again. This is because you must rebuild your container from fresh ASF docker image every time you want to use ASF version included in that image. In latest tag, ASF has included capability to auto-update itself, so rebuilding the image is not necessary for using up-to-date ASF (but it's still a good idea to do it from time to time in order to use fresh .NET Core runtime and underlying OS).
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. This has many advantages as typically the app should not touch its own code when being run, but we also understand convenience that comes from not having to worry about ASF version in your docker container. 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.
You should typically run ASF in docker container with Headless: true global setting. This will clearly tell ASF that you're not here to provide missing details and it should not ask for those. 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. This way ASF won't have to wait infinitely for user input that will not happen (and waste resources while doing so). It will also allow ASF to run in non-interactive mode inside container, which is crucial e.g. in regards to forwarding signals, making it possible for ASF to gracefully close on docker stop asf request.
 |
 |
 |
 |
|---|---|---|---|
 |
 |
 |
 |
|---|---|---|---|
- ๐ก Home
- ๐ง Configuration
- ๐ฌ FAQ
- โ๏ธ Setting up (start here)
- ๐ฅ ๅพๅฐๅบ่ๅๅๅจ
- ๐ข Commands
- ๐ ๏ธ Compatibility
- ๐งฉ ItemsMatcherPlugin
- ๐ Management
- โฑ๏ธ Performance
- ๐ก Remote communication
- ๐ช Steam ่ฆชๅๅไบซ
- ๐ Trading