Jak praktycznie wykorzystywać obrazy dockerowe?

Od paru dni uczę się dockera. Znam komendy, oglądam sobie tutoriale na YT, testuję pierwsze komendy. Jednak większość tutoriali opiera się o założenie "stworzyłem sobie poza kamerą stronę internetową, bazę danych, to i tamto i teraz jedną komendą wyślę to na księżyc przez dockera".

A ja próbuję zrozumieć sam workflow. Bo rozumiem, że mogę napisać sobie program w pythonie przykładowo.. utworzyć plik dockerfile i stworzyć obraz. Potem ten obraz wysłać gdzieś tam dalej.

Ale mogę też ściągnąć z docker hub obraz o nazwie "python" i go uruchomić. No ale właśnie.. co dalej? Co mogę z nim zrobić? Czy mogę w nim "programować"? Mogę go sobie uruchomić jako taką "wirtualną maszynę" i normalnie w nim odpalać swoje skrypty? A jak skończę to zrobić "save" i wysłać obraz koledze? Jeśli tak to jak?

Nie takie jest założenie docera. Docker jest środowiskiem uruchomieniowym a nie deweloperskim. Robisz program budujesz obraz i nim się posługujesz. Jak robisz zmiany to budujesz nowy obraz / nowa wersje obrazu.

Być może umyka ci ważne rozróżnienie. Docker to nie tylko obrazy. Obraz to tylko taki przepis na system. Sam uruchomiony obraz jest już nazywany kontenerem.

Ogólnie kontenery to sposób izolacji. Na produkcji możesz mieć ileś kontenerów w chmurze, które będą się ze sobą nawzajem komunikować. Ale każdy kontener będzie odizolowany, programy w nim uruchomione będą myślały, że są na osobnych systemach.

Z drugiej strony możesz mieć tez jeden kontener na produkcji. Wtedy i tak masz zaletę taką, że możesz zdefiniować sobie wcześniej obraz, w którym zdefiniujesz całe środowisko uruchomieniowe (programy które maja być zainstalowane na serwerze itp ). Każdy programista tez będzie miał spójne środowisko i nie będzie musiał sam instalować np. baz danych u siebie.

normalnie w nim odpalać swoje skrypty? A jak skończę to zrobić "save" i wysłać obraz koledze?

Jak skończysz prace z kontenerem, to zwykle go usuwasz i tyle xD i to jest piękne. Nawet bawiąc się lokalnie możesz wykorzystać Dockera do tego, żeby odpalać jakieś programy bez instalacji ich na własnym systemie. Powiedzmy, że chcesz się nauczyc MongoDB. Zamiast instalować je u siebie, to po prostu ściągasz obraz z Mongo i odpalasz w kontenerze, a po zabawie usuwasz kontener. Chcesz się nauczyć kolejnej serwerowej technologii - robisz podobnie

Ja dorzucę przykład. Napisałeś serwis z jednym endpointem, który ma dostać 2 parametry i zwrócić wynik. Wysyłasz do mnie jakiś tam jav, py, czy w czym to napisałeś. Żeby to uruchomić, musze wiedzieć, że mam mieć na maszynie jakieś środowisko uruchomieniowe - java ileś tam, albo python w jakiejś konkretnej wersji, powinienem uruchomić program z jakimiś tam parametrami, bo inaczej nie będzie działać. Tę informację musisz mi jakoś dostarczyć, ja muszę zmarnować czas na jej przeczytanie, skonfigurowanie tego czego mi w systemie brakuje, na koniec walczyć z programami, bo u siebie miałeś jakąś zmienną systemową, o której nie napisałeś, a okazała się ważna...
Dla odmiany, pakujesz tę usługę w kontener. Razem z nią jakieś tam maszyny wirtualne, skrypt, który tę usługę uruchamia, ustawia parametry itd. Wszystko co muszę wiedzieć, to, że jest to kontener dockerowy, który udostępnia endpoint na porcie 8080 - koniec.
Wysyłam to do testerów - testują to w dokładnie tej konfiguracji, którą zaszyłeś w kontenerze.
Wrzucam na produkcję dokładnie to co zostało dostarczone i przetestowane...
Czyli znikają spore problemy:

1. Potrzeba dokumentacji wdrożeniowej
2. Potrzeba konfigurowania środowiska
3. Ryzyko, że python 2 pogryzie się z pythonem 3, itp...
4. Ryzyko, że to co zostało napisane, przetestowane i wdrożone, to 3 różne rzeczy

Czyli nie ma w sumie żadnego powodu by używać Dockera w programowaniu "dla siebie". Chyba, że pracujemy w środowisku komercyjnym z całym pipeline itd, testowaniem etc. Z tego co zrozumiałem, kontener to w zasadzie służy jako środowisko uruchomieniowe.. więc taki "read only". Taki PDF wśród wordów.

W takim razie jak mogę uruchomić własny skrypt (np. main.py zawierający print('hello')) na obrazie pythona z docker hub? Jak to się robi (jaki ciąg komend)?

@Ravender: zrób sobie przykład z dockera https://docs.docker.com/language/python/build-images/
przeczytaj tą stronę od góry do dołu i wykonuj polecenia, opisane masz wszystkie polecenia użyte i co one robią i jak uruchomić potem kontener.

Czyli nie ma w sumie żadnego powodu by używać Dockera w programowaniu "dla siebie".

No właśnie napisałem w poprzednim poście jeden przykład, w którym Docker może się przydać nawet do osobistego programowania/bawienia się - chcesz poznać jakieś technologie, to zamiast bawić się w ich instalacje i konfiguracje, możesz ściągnąć obraz, gdzie one są już zainstalowane. Możesz tez Ogolnie „śmiecić” sobie w takim kontenerze, a potem jak coś za bardzo nasmiecisz, to od nowa na czysto się bawić.

. Z tego co zrozumiałem, kontener to w zasadzie służy jako środowisko uruchomieniowe.. więc taki "read only".

Można podłączyć wolumen (volume), wtedy taki kontener będzie mógł zapisywać dane
https://docs.docker.com/storage/volumes/

W takim razie jak mogę uruchomić własny skrypt (np. main.py zawierający print('hello')) na obrazie pythona z docker hub? Jak to się robi (jaki ciąg komend)?

Możesz zrobić własny Dockerfile i zbudować własny obraz

Możesz też jak chcesz coś doraźnie uruchomić, to możesz uruchomić kontener z jakiegoś istniejącego obrazu, a potem docker exec
https://docs.docker.com/engine/reference/commandline/exec/

Zerknij na mój artykuł ;) https://lsdev.pl/posts/docker-w-praktyce/