Dynamiczne zarządzanie plikiem Dockerfile dla różnych najemców w implementacji potoku CI / CD

13

Próbuję zaimplementować potok CI / CD dla mojego projektu za pomocą Docker, Kubernetes i Jenkins. Moja aplikacja to aplikacja dla wielu dzierżawców, w której zmienne aplikacji bazy danych są różne dla różnych dzierżawców.

Strategia aplikacji

Kiedy buduję obraz dokera, korzystam z Dockerfile. I trzymam mój plik Docker w repozytorium kodu SVN. Dla każdego najemcy repozytorium kodu jest takie samo. Kiedy buduję obraz, muszę budować różne obrazy dla różnych najemców.

Implementacja Dockerfile

W moim pliku dokera dodaję punkt wejścia w następujący sposób,

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=tenant1config" , "TestProject.war"]

Jeśli muszę zbudować obraz Dockera dla innego najemcy, muszę go dodać
-Dspring.profiles.active=tenant2config

Zatem punkt wejścia w Dockerfile jest dynamiczny.

Moje zamieszanie

  1. Do zarządzania poleceniem punktu wejścia w Dockerfile jest możliwe dynamicznie?
  2. Czy też muszę dodać kolejny plik Docker dla innego najemcy? I potrzebujesz osobno uruchomić polecenie kompilacji dokera dla osobnego najemcy?

Jak znaleźć dobry standardowy sposób realizacji tego problemu?

docker dockerfile Jakub
źródło
3
Możesz użyć zmiennej środowiskowej w swoim, ENTRYPOINTtj. ... -Dspring.profiles.active=${TENANT}Następnie ustawić poprawne środowisko podczas wdrażania.
masseyb

Odpowiedzi:

13

Cytowanie z 12 Factor - Config

Konfiguracja aplikacji to wszystko, co może się różnić w zależności od wdrożeń (środowisko przejściowe, produkcyjne, środowiska programistyczne itp.). To zawiera:

  • Uchwyty zasobów do bazy danych, Memcached i innych usług tworzenia kopii zapasowych

  • Poświadczenia do usług zewnętrznych, takich jak Amazon S3 lub Twitter

  • Wartości dla wdrożenia, takie jak kanoniczna nazwa hosta dla wdrożenia

Należy nie budować oddzielne obrazy Döcker dla każdego lokatora jako binarna powinna być taka sama, a wszelkie konfiguracje środowiska wykonawczego powinien być wstrzykiwany przez środowisko.

Istnieją różne opcje wstrzykiwania konfiguracji środowiska wykonawczego

  1. Zmienne środowiska

Zamiast zakodować profil w punkcie wejścia dodaj zmienną środowiskową

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=$TENANT_PROFILE" , "TestProject.war"]

Następnie wstrzyknij zmienną środowiskową z konfiguracji wdrażania kubernetes. Patrz https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

  1. Zamontuj konfigurację profilu jako config i odnieś ją

Twój punkt wejścia będzie wyglądał

ENTRYPOINT ["java", "-jar", --spring.config.location="file:/path/to/tenantconfig.yaml" , "TestProject.war"] Następnie zamontuj wymagany plik konfiguracyjny jako konfigurację kubernetes.

W obu przypadkach należy zewnętrznie skonfigurować konfigurację środowiska wykonawczego z obrazu dokera i wstrzyknąć ją przez konfigurację wdrażania jako zmienną środowiskową lub konfigurację.

Mohit Mutha
źródło
1
SPRING_PROFILES_ACTIVE jako zmienna środowiskowa powinna działać od razu po wyjęciu z pudełka. Dodatkowy parametr java nie jest potrzebny.
Manuel Polacek,
3

Możesz skorzystać z ARGS dokera, będzie on dostępny tylko w czasie kompilacji i może być użyty w punkcie wejścia.

docker build --build-arg CONFIG_FILE=<file_name> -t tag_name .

CONFIG_FILE przechowuje lokalizację pliku konfiguracyjnego i możesz przekazać go dynamicznie. Zamień punkt wejścia na$CONFIG_FILE

ENTRYPOINT ["java", "-jar", "-Dspring.profiles.active=$CONFIG_FILE" , "TestProject.war"]
Sivakumar
źródło
ARG CONFIG_FILE - należy zadeklarować wewnątrz Dockerfile
Roman M
0

Patrz - Najlepsze praktyki Dockerfile

ENTRYPOINT pomaga skonfigurować kontener do działania jako plik wykonywalny, który może przyjmować argumenty w czasie wykonywania

Dowolną właściwość dynamiczną, którą chcesz zastąpić, można wykonać w czasie wykonywania z tym samym obrazem.

Możesz przekazać niezbędny argument w czasie wykonywania.

Satish Kumar Nadarajan
źródło