 So let's start Okay Yeah, we're gonna talk about bug give an introduction to it. It's a tool that we created Together bug stands for it's an acronym stands for Borsch UA a credit and concourse And we created a utility which also called bug with lowercase Yeah, I'm Ruben and this is Roman and we work for Stark and Wayne You know from the awesome shirts that we don't have at the moment For the people that don't know Stark and Wayne we do consultancy around Cloud Foundry and Bosch Yeah, so buck it's open source just you can get it from Get up, but we this talk will be more about like the things Underneath bug or yet that helps us build bug we have another session Later today where we go into really show off the buck utility. This is more about Bosch UA a credit bank concourse and the new things in that how they really fit together really well So why did we create bug? Yeah, it was We saw the new developments with CF deployment the CF deployment repo and got really excited about wanting to use that in a production manner like have Using Bosch config server for potential management and all those things But it still felt getting an environment for that up-and-running Was a bit troublesome. I really liked Bosch lights for development purposes, so I wanted to have some of the user experience of Bosch lights and I brought that to Yeah, the Bosch create and for Yes, so when you first go to the Bosch deployment repo you think what the hell do I need to do here? So we figured out we need to build something around that really small thing So that we can just we invoke the Bosch deployment and you can just do buck up and there should be something there The same thing you do. Yeah, we did with Bosch light. Yeah, I think we can go to the next slide Yeah, so we have some fuel ingredients for it So what were the things that allowed us to create bug so the first yeah, we have this There's this new Paradigm of creating deployment repos Dash deployment repos for example, you have the cloud foundry deploy CF deployment repo You have the Bosch deployment repos, but there are more deployment repos for Yeah, more and more Bosch releases coming up. So you have like the Bosch release, but you also have the Deployment repo and the deployment repo is it's for where release maintainers can publish manifests and not like manifest that just work in one environment, but manifest that are built for shareability, right? So you have a base manifest and that base manifest you can enable features or and Yeah, enable some features for that manifest and that's done with ops files. That's something That we now have because of the new Bosch CLI that brought us ops files So those are used in those deployment repos another thing is the new Bosch CLI has support for variables So things that are and there's no same default for something for example a domain for your cloud foundry deployment That will be a variable other things like secrets and stuff Those will be generated by the CLI and stored in a vars store more on that later Yeah, so they are really built for share a bit with shareability in mind that the Bosch deployments repo is now actually referenced a lot in the Bosch docs So it's like the standard way to do things the recommended way to do things There's even a style guide in CF deployment about how to how those deployment repos should be laid out and what are best practices around them and Yeah, I don't know if this already happens, but like CF deployment will be replacing the CF release, right? so CF release is big release where all sorts of Bosch releases are Mesh together into one big release and with the deployment CF deployment It's going to like one big manifest which references all those separate releases. So you have and those sort of the Compatibility matrix basically is owned by CF deployment instead of CF release or at least that's moving I don't know if it's already happens. That's the idea. That's basically the idea So yeah, the nice thing about the new Bosch is that we have this we have this whole notion of Bosch compiled releases We used to have these the Bosch compiled package cache where we already been redirected to one big package cache Which will basically see from okay, which release do I have which stem cell do I which stem cell do I need For it. So now we have the Bosch compiled releases and the nice thing about this is What we would we also do we will show you in a minute is that we would buck we say that we want to deploy it almost try to install Bosch almost offline because most of the time we have crappy internet and we we want to have the ability to just deploy Bosch and So yeah one of the main reasons for this for or why this is relevant to buck is because One of the goals is we wanted to have a Bosch light experience like the with Bosch light for those if you don't know that was like a Vagrant based machine where you could really easily have your Bosch running and so For a speed was important, right? Because in development scenarios, you will be often tearing down your environment and building it back up. So compiled releases basically With compiled releases you skip the whole compilation step during deployment So that was was one of the reasons why it was important for us to use compiled releases Yeah, I think it Takes about 20 minutes takes off 20 minutes of our deployment. Yeah So, yeah, for those of secrets. I don't know if anyone here is no credit up So what we yeah, there's a conceding It's really small Yeah So yeah, what what we invoke with buck is that because first you need to your credentials for deploying Bosch and you need you need to generate something and We don't want to do that. We want someone else need to handle that and we do this with Bosch in So Bosch in then we have a variable name food type password and it will be stores in Kred so Jamal This is the same time This is the same thing what we do with buck because buck up will just do a bush in it and it will set a set of passwords that you need like for the the directory password at the UI UI user name and passwords and that kind of stuff and So as you can see is just been put in Kred so Jamal and if you do if you use buck up There will be a Kred so Jamal created and that's where all the fire variables will be Secrets all the secrets will be So this is the Bosch config sir. This is how we When we wanted to use it with Which is in a concourse pipeline So this is no, this is not the code pipeline. I'm getting ahead of myself. So this is for a deployment for if you can see here dot the docker swarm and All that this is the docker TLS CA the docker TLS certificate the private key. It's all generated by Kred up Because Kred up is the config server in Bosch. Yeah, so okay So what's important to note here is the variables, right? So that's in a Bosch deployment manifest You can specify variables and that's basically where you say that those will be generated variables And they're like two ways those variables can be Generated like if you have your full director up and running then it will be done by config server, right? Config and config server. There are multiple config server implementations. One of them is Kred up Which is becoming the factor standard But yeah config servers are pluggable, but they should be able to take those things and generate the secret and store it It's for the director to get it back later. But the problem is when you are creating your initial director You don't have your credit up yet or your thing. So that's why the same functionality exists in the CLI that was like this is what like the Bosch CLI has its own credit Implementation basically and this is just showing that you can generate passwords with the Bosch CLI But in the end, it's just Using those variables in the manifest and they will be either stored in a In a credits file or they will be stored in credit Yeah Yeah, okay, no you go Okay Yeah, so the manifest we saw previously that was like the thing for Docker So we are actually deploying this Docker deployment here You see that it finishes and then we have we can use the voice CLI to list the variables that were generated You see the parts here Hey, wait Yeah, it works Yeah, so This is the Bosch director name. This is the Deployment name and this is the variable name. So that's just how they will be. I don't know That's the how the part is generated and we can then use the credit up CLI to actually Get one of those secrets back. So this is what happens when you're using credit instead of the Bosch far store flag okay, and Now it's got more exciting because really recently we haven't even published this version of bug yet, but concourse has now support for They added credential manager support initially for vaults But they now also have support for credit up Which means that we can now connect? the concourse Which we deploy with buck to Okay Yeah, connect it as well. So you see that the variable syntax is really similar So the use case we have is you set up your pipeline and from the pipeline you want to start deploying stuff Right, but you need connect a connection to a director Which how do you get those credentials? Yeah, you use variables So you can do this and when you run it You get this It expects to find those variables And Yeah, so we have this this inception problem, right? We we create this VM with Bosch UAA credit up and concourse all running together But the variables for those things the secrets were generated and are stored in a file right on your machine Where you initially created? Run backup from And so what we want is basically we want to have some of those credentials end up in In concourse in credit up and then later in concourse to be used in concourse This is dislike so that's why have we have came up with a solution like credit up importer So it will take everything that we created in our step that we set up Bosch with buck. You have to stand here and Okay So when everyone was when everything was Bosch was set up with buck It has all these it knows all these credentials But it isn't yet in credit in the credit part where concourse can access it So what we do is with credit up importer It just simply gets all the credentials variables and we'll just put it into put it into credit up and then we have We have this no, this is the use cases. We don't have an example problem We have in our next talk we are having a next talk in a next talk We are going to show the demo and how we are going to use it So Yeah, it's also if anyone wants the same it also wants to import their Haven't have their own Bosch release and I want to import stuff into credit up. They can use the credit up importer Yeah, it's really simple. It's just a Bosch release with with one Manifesting which you specify the credit up or the credentials that need to be seated into But yeah Yeah, no use cases, right? Yeah, yeah Yeah, so I use it myself a lot for development purposes, I don't know creating Bosch releases It's stuff. I first did to it was light but now with all the new push features Creating concourse pipelines But also, yeah working on dash deployment repos, right? That's and yeah When working on those it's really nice to have all those things together and Yeah for production. It's also Sometimes really useful to have like a concourse running alongside your Bosch So it's not for environments where so sometimes you have environments where you have like you have one concourse and you go out to many different environments, but if you're not doing that or you don't have Access network access to all those separate environments. It can be really helpful to just have like one machine with a concourse co-located Because like you can scale out your concourse with this approach, right? So it's not for a big build cluster, but it's more for running a deployment job once Or yeah an update stem cell pipeline, right? All those pipelines that are really tied to Bosch It it's really useful to have those running on the same machine. It makes it easier to manage Yeah, so yeah, we need to keep back up to date because It evolves and we have a lot of because the Bosch deployments will get new versions Every week the concourse release will probably be released every two weeks the credit CLI as well So what we do is we build a big pipeline where it gets the resources from From the Bosch deployments from the concourse releases and then it will compile all these releases that are not yet compiled yet So that's that's the whole thing that you then can use it in a more offline environment Yeah So this is the next step Yeah, so I want to be talking a bit about the history of sharing within the Bosch community. So first, yeah, we had Bosch releases and they were on github and we needed I don't know at some point people started publishing tar Tar so final releases so you wouldn't have to create your Bosch first you had to like before that you had to clone the The repo and then do the Bosch create release and then it would download everything create a thing So that has evolved and now we have like Bosch IO, which is awesome So we just I don't know Bosch see like an even fetch releases and that's nice. So that's all happened and after that We started to work on I don't know. How do you share deployments, right? How do you make your manifest how so we had all pattern sorts of patterns there It started with examples that lived in Bosch releases and we had some spiff spruce Face, I don't know stuff how to generate and concatenate all those manifests But yeah, that that now has evolved to Deployment repos being published and the new with a new bossy ally That's like all I don't know stabilizing around some common patterns And I think like the next challenge will be around how are we gonna share? concourse pipelines, how are we gonna generate them? How are we gonna? Yeah, make them shareable like useful for others Because I don't know a deployment repo There's a link with a concourse pipeline probably right you also want to have this pipeline to deploy it Which has knowledge about what errands to run and stuff like that So that's why I wanted to create this base to start developing on because I think like the core technologies here from like the bug Acronym those core technologies. I think these are like a nice foundation to build up On top of the next Yeah way of sharing Deployment pipelines. Yeah to just make it easier for people to just get involved with all the new releases and that kind of stuff Yeah Yeah, so as we already told I don't have yet. We have enough time if you have enough time we can show the demo here I think we have enough more than enough time This is already 20 minutes or is that not to have 20 minutes? I thought we have 20 minutes. How much time do I have left? Does anyone know how much time we have left? So yeah our next our demo of bug itself will be in the next Session so in an accession if you have any questions about this and not the demo Six seven eight eight questions eight minutes eight minutes. Okay. Oh self eight minutes. Okay Just go for it. Does that work? No, then you have to exit that one and increase the font Are there questions anywhere? Yeah, I already asked that one You have a question or it's big enough for you So yeah for for a CA that's still an issue Yeah, that's there. There isn't there is nothing at the moment yet that no It has a complete integration with a CA system No, but I mean like you could do that I think so you can use the credit credit up CLI to change those certificates, right? Then you do a post deploy and it's done. Yeah, but yeah for yeah, okay No, it does add the credit up doesn't integrate with the custom CA. Yeah, but yeah That's the variable syntax. So in a Bosch deployment, you just have to double up for an that's like a variable and that's the name Yeah, I think we had that like a few slides back How do you get that back? Yeah, and then the slides about That one. Yeah, I think full screen that so So the question was about how does Bosch know where variables and certificates should go so no Yeah, so the credit so credit is generating the certificates and for that That's the other slide. So there are two there are two times when No, yeah, but that this is There yeah this one so in so here you specify This is just a Bosch manifest, right? So in a Bosch manifest you have now a variable section and in here you define how to Generate the certificates Yeah, so you have one which is the CA and that CA will be used by this one Yeah, that's that's how those things are generated more questions I Can maybe We would what will we show? What do you want to show? So what we have here is if we do buck and we have all the environments variables that will be exposed So you can invoke buck as you can invoke Bosch immediately No Boy Yeah, so Since all those environments are already set. We just can work with Bosch, right? in from within this directory and We can also do buck credit hub Which will Install to see live it's not there and it will set a login to credit up so we can do We can find all the credentials that are already in credit up Get them generate them everything you can do with a credit up CLI Yeah, so What else? Yeah, maybe he's how to Set up buck We don't have anything left for the others Okay, wait, maybe that's good So this is like buck up is basically all you do right so and this is in the end It's just doing a Bosch create nth in the end. Oh wait, there's another question Hmm also it runs on Mac OS six or only Linux No, no, it runs on Mac OS. So in the end To tell a bit more about Bosch deployment so the Bosch deployment repo There's like a lot of CPIs in there that you can use We have here a list of the CPIs that we currently support So as you can see we we can use virtual box the virtual box CPI for Bosch And that's what it's using so on OS X you will just need to have virtual box and then when you do a buck up it will use the Bosch virtual box CPI And the stem cell for it to create a virtual machine and if you do dash dash light This will give you like a warden It will internally use the warden CPI. So instead of creating VMs, it will create Warden containers. So that's what you typically would use for development, right? You would use the virtual box CPI to create the VM like one VM with everything in it and then When you do a Bosch deploy that will actually create containers running inside that VM So, yeah, it works on macOS more questions Yeah Yeah, just buck up That will create a vars file So if you have to configure CPI to talk to your vSphere or something Yeah, that goes into here. So you have to specify a network and all those things For virtual box we we can default all those things. But if we can't For example for vSphere because we don't know your password yet Yeah, that's why So you would put those things into the vars file and then you go back up and you have a Yeah, so the basic thing why we build bug is that we just want to make it simpler for people To get up and running with the latest Bosch and the latest the latest startup latest With all the cloud config integrations and the concourse. Yeah, I Use it a lot to test my I want a vanilla environment every time when I want to test a new Bosch release that I'm creating Yeah, cuz If you do if you have a Bosch light and every time you need to tear down your Bosch light And it's just a lot of hassle to to work with So we hope this will help help some people. Yeah, so there's a bug info which Gives you Fly the concourse endpoint with the username and password. So that's what you would use to connect to your Concourse in the browser. How do we What do you want to do? Copy paste that into I can think click on the link, but Any more questions about anything Bosch? No Yeah, sorry, there's not a lot more to it. We can go over all files, but there were all the talks about that. I don't know Yeah question Yeah What you import it does it it fetches the certificates and passwords from credit up and puts it into the manifest before uploading or So maybe we can show the whole So you mean how we seed the credentials to credit up How you take it from there? So what my question is regarding skill abilities or what happens if you want to Fetch like 1000 certificates from credit up So do you end up with a huge manifest that you have to upload or have you any Have you made any tests regarding skill ability if you use so this is so in underneath It's just using so the credit up CLI has an import command which takes like a big YAML file And then will generate those certificate Credential so it's just talking to the API, but it's all going local right and it's only run Run once on startup So yeah, but we don't so we haven't made any skill ability Any scalability issues because we don't have like a thousand certificates because we only have this is all a really limited scope right, we only want to have the credentials and stuff available That are generated by bug right so it's only the API endpoints of Borsche The certificate of Borsche Username password. It's not like there will be more things in the end Okay, thanks Okay Maybe we can show it here, but what is Exactly going into yeah, so you can do Borsche or buck in to actually get the generated manifest If you want to look what what we are using to create the VM that yeah I don't know where exactly it is never do it this way What are you looking for for the credit up importer stuff where you can see that the job that it just Okay, I will show a trick Think we have enough Okay, so with bug in or bush and which is calling out to Bosch in which tends for interpolate You can do give a pot Which is like the ops file style right so you can do instance groups slash and then the name is credit Up importer Yeah So this way you will get Problem Yeah, sorry think there's just just not more people Okay, thanks