Kør job på tværs af netværk fra én brugerflade

Globale runnere registreres til brug på tværs af instansen, mens projektrunnere tilhører et bestemt projekt. Global distribueret eksekvering er tilgængelig i alle planer; projektomfang og relaterede routingmuligheder indgår i Pro og Enterprise som vist i priserne. Vælg omfang efter driftsansvar og miljøadgang. En projektspecifik runner kan give bevidst placering, men runtimekonfigurationen bestemmer stadig, hvad en eksekverende proces kan tilgå.

Runneren starter kommunikationen ved at forbinde til Semaphore og forespørge efter arbejde. Det muliggør placering bag NAT eller i privat netværk uden en serverinitieret indgående forbindelse til runneren. Runneren skal stadig nå Semaphore-endpointet og opgavernes repositories, pakkekilder, eksterne tjenester og mål. Kontroller forbindelserne enkeltvis; udgående polling fjerner ikke andre netværkskrav.

Brug understøttede runnertags, skabelonkrav og standardrunnerindstillinger til at matche arbejde med et passende eksekveringsmiljø. Navngiv tags efter meningsfuld funktion eller placering, og hold tilgængelighed og kapacitet synlig. Hvis ingen egnet runner er klar, kan opgaven vente. Test ruten med en ufarlig operation, og bekræft den udførende runner i opgavedetaljerne før produktionsændringer.

Ikke i sig selv. En lokal eksekutor kører i runnerværtens proceskontekst med den adgang, miljøet giver. Docker eller Kubernetes indfører en anden grænse, men mounts, privilegier, netværk og imageindhold er stadig vigtige. Vælg placering og eksekveringstilstand som separate beslutninger. Forbered afhængigheder og gennemgå værtsadgang frem for at betragte ordene runner eller container som en fuldstændig sikkerhedsgaranti.

Forbered den runtime, hvert job kræver på sin valgte eksekveringsvej. Understøttede eksekutorimageindstillinger kan holde et bestemt sæt Ansible-, Terraform-, Python- eller andre afhængigheder tydeligt uden at ændre alle job på en fælles vært. Kontroller installeret version og edition for de relevante eksekutormuligheder. Test derefter repositoryadgang, pakker og målforbindelser i det faktiske miljø, ikke kun fra en administrators interaktive session.

Tilføjelse af runnere udvider eller flytter opgaveeksekveringen; det skaber ikke et kontrolplan for applikationen med høj tilgængelighed. Applikations-HA bruger flere koordinerede Semaphore-noder med den dokumenterede fælles database, Redis og belastningsfordeling. Mulighederne kan supplere hinanden, men løser forskellige problemer. Afgør, om flaskehalsen er eksekveringskapacitet, netværksadgang eller adgang til brugerfladen og API'et, før du vælger, hvilken del af installationen der skal skaleres.

Opgaven venter, indtil en tilgængelig runner matcher skabelonens routingkrav. Kontroller runnertag, aktiveringsflag og seneste forbindelsesstatus og derefter eksekveringskapaciteten. Et tag er en udvælgelsesregel, så en runner uden tag eller med andet tag tager ikke automatisk jobbet.

Ja. En skabelon kan tilsidesætte standardjobimaget, når runneren bruger Docker-eksekutoren i Pro eller Kubernetes-eksekutoren i Enterprise. Det lader job bruge den værktøjskæde, automatiseringen kræver. Forbered imaget med nødvendige applikationer og afhængigheder; feltet ændrer ikke lokal eksekutoradfærd. Se skabelonens eksekveringsindstillinger.