2017-04-09 48 views
6

Moja firma już od ponad roku prowadzi Kuberenetes, a GitLab około 6 miesięcy. Niedawno uaktualniliśmy do GitLab 9.x i mamy problem z ustaleniem, co dzieje się z decyzją dotyczącą konfiguracji aplikacji CI + z Kube. Ta funkcja jest niesamowita i chciałaby, aby działała w naszym środowisku.GitLab 9.x Integracja Kubernetes

Wygląda na to, że GitLab oczekuje, że będziesz mieć tylko jedną konfigurację klastra ze wszystkimi środowiskami wewnątrz tego jednego klastra podzielonymi przez przestrzeń nazw, która byłaby równa twojej usłudze/aplikacji i aplikacji, która byłaby podobna do twojego środowiska. To, co wygląda GitLab chce mojego środowiska Kuberenetes wyglądać, pojedynczy klaster z usługą rozbite pod nazw:

namespace = hello-world 
app = development 
app = qa 
app = production 

gdzie w prawdziwym przykład światowej wolelibyśmy mieć odwrotny, które działają dobrze z pojedynczego klastra oraz

DEVELOPMENT CLUSTER 
namespace = development 
app = hello-world 

QA CLUSTER 
namespace = qa 
app = hello-world 

PRODUCTION CLUSTER 
namespace = production 
app = hello-world 

Mając nazw mieć zastosowanie i aplikacje za środowisko, nie mielibyśmy możliwość aktualizacji do najnowszej wersji Kube bez uaktualniania wszystkich. Może brakuje mi czegoś, ale na podstawie tego, co czytam i po przetestowaniu tego, wygląda na to, że tak zaprojektowano.

Dla porównania jest to, co mój CI wygląda teraz zrobić płytę wdrożyć + zacisk szczęśliwy

development: 
    <<: *deploy_definition 
    stage: development 
    environment: hello-world 
    script: 
     deploy.sh -a "hello-world" 

ale powinno to wyglądać tak

development: 
    <<: *deploy_definition 
    stage: development 
    environment: development 
    script: 
     deploy.sh -a "hello-world" 

Aby dodać do tego zamieszania, oni da ci tylko jednego mastera Kubsengetes do połączenia się w zakładce integracji.

Czy to się zgadza, czy też czegoś brakuje?

+0

Hej, ponieważ jesteś jednym z niewielu, którzy mogą znaleźć drogę rozmieścić tablice pracy, można poszerzyć nieco na co to wygląda? W szczególności, jakie środowisko potrzebuje każdy etap? W tej chwili używamy środowisk 'review/*' i 'prod', ale w twoim przykładzie wygląda na to, że możesz wdrożyć tylko w środowisku z' ' –

+0

@ north.mister. Po skonfigurowaniu wszystkiego z integracją z kernernetes, musisz skonfigurować swoje ci tak jak powyżej. Jedynym sposobem, w jaki mogę go uruchomić, jest to, że nazwa środowiska w moim pliku gitlab-ci jest taka sama jak nazwa aplikacji w szablonie wdrażania kubernetes, dla ref https://kubernetes.io/docs/concepts/workloads/ kontrolery/wdrożenie /. Prawdopodobnie zadziała to dla ciebie, ponieważ masz tylko jedno środowisko kubernetes, ale mamy klaster w środowisku, więc dla mnie się nie powiodło. Mam nadzieję, że to ci pomoże. –

Odpowiedz

5

Masz rację. Znalazłem to również frustrujące.

Ale można użyć środowiska nawet bez ich integracji kubernetes development: <<: *deploy_definition stage: development environment: name: development url: https://development.yourdomain.com script: deploy.sh -a "hello-world"

Sprawdź posta pisałem niedawno o konfiguracji auto wdrożyć do kubernetes z gitlab.

http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/

+0

Czy ta metoda obsługuje wdrażanie desek? To jedyny cel, jaki mam tutaj. –