Optymalizacja procesu wdrażania – trochę o Docker i Azure Pipelines
Budowanie i wdrażanie aplikacji to kluczowy etap w procesie tworzenia oprogramowania – często wykorzystujemy do tego Azure Pipelines i Docker. W jednym z naszych projektów udostępniona przez klienta maszyna okazała się do tego za słaba, co było przyczyną dalszych kłopotów. Powodowało to trudności przy budowaniu frontendu – w wielu przypadkach proces ten kończył się niepowodzeniem. Znaleźliśmy jednak efektywne rozwiązanie dzięki wykorzystaniu chmury – ciekawi szczegółów?
Dokładny opis problemu z Azure Pipeline
Agent zainstalowany na maszynie wirtualnej naszego klienta przetwarzał pipeline’y, których zadaniem było zbudowanie frontendu oraz backendu, a następnie wdrożenie całości. Z czasem, kiedy aplikacja się rozrosła, takie rozwiązanie przestało działać, ponieważ maszyna posiadała zbyt mało pamięci RAM, żeby zbudować frontend naszej aplikacji. Zdarzało się, że przy uruchamianiu pipeline system dochodził do pewnego etapu i wtedy pokazywał mu się błąd. Nasza diagnoza wykazała, że maszynie kończyła się pamięć podczas transformacji frontendu. Przez brak partycji swap po prostu przestawała działać zamiast zwolnić z budowaniem. Doraźnym rozwiązaniem, jakie wprowadziliśmy, było upscaleowanie maszyny przed releasem i downscaleowanie jej po zbudowaniu pierwszego środowiska. Tym sposobem Docker miał już zcacheowany nasz pierwszy build i nie musiał nic realnie budować. Nie miało jednak sensu długoterminowo i trzeba było opracować inne rozwiązanie.
Leczenie przyczyny zamiast objawów
Ciągłe upscaleowanie maszyny przed releasem i jej downscaleowanie było uciążliwe, więc pracowaliśmy nad znalezieniem innego wyjścia z tej sytuacji. Okazało się, że rozwiązaniem naszych problemów jest chmura, a dokładniej Microsoft-hosted agent. Zamiast instalowania agenta na maszynie wirtualnej klienta mogliśmy użyć tego udostępnianego przez Microsoft. Stworzyliśmy nowy pipeline i wystarczyło utworzyć w nim dwa joby o różnych poolach: pierwszy budował cały projekt, a następnie wrzucał go na container registry, podczas gdy drugi pobierał całość na naszą maszynę i robił release. Wydawało się, że jest genialna opcja: odpowiadająca na potrzebę i prosta w implementacji. Jednak kolejny problem napotkaliśmy już przy pierwszym faktycznym użyciu nowego pipeline’a. Jak łatwo się domyślić, losowo wybrana maszyna z chmury nie będzie miała dostępu do cache’a Dockera i oprócz tego sama z siebie będzie też wolniejsza.
Rozwiązanie problemu rozwiązania problemu
Nie trzeba było długo szukać, żeby dowiedzieć się, że ktoś już zmagał się z czymś podobnym. Pierwszy wynik z Googla po wpisaniu „azure build agent docker cache” już daje częściowe rozwiązanie. Możliwe jest pobranie ostatniego zbudowanego obrazu przed każdym kolejnym oraz użycie tego obrazu jako cache’a. Nie wydało się to skomplikowane, jednak w zderzeniu z rzeczywistością było tylko częściową odpowiedzią na problem. Na ten moment pipeline pobierał ostatni obraz, budował nowy, ale nie wykorzystywał starego obrazu jako cache’a. Pełnego rozwiązania nie znaleźliśmy ani w dokumentacji Dockera, ani Microsoftu odnośnie Azure Pipelines, ani na stacku. Opracowaliśmy, że do standardowej komendy budowania 'Docker@2 build' należało dodać jeszcze flagę 'BUILDKIT_INLINE_CACHE=1', która informuje Dockera, aby pozostawił w obrazie metadane z budowania. Natomiast do zmiennych środowiskowych Pipeline'a należało dodać flagę 'DOCKER_BUILDKIT: 1', która każe Dockerowi korzystać z nowego silnika budowania. Po tych poprawkach czas budowania udało się zredukować z 5 minut do jednej!
Podsumowanie
Wysiłek poświęcony na szukanie optymalnego rozwiązania bardzo się opłacił - dzięki rozwiązaniu problemu i zredukowaniu kilkukrotnie czasu potrzebnego na wykonanie operacji pozwolił na szybsze dostarczanie oraz zaoszczędzenie pieniędzy. Okazuje się, że opisany przez nas problem zauważył również sam Microsoft i obecnie implementuje usługi mogące na niego odpowiedzieć.
