 All right, hello everyone My name is our boss ready. I am a software engineer at Cloud Foundry I currently work on a close-source team called dedicated my sequel. It's the version to of my sequel for PCF Just commercial But I'm gonna talk about open source stuff today and that's Bosch's operation files so Why should we care about operation files? I really think that in Bosch 2.0 We got a whole subset of new features and new things that we could use and Although ops files is just a slice of that feature set in Bosch 2. It's really versatile and it's changed I think as a Bosch release author and as a consumer how I think about what should go inside of my release repository I think that We need to start establishing a common language about how we talk about these ops files because they are so versatile We could just go off and start using them in a number of which ways which could further complicate our platform Which I think already is difficult for deploying So I'm hoping that the purpose of my talk is to start engaging in some of those conversations So that we can talk about better ways to use ops files and maybe share some of the patterns that we're already using And a little bit about our project dedicated my sequel We started the project. It was greenfielded about a year ago And since we didn't have a legacy code base or really any consumers at this time. It was brand new We started to we had a unique opportunity to start using Bosch 2.0 when it was still experimental along with ops files So over the past year that I've been working on this project I've really seen ops file specifically expand and people start developing different patterns across the call Foundry 4 about how they're using them So I'm here to share about how we use them on our project as well as some other things other really good things I think the community is starting to do so in order to like Remember the world before ops files, which was a year ago for me I had to go back and look at what manifest generation for your deployment looked like So apologies if this is small, but I'm gonna highlight some of those so I used to be a member of the Cloud Foundry API team and we used the script pretty regularly what it did was Generate a manifest for a bunch of use cases including for our Bosch light environment Which is where we would do regular development every single day and as a developer on that team I just kind of use the script Maybe once or twice a week and if I ever had to edit it I knew was going to be a nightmare because I was gonna have to go into deep in the weeds of using spiff and some templating logic that I knew Was going to be a time sink and not actually advance on creating the feature that I wanted for the release So taking a look at this manifest generation script first thing I remembered was that you had to check if this external tool spiff was installed The nice thing about Bosch to and ops files is that there's native support for it in the new goaling CLI The other thing I noticed is that there was a lot of like spaghetti bash. There's a conditional here That's checking for which type of infrastructure that you could be using for your deployment manifest and based on that It's going to bring in somewhere along the lines of like 500 lines of yaml's to Incorporate into your deployment manifest. So I think that in ops files. We got a chance to have less redundancy I'm going to show that in an example later on but essentially like you don't have to have a copy of your manifest for AWS for GCP for like all of the various use cases not just IS specific You can start using ops files, which will be snippets and it's confined to you know Hear the properties that I need towards a concept that you can then interpolate into a larger manifest and I mentioned like having to download spiff Spiff is like notoriously difficult to understand and it was kind of like this black box where it just was like Give me your yaml and I will merge them together and at deploy time. Maybe you'll find out if it worked or not So this is what I was talking about when I said as a developer on the team I really didn't want to have to like edit this thing I knew that I was going to spend a lot of time Manually looking through and visually trying to verify whether the manifest that was merged out of spiff was actually correct So I think that with Bosch to and with ops files. We got simplified templating logic and You're probably thinking what is simplified templating logic? I don't think that exists especially in Cloud Foundry when you're dealing with thousands of yaml But I'll show you some examples and maybe you guys can tell me whether or not that's real Okay, so throughout my talk. I'm going to be using this Example and start to break it down and just show you like a common use case of using ops files So this is a deploy task that as a developer on my team I would use it's very simplified for for this talk, but basically I'm trying to deploy in my SQL service broker You can tell that I'm bringing in an ops file that says Bosch light on it So there's probably something specific to Bosch light in there And then another ops file for enabling syslog to my service broker The use case for this task I should mention this deploy task is for a person like me Who's on my team was just trying to iterate on this broker and create a new feature on it So I just want the quickest thing to get a service broker up and running Maybe I have some integration tests or something that I want to run later down the line that are related to syslog Which is why I'm doing this deploy So the first thing that I really like about the new way to deploy with these ops files Is that you have this concept of a base manifest and that's the first argument to your deploy I don't think a minimal deployment is new to cloud foundry because I've definitely seen that in other projects prior to Bosch 2 But I think we've Elevated it and made it a first-class citizen and really forced Bosch release authors to think about what is the most basic Deployment that I can do of your thing and without any frills just to get up and running So really thinking about that and not bringing every single property that needs to be a part of that manifest along for the ride And then I have my ops files, which I'm gonna dig into what they have inside of them but they're layering on additional configurations to my base manifest and One thing that you may notice is that the enable syslog file is kind of it's the way that it's named is very action-based So I'm enabling syslog You could imagine there'd be other ops files that are disabling syslog if that was what was in my minimal deployment You always got that so it's additional configuration that you're adding in and it's very actionable So it makes sense from like a high level what's going on in there And if you're curious exactly how we're enabling syslog as a consumer of that deployment you would dig into that ops file One thing I want to mention here This is goes back to the need of support in the Bosch to CLI is that you can use the deploy command Which will interpolate your manifest, but there's also a Bosch interpolate command Which is nice because then you can see pretty quickly what your manifest is going to turn into without actually having to go ahead with the deploy There's also this really nice Flag that you can pass to it called dash dash path and you can take any YAML file and what Bosch will do is traverse that Manifest file With the path that you have specified and pull out the value of the property that you've given So in this specific case that I have an instance groups service broker Everything under service broker is going to get spit back I really like using this when I'm iterating on an ops file It makes me double check like that have my pass sets correctly and that I have the Expected like output when I'm running this path Okay, let's go into the opera the two types of operations that we have inside of an ops file So there's remove and replace The remove is pretty simple. So this is my Bosch light ops file And I'm deploying in my SQL service broker and it's on Bosch light So I don't really care about it having a persistent disk. So this is a great use case for that specific environment So I want to go and find the value of the persistent disk in my manifest and just remove it so I'm specifying the type of operation in the type field and Then the path at which that property is going to exist So when I run interpolate or deploy what's going to happen to my base manifest is that it's going to traverse that manifest and find exactly where persistent disk is and Do the operation of removing it? Pretty straightforward replaces where you can kind of do the more interesting stuff So if you have a value that you want to replace in the manifest you can use the operation replace and Similarly, you give it the path to the property that you want to change So for my service broker, that's going to be on Bosch light I want it to be the tiniest thing possible because I'm just trying to get quick and up and running So I want to scale down my usually minimal deployment. That's highly available and has multiple instances over to just one So same thing as with remove it's going to find the path that I specified in my base manifest for my SQL broker Take that instance property and replace it to two So then I also had that enable syslog example or sorry enable syslog ops file and The I what I like doing with these replace commands is being able to enable features as I said so for syslog It's an optional thing that may or may not be wanted inside of that broker and as a developer Maybe I'm testing out syslog as I said as for an integration test So I just want to quickly put that into my deployment So jobs is an array in the Bosch manifest and I can use this dash syntax to say that I'm appending to an array And then I can specify the job syslog forwarder and start adding that to the manifest There's also you can use numerical syntax here as well like to this for the zero with index element things like that I'm also using variable syntax here Which is pretty nice, especially for something like this You can imagine that in the enable syslog ops file could be used not only for Bosch light for various other Circumstances like a production environment and for that I would want to replace some of these variable values with Actual addresses instead of like fake addresses for my Bosch light So as you probably may have heard of Dan's talk is that you can actually have Bosch generate these Variables if you specify the type So if you had something like not necessarily for syslog address But if you had a password type or something you could specify that in the variable section of your manifest and Bosch would generate it for you Or you can just specify it on the command line and one tip that I have for this is to Whenever you're running Bosch deploy or Bosch interpolate to use dash dash var errors This will actually catch any Variables that haven't been interpolated or filled in because what ends up happening is that if you just straight up use this and forgot to Specify syslog address it would just show up as the string Perence perence syslog address in your manifest and you wouldn't find out until that that variable is actually getting exercise Maybe somewhere in the deploy So enable syslog is just going to come in here and just shove this information into the jobs array Which is nice and one other syntax that I wanted to go over for this is the question mark syntax So if for some reason I just wasn't sure whether this syslog forward or job had already been a part of the manifest or not I could use this question mark to say hey Bosch check for the existence of that job and if it's not there at it and What's nice about this question mark is that it carries over to the rest of the path So I don't have to sprinkle in question marks throughout the entire path if there was more than just going on beyond release it'll just continue to add it and it serves well for Situations like this if I wanted to one off use my own custom syslog release I could go in and just change that value and this could be a standalone ops file in itself or a part of the enable syslog ops file so I think this task is a little misleading because it has It seems like all of these properties are confined into their own ops files And they're kind of operating independent of each other when in fact you as the deployment curator Actually need to know the specifics of what's going on in each spot ops file so that you don't end up We're overriding any properties in subsequent ops files So this is an ordered dependent command and although it's nicely kind of seemingly separating concerns You still may end up in a situation where you are overriding for example in my Bosch light. I'm removing the persistent disk But for very very valid reasons I could also want to add a persistent disk in my enable syslog ops file So the result would be that I would end up with one I'm not doing that currently, but that's something me as the deployment curator is in charge of right like I have all These ops files at my disposal ones that I've written myself ones that are part of the Bosch release themselves You can't just based on the names start pulling together and and have a deployment. You really need to think about how it's orchestrated Okay, so to recap in my example, we have a base manifest Have a Bosch light ops file and enable syslog ops file so the Bosch light one is scaling down and Removing the persistent disk and then my syslog one is adding a syslog forwarder job But what if you wanted to configure syslog specifically for Bosch light What do I mean by that? Also, this is a great episode So syslog for Bosch light if you've seen the open source syslog release Syslog Bosch release there's an optional job that you can pass to it called syslog store And it has a very valid use case especially for testing So if I've configured my syslog forwarder job correctly I want to see that those logs are actually ending up somewhere you'd bring in syslog store to test that it's very valuable Especially in like CI and local development testing environments But then I start to wonder like where should I put it right? If I it's kind of something that I would only deploy on my Bosch light Should I put it in the Bosch light yaml file? But then there's also this like enable syslog yaml file and that has all the syslog important properties But if I want people to use my enable syslog file outside of just for this Bosch light specific deploy task and also when they're not having to Optionally they don't have to think about optionally bringing in store or not like where do I put in this like piece of information? There's a lot of alsos and back there But basically this is a this is a question which then leads me to you ask another question Who are these ops files even for right? so as A Bosch author and a Bosch consumer we have separate concerns Bosch author wants to iterate as quickly as possible. So put it in the Bosch light yaml file Let's get going so I can just deploy and I know I'm just going to need store as a Consumer I'm coming to a Bosch release and just wondering how do I even deploy this thing? I know that I want a service broker that has syslog on it I don't know what store is. I don't know that it's optional and I don't know if I actually need it so just tell me how do I deploy this thing pretty quickly and Although at times it can seem like these are competing concerns I actually think that ops files gives us a lot of headway and ways to like Make it so that we can meet the concerns of both of these types of users of Bosch releases and For release authors, I think that there's just still at least what I found is there's no way of getting out of Manifest generation scripts even with the addition of ops files I'm super curious about developers out there who are using ops files and for quick development What are the ways that are getting around this because at least for what I've done in my projects We've still needed a way to be like here the set of Operation files and configurations that you would need to enable a certain feature All right now bring those values in into this specific order So that I can get going and like start developing on it So for the question that I asked earlier, what if I wanted to you know use store But only specifically for in the context of my Bosch light environments and for like local testing Start having some like bash again So it's set a syslog configuration variable and one thing I changed was I extracted The ops files so that enable syslog forwarder is its own thing and then enable syslog store is another Ops file in itself so that way I can meet both of those needs however, I As the deployment curator right still need to know that the syslog story doesn't really make sense without the forwarder being A part of it as well and that it needs to happen in this sequence more or less So my Bosch deploy command starts to look a little bit like this and then I still have my base manifest I still have my Bosch light that I want to deploy my service broker to and then some additional syslog Configuration that I've defined elsewhere So trying to encapsulate that as much as possible and then all the other stuff that's in there because this is a very simplified version of how you could deploy I Think there there are a lot of ops files and things that you would probably want to insert in here going forward and It makes sense to have a script that's versioned in your git repository that says this is how a dev A person who's authoring this release would run this and and use these ops files in this order So that's for someone who's iterating on it I think going back to what I said earlier about like ops files changing the way that we think about our Bosch releases I think we need to start like actually including them as part of our Bosch releases and Commit them as release artifacts that we hand over to consumers and end users So the base manifest thing making it a first-class citizen and talking about it in your read-me's and saying here's here's the simplest way to deploy like my thing and then some example ops files This could very well be the exact ops files that you use for example enable syslog forwarding is the exact ops file that we would use Inside of our our dev environments as well as maybe even some production environments that we set up However, let consumers know that these this is an example of if you wanted to bring in those features here the exact properties that you would need Feel free to author your own ops file based on the examples that we've given you So That kind of looks like This in a read-me. I think is the cheapest way to get that done in your Bosch release It's just being like here's here's a common use case of deploying broker with syslog Here are the set of operations that you would need to do by the way You're gonna come across some of these other ops files inside of your repo. Here is what we use them for Kids, they're basically examples for your disposal there's a interesting thing that the CF deployment team started doing and it's called Workflows and I really like this idea where they started productizing their ops files So what they do is actually say, you know, this this ops file we verified it We've unit tested it in isolation and we know it works However, since the nature of deploy commands and ops files are order dependent Here's a static workflow on how to achieve the type of deployment that you're looking for So a CF deployment across multiple acs. This is what your deployment workflow could look like And they do a really good job of this is a screenshot from when their github Read me is they do a really good job of going over each and every single one of their ops files What the purpose is and exactly some of the gotchas are things that you should know about beforehand before you start using that Ops file. I think this is a really awesome pattern and that we should move toward this It does mean, you know having to document document some of these ops files and taking the time to make sure that they actually work and unit test them Whether or not you do that and whether you choose to use them as examples I think is up to you as a as a Bosch Release author, but I've really seen this pattern like seem to work well and people respond to it well in the community so in conclusion just to review if Anything you learn is just to clearly name your ops file So it's obvious to everyone not only developers on your team, but people outside who are looking into your Bosch release repo Like what exactly is this thing doing? commit some of those example ops files and definitely a base manifest inside of your release repo and If possible and appropriate find out what are your common use cases are How are people deploying the thing that you're authoring and based on that What are the workflows that you can provide to them that you know work and are fully tested? Thank you for attending this talk I Am not a member of the Bosch team and cannot answer specific questions about Bosch, but If you do have questions, I'm here to take them