The actual "wanna be final" description is in the bottom.
The purpose of this talk is to give an overview of the work we've done at our client. We're speaking about a real "corporate" environment where the process for delivery was really, really slow. Releases were scarce and something everyone was afraid of. Deployments were tied to a tedious process of setting up VMs that needed to be previously requested, provisioned and configured. So, 7 months ago, we started looking for alternatives that could ease the pain for everyone (developers, stakeholders, ops, etc.). We were familiar with containers and have been using it for a while, but rarely for production environments. We knew however that these were the way to go, as reproducibility was a key factor for the pipelines we wanted to put in place. During the same period of time, the organisation we were working in decided to migrate some of their projects living in a private github organisation to a private gitlab. This introduced us to the gitlab CI and after some trials we completely fell in love with it! For 2 months we investigated and built a PoC that had a clear goal to create a deployment pipeline using containers that was easy to use and replicate by any developer in the organisation. In the end we went with:
- Kubernetes for orchestration (Has become an industry standard with a great community backing it, a lot of resources and also... really fun to work with!)
- Helm for packaging applications (We get to abstract the whole k8s layer from the developers that just need to deploy a new web application for example. Through helm charts they just need to set the values that really matter to them!)
- External DNS (integrates with our cloud provider allowing us to dinamically set DNS records!)
- Traefik (acting as our ingress controller)
This setup, together with gitlab, allowed us to set solid deployment pipelines with support for stuff like dynamic environments per branch with DNS and TLS out of the box. All of this brought together in the gitlab UI, accessible to everyone working in the project. With the success of the PoC we were finally greenlighted and got our hands in a kubernetes cluster that we could work with and configure to our needs, according to what we've learned for the past couple of months. This is what we've been fortunate enough to have been working on until now \o/
- Who should I aim this at? Project stakeholder? Developers? DevOps?
- Super ultra duper afraid that, for an audience such as the one in container camp, this might come as something that "everyone is doing" and not really adding anything new to it.
- What should be the main focus of this story (this comes hand in hand with the next bullet)? Should I focus on the value that was brought to the project? Or should I focus on a "more technical" perspective of how well Gitlab and k8s go together?
- Worth giving a demo of k8s + gitlab?
Faster delivery cycle with Kubernetes and GitLab
Bringing new ideas and changing the ways of working inside big organisations can sometimes be a cumbersome endeavour. This is the story of a project where me and some of my colleagues at YLD have been working on for the past months where, through the usage of containers, Kubernetes and GitLab, we enabled a faster delivery cycle, better deployment and release pipelines and, in the end, the ability to react to business demands much faster. We'll walk through how we structured our deployment pipelines and how these integrate with our Kubernetes cluster. The multiple tools that allowed us to achieve this and finally, what worked out for us and what didn't.
Personally I think both developers / DevOps - you could take it in two directions, you could focus more on the pipeline, building the pipeline and how it works when deploying into kubernetes (this is something that I think a lot of kubernetes deployments are missing) or you can talk about building kubernetes with a pipeline and focus more on the technical kubernetes part.
I would say the latter would be a more interesting talk for myself, and from what I have heard of, people still haven't figured out a sane way to do this.
There will always be someone in the audience who will think that, however having been to container camp before (on many occasions) I feel that the talks around implementations, issues and things you think well go down the best. It provides some actionable content, which everyone can take on-board and use your teachings as a possible data-point for their next implementation. For that reason alone, I would say that this talk is something that I would like to watch. It is something I can relate to, and possible even consider it later on.
I would focus on the technical perspective as well as wins and fails you had.
Demos are scary as they can break! You could do, but only if you really need to. And if you do I would have a recording on hand to use if the demo breaks.