ASF finnes som docker-beholder. Våre dockerpakker er for øyeblikket tilgjengelige på ghcr.io samt Docker hub.

Det er viktig å være oppmerksom på at å kjøre ASF i Docker container er ansett som avansert oppsett, som er ikke trengs til et stort flertall av brukerne, og gir vanligvis ingen fordeler ved over container-mindre oppsett. Hvis du vurderer Docker som løsning for å drive ASF som en tjeneste, for eksempel kan du få det til å starte automatisk med ditt OS, da bør du vurdere å lese Management i stedet og sette opp en riktig systemd tjeneste som vil være nesten alltid en bedre ide enn å drive ASF i en Docker-beholder.

Å ha ASF i Docker container involverer vanligvis flere nye problemer og problemer som du må møte og løse deg selv. 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. Denne delen er for det meste til gyldige brukstilfeller av svært komplekse oppsett, for eksempel når det gjelder avansert nettverks- eller sikkerhet utover standard sandkassen som ASF følger med i systemd tjenesten (som allerede sikrer bedre isolasjon gjennom svært avanserte sikkerhetsmekanismer). For de håndfaste menneskemengdene forklarer vi her bedre ASF-konsepter med hensyn til Docker compatibility, og at du bare forutsettes å ha tilstrekkelig kunnskap om legen selv hvis du bestemmer deg for å bruke det sammen med ASF.

ASF er tilgjengelig med 4 hovedtyper av tagger:

Denne taggen peker alltid på ASF fra siste commit i hovedgrenen, som fungerer som grabbbing av siste forekomst direkte fra CI rørledning. Vanligvis bør du unngå denne taggen ettersom det er det høyeste nivået av feil programvare som er dedikert til utviklere og avanserte brukere av utviklingsformål. Bildet oppdateres med hver utførelse i hoved GitHub grenen, derfor kan du forvente svært ofte oppdateringer (og at ting er ødelagt). Her er det her å markere gjeldende status for ASF-prosjekt. som ikke nødvendigvis garanteres å være stabil eller målt, akkurat som påpekt i frigjøringssyklusen. Denne taggen bør ikke brukes i noen produksjonsmiljø.

Veldig lik det som er nevnt ovenfor, peker denne taggen alltid til den nyeste utgitt ASF-versjonen, inkludert forhånds-utgivelser. Sammenlignet med hoved- -tagg, blir dette bildet oppdatert hver gang en ny GitHub tagg blir trykket. Dedikert til fremskredne/strømbrukere som elsker å leve på kanten av det som kan anses som stabil og fersk samtidig. Dette er hva vi vil anbefale hvis du ikke ønsker å bruke siste -tag. I praksis fungerer det som som rullende stikkord som peker til nyeste A.B.C.D slippes på tidspunktet for trekking. Vær oppmerksom på at bruk av denne taggen er lik ved hjelp av vår forhåndslansering.

Denne taggen sammenligner med andre, er den eneste som inkluderer ASF auto-oppdatering-funksjonen og peker til den nyeste stabil ASF versjon. Målet med denne taggen er å gi en sane standard Docker-beholder som er i stand til å kjøre selvoppdatering, OS-spesifikk versjon av ASF. På grunn av det må ikke bildet oppdateres så ofte som mulig. Som inkludert ASF-versjon vil alltid være i stand til å oppdatere seg selv hvis nødvendig. Selvsagt kan UpdatePeriod være slått av (satt til 0), men i dette tilfelle bør du antakelig bruke frosset A. .C.D frigjøring i stedet. På samme måte kan du endre standard UpdateChannel for å lage automatisk oppdatering utgitt tagg.

På grunn av det faktum at det nyeste bildet gir mulighet for auto-oppdateringer, det inkluderer bare OS med OS-spesifikk linux ASF-versjon, i motsetning til alle andre tagger som inkluderer OS med . ET kjøretid og generisk ASF versjon. Dette fordi nyere (oppdatert) ASF-versjon kanskje også krever nyere kjøretid enn den som bildet muligens kan bygges med, Ellers ville det være nødvendig å bygge om bildet fra bunnen av, og lukke det planlagte brukstilfellet.

