W tym wpisie chciałbym opisać jeden z problemów, na który natrafiłem w pracy. Do wdrożenia było środowisko developerski składające się około 10 skonteneryzowanych elementów systemu: kilka aplikacji webowych, kolejka, agregator log’ów, itp. W skrócie nic wielkiego. Należało znaleźć najbardziej optymalne kosztowo/czasowo rozwiązanie do wdrożenia wyżej opisanego systemu. Poniżej przedstawiam kilka rozwiązań tego problemu.

1. Azure app service – najprostsze możliwe rozwiązanie. Już wcześniej można na nim było wdrażać kontenery, a od niedawna obsługuje też docker-compose. Jednakże ma znaczne ograniczenia w tej kwestii. Tylko jeden kontener może mieć otwarte porty na świat zewnętrzny (docker-compose) i otworzyć można jedynie porty 80 i 8080. Rozwiązanie wyeliminowane od razu z powodu tych ograniczeń.
2. Azure Container Instances – dedykowane pod kontenery, bez ograniczeń App Service, proste w konfiguracji. Jednakże ma jedną wadę – musielibyśmy wdrażać to jako jedna instancja usługi per kontener. W takim wypadku za każdą instancję trzeba by było ponieść koszty i już przy 10 kontenerach koszty przekraczają już 300 dolarów. Dla środowiska które nie byłoby mocno wykorzystywane jest to dosyć duża kwota.
3. Azure Kubernetes Service – tutaj problemem był akurat brak kompetencji. Chcieliśmy mieć coś prostego w postawieniu i utrzymaniu, a nikt w projekcie nie znał Kubernetes’a na tyle by móc podjąć się zadania. Ponadto nie chcieliśmy podejmować ryzyka zwłaszcza, że kolejne przedstawione rozwiązanie okazało się w pełni spełniać wymagania.
4. Wirtualna maszyna z docker-compose – finalnie zdecydowaliśmy się na to rozwiązanie. Tańsze w porównaniu do rozwiązania z ACR’em, brak ograniczeń innych usług – instalujemy i uruchamiamy co chcemy. Samo skonfigurowanie zwłaszcza przy skonteneryzowanym systemi okazało się bajecznie proste. Zainstaluj Docker’a, docker-compose, plik .env dla docker compose i jazda. A CI i CD? W Azure Devops w release pipeline’ach są taski pozwalające połączyć się po SSH do VM’ki. Kilka poleceń puszczonych przez SSH i kolejny problem z głowy. Ponadto rozwiązanie w przyszłości można łatwo zeskalować albo wertykalnie zwiększając zasoby maszyny wirtualnej, albo horyzontalnie poprzez przejście na Docker Swarm i dostawienie kilku kolejnych maszyn.

A jak ty byś potrzedł do takiego problemu? Zastosowałbyś może inne rozwiązanie.