Fjern rutinejob fra huskelisten

Ja. En Semaphore-tidsplan starter en eksisterende opgaveskabelon, hvad enten applikationen kører en Ansible-playbook, Terraform- eller OpenTofu-konfiguration eller et Bash-, Python- eller PowerShell-script. Konfigurer først repository, legitimation, mål og eksekveringsmiljø i skabelonen. Tilføj derefter tidspunkt og understøttede input til tidsplanen. Hver kørsel gemmer en normal opgaveregistrering frem for en særskilt model for planlagte scripts.

Ja. Semaphore tilbyder almindelige forudindstillede tidsplaner og accepterer et standard-cron-udtryk med fem felter til mere præcis timing. Kontroller betydningen med næste kørselsvisning før lagring. En tidsplan starter en eksisterende opgaveskabelon; den erstatter ikke playbook, Terraform-konfiguration eller script i Git-repositoryet. Hold jobbet idempotent, hvor gentagelser kan berøre samme infrastruktur.

Ja, hvis du allerede har en testet opgaveskabelon til operationen. Eksempelvis kan en ugentlig Ansible-patchplaybook eller et certifikatfornyelsesscript udløses af en tidsplan. Semaphore bestemmer starttid og gemmer eksekveringsregistreringen; playbooken eller scriptet skal stadig opdatere, verificere resultatet og rapportere fejl korrekt. Tilføj notifikationer, når en mislykket kørsel kræver opmærksomhed før næste patchvindue eller certifikatudløb.

Tidsplaner bruger Semaphore-serverens konfigurerede tidszone med UTC som standard. Den viste tidszone og næste kørselsvisning hjælper med at forklare udtrykket; de er ikke en separat tidszoneindstilling for hver tidsplan. Dokumenter serverens tidszone sammen med frekvensen, især når ingeniører arbejder i flere regioner. Kontroller forventede kørsler omkring tidsskift, hvis zonen bruger sommertid, før du stoler på et vedligeholdelsesvindue.

En tidsplan kan levere understøttede opgaveparametre via prompts, der er aktiveret på skabelonen. Start med at beslutte, hvilke værdier der må variere, og aktivér kun de input. Test den tilsigtede kombination manuelt, og gem derefter tidsplanens overrides. Skabelonen indeholder fortsat den genbrugelige eksekveringskonfiguration. En tidsplan må ikke blive en måde at omgå handlingens inputdesign eller stilfærdigt udvide dens målomfang.

Planlagt arbejde bruger den normale opgaveeksekveringsmodel og dens indstillinger for samtidighed og kapacitet. En hyppig timer gør ikke overlappende ændringer på samme mål sikre. Sammenlign forventet opgavevarighed med intervallet, og overvej låse eller idempotent adfærd i automatiseringen selv. Test den relevante vente- og overlapadfærd i installationen, før en kort frekvens bruges til ressourcekrævende eller destruktive operationer.

Åbn projektets opgavehistorik, og find den kørsel, du vil undersøge. Gennemgå status, tider, kildekontekst og værktøjsoutput før beslutning om genkørsel. Sammenlign planlagt og observeret start ved diagnosticering af forsinkelser. Notifikationer kan sende vigtige resultater til en konfigureret kanal, men opgaven forbliver den detaljerede eksekveringsregistrering.

Antag ikke genforsøg, indhentning af mistede kørsler eller kalenderadfærd, som ikke er dokumenteret for den installerede version. En tidsplan definerer, hvornår en operation skal startes; gendannelse efter nedetid er et separat krav, der skal designes og testes. Beslut, om en mistet sikkerhedskopi eller vedligeholdelseskontrol skal køre forsinket, springes over eller kræve en ingeniørs beslutning. Valget afhænger af operationen og dens virkning på målmiljøet.

Den aktuelle tidsplanformular vælger en opgaveskabelon frem for et workflow. Start et helt workflow på en timer ved at kalde Pro-workflow-API'et fra en ekstern planlægger eller en scriptopgaveskabelon planlagt i Semaphore. Workflowet følger derefter konfigurerede afhængigheder, godkendelser og succes- eller fejlgrene. Fremskridtet registreres som en separat workflowkørsel. Se workflows og workflow-API-dokumentationen.