Waarom Combineer Systemed met Docker voor productie-implementaties

Moderne infrastructuur vereist dat containerized services overleven onverwachte reboots, hardwarestoringen of pakketupdates. Terwijl Docker herstart beleid () biedt, deze beleidsmaatregelen werken alleen zolang de Docker daemon draait. Systemed .. het init systeem gebruikt door Ubuntu, Debian, Fedora, CentOS, en de meeste moderne Linux distributies ..neemt dit verder door het beheer van de levenscyclus van de Docker daemon zelf en kan containers zelfs voordat de Docker socket beschikbaar komt te starten. Voordelen van het gebruik van systemd omvatten:

  • Gegarandeerde opstartorder via afhankelijkheidsrichtlijnen (bijv. na netwerk.target, na docker.service)
  • Unified logging via , waardoor debuggen eenvoudigweg wordt
  • Fijnkorrelige controle over resource limits (CPU, geheugen, I/O) met behulp van systeem-eenheid richtlijnen
  • Automatische herstart bij storing met instelbare vertraging en burstlimieten
  • Ondersteuning voor het activeren van de socket en het getimede opstarten

Door elke Docker container in een systeemservicebestand te verpakken, krijgen de operationele teams een consistente interface voor het starten, stoppen en monitoren van containers, waardoor het vertrouwen op ad-hoc scripts en handmatige interventie wordt verminderd.

Een Systemed Service voor een enkele Docker Container aanmaken

De standaard aanpak omvat het schrijven van een service unit bestand dat Docker commando's oproept om de container te draaien en te stoppen. Hieronder lopen we stap voor stap door het proces, te beginnen met een basisvoorbeeld en dan de gemeenschappelijke productie eisen.

Stap 1: Schrijf het Service Unit bestand

Maak een bestand aan met de naam . Gebruik het volgende sjabloon als startpunt:

[Unit]
Description=My Application Container
After=network-online.target docker.service
Wants=network-online.target
Requires=docker.service

[Service]
Restart=always
RestartSec=10
StartLimitBurst=3
ExecStartPre=-/usr/bin/docker kill myapp
ExecStartPre=-/usr/bin/docker rm myapp
ExecStart=/usr/bin/docker run --rm --name myapp \
 -e DB_HOST=10.0.1.50 \
 -e DB_PORT=5432 \
 -v /data/myapp:/app/data \
 -p 8080:8080 \
 myregistry/myapp:latest
ExecStop=/usr/bin/docker stop -t 10 myapp
ExecStopPost=-/usr/bin/docker rm myapp

[Install]
WantedBy=multi-user.target

Uitleg van belangrijke richtlijnen:

  • . . . als Docker wordt gestopt, stopt deze dienst ook.
  • . . De container wordt met een timeout (10 seconden) op een sierlijke manier gestopt.
  • . . . start de container opnieuw op, ongeacht de code van de uitgang.
  • . . . wacht 10 seconden voordat de start begint.

Stap 2: Inschakelen en starten van de dienst

sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.service

De vertelt systemd om servicebestanden opnieuw te lezen. maakt de symlink zodat de service start op opstarten.

De service beheren met standaard gesystemeerde commando's

Zodra de service draait, je controleert het net als elke andere systeem service:

  • Start:
  • Stop:
  • Herstart:
  • Status:
  • Logs: (volgt levende logboeken)

Geavanceerde configuratiepatronen

Productie-implementaties vereisen vaak meer dan een eenvoudige . Hieronder zijn veel voorkomende verbeteringen die u kunt toevoegen aan uw systeemservicebestanden.

Omgevingsvariabelen passeren

Harde codering geheimen of configuratie in het servicebestand wordt niet aanbevolen. Gebruik in plaats daarvan een apart omgevingsbestand:

[Service]
EnvironmentFile=-/etc/myapp/env.conf
ExecStart=/usr/bin/docker run --rm --name myapp \
 --env-file /etc/myapp/env.conf \
 myregistry/myapp:latest

Het voorvoegsel voor het pad betekent dat de dienst zal starten, zelfs als het bestand niet bestaat (handig tijdens de eerste installatie).

Netwerken en poorten binden

Voor containers die op dezelfde host met elkaar moeten communiceren, moet u overwegen of door de gebruiker gedefinieerde brugnetwerken te gebruiken. Voorbeeld:

ExecStart=/usr/bin/docker run --rm --name web \
 --network=my-net \
 -p 443:443 \
 -v /etc/ssl/certs:/etc/ssl/certs:ro \
 myregistry/web:latest

Als u een aangepast netwerk gebruikt, zorg dan dat het netwerk bestaat voordat de dienst start. U kunt een commando toevoegen om het aan te maken:

ExecStartPre=/usr/bin/docker network create my-net

Inter-Containerafhankelijkheden

Wanneer een container een andere vereist om klaar te zijn voordat hij begint (bijvoorbeeld een webapp die wacht op een database), kan systemd bestellen afdwingen. Maak een tweede servicebestand voor de database en dan:

[Unit]
Description=Web App Container
After=network-online.target docker.service mydb.service
BindsTo=mydb.service

verbindt de webapp de levenscyclus van de database container . . . als de database stopt, de web-app wordt ook gestopt.

