Wersje obrazów Docker do ciągłej integracji/Ciągłego wdrażania

Question

Wdrażamy proces ciągłej integracji i ciągłej dostawy przy użyciu dwóch dobrze znanych koncepcji: pakietów binarnych Linux i obrazów Docker.

Najbardziej część prac została już wykonana: bierzemy kod z GitLab repo, skompilować je i włożyć do deb pakietów przechowywanych w Aptly, następnie tworzymy Docker obrazów dla każdej usługi mamy i przesunąć obrazy w prywatny serwer Docker Registry. Następnie obrazy te są przenoszone do środowiska testowego. Wreszcie rozpoczynamy usługi i przeprowadzamy testy akceptacyjne. Jest to proces ciągły i rozpoczyna się za każdym razem, gdy ktoś przesyła zatwierdzenia do origin/master.

Co nie jest jeszcze jasne, jak odróżnić stabilnych obrazów zapisane w Docker rejestru?

Musimy śledzić stan każdego obrazu, ponieważ musimy wykonywać okresowe aktualizacje stabilnego serwera. Oczywiście niektóre wydania (tj. Wersje obrazów) nie przejdą testów akceptacyjnych i muszą zostać oznaczone jako nieużyteczne i odfiltrowane przy każdej kolejnej iteracji Ciągłej dostawy.

Wydaje się, że nie ma Domyślna implementacja tej funkcji:

1. Domyślny obraz repo/tag jest trywialne zwykły ciąg znaków, który nie może posiadać zarówno numer wersji, daty i budować QA śladów.
2. Labels (wprowadzone w 1.6) może być dobrym punktem wyjścia do obejścia tego problemu, ale nie byliśmy w stanie znaleźć okazji do zastąpienia istniejących obrazów (należy pamiętać, że musimy zaktualizować "metadane" obrazu, biorąc pod uwagę wyniki QA). Nie ma użytecznej metody sprawdzania obrazu według wartości etykiety, ale prawdopodobnie możemy zawinąć interfejs API Docker.

Jaki jest właściwy sposób przypisywania wersji do obrazów Docker? W jaki sposób można przechowywać informacje związane z kontrolą jakości? W jaki sposób możemy "podkreślić" stabilne konstrukcje obrazu? Jakie funkcje Jenkins CI mogą zostać użyte do osiągnięcia tych celów? Podziel się wrażeniami.

UPD: po chwili musiałem uruchomić discussion w narzędziu do śledzenia problemów Docker. Prawdopodobnie ktoś też uzna to za przydatne.

Answer 1

Wygląda na to, że na twoje pytanie już udzielono odpowiedzi w tym linku do dyskusji, ale chciałbym tylko zauważyć, że w Raporcie Wybielacza nigdy nie przekazywaliśmy obrazów do centrum dokowania (prywatnego lub hostowanego), które nie przekazało najpierw CI.

• Kod pchnął
• CircleCI tworzy oznaczony build
• testy wykonywane wewnątrz oznakowanego pojemnika
• Jeśli testy przeszły CircleCI popycha oznaczone pojemnik do koncentratora

Detailed explanation