 Cool Thank you very much for coming. We're a little bit behind schedule. So I'd like to get started as soon as possible Our next speaker Jeff. I have known Jeff for a very long time and the first day we met we Had a walk in Alaska Jeff was on flip-flops, and I'm very happy that he's here now So Please go ahead Thank you Walter The audio good it can I think so so I'd like to go back about two years ago not as far back as I've known Walter but At the point at travel audience where I work now We were in a process where many of you have probably been or will be at some point soon We were migrating into Kubernetes and so we of course started with the process of putting everything in Docker Containers and then for the Kubernetes infrastructure. We were managing it with helm So all the ammo configuration of an application was put into an a helm chart So at the time we had maybe about ten services that we started with and we created an umbrella helm chart to manage all Those help the ten services we had so this umbrella chart had the configuration to deploy each of those ten things into our production environment and so the the benefits here is that we could take this Umbrella chart deployed into production deployed into a staging environment, or if the developer wanted to work on something They could deploy the same thing that we had which is some small configuration changes and everything was deployed nicely However, this didn't work so well the the umbrella chart is broken It doesn't scale as we add more services to it it becomes a big entity that helm itself has trouble managing and The other problems were that's the individual release cycle of an application Being able to just say hey, I want to roll this out then dependent on rolling out this bigger umbrella chart And so we had some reasons for taking away the umbrella chart and then having a nice CI CD process That took an application directly into production and that was fantastic for production environments But we lost the reproducibility of our umbrella chart We couldn't just take all those 10 now 20 30 services and create a dev environment with them Because we needed to know which of those 10 30 am I missing something is there's something new that's come That's critical for my environment and how do I set it up in my dev environment? So I began looking out in the community trying to find some tooling that provided such a solution and I found some blog posts of other companies who had the same problem. They described exactly what I wanted They wrote a tool for it gave the tool a really fun name and failed to open source it There was actually nothing available for me to work with to be able to do this But everybody else had this problem. So of course We're sitting there with these empty shelves wondering what to do and a travel audience Thankfully the management agreed. Hey, we do need something to provide this functionality to our developers and They also agreed with the concept of let's put it back out in the community. Let's share this with everyone else And so before I get into how to create your dev environment The question is where so at travel audience we run everything in the cloud We use Google Cloud and so we have a dedicated project in Google Cloud where Developers now have greater access. They can deploy things and do what they want that they wouldn't be able to access and do In our production environment. So for us, we're able to have one cluster with many namespaces for each developer This might not be a Solution based on costs, whatever and so your next best option is to run these dev environments locally now two years ago Running a Kubernetes locally probably meant Kubernetes the hard way You had to learn what Kubernetes is how to manage all the moving pieces of Kubernetes itself Just so you could run your application like that was not sustainable Mini Cube was around then but it's come a long way to make it more usable. It's much faster. It provides Docker image support now I believe it's been released and This is usually my tool when I'm doing something locally. However, there's some other great tools out there If you're on Mac or Windows then Docker for desktop is an alternative to Mini Cube for running Kubernetes on your machine Micro KS is a tool. That's really good if you're running Linux But also supports Windows and Mac OS and basically these are the equivalent alternatives of Mini Cube where you just have the full Kubernetes infrastructure running on your machine and you're able to play around and do things as you need There's some interesting tooling out there for Running Kubernetes in Docker. So basically you have Docker running on your machine Then you put a container of Kubernetes running which in theory you could have another Docker image of Kubernetes and then another Docker running Kubernetes and You're in this inception model. You have to spin the top to find out if you're on a real machine or not But these ones I haven't used them on my local machine for running Kubernetes I know that can be done. What's really cool about these is they run great in CI So if you have to spin up Kubernetes to run a test on some application you're doing these are your great Solution for pretty much any CI tool out there will allow you to run Docker Which therefore will allow you to have Kubernetes to do your testing So now we have our place to run our dev environments and I want to get into this some of the tools that are available I'm of course definitely biased having been the main developer of Armador There's some other tools I'm going to get into so now this part of the talk will be much more tool focused and How these things will work for you? Armador itself is based on the concept of Docker compose, but it works for Kubernetes And so Docker compose comes with this Example app which is very over architected for what it does, but it creates something better than just a hello world so we have this voting app that is a front-end users can go in and Vote for something that saves to a redis database. You have a worker process running in the background That's converted into Postgres data and then another front-end where you can see the results of the votes So very over architected, but it provides What we would have of this Docker compose configuration on the right-hand side or left there and If you extract this out a bit more you would imagine in your company the voting app isn't just you know One developer working on this but a whole team of people and this whole team of people Doesn't need to know that there's a postgres database that the worker converts You know what they save in a redis to postgres and that the port for the result app is five eight five eight like Why do I as a voting app developer need to know all this in order to run my application to see if it's working? so what armador does is It's based on helm and so each of these applications is a helm chart of its own and the voting app is Included with an armador file that indicates the dependencies it needs So as a voting app developer, I need a redis because I know I save my data to redis and I need a result app so I can see what's happening in the end and When armador starts running it'll spin up or it'll find these dependency charts in your voting app look for Those dependencies find the result app that you know another team has worked on and created and they said Hey when you run the result app you need a postgres and a worker that converts it and so everything you get need gets compiled into built out into a graph and deployed into your environment, so Armador takes your helm configuration of your voting app and then fills out all the rest of the configuration of the ops you have and It leaves out all the other stuff So if you have 30 other services running in your production environment that do additional things of how likely will somebody vote for this and all this Yeah, that's not what you need to test the voting app itself. You just need this components so Armador isn't the only tool that does this and it was actually interesting as I started the development of armador I Found that one of the tools that somebody had blogged about and described exactly what I want Came out as ASIL and was released an open source. I already started You know what do I do here, but the functionality for as so this Generally the same it builds out the dependency graph of what you need So it doesn't include all this extra stuff and that was one of my key reasons for building something and Then it Functions on git Webhooks so as you create a new PR ASIL will trigger a call to the ASIL server which will then spin up an environment based on what's in that PR And then as you update the PR the environment gets updated And then when you merge the PR and close it the environment gets club deleted so if your use case follows into this Presentation mode of what's happening in a PR and then ASIL is a great solution what armador has slightly Benefits over is that it's a CLI tool and so you don't need the additional hardware to run armador You just run it locally and it spins up the environment with what you need And then you're able to hack it and get in and do whatever you want And you're responsible then to make sure it's still working that it updates as you need so depending on your use case these two tools are Potentially the better of the rest now. That's my opinion and If it wasn't for this concept of having a huge Dependency chain of not needing everything we have in production in my environment Then I would find tilt to be really fascinating because it not only provides a great UI both in the CLI As well as a web interface It ties into your IDE so as you develop the changes will get updated into your environment And you get an aggregate of all the logs of all the things that are running in your environment when something isn't working it shows up in a nice UI interface and The other advantage of tilt is that it doesn't depend on helm the ASIL and armador are helm dependent Whereas tilt will function with just pure yaml configurations But what you do need is to know everything that's happening So you do need that full docker compose that describes the whole environment So as your dependencies grow bigger and more complex it becomes a little harder to manage Exactly what you need in your dev environment A popular tool out there that has been around for much longer and was there So before anything started was helm file and this has the the concept of what the umbrella chart had Where everything is there and all managed by helm and deployed as kind of one instance But it does deploy it individually, so you you don't have that bulkiness that's restriction to it But the the disadvantage of using helm file for your dev environment is if you're doing it across multiple namespaces Each time you make a new environment you have to then make new changes to your configuration So you can't just say here developer here's a home file You can deploy it if somebody else has already deployed that same thing So it's the fantastic tool for managing a production environment and your configuration and knowing what's there But having that dev environment usage might not be the best use case a tool that came out of a company in Berlin where travel audiences also located is from garden and they actually started a while ago, but didn't come out with public, you know usage until after all this started a year ago and What they have is similar where they'll build out a dependency graph of everything you need But the configuration seems to need to be kind of contained in the one general location And so I haven't actually tried using it But the the fantastic thing with them is that the company behind it is willing to put in the effort and work with You to get it up and running so if you're low on resources internally and want to be able to have dev environments then Contact them and get the support you need while they're at least doing it for free. So If you're dealing with a much less Much less components there your dependency chain isn't so large You just have one or two applications that depend on you know I need a database with my front-end like that's kind of the scope of your Existence with your development environment then the scaffold is a great tool it ties directly into IDs with VS code and telege and It provides a direct environment for the developer Handles all the files syncing directly and in a faster iteration process But where it lacks is the bigger dependency chain so again use case-dependent this might be a good solution and Lastly at least alphabetically is Valero, which was originally developed by Heptio and called arc Which then would have been first alphabetically I think but its concept is that it creates a backup of your cluster and there was actually just to talk a few minutes ago about Valero and So I can't really do what was probably there's talk about it in the same way But it what you can do is when you have this snapshot of your cluster You can then just deploy that into another cluster right and then in another cluster in another cluster And so then you have your ephemeral environment that you can just tear down and create because you have a backup of it The what I don't see working I don't know maybe it was described how you can manage this but in your production You probably have hundreds of pods thousands of replicas big Persistent volumes, you know Things that when you take that snapshot and put it on your local machine your local machine It's not going to be able to handle the scope of that so the the dev environment for Valero might not be the The place for using it, but it is a good tool that has benefits So this wouldn't be a good tech talk if I didn't try a live demo and I'm gonna have a go at Doing a demo of Armador, so we have the armador repo And in this armador repo, there's a docs folder with the example and Basically everything in here is as I described already How it functions. There's also a blog post about what's happening and the reason for armador and then at the end there's really just simple one line to get it up and running this example app and What's happening inside is? Actually, I already cloned the code So and we have our example apps and so there's the result in the vote app Because these needed to be included because these are our internal company apps Where is the Postgres and the the Redis? Those are you know external? upstream helm charts and the worker chart as well The folks that's code fresh I believe already packaged this example app into helm charts And so we just took the the examples that they gave and we can pull down their worker chart because we're not making any changes of that so if I Locally go into my I'm gonna copy the voting app and So this is in theory my whole functionality of the voting app would be in here including my helm Configuration including my YAML file which lists the dependencies from the upstream stable repo and the result app Which is a local repo? within you know our company and has a specific path to the configuration and I just run armador create Jeff I'm assuming I have mini cube up and running already Yeah, save some time there and here we can see that these five charts are going to be installed so this is the components that we need and There they should all be running to go to all get pods the Redis and the database are on their way to be running and The way mini cube works for Being able to access your ports is by having a cube service Oops, I was gonna try to show the help here So it creates URLs that are dedicated to the applications that are running in your cluster. And so kubectl get this so I want to be able to connect to the voting app and cast my vote and This cluster IP is only located within the mini cube but if we For it out stat traffic it loads it up and now I can vote for dogs because I like dogs Still got a Play from current slides So now we have a full set of tools available in the community. I kind of just gave you a tool dump I can say what's best for you is of course armador but Again, you know find your use case find out what's available What's most likely the case is now that there's all these tools you probably don't need to go through the trouble of rewriting your own you can instead work on what's available and I have a talk tomorrow where I'm going to discuss What you can do now that you have your ephemeral environment now that you have this dev environment how do you debug and how do you actually use it to the best you can and I just want to give a shout out to the helm contributors the maintainers are going to be given a talk at the Config management camp Thank you