Wprowadzenie
W poprzedniej części tego cyklu przybliżyłem sposób pracy z kontenerami i gotowymi obrazami. Co jednak zrobić, gdy istniejące obrazy nie spełniają do końca naszych potrzeb?
Czy jesteśmy skazani na żmudną zmianę konfiguracji, instalacje pakietów za każdym razem, gdy korzystamy z takiego „prawie gotowego” obrazu? W poprzednim poście pokazałem polecenia docker commit jako możliwość zapisywania stanu obrazów. Na dłuższą metę nie jest to jednak rozwiązanie wygodne, jak np. śledzić zmiany, które zostały wprowadzone wraz z wykonaniem tego polecenia?
W tym wpisie pokażę sposób budowania obrazów od (prawie) podstaw, jak można je współdzielić w zespole / szerszej społeczności oraz jak można zautomatyzować ten proces przez integrację z serwisem Github.
