2017-04-09 6 views
6

Meine Firma betreibt seit über einem Jahr Kuberenetes und seit ca. 6 Monaten GitLab. Wir haben kürzlich ein Upgrade auf GitLab 9.x durchgeführt und haben Probleme, herauszufinden, was mit der Entscheidung über die Konfiguration der CI + -App mit Kube zu tun hat. Diese Funktion ist großartig und würde es gerne in unserer Umgebung funktionieren lassen.GitLab 9.x Kubernetes Integration

Es scheint, als erwarte GitLab, dass Sie nur ein Cluster-Setup mit all Ihren Umgebungen innerhalb des einen Clusters haben, aufgeteilt nach Namespace, was Ihrem Service/Ihrer Anwendung und Ihrer Umgebung entspricht. Dies ist, was es sieht aus wie Gitlab meine will Kuberenetes Umgebung aussehen, einen einzelnen Cluster mit Ihrem Service in Namensräume aufgeteilt:

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

wo in einer realen Welt Beispiel würde es vorziehen, wir das Gegenteil haben, die gut funktionieren würde als auch mit einem einzigen Cluster

DEVELOPMENT CLUSTER 
namespace = development 
app = hello-world 

QA CLUSTER 
namespace = qa 
app = hello-world 

PRODUCTION CLUSTER 
namespace = production 
app = hello-world 

mit dem Namensraum die Anwendung sein und die Anwendungen die Umwelt sein, würden wir die Möglichkeit haben, nicht auf die neueste Version von kube zu aktualisieren, ohne alle zu aktualisieren. Vielleicht verpasse ich etwas, aber basierend auf dem, was ich lese, und nachdem ich das getestet habe, sieht es so aus, als ob es so entworfen wurde.

Als Referenz ist das, was mein CI wie jetzt sieht das deploy Board + -Anschluss glücklich

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

aber es sollte sie auf diese Verwirrung wie diese

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

hinzuzufügen aussehen zu lassen, Geben Sie nur einen Kubernetes-Master an, mit dem Sie sich in der Registerkarte Integrationen verbinden möchten.

Ist das korrekt, oder fehlt mir etwas?

+0

Hey, da Sie einer der wenigen sind die ich finden kann, die Arbeitsplatten einsetzen bekam, könnten Sie ein bisschen auf erweitern, was so aussieht? Welche Umgebung benötigt jede Stufe? Im Moment laufen 'review/*' environments und 'prod', aber in Ihrem Beispiel sieht es so aus, als könnten Sie nur in einer Umgebung mit' ' –

+0

@ north.mister das korrekt ist. Sobald Sie alles mit der Kubernetes-Integration eingerichtet haben, müssen Sie Ihre Ci wie oben beschrieben konfigurieren. Der einzige Weg, um es zum Laufen zu bringen, besteht darin, dass der Name der Umgebung in meiner Datei gitlab-ci mit dem Namen der App in der Vorlage deployment kubernetes übereinstimmt. Siehe auch ref https://kubernetes.io/docs/concepts/workloads/ Controller/Bereitstellung /. Dies wird wahrscheinlich für Sie funktionieren, da Sie nur eine einzige kubernetes-Umgebung haben, aber wir haben einen Cluster pro Umgebung, so dass es für mich fehlgeschlagen ist. Hoffentlich hilft dir das weiter. –

Antwort

5

Sie haben Recht. Ich fand es auch frustrierend.

Aber können Sie Umgebungen auch ohne ihre Kubernetes Integration development: <<: *deploy_definition stage: development environment: name: development url: https://development.yourdomain.com script: deploy.sh -a "hello-world"

Schauen Sie sich den Beitrag habe ich vor kurzem über die Konfiguration von Auto zu Kubernetes von Gitlab bereitstellen schrieb.

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

+0

Unterstützt diese Methode die Bereitstellung von Boards? Das ist das einzige Ziel, das ich hier habe. –

Verwandte Themen