Gezondheidscontroles en -readyness

Docker gezondheidscontroles kunnen worden geïntegreerd met het systeem om vroegtijdige beschikbaarheid van de dienst te voorkomen. Gebruik met een script dat het eindpunt van de gezondheid pols:

ExecStartPost=/usr/local/bin/wait-for-health.sh http://localhost:8080/health 30

Het script moet 0 alleen verlaten als de container gezond is. Als het mislukt, markeert het systeem de eenheid als mislukt.

Middelenlimieten via Systemed

U kunt een container PCU en geheugen op het niveau van de cgroup zonder Docker own resource vlaggen. Dit is vooral handig bij het uitvoeren van meerdere containers op een enkele host:

[Service]
MemoryMax=512M
CPUQuota=50%

Deze instellingen creëren een harde limiet die systeem onafhankelijk van Docker afdwingt.

Beheer van meerdere containers: Gesystemeerd vs. Docker componeren

Voor een klein aantal containers (bijv. 2-5), zijn individuele systeemservicebestanden eenvoudig en onderhoudbaar. Echter, wanneer een project veel onderling verbonden diensten omvat, wordt Docker Compose handiger. U kunt nog steeds gebruik maken van het systeem om de gehele Docker Compose stack te orkestreren door het creëren van een enkele service-eenheid die aanroept . Voorbeeld:

[Unit]
Description=My Application Stack
After=network-online.target docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/myapp
ExecStart=/usr/local/bin/docker-compose up -d
ExecStop=/usr/local/bin/docker-compose down

[Install]
WantedBy=multi-user.target

Deze benadering geeft je de eenvoud van Compose voor het definiëren van diensten in combinatie met systeembeheer van de levenscyclus. Merk op dat wordt gebruikt omdat onmiddellijk vertrekt. houdt de eenheid in een actieve ..staat totdat wordt genoemd.

Welke methode moet u kiezen?

  • Individueel systeemdiensten .. het beste voor oudere toepassingen, diensten met strikte opstartbestelling, of wanneer u per container resource limieten nodig hebt.
  • Docker Compose with systemd .. ideaal voor microservices stapels waar afhankelijkheden intern worden behandeld door Compose, en je wilt een enkele eenheid om de hele groep te beheren.

Problemen oplossen van gemeenschappelijke problemen

Zelfs met een zorgvuldige setup, kunt u problemen tegenkomen. Hieronder zijn frequente valkuilen en hun oplossingen.

Service mislukt met

Dit betekent meestal dat de service begint voordat de Docker socket klaar is. Zorg ervoor dat uw unit bevat en ]. Controleer ook of de Docker daemon is ingeschakeld: .

Container herstart in een lus

Als de container onmiddellijk verlaat, zal het systeem het blijven herstarten overeenkomstig en ]. Controleer containerlogboeken met . Verhoog (bijv. 30 seconden) en stel in om een drukke lus te voorkomen.

Service stopt niet schoon

Een verkeerd geconfigureerd mag de container laten draaien. Controleer of de juiste containernaam gebruikt. Gebruik om de container krachtig te verwijderen als de stop niet werkt.

Omgevingsvariabelen niet geladen

Als u gebruikt, bevestig dan dat het bestand bestaat en door root leesbaar is. Vermijd het citeren van problemen ..systeem strips citaten van variabele waarden. Voor geheime injectie, overwegen het gebruik van systeemgegevens of een speciale geheime manager.

Veiligheidsoverwegingen

Het uitvoeren van Docker containers door systeem verhoogt een paar veiligheidspunten:

  • Voer altijd de systeemdienst als niet-root gebruiker uit indien mogelijk (gebruik en ] richtlijnen, maar zorg ervoor dat de gebruiker toegang heeft tot de Docker socket of in rootless modus draait).
  • Vermijd het gebruik van in systemed units tenzij absoluut noodzakelijk.
  • Gebruik alleen-lezen bind mounts () wanneer de container niet naar de host hoeft te schrijven.
  • De maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale maximale 
[Service]
ProtectSystem=strict
ReadWritePaths=/var/log/myapp
PrivateTmp=true
User=myappuser

Externe middelen

Voor nadere informatie, zie deze officiële referenties:

Conclusie

Het integreren van systeemed met Docker containers geeft u een robuust, geautomatiseerd opstartmechanisme dat naadloos integreert met de rest van uw Linux systeem. Door goed gestructureerde service unit bestanden te schrijven, kunt u de opstartorder beheren, afhankelijkheden beheren, resourcelimieten instellen en logs monitoren met behulp van tools die uw operationele team al weet. Of u nu individuele services kiest voor elke container of één enkele unit om een Compose stack te orkestreren, het systeem biedt de betrouwbaarheid en voorspelbaarheid die productieomgevingen vereisen.

Begin met een eenvoudig unit bestand, test het grondig, dan laag op geavanceerde opties zoals omgevingsbestanden, gezondheidscontroles en veiligheid verharding. Met deze aanpak, uw Docker containers zal overleven reboots, crashes, en configuratie veranderingen zonder handmatige interventie, waardoor uw team te concentreren op het bouwen van toepassingen.