Sammenlignet med ovenstående emneord er denne taggen blitt fullstendig frosset, noe som betyr at bildet ikke vil bli oppdatert når det er publisert. Dette fungerer som ligner på våre GitHub-utgivelser som aldri blir berørt etter den første utgivelsen, og som garanterer deg stabilt og frosset miljø. Vanligvis bør du bruke denne taggen når du vil bruke en bestemt ASF-utgivelse, og du vil ikke bruke noen typer auto-oppdateringer (e. . de tilbyr i siste tag).

Det kommer an på det du leter etter. For flertallet av brukere, nyeste bør være det beste fordi det tilbyr nøyaktig hva desktop ASF gjør, bare i spesiell Docker-beholder som en tjeneste. Personer som gjenoppbygger bildene sine ganske ofte og som i stedet foretrekker full kontroll med ASF-versjon knyttet til en gitt utgivelse, er velkomne til å bruke utgitt -taggen. Hvis du i stedet ønsker å bruke en spesifikk frossen ASF-versjon som aldri vil forandre seg uten din klare intensjon, A. .C.D utgivelser er tilgjengelig for deg som faste ASF-milepæler du alltid kan gå tilbake til.

Vi ønsker generelt å unngå å prøve hovedbygg , som det er her for å markere gjeldende tilstand i ASF-prosjektet. Ingenting garanterer for at slik stat vil fungere ordentlig, men du er selvfølgelig mer enn velkommen til å gi dem et forsøk hvis du er interessert i ASF-utvikling.

ASF dockerbilde er bygget på linux plattform som sikter mot 3 arkitekter - x64, arm og arm64. Du kan lese mer om dem i kompatibilitet seksjonen.

Våre tagger bruker manifestet for flerplattformer, hvilket betyr at Docker som er installert på maskinen din vil automatisk velge riktig bilde for plattformen din når du trekker bildet. Hvis du på en sjanse vil du trekke et bestemt plattformbilde som ikke samsvarer med den du kjører akkurat nå, du kan gjøre det gjennom --platform -bryteren i egnede docker-kommandoer, slik som docker kjører. Se dokumentasjonen for docker på bilde-manifest for mer informasjon.

For fullstendig referanse skal du bruke **offisiell dokumentasjon**Vi dekker bare grunnleggende bruk i denne veiledningen, du er mer velkommen til å grave dypere.

Først bør vi kontrollere om vår dokker fungerer riktig, dette vil tjene som vår ASF "hallo verden":

dokker kjører -it --name asf --pull alltid --rm justarchi/archisteamfarm

docker run oppretter en ny ASF docker-beholder for deg og kjører den i forgrunnen (- it). - trekk alltid sikrer at det oppdaterte bildet vil bli trukket først, og --rm sikrer at beholderen vår blir renset når den har stoppet, siden vi bare tester om alt fungerer bra nå.

Hvis alt gikk suksessfullt, etter å ha trukket alle lag og startbeholder, du bør merke deg at ASF startet riktig og informerer oss om at det ikke finnes noen definert botter, Det som er godt, vi bekreftet at ASF på dokker fungerer riktig. Hit CTRL+C for å avslutte ASF-prosessen og derfor også beholderen.

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. Hvis du vil bruke en annen tagg enn nyeste, for eksempel utgitt, skal du deklarere den eksplisitt:

dokker kjører -det --name asf --pull alltid --rm justarchi/archisteamfarm:released

Dersom du bruker ASF i forankringsbeholderen, må du åpenbart konfigurere programmet selv. Du kan gjøre det på ulike måter. men den anbefalte ville være å opprette ASF config mappen på lokal maskin, Demonter det som et delt volum i ASF-docerbeholder.

For eksempel, vi antar at mappen med ASF config er i /home/archi/ASF/config mappen. Denne mappen inneholder kjernen ASF.json samt bots som vi vil kjøre. Nå trenger vi bare å gjøre ved å feste denne mappen som delt volum i vår docker-beholder, der ASF forventer sin konfigurasjonsmappe (/app/config).

