Ta odpowiedź jest po prostu bardziej szczegółową wersją rozwiązania Bradforda Medeirosa , które również dla mnie okazało się najlepszą odpowiedzią, więc zasługa jego.
W swojej odpowiedzi wyjaśnia CO robić ( nazwane rury ), ale nie dokładnie JAK to zrobić.
Muszę przyznać, że nie wiedziałem, jak nazywa się rury, kiedy czytałem jego rozwiązanie. Więc starałem się go wdrożyć (chociaż jest to naprawdę proste), ale mi się udało, więc z przyjemnością pomogę, wyjaśniając, jak to zrobiłem. Tak więc celem mojej odpowiedzi jest po prostu wyszczególnienie poleceń, które musisz uruchomić, aby działało, ale znowu zasługa jego.
CZĘŚĆ 1 - Testowanie koncepcji nazwanego potoku bez dokera
Na głównym hoście wybierz folder, w którym chcesz umieścić swój nazwany plik potoku, na przykład /path/to/pipe/i nazwę potoku mypipe, a następnie uruchom:
mkfifo /path/to/pipe/mypipe
Rura została utworzona. Rodzaj
ls -l /path/to/pipe/mypipe
I sprawdź, czy prawa dostępu zaczynają się od „p”, na przykład
prw-r--r-- 1 root root 0 mypipe
Teraz biegnij:
tail -f /path/to/pipe/mypipe
Terminal oczekuje teraz na przesłanie danych do tego potoku
Teraz otwórz kolejne okno terminala.
A potem biegnij:
echo "hello world" > /path/to/pipe/mypipe
Sprawdź pierwszy terminal (ten z tail -f), powinien wyświetlać „hello world”
CZĘŚĆ 2 - Uruchom polecenia przez potok
W kontenerze hosta, zamiast uruchamiania, tail -fktóre po prostu wyświetla wszystko, co jest wysyłane jako dane wejściowe, uruchom to polecenie, które wykona je jako polecenia:
eval "$(cat /path/to/pipe/mypipe)"
Następnie z drugiego terminala spróbuj uruchomić:
echo "ls -l" > /path/to/pipe/mypipe
Wróć do pierwszego terminala i powinieneś zobaczyć wynik ls -lpolecenia.
CZĘŚĆ 3 - Niech słucha wiecznie
Być może zauważyłeś to w poprzedniej części, zaraz po ls -l wyświetleniu wyjścia, przestaje nasłuchiwać poleceń.
Zamiast eval "$(cat /path/to/pipe/mypipe)"uruchamiać:
while true; do eval "$(cat /path/to/pipe/mypipe)"; done
(nie możesz tego zrobić)
Teraz możesz wysłać nieograniczoną liczbę poleceń jedno po drugim, wszystkie zostaną wykonane, a nie tylko pierwsze.
CZĘŚĆ 4 - Spraw, aby działało nawet po ponownym uruchomieniu
Jedynym zastrzeżeniem jest to, że jeśli host musi się zrestartować, pętla „while” przestanie działać.
Aby obsłużyć ponowne uruchomienie, oto co zrobiłem:
Umieść while true; do eval "$(cat /path/to/pipe/mypipe)"; doneplik w pliku o nazwie execpipe.shz #!/bin/bashnagłówkiem
Nie zapomnij o chmod +xtym
Dodaj go do crontab, uruchamiając
crontab -e
A potem dodawanie
@reboot /path/to/execpipe.sh
W tym momencie przetestuj to: zrestartuj serwer, a kiedy zostanie utworzony, powtórz echo niektórych poleceń w potoku i sprawdź, czy są wykonywane. Oczywiście nie możesz zobaczyć wyniku poleceń, więc ls -lnie pomoże, ale touch somefilepomoże.
Inną opcją jest zmodyfikowanie skryptu, aby umieścić dane wyjściowe w pliku, na przykład:
while true; do eval "$(cat /path/to/pipe/mypipe)" &> /somepath/output.txt; done
Teraz możesz uruchomić, ls -la dane wyjściowe (zarówno stdout, jak i stderr używane &>w bash) powinny znajdować się w output.txt.
CZĘŚĆ 5 - Spraw, by działało z dockerem
Jeśli używasz zarówno docker compose, jak i dockerfile, tak jak ja, oto co zrobiłem:
Załóżmy, że chcesz zamontować folder nadrzędny mypipe /hostpipew swoim kontenerze
Dodaj:
VOLUME /hostpipe
w pliku dockerfile, aby utworzyć punkt montowania
Następnie dodaj to:
volumes:
- /path/to/pipe:/hostpipe
w swoim pliku Docker Compose, aby zamontować / ścieżkę / do / potok jako / hostpipe
Zrestartuj kontenery Dockera.
CZĘŚĆ 6 - Testowanie
Wykonaj do swojego kontenera docker:
docker exec -it <container> bash
Przejdź do folderu montowania i sprawdź, czy widzisz rurę:
cd /hostpipe && ls -l
Teraz spróbuj uruchomić polecenie z kontenera:
echo "touch this_file_was_created_on_main_host_from_a_container.txt" > /hostpipe/mypipe
I powinno działać!
OSTRZEŻENIE: jeśli masz hosta OSX (Mac OS) i kontener Linuksa, to nie zadziała (wyjaśnienie tutaj https://stackoverflow.com/a/43474708/10018801 i wystaw tutaj https://github.com/docker / for-mac / Issues / 483 ), ponieważ implementacja potoku nie jest taka sama, więc to, co napiszesz do potoku z Linuksa, może być odczytane tylko przez Linuksa, a to, co napiszesz do potoku z Mac OS, może zostać odczytane tylko przez Mac OS (to zdanie może nie być zbyt dokładne, ale pamiętaj, że istnieje problem między platformami).
Na przykład, kiedy uruchamiam konfigurację dockera w DEV z mojego komputera z systemem Mac OS, nazwany potok, jak wyjaśniono powyżej, nie działa. Ale w przejściach i produkcji mam Linux hosta i kontenery Linuksa i działa idealnie.
CZĘŚĆ 7 - Przykład z kontenera Node.JS
Oto jak wysyłam polecenie z kontenera node js do głównego hosta i pobieram dane wyjściowe:
const pipePath = "/hostpipe/mypipe"
const outputPath = "/hostpipe/output.txt"
const commandToRun = "pwd && ls-l"
console.log("delete previous output")
if (fs.existsSync(outputPath)) fs.unlinkSync(outputPath)
console.log("writing to pipe...")
const wstream = fs.createWriteStream(pipePath)
wstream.write(commandToRun)
wstream.close()
console.log("waiting for output.txt...") //there are better ways to do that than setInterval
let timeout = 10000 //stop waiting after 10 seconds (something might be wrong)
const timeoutStart = Date.now()
const myLoop = setInterval(function () {
if (Date.now() - timeoutStart > timeout) {
clearInterval(myLoop);
console.log("timed out")
} else {
//if output.txt exists, read it
if (fs.existsSync(outputPath)) {
clearInterval(myLoop);
const data = fs.readFileSync(outputPath).toString()
if (fs.existsSync(outputPath)) fs.unlinkSync(outputPath) //delete the output file
console.log(data) //log the output of the command
}
}
}, 300);