Gör en agent till en tjänst, inte en bortglömd terminal.

Paketera arbetaren

Använd en runtime som stöds, låsta beroenden och en tjänstehanterare eller container. Konfigurera omstartsgränser och en dedikerad tjänsteanvändare. Förvara privata leverantörsuppgifter i skyddad konfiguration utanför applikationens publika filer.

Spara förloppet innan åtgärderna spelar roll

Använd en hållbar kö eller databas för jobb. Tilldela en unik åtgärdsidentifierare, registrera externa förfrågningar och stäm av osäkra utfall. En omstart bör inte skicka ett andra e-postmeddelande, skapa en andra order eller debitera två gånger.

Lägg till användbar observerbarhet

Övervaka jobbens slutförande, köns ålder, felkvot och kostnad i stället för att bara kontrollera om en process finns. Håll loggarna tillräckligt små för att granskas och maskera tokens, prompter och dokument som inte behöver sparas.

Sätt ett tydligt tak

Begränsa modellutgifter, webbläsarkonkurrens, körtid och antal återförsök. Håll en enkel pausbrytare och en mänsklig granskningsväg för konsekvensfyllda åtgärder. En mindre, väl observerad arbetare är lättare att lita på än en obegränsad.

Använd en supervisor och ett genomtänkt schema

Systemd och Docker är vanliga sätt att få en process att överleva en frånkoppling av terminalen. För en systemd-tjänst kan Type=exec rapportera körningsfel mer direkt än en enkel bakgrundsstart, och Restart=on-failure kan starta om fel med en begränsad policy. Schemalagda jobb bör undvika överlappande körningar. Håll arbetskatalog, tjänsteanvändare och miljö explicit angivna. Exemplet förutsätter att användaren koala-agent, den virtuella miljön, arbetsmodulen och den privata miljöfilen redan finns; anpassa dem innan du installerar en enhet.

• Använd ett dedikerat tjänstekonto
• Ställ in en omstartsfördröjning och ett felgränsvärde
• Kontrollera föregående jobbstatus innan en schemalagd körning startas

[Unit]
Description=Example agent worker
After=network-online.target

[Service]
Type=exec
User=koala-agent
WorkingDirectory=/opt/koala-agent
EnvironmentFile=/etc/koala-agent.env
ExecStart=/opt/koala-agent/.venv/bin/python -m worker
Restart=on-failure
RestartSec=10
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Officiell dokumentation: Systemd-tjänstens semantik

Sätt en daglig budget och en gräns för dubbletter

Ge arbetaren ett maximalt antal förfrågningar, en utgiftsgräns och en tidsgräns för körning. Använd en beständig idempotenspost för åtgärder som påverkar omvärlden. Ett lyckat klick i webbläsaren kan inträffa innan processen tar emot ett svar; granska det externa tillståndet innan du försöker igen. Docker Compose-hemlighetsmonteringar kan hålla en hemlighet utanför avbilden, men behörigheter och det konsumerande programmet behöver fortfarande granskas.

Officiell dokumentation: Docker Compose-hemligheter

Ge ett periodiskt jobb en uttrycklig policy för att komma ikapp

Använd en långvarig tjänst för en beständig köarbetare och en timerutlöst oneshot-tjänst för en avgränsad schemalagd uppgift. Med en systemd-kalendertimer kan Persistent=true utlösa en missad aktivering efter driftstopp; det återskapar inte en hel affärsbacklog. Bestäm om denna återhämtning är önskvärd. RandomizedDelaySec kan sprida starter, medan ett lease på applikationsnivå förhindrar att två repliker bearbetar samma schemalagda arbete.

• Registrera den avsedda tidszonen och granska nästa körningstider innan du aktiverar schemat.
• Håll uppgiftens körningsdeadline kortare än ett intervall som inte får överlappa, eller använd ett hållbart lease med utgång och ägarskap.
• Låt jobbet välja utestående arbete från lagrat tillstånd i stället för att anta att varje tidigare timerhändelse kördes.
• Kontrollera den installerade systemd-versionen innan du använder ett direktiv från den senaste manualen.

# Read-only checks after creating your own matching units.
systemctl list-timers --all
systemctl status koala-agent.service
journalctl -u koala-agent.service --since today --no-pager

Officiell dokumentation: systemd: schemaläggning med timers

Skilj en kraschloop från en stannad worker

En omstartspolicy kan återställa en misslyckad process, men att upprepa en ogiltig autentiseringsuppgift eller en trasig migrering var några sekunder gör ett fel mer högljutt. Begränsa tjänstestarter och larma vid upprepat fel. En levande process kan också ha fastnat: mät åldern på det äldsta jobbet och den senast slutförda åtgärden. Testa ett API-avbrott, en tom disk och ett processstopp med engångsjobb och verifiera sedan att det beständiga tillståndet förhindrar dubbla externa åtgärder.

• Ange en leverantörsbudget och en begärandetimeout i applikationen samt en CPU/minnesgräns i körmiljön.
• Docker-containrar har ingen användbar arbetsbelastningsspecifik minnesgräns bara för att de är containrar; konfigurera och testa gränser medvetet.
• Lagra en hemlighet utanför avbilden och den publika trädstrukturen och testa sedan att kraschloggar och diagnostik maskerar den.
• Behåll en manuell stoppväg och kräv lämplig granskning för utgifter, produktionsskrivningar eller externa meddelanden.

Officiell dokumentation: systemd: tjänsteövervakning · Docker: resursbegränsningar för containrar