docker kjører -det -v /home/archi/ASF/config:/app/config --name asf --pull alltid justarchi/archisteamfarm

Og det er det, nå vil ASF-forankringsbeholderen bruke delt mappe med den lokale maskinen i lesemodus, som er alt du trenger for å konfigurere ASF. På samme måte kan du montere andre volumer som du ønsker å dele med ASF, som /app/logs eller /app/plugins.

Selvsagt er dette bare én spesifikk måte å oppnå det vi ønsker, ingenting stopper deg ved f.eks. oppretter din egen Dockerfile som skal kopiere konfigurasjonsfilene til /app/config mappen, i ASF docker beholderen. Vi dekker bare grunnleggende bruk i denne veiledningen.

ASF-beholder som standard er initialisert med standard rot -bruker, som tillater den å håndtere interne tillatelsesting og deretter til slutt bytte til asf (UID 1000) brukeren i den gjenværende delen av hovedprosessen. Selv om dette skal tilfredsstilles for de aller fleste brukerne, det påvirker delt volum som nygenererte filer vil normalt eies av asf brukeren, kanskje ikke er ønsket situasjon hvis du vil like en annen bruker for ditt felles volum.

Det er to måter du kan endre bruker ASF på på. Den første, anbefalt, er å erklære ASF_USER miljøvariabler med mål UID du vil kjøre under. For det andre: alternativet, er å sende --user flagg, som støttes direkte av docker.

Du kan sjekke uid for eksempel med id -u -kommandoen, og erklære den som angitt ovenfor. For eksempel, hvis din målbruker har uid av 1001:

docker kjør -det -e ASF_USER=1001 -v /home/archi/ASF/config:/app/config --name asf --pull alltid justarchi/archisteamfarm

# Alternativt Hvis du forstår begrensningene under
docker kjører -den -u 1001 -v /home/archi/ASF/config:/app/config --name asf --always justarchi/archisteamfarm

Differansen mellom ASF_USER og --user flagg er delt, men viktig. ASF_USER er egendefinert mekanisme støttet av ASF, i dette scenarioforankringsbeholderen starter fremdeles som root, og så ASF startet oppstartsskriptet hovedbinær under ASF_USER. Ved bruk av - bruker -flagg, starter du hele prosessen, inkludert ASF oppstartsskriptet som gitt bruker. Først valg tillater ASF oppstartsskriptet å håndtere tillatelser og andre ting automatisk for deg, å løse noen vanlige problemer som du kan ha medført for eksempel sikrer den at /app og /asf mappene eies av ASF_USER. I andre scenario, siden vi ikke kjører som root, Det kan vi ikke gjøre, og det er forventet du å håndtere deg selv på forhånd.

Hvis du har bestemt deg for å bruke --user flagg, du må endre eierskapet til alle ASF-filer fra standard asf til din nye egendefinerte bruker. Du kan gjøre dette ved å utføre kommandoen nedenfor:

# Kjør bare hvis du ikke bruker ASF_USER
docker exec -u root asf chown -hR 1001 /app /asf

Dette må gjøres bare én gang etter at du har laget beholderen din med docker kjørt, og bare hvis du bestemte deg for å bruke egendefinert bruker gjennom --user docker flagg. Ikke glem å endre 1001 argument i kommandoen ovenfor til UID du faktisk ønsker å kjøre ASF under.

Dersom du bruker SELinux i tvungen tilstand på OS'en, som er misligholdt for eksempel på RHEL-baserte distroer, deretter bør du montere volumet som legges til :Z -valget, som vil angi riktig SELinux-kontekst for den.

docker kjør -det -v /home/archi/ASF/config:/app/config:Z --name asf --pull alltid justarchi/archisteamfarm

Dette gjør det mulig med ASF å opprette filmål på volumet mens du befinner deg i beholderen for dockere.

ASF inkluderer støtte for flere forekomster synkronisering, som angitt i håndtering avsnitt. Når du bruker ASF i dokkerbeholderen, kan du eventuelt «opt-in» i prosessen, Hvis du kjører flere beholdere med ASF, og du vil gjerne at de skal synkroniseres med hverandre.

