Docker no NO
Starting with version 3.0.3.2, ASF is now also available as docker container. Running ASF in docker container typically has no advantages for casual users, but it might 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 repo can be found here.
ASF is available through 4 main types of tags:
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. Typically you should avoid this tag, as it's the highest level of bugged software dedicated to developers and advanced users for development purposes. 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. It's here for us to mark current state of ASF project, which is not necessarily guaranteed to be stable or tested, just like pointed out in our release cycle. This tag should not be used in any production environment.
Very similar to the above, this tag always points to the latest released ASF version, including pre-releases. Compared to master tag, this image is being updated each time a new GitHub tag is pushed. 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 is what we'd recommend if you don't want to use latest tag. Please note that using this tag is equal to using our pre-releases.
This tag in comparison with previous two, as the first one includes ASF auto-updates feature and will typically point to the one of the stable versions, but not necessarily the latest one. The objective of this tag is to provide a sane default Docker container that is capable of running self-updating 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 ``), 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.
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 and you don't want to use auto-updates that are offered in latest tag.
That depends on what you're looking for. 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 fallback to.
We generally discourage trying master builds, just like automated AppVeyor builds - this build is here for us to mark current state of ASF project. 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 available for 2 architectures - x64 and arm. You can read more about them in compatibility section.
Since multi-arch docker tags are still work-in-progress, builds for other architectures than default x64 are currently available with -{ARCH} appended to the tag name. In other words, if you want to use latest tag for arm architecture, simply use latest-arm.
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 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).
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, and remove it with docker rm asf.
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 latest-arm, then you should declare it explicitly:
docker pull justarchi/archisteamfarm:latest-arm
docker run -it --name asf justarchi/archisteamfarm:latest-armIf you're using ASF in docker container then obviously you need to configure the program itself. 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.
For example, we'll assume that your ASF config folder is in /home/archi/ASF/config directory. 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/archisteamfarmAnd that's it, now your ASF docker container will use shared directory with your local machine in read-write mode, which is everything you need for configuring ASF.
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. We're only covering basic usage in this guide.
ASF is by default run with default root user inside a container. 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 might 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. For example, if your target user has uid and gid of 1000:
docker pull justarchi/archisteamfarm
docker run -it -u 1000:1000 -v /home/archi/ASF/config:/app/config --name asf justarchi/archisteamfarmRemember that by default /app directory used by ASF is still owned by root. If you run ASF under custom user, then your ASF process won't have write access to its own files. This access is not mandatory for operation, but it is crucial e.g. for auto-updates feature. In order to fix this, it's enough to change ownership of all ASF files from default root to your new custom user.
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 allows you to pass command-line arguments in docker container by using ASF_ARGS environment variable. This can be added on top of docker run with -e switch. For example:
docker pull justarchi/archisteamfarm
docker run -it -e "ASF_ARGS=--process-required" --name asf justarchi/archisteamfarmThis will properly pass --process-required argument to ASF process being run inside docker container. Of course, if you're advanced user then you can also modify ENTRYPOINT and pass your custom arguments yourself.
For using IPC, firstly you should configure ASF to launch it properly, which would be setting IPC, IPCPrefixes and SteamOwnerID global configuration properties appropriately.
Once we achieve that and ASF properly brings up IPC interface, we need to tell docker to map ASF 1242/tcp port either with -P or -p switch.
For example, this command would expose ASF IPC interface to host machine (only):
docker pull justarchi/archisteamfarm
docker run -it -p 127.0.0.1:1242:1242 --name asf justarchi/archisteamfarmAssuming you set IPCPrefixes properly to something like http://*:1242/, the above command will make IPC client examples work from the host machine.
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 might still be 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).
 |
 |
 |
 |
|---|---|---|---|
 |
 |
 |
 |
|---|---|---|---|
- 🏡 Hjem
- 🔧 Konfigurasjon
- 💬 FAQ
- ⚙️ Oppsett (start her)
- 👥 Bakgrunn-spillinnløser
- 📢 Kommandoer
- 🛠️ Kompatibilitet
- 🧩 ItemsMatcherPlugin
- 📋 Håndtering
- ⏱️ Ytelse
- 📡 Fjerntilgang
- 👪 Steam familiedeling
- 🔄 Bytting