7

My company has been running Kuberenetes for over a year now and GitLab for about 6 months. We recently upgrade to GitLab 9.x and are having trouble trying to figure out what's up with the decision around the CI + app configuration with Kube. This feature is awesome and would love to get it working in our environment.

It seems as though GitLab is expecting you to only have one cluster setup with all of your environments inside of that one cluster broken up by namespace which would equal your service/application and app which would equal your environment. This is what it looks like GitLab wants my Kuberenetes environment to look like, a single cluster with your service broken up into namespaces:

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

where in a real world example we would prefer to have the opposite which would work well with a single cluster as well

DEVELOPMENT CLUSTER namespace = development app = hello-world QA CLUSTER namespace = qa app = hello-world PRODUCTION CLUSTER namespace = production app = hello-world

Having the namespace be the application and the apps be the environment, we wouldn't have the ability to upgrade to the latest version of kube without upgrading all. Maybe I'm missing something but based on what I'm reading and after testing this out, it looks as though this was the way it was designed.

For reference this is what my CI looks like right now to make the deploy board + terminal happy

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

but it should look like this

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

To add to this confusion, they give you only one Kubernetes master to connect to in the integrations tab.

Is this correct, or am I missing something?

Improve this question
2
  • Hey, since you're one of the few I can find who got deploy boards working, could you expand a bit on what this looks like? Specifically, what environment does each stage need? Right now we're running review/* environments and prod but in your example it looks like you can only deploy to an environment with <project-name> Commented Oct 13, 2017 at 20:07
  • @north.mister that's correct. Once you've setup everything with the kubernetes integration, then you need to configure your ci like I did above. The only way I could get it to work is by having the environment name in my gitlab-ci file be the same as the app name in the deployment kubernetes template, for ref kubernetes.io/docs/concepts/workloads/controllers/deployment. This will probably work for you since you only have a single kubernetes environment but we have a cluster per environment, so it failed for me. Hopefully this helps you out. Commented Oct 13, 2017 at 22:17

1 Answer 1

Reset to default
5

You're correct. I found it frustrating too.

But you can use environments even without their kubernetes integration 

development: <<: *deploy_definition stage: development environment: name: development url: https://development.yourdomain.com script: deploy.sh -a "hello-world"

Check out the post I wrote recently about the configuration of auto deploy to kubernetes from gitlab.

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

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Does this method support deploy boards? That's the only goal I have here.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.