Som standard er hver ASF som kjører inne i en docker-beholder frittstående, noe som betyr at det ikke skjer noen synkronisering. For å aktivere synkronisering mellom dem, må du binde /tmp/ASF banen i hver ASF-beholder som du vil synkronisere, til en, delte stier på din docker-vert, i lese-skrivemodus. Dette oppnås nøyaktig det samme som å binde et volum som er beskrevet ovenfor, bare med forskjellige baner:

mkdir -p /tmp/ASF-g1
docker run -v /tmp/ASF-g1:/tmp/ASF -v /home/archi/ASF/config:/app/config --name asf1 --pull alltid justarchi/archisteamfarm
docker kjører -v /tmp/ASF-g1:/tmp/ASF -v /home/john/ASF/config:/app/config app/name asf2 --pull alltid justarchi/archeamfarm
Og så på alle ASF-beholdere er nå synkronisert med hverandre

Vi anbefaler å binde ASF's /tmp/ASF katalog også til en midlertidig /tmp mappe på maskinen, men du er selvfølgelig klar til å velge en annen som har oppfylt bruksområdet ditt. Hver ASF-beholder som forventes å synkroniseres, bør ha mappene /tmp/ASF delt med andre beholdere som tar del i samme synkroniseringsprosess.

Som du sannsynligvis har gjettet over eksempelet er det også mulig å opprette to eller flere "synkroniseringsgrupper", ved å binde en annen forankringsstasjon til ASFs /tmp/ASF.

Montering /tmp/ASF er helt valgfritt og anbefales faktisk ikke med mindre du eksplisitt ønsker å synkronisere to eller flere ASF-beholdere. Vi anbefaler ikke montering /tmp/ASF til engangsbruk siden det absolutt ingen fordeler hvis du forventer å kjøre bare én ASF-beholder, – og det kan faktisk forårsake problemer som ellers kunne unngås.

ASF lar deg sende kommandolinjeargumenter i dokumentasjonsbeholderen gjennom miljøvariabler. Du bør bruke spesifikke miljøvariabler for støttede brytere, og ASF_ARGS for resten. Dette kan oppnås med -e bryteren ble lagt til docker kjøring, for eksempel:

docker kjør -den -e "ASF_CRYPTKEY=MyPassword" -e "ASF_ARGS=--no-config-migrate" --name asf --pull alltid justarchi/archisteamfarm

Dette vil sørge for at --cryptkey -argumentet for at ASF-prosessen skal kjøres i beholderen for dokker i tillegg til andre mål. Hvis du er avansert bruker, kan du selvfølgelig også endre ENTRYPOINT eller legge til CMD og sende dine egendefinerte argumenter selv.

Med mindre du ønsker å legge inn egendefinert krypteringsnøkkel eller andre avanserte alternativer, vanligvis ikke du trenger å inkludere noen spesielle miljøvariabler, siden løsningsbeholderne våre allerede er konfigurert til å kjøre med et sane forventede standardalternativer for --ingen omstart --system-påkrevd, så disse flaggene trenger ikke angis eksplisitt i ASF_ARGS.

Forutsatt at du ikke endret standardverdien for IPC globale konfigurasjonsegenskapen, er den allerede aktivert. Du må imidlertid gjøre to ting ekstra for at klimapanelen skal virke i Docker-beholderen. Først må du bruke IPCPassword eller endre standard KnownNetworks i egendefinert IPC. onfig slik at du kan koble deg fra utsiden uten å bruke en. Med mindre du virkelig vet hva du gjør, bruk bare IPCPassword. For det andre, du må endre standard lyttingsadresse av localhostsiden docker ikke kan rute utenfor trafikk til loopback-grensesnitt. Et eksempel på en innstilling som vil lytte på alle grensesnitt vil være http://*:1242. Selvsagt kan du også bruke mer restriktive bindinger, for eksempel kun lokalt nettverk for LAN eller VPN men det må være en rute som er tilgjengelig fra utsiden - localhost vil ikke fungere. siden ruten er helt på gjestemaskinen.

