Phenquestions
S svojimi storitvami sistemd vse to olajša, resnično lažje. Takoj, ko želite, da nekaj spremlja vašo aplikacijo in jo enostavno nadzirate, gre pot systemd in to bom razložil tukaj!
Kje so Systemd Services
No, če želite dodati novo storitev, morate odgovoriti na to vprašanje. Kot vedno v systemd, je odvisno, ali je storitev namenjena samo vašemu uporabniku ali celotnemu sistemu. Osredotočili se bomo na to, kako systemd deluje za celotne sistemske storitve.
Natančna lokacija je odvisna od tega, zakaj in kako je bila storitev nameščena. Če storitev namesti upravitelj paketov, bo na splošno v / usr / lib / systemd / system. Za programsko opremo, ki jo razvijete, ali za tisto, ki sama ne podpira systemd, boste datoteko storitve postavili v / usr / local / lib / systemd / system. Upoštevajte, da nekatere distribucije ne podpirajo te mape v / usr / local. Nazadnje, če želite konfigurirati obstoječo storitev systemd, je pot / etc / systemd / system prava pot.
V teh mapah lahko najdete več končnic datotek, kot je *.vtičnica, *.tarča ali *.storitev. Očitno se bomo osredotočili na zadnje. systemd uporablja ime datoteke kot ime storitve, ko jo zažene ali ustavi itd. Tako na splošno imena datotek v storitvi vsebujejo samo alfanumerične znake skupaj z vezaji in podčrtaji. Med razvojem priporočam, da ga ustvarite v svojih dokumentih in nato po koncu kopirate na sistemsko lokacijo, da se izognete težavam, če med urejanjem shranite.
V redu, zato vas prosimo, da v svojih dokumentih ustvarite svojo servisno datoteko. Zdaj smo pripravljeni pregledati, kako napisati to datoteko.
[Opomba: Oglejte si poročilo o morebitnih napakah v oddelku za komentarje tega prispevka]
Opis = HTTP strežnik Penguins Web Application (deluje v vratih 8080)
WantedBy = več uporabnikov.cilj
[Storitev]
Tip = preprosto
ExecStart = / usr / bin / python3 / usr / local / bin / penguin-web-app / main.py
Ponovni zagon = vedno
Format datoteke je dejansko blizu ini. Vem, da je morda čudno, ker datoteke ini pogosto najdemo v sistemu Windows, vendar tako to deluje. Datoteka s storitvami je najprej razdeljena na 2 oddelka: [Enota] in [Storitev]. Vsak odsek konfigurira določen vidik systemd: [Unit] vsebuje elemente, ki jih imajo v skupni rabi vse datoteke systemd unit, medtem ko je [Service] namenjen samo konfiguraciji za nastavitev nove storitve.
Nato je razdelek konfiguriran z lastnostmi, kot sta Opis = ali ExecStart =. Vrednost je od imena lastnosti ločena z enačbo = brez presledka.
Vrnimo se k zgoraj prikazani datoteki. Opisuje storitev, zasnovano za zagon spletne aplikacije, napisane v Pythonu o pingvinih. systemd ga bo znova zagnal vsakič, ko postopek zapre in zažene strežnik ob zagonu strežnika, če ga omogočite z ukazom systemctl enable. Kul, a?
Morda pa vaša naslednja spletna aplikacija ne govori o pingvinih - in to je sramota - in ni napisano v Pythonu. V tem primeru boste želeli izvedeti več o možnih konfiguracijah.
Lastnosti storitev Systemd
Najprej se osredotočimo na lastnosti v [Enota]:
Opis = gre le za jasen opis, kaj storitev počne. Prikazan je na seznamu storitev, v dnevnikih storitev, zato želite, da je opisen, vendar naj ostane v eni vrstici in enem stavku.
WantedBy = dovoli reči systemd: ko se ta stvar zažene, se tudi mene zažene. Na splošno boste postavili ime cilja. Primeri skupnih ciljev:
- več uporabnikov.target: ko je strežnik v redu in je pripravljen za zagon aplikacij ukazne vrstice
- grafično.Cilj: ko sta pripravljena GNOME ali KDE
- omrežje.Cilj: ko je strežnik pravilno povezan z omrežjem
V redu za začetek so te lastnosti [Enote] dovolj. Oglejmo si zdaj [Service].
Type = pomaga systemd pri ugotavljanju, ali se storitev izvaja. Tu so pogoste vrste:
- je verjetno najpogosteje uporabljen preprost: systemd meni, da postopek, ki ga zaženete, izvaja kot storitev. Če se postopek ustavi, meni, da je tudi storitev ustavljena itd.
- forking je najprimernejši za aplikacije, ki so bile napisane kot strežnik, vendar brez pomoči sistema za upravljanje storitev. V bistvu pričakuje, da se bo začeti postopek razdeljeval in ta vilica velja za končni postopek storitve. Da bi bili natančnejši, lahko pomagate tudi s sistemom z datoteko PID, kjer PID procesa, ki mu želite slediti, zapiše zagnana aplikacija.
ExecStart = je verjetno najpomembnejši za storitev: natančno določa, katero aplikacijo zagnati ob zagonu storitve. Kot lahko vidite v storitvi Penguin, sem takoj uporabil / usr / bin / python3 in ne python3. To je zato, ker sistemska dokumentacija izrecno priporoča uporabo absolutnih poti, da se izognemo presenečenjem.
A to je tudi iz drugega razloga. Sistem upravljanja drugih storitev običajno temelji na Shell skriptih. Vendar systemd zaradi zmogljivosti privzeto ne zažene lupine. Torej ne morete neposredno zagotoviti ukaza lupine v ExecStart =. Vendar lahko še vedno uporabljate skript lupine, tako da naredite:
ExecStart = / usr / bin / bash / usr / local / bin / launch-penguin-server.shNi tako težko, prav? Upoštevajte, da če morate zagnati nek postopek, s katerim želite, da se vaša storitev ustavi, ExecStop = obstaja, pa tudi ExecReload = za ponovno nalaganje storitev.
Restart = vam omogoča, da izrecno določite, kdaj je treba storitev znova zagnati. To je ena od pomembnih značilnosti systemd: zagotavlja, da vaša storitev ostane tako dolgo, kot želite, zato bodite pozorni na to možnost.
| Ponovni zagon = | Pomen |
| nenehno | systemd ga bo znova zagnal, kadar koli se konča ali zruši. No, dokler ne naredite systemctl ustavite ime-storitve.storitev. Idealen je za strežnike in spletne storitve, saj vam je ljubše malo neuporabnih ponovnih zagonov, kot da bi morali ročno znova zagnati storitev brez kakršnega koli razloga. |
| na-nenormalno | Ko se postopek storitve zruši, ga znova zaženite. Če pa aplikacija zapre čisto, je ne zaženite znova. To je bolj uporabno za cron-opravila, kot so storitve, ki morajo zanesljivo opraviti nalogo, vendar jih ni treba ves čas izvajati. |
| ob okvari | Podobno kot on-nenormalno, vendar tudi znova zažene storitev, ko aplikacija izstopi čisto, vendar z izhodno kodo, ki ni nič. Izhodne kode, ki niso nič, na splošno pomenijo napako. |
| št | systemd ne bo samodejno znova zagnal storitve. Na splošno koristno za dostop do drugih sistemskih funkcij, kot je zapisovanje dnevnika brez funkcije ponovnega zagona. |
WorkingDirectory = lahko uveljavi delujoči imenik med zagonom vaše aplikacije. Vrednost mora biti absolutna pot do imenika. Delovni imenik se uporablja, kadar v kodi aplikacije uporabljate relativne poti. Za našo službo za pingvine je to lahko:
WorkingDirectory = / srv / penguin-web-app /Nato je pomembna varnost, zato na splošno ne želite zagnati svoje storitve s skrbniškimi pravicami. User = in Group = vam omogoča, da nastavite ime uporabnika ali skupine ali UID / GID, pod katerim se bo vaša aplikacija zagnala. Na primer:
Uporabnik = pingvin-spletSkupina = splet pingvinov
EnvironmentFile = je močna možnost. Aplikacije, ki se izvajajo kot storitve, pogosto potrebujejo konfiguracijo in datoteke okolja omogočajo nastavitev te konfiguracije na dva načina:
- Aplikacija lahko neposredno bere spremenljivko okolja.
- Lahko pa tudi svoji aplikaciji nastavite različne argumente ukazne vrstice, ne da bi spremenili datoteko storitve.
Sintaksa te datoteke je preprosta: vtipkate ime spremenljivke okolja, znak enačbe = in nato njeno vrednost. Nato v lastnost EnvironmentFile vnesete absolutno pot do datoteke okolja.
Primer:
EnvironmentFile = / etc / penguin-web-app / environmentDatoteka / etc / penguin-web-app / environment vsebuje:
LISTEN_PORT = 8080Potem bo naša spletna aplikacija pingvinov imela dostop do spremenljivke okolja LISTEN_PORT in poslušala pričakovana vrata.
Shranite in zaženite novo ustvarjeno storitev Systemd
Če ste upoštevali moj nasvet, ste datoteko storitve uredili v domačem imeniku. Ko ste zadovoljni, kopirajte to datoteko v / usr / local / lib / systemd / system, ob predpostavki, da vaša distribucija podpira to pot. Ime datoteke vaše servisne datoteke bo ime storitve. To ime datoteke se mora končati z .storitev. Na primer, za naš strežnik pingvinov bi to bila aplikacija pingvin-splet.storitev.
Nato morate sistemu systemd povedati, da ste dodali novo storitev, zato morate vnesti ta ukaz:
$ sudo systemctl daemon-reloadV redu, zdaj je systemd seznanjen z vašo novo storitvijo, če vaša datoteka ne vsebuje sintaksne napake. Konec koncev je to vaša prva datoteka, zato boste verjetno naredili napake. Ta ukaz morate zagnati pri vsaki posodobitvi v servisni datoteki.
Zdaj je čas za zagon storitve:
$ sudo systemctl zaženi spletno aplikacijo pingvin.storitevČe ne uspe z napako Unit not found, kot je ta:
$ sudo systemctl zaženi spletno aplikacijo pingvin.storitevZagon aplikacije pingvin-web ni uspel.storitev: Enote ni mogoče najti.
To pomeni, da vaša distribucija ne podpira imenika ali da niste pravilno poimenovali službene datoteke. Preverite.
Če svojo storitev nastavite z WantedBy = in želite, da se vaša storitev zažene samodejno, jo morate omogočiti s tem ukazom:
$ sudo systemctl omogoči spletno aplikacijo pingvinov.storitevKul stvar pri storitvi je, da deluje v ozadju. Težava: kako vedeti, ali deluje pravilno in ali se izvaja v ozadju? Ne skrbite, sistemska ekipa je razmišljala tudi o tem in poslala ukaz, ali deluje pravilno, od koliko časa itd:
$ systemctl status pingvin-spletna aplikacija.storitevZaključek
čestitke! Zdaj lahko upravljate svoje programe, ne da bi vam bilo treba vsakič znova ročno zagnati. Zdaj vam priporočam, da preberete naš drugi članek o sistemskih dnevnikih: Master journalctl: razumejte sistemske dnevnike. S tem lahko v svoji novi storitvi uporabite zmogljiv sistem beleženja in ustvarite bolj zanesljive strežnike!
