Sind Serviceadressen für das dc/os-Host-Betriebssystem verfügbar?

Question

Ich versuche, meine dc/os 1.8 docker container senden Log-Nachrichten an eine Logstash, die auch in dc/os läuft unter Verwendung der Service-Adresse des Logstash-Service.

, die nicht zu funktionieren scheinen, als Docker einen Fehler wirft: logstash.marathon.l4lb.thisdcos.directory: no such host

sind Service-Adressen an die Host-Systeme nicht ausgesetzt (oder muss ich etwas für diese konfigurieren)?

auf dc/os 1.7 Ich verwendete einen festen Host-Port in meiner Logstash-Konfiguration und logstash.marathon.mesos als Host, aber diese .marathon.mesos Hostnamen scheinen nicht in 1.8 mehr existieren.

Die Dienstadressen funktionieren einwandfrei, wenn ich versuche, sie innerhalb eines Containers zu verwenden (zum Beispiel um meinen Prometheus-Dienst mit meinem Alertmanager-Dienst zu verknüpfen). aber von der Host-Ebene existieren sie nicht.

EDIT:

meine Aussage über die fehlenden marathon.mesos Urls war falsch. Sie funktionieren, aber ich benutze die falsche. vorerst behebt das mein Problem irgendwie. Ich habe die Protokollierung mit diesem Host und einem festen Container-Port konfiguriert.

für alle, die das gleiche versuchen: Sie müssen den festen Host-Port jedes Mal konfigurieren, wenn Sie Änderungen an der Dienstkonfiguration im UI über den JSON-Modus vornehmen. Die Konfiguration des festen Hostports ist in der Netzwerkregisterkarte des ui nicht mehr verfügbar, daher löscht das dc/os ui bei jedem Ladevorgang die Konfiguration des Hostports.

immer noch keine Ahnung, warum die l4lb URLs nicht funktionieren.

EDIT2

noch keine Ahnung, aber ich herausgefunden, dass minuteman Protokolle Absturz und Fehler erzeugt jede zweite Sekunde:

/opt/mesosphere/active/minuteman/minuteman/error.log:

CRASH REPORT Process <0.25809.2> with 0 neighbours exited with reason: {timeout,{gen_server,call,[{lashup_kv,'navstar@10.2.140.216'},{start_kv_sync_fsm,'minuteman@10.2.103.143',<0.25809.2>}]}} in gen_server:call/2 line 204 

/opt/mesosphere/active/minuteman/minuteman/log/crash.log

2016-10-12 13:16:49 =CRASH REPORT==== 
    crasher: 
    initial call: lashup_kv_sync_tx_fsm:init/1 
    pid: <0.29002.2> 
    registered_name: [] 
    exception exit: {{timeout,{gen_server,call,[{lashup_kv,'navstar@10.2.140.216'},{start_kv_sync_fsm,'minuteman@10.2.103.143',<0.29002.2>}]}},[{gen_server,call,2,[{file,"gen_server.erl"},{line,204}]},{lashup_kv_sync_tx_fsm,init,1,[{file,"/pkg/src/minuteman/_build/default/lib/lashup/src/lashup_kv_sync_tx_fsm.erl"},{line,23}]},{gen_statem,init_it,6,[{file,"gen_statem.erl"},{line,554}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]} 
    ancestors: [lashup_kv_aae_sup,lashup_kv_sup,lashup_platform_sup,lashup_sup,<0.916.0>] 
    messages: [] 
    links: [<0.992.0>] 
    dictionary: [] 
    trap_exit: false 
    status: running 
    heap_size: 610 
    stack_size: 27 
    reductions: 127 
    neighbours: 

die dc/os ui behauptet spartan und minuteman sind gesund, aber während die crash.log des dns dispatcher ist leer die l4lb bekommt neue stürze jede zweite sekunde.

Answer 1

mein Problem war zweifach:

1. die L4B nicht richtig ausgeführt werden, dass erst nach einer Gesamt Neuinstallation des Clusters

2. die L4B nur TCP-Datenverkehr festgelegt wurde unterstützt. Container-Protokolle senden logstash udp mit (Docker-GELF unterstützt nur UDP) dies fehlschlug, weil ich es benutzen wollte

Answer 2

Sie sollten sicherlich von der Host-Betriebssystem verfügbar sein. Betreiben diese Host-Dienste die Dienste "Spartan" und "Minuteman"?