For å gjøre det ovennevnte bør du bruke egendefinert IPC config , som for eksempel følgende:

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

        }
    }

Når vi setter opp IPC på «non-loopback»-grensesnitt, vi må fortelle docker for å kartlegge ASF's 1242/tcp port enten med -P eller -p bryter.

For eksempel vil denne kommandoen utsette ASF IPC sitt grensesnitt til vertsmaskin (bare):

docker kjør -it -p 127.0.1:1242:1242 -p [::1]:1242:1242 --name asf --pull alltid justarchi/archisteamfarm

Legger du på alt ordentlig, docker kjøre kommandoen ovenfor vil gjøre IPC grensesnittet fungerer fra vertsmaskinen, på standard localhost:1242 rute, som nå blir omdirigert til din gjestemaskin. Det er også fint å merke seg at vi ikke utsetter denne veien ytterligere. Det kan derfor gjøres forbindelse bare hos legens vert, og derfor holde den sikker. Du kan selvsagt utsette ruten videre hvis du vet hva du gjør og sørge for egnede sikkerhetstiltak.

Ved å kombinere hele kunngjøringen ovenfor vil et eksempel på et fullstendig oppsett kunne se slik ut:

docker run -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 alltid justarchi/archisteamfarm

Dette forutsetter at du bruker en enkel ASF-beholder, med alle ASF-konfigurasjonsfiler i /home/archi/ASF/config. Du bør endre konfigurasjonstien til den som matcher maskinen. Det er også mulig å skrive inn egendefinerte plugins for ASF, som du kan skrive i /home/archi/ASF/plugins. Dette oppsettet er også klart for valgfri bruk av IPC hvis du har besluttet å inkludere IPC. onfig i konfigurasjonsmappen med et innhold som nedenfor:

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

        }
    }

Når du allerede har ASF-forankringsbeholderen klar, trenger du ikke bruke docker run hver gang. Du kan enkelt stoppe/starte ASF docker-beholderen med docker stop asf og docker starter asf. Husk at hvis du ikke bruker nyeste tagg, vil det fortsatt kreves up-to-date ASF fra deg til docker stopp, docker rm og docker kjører igjen. Dette er fordi du må gjenoppbygge beholderen fra et friskt ASF-docerbilde hver gang du ønsker å bruke ASF-versjon inkludert i det bildet. I siste tag, har ASF inkludert mulighet til å automatisk oppdatere seg selv. Det er ikke nødvendig å gjenoppbygge bildet for å bruke oppdaterte ASF-er (men det er likevel lurt å gjøre det fra tid til annen for å bruke ny versjon. ET kjøretidsavhengigheter og det underliggende OS, som kan være nødvendig ved hopping over store ASF-versjoner).

Som ventet ovenfor vil ASF i andre tag enn siste ikke automatisk oppdatere seg selv. som betyr at du tar ansvaret for å bruke moderne justarchi/archisteamfarm opppo. Det er mange fordeler, slik at appen vanligvis ikke bør røre sin egen kode når den kjøres, men vi forstår også bekvemmeligheter som ikke kommer fra å være bekymret for ASF-versjon i dockerbeholderen. 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.

Du bør vanligvis kjøre ASF i en docker-beholder med Hodemin: sann global innstilling. Dette vil tydelig fortelle ASF at du ikke er her for å oppgi manglende opplysninger og bør ikke spørre om disse. Selvfølgelig, for første oppsett bør du vurdere å forlate dette alternativet på false slik at du enkelt kan sette opp ting, men på lenge er du typisk ikke knyttet til ASF-konsoll, derfor vil det gi mening å informere ASF om at og bruke input kommando hvis det oppstår problemer. På denne måten vil ASF ikke trenge å vente uendelig på brukerinndata som ikke vil skje (og ikke sparingsressurser når du gjør det). Det vil også gjøre det mulig for ASF å kjøre i ikke-interaktiv form inne i beholderen, noe som er viktig, f.eks. når det gjelder å videresende signaler, noe som gjør det mulig for ASF å forsikre seg om at docker stopper asf forespørselen.