Jeśli komuś by zależało na tym by jednak wykorzystać cargo watch lub nodemona uruchomionego na kontenerze i używać do tego podmontowanego dysku na Windows, to wrzucam rozszerzenie filmu w postaci artykułu. devenv.pl/jak-sprawic-by-cargo-watch-nodemon-dzialaly-na-kontenerach-na-windows/
Jeżeli ta konfiguracja kontenerów jest zaprojektowana z myślą o programowaniu na stacji roboczej programisty a nie środowisku produkcyjnym, nie lepiej byłoby po prostu współdzielić cały folder projektu między hostem a kontenerem i uruchamiać polecenie budowania nie w Dockerfile, a w skrypcie entrypoint (dla wygody pierwszego uruchomienia) + ręcznie, ale w powłoce tekstowej z wnętrza kontenera (przy zmianach w kodzie)? Ja tak robię i działa mi to dosyć dobrze, choć moje rozwiązanie też ma potencjalne problemy: gorsza wydajność na desktopach innych niż Linux (ze względu na VM); problemy z uprawnieniami plików przy uruchamianiu tych samych poleceń raz na hoście, raz w kontenerze (ale to znowu głównie na Linuksie, bo pewnie VMka na Windows to spłaszcza jakoś…). Być może moje rozwiązanie się nie sprawdzi w przypadku pokazanym na wideo, bo ja pracuję na Fedorze (więc problemy wydajności VM mnie nie dotyczą) i pracuję w językach interpretowanych (więc kompilować ciągle niczego nie muszę). Problem z uprawnieniami częściowo rozwiązuję takim madżik trikiem: github.com/TomaszGasior/RadioLista-v3/blob/f903503fcc75c84a8954014151af86283585bea7/container/php-fpm/entrypoint.sh#L8
Dzięki za komentarz :) Ta konfiguracja startowa jest zaprojektowana z myślą o uruchamianiu lokalnym, jak i potem pod kątem testowania min: integracji i regresji, oraz ciągłej integracji. Rozważałem współdzielenie, ale użyty sposób wydał mi się bardziej intuicyjny, prostszy oraz ... nawet nie będę ukrywał, że samo znalezienie rozwiązania dało mi dużą frajdę ;) Twoje rozwiązanie z entrypointem jest ciekawe. Sprawdzę jak to u mnie zadziała ta zmiana :)
Jeśli komuś by zależało na tym by jednak wykorzystać cargo watch lub nodemona uruchomionego na kontenerze i używać do tego podmontowanego dysku na Windows, to wrzucam rozszerzenie filmu w postaci artykułu. devenv.pl/jak-sprawic-by-cargo-watch-nodemon-dzialaly-na-kontenerach-na-windows/
Ale jak to debugować?
Dodaje do listy tematów do omówienia :) Na razie debuguje z wykorzystanie logów :)
Jeżeli ta konfiguracja kontenerów jest zaprojektowana z myślą o programowaniu na stacji roboczej programisty a nie środowisku produkcyjnym, nie lepiej byłoby po prostu współdzielić cały folder projektu między hostem a kontenerem i uruchamiać polecenie budowania nie w Dockerfile, a w skrypcie entrypoint (dla wygody pierwszego uruchomienia) + ręcznie, ale w powłoce tekstowej z wnętrza kontenera (przy zmianach w kodzie)?
Ja tak robię i działa mi to dosyć dobrze, choć moje rozwiązanie też ma potencjalne problemy: gorsza wydajność na desktopach innych niż Linux (ze względu na VM); problemy z uprawnieniami plików przy uruchamianiu tych samych poleceń raz na hoście, raz w kontenerze (ale to znowu głównie na Linuksie, bo pewnie VMka na Windows to spłaszcza jakoś…).
Być może moje rozwiązanie się nie sprawdzi w przypadku pokazanym na wideo, bo ja pracuję na Fedorze (więc problemy wydajności VM mnie nie dotyczą) i pracuję w językach interpretowanych (więc kompilować ciągle niczego nie muszę). Problem z uprawnieniami częściowo rozwiązuję takim madżik trikiem: github.com/TomaszGasior/RadioLista-v3/blob/f903503fcc75c84a8954014151af86283585bea7/container/php-fpm/entrypoint.sh#L8
Dzięki za komentarz :)
Ta konfiguracja startowa jest zaprojektowana z myślą o uruchamianiu lokalnym, jak i potem pod kątem testowania min: integracji i regresji, oraz ciągłej integracji.
Rozważałem współdzielenie, ale użyty sposób wydał mi się bardziej intuicyjny, prostszy oraz ... nawet nie będę ukrywał, że samo znalezienie rozwiązania dało mi dużą frajdę ;)
Twoje rozwiązanie z entrypointem jest ciekawe. Sprawdzę jak to u mnie zadziała ta zmiana :)
Ale przyznam racje zabawa z dockerem na Windowsie to czasami inna dyscyplina sportu :)