Einige Befehle wie up -d service_name oder start service_name dies ist ziemlich nützlich, wenn Sie nicht möchten, dass die ausgeführten Container vom Status der Shell abhängen, wie dies bei regulären Containern der Fall ist up service_name. Der einzige Anwendungsfall besteht darin, es von einer Art kontinuierlichem Integrations- / Bereitstellungsserver aus auszuführen.
Diese Art des Ausführens / Startens von Diensten gibt jedoch keine Rückmeldung über den tatsächlichen Status des Dienstes danach.
Ich hatte ein ähnliches Bedürfnis. Ich habe jedoch eine restart: always in meiner Umgebung. Es kann also etwas schwierig sein zu erkennen, ob etwas abstürzt und in einer Schleife neu startet.
Ich habe einen Icinga / Nagios-Check durchgeführt, um auch die Erstellungs- und Startzeiten zu vergleichen. Vielleicht ist es für jemand anderen auf der ganzen Linie nützlich:
#!/usr/bin/env pythonfrom __future__ import print_functionimport argparsefrom datetime import timedeltafrom datetime import datetimeimport sysfrom dateutil.parser import parse as parse_dateimport dockerimport pytzparser = argparse.ArgumentParser()parser.add_argument("compose_project", help="The name of the docker-compose project")parser.add_argument("compose_service", help="The name of the docker-compose service")args = vars(parser.parse_args())client = docker.from_env()service_containers = client.containers.list(filters={ "label": [ "com.docker.compose.oneoff=False", "com.docker.compose.project={}".format(args["compose_project"]), "com.docker.compose.service={}".format(args["compose_service"]) ]})if len(service_containers) == 0: print("CRITICAL: project({})/service({}) doesn't exist!".format( args["compose_project"], args["compose_service"])) sys.exit(2)elif len(service_containers) > 1: print("CRITICAL: project({})/service({}) has more than 1 " "container!".format( args["compose_project"], args["compose_service"])) sys.exit(2)service_container = service_containers[0]created_at = parse_date(service_container.attrs['Created'])status = service_container.attrs['State']['Status']started_at = parse_date(service_container.attrs['State']['StartedAt'])now = datetime.utcnow().replace(tzinfo=pytz.utc)uptime = now - started_atif status in ['stopped', 'exited', 'dead']: print("CRITICAL: project({})/service({}) is status={}".format( args["compose_project"], args["compose_service"], status)) sys.exit(2)if (started_at - created_at) > timedelta(minutes=5): if uptime < timedelta(seconds=5): print("CRITICAL: project({})/service({}) appears to be " "crash-looping".format( args["compose_project"], args["compose_service"])) sys.exit(2)if status == "restarting": print("WARNING: project({})/service({}) is restarting".format( args["compose_project"], args["compose_service"])) sys.exit(1)print ("OK: project({})/service({}) is up for {}".format( args["compose_project"], args["compose_service"], uptime))sys.exit(0)
Dies gibt nur den Status des Docker-Containers zurück. Wenn Sie den tatsächlichen Status Ihrer Anwendung überprüfen möchten, sollten Sie HEALTHCHECK zu Ihrer Docker-Datei hinzufügen (https://docs.docker.com/engine/reference/builder/#healthcheck). Danach können Sie es inspizieren mit:
container starten und laufen entweder unbegrenzt oder stoppen sofort mit einem Fehlercode (z. B. für fehlende Konfiguration)
sie führen die Prüfung nur einmal durch, nachdem docker-compose up -d zurückgegeben wurde
sie können überprüfen, ob ein Container aufgrund eines Fehlers gestoppt wurde mit:docker ps -a | grep 'Exited (255)'.
Diese Prüfung funktioniert auch bei Containern, von denen erwartet wird, dass sie sofort fehlerfrei anhalten (dh Datencontainer), korrekt, da ihr Status (von docker ps -a) ist gekennzeichnet als Exited (0).
Zum Beispiel in unserem Docker-Compose.yml, wir beginnen unsere Container mit: