Automating builds and deployment – Jan Aleman, Scott Butler

Let’s get started. So what is this thing that Scott has built? So I’m actually a happy user of the sort of white cloud and if you already have server a cloud you don’t need this. That’s the first conclusion. However, if you can’t run a server cloud you don’t want to run a server white cloud. You want to run on your own cloud, you want to deploy it to your own server and this is a solution. That’s a simple description of this product. So essentially it is a complete CI and CD product to build your server way application and then once the build is done, then you can decide do we want to continue with some automation. So it can automatically deploy to for example Azure or to another cloud to your own cloud. Or do you just want to take the war or the container of the Docker image and then deploy it by yourself? Well that’s what you can do with this. And today it is based on GitHub so your code has to be on GitHub. If your code is not on GitHub then this will not work. Maybe Scott is going to make it work with other repositories. You can ask him, I don’t know. Also if you have any specific questions I will not be able to answer that. So if you have questions then please post them in the Discord channel and I will make sure that Scott gets online on the Discord channel today to answer any of those questions that you may have. Alright so I’m going to start with a brief overview and then we will actually build from scratch and Azure application. Scott kind of sent me a video on how to do that. But I decided instead of trying it myself. His video is pretty good. So I can never be doing better than his video. So I’m just going to play his video. But I will go through slides. And yeah he wanted to be here but he was so busy with work. And Scott is a bit of a touch. I think he has some touch genes in him because he’s also very cheap. And many ducks will be including myself. So he’s like no if I got to serve my camp I lose three days of work and I need to buy a ticket. Maybe I’ll be a sponsor. I have a lot of years to work. But that’s fine because he makes great products. He’s probably going to watch this video so I have to be kind. So Scott you’re a great guy. So let’s go through the current workflow and you all know this. The current workflow of making a build. You go to this fantastic dialogue which has a bunch of options. And you pick your options. And it is a manual process as we all know. You have to go there every time you want to do a build. It’s quite slow. If you have a bigger application. So typically if you want to start this you go out for a coffee or a cigarette back in the days. Does anybody still smoke you? Last night. Something dead. I remember back in the days when everybody uses smoke. That’s confidence. That’s what a lot of all the thought make a conference. And yeah so it’s not always consistent. And it really depends on the local computer that you’re running this on. I mean generally it produces okay builds. But it’s not always consistent depending on your computer. So then Scott came up with a way. Essentially to do two kinds of builds. Simple one. So your insert for a developer. You do a commit and a push. Goes to your to your private or public GitHub repository. And then using GitHub actions. It does all that process. So it builds the application. And then after it might last a long because I can’t read this. It builds a survey. War file which you could then save to to S3. Or as a GitHub release. Then maybe upload it using Sftp. And it can build a Tomcat Docker image with the server. War already inside of that image. So all you have to do is just fire it up. And then if you’re going to the advanced then you can also automate this whole section with it. So you can automate it all the way into your own in-house server and going live with no human interaction. Which I think is pretty neat because now you can make your deployment a very good way. to deployment a very predictable process. Just by putting in essentially using specific tags in your commit. And then the commit knows, okay, you want to push it to death. You want to push it to production. And then it will follow that whole process for you. Any questions so far over this is pretty clear. Right. Yeah. So that’s what it does. And we’re going to look at now the detailed steps. But what you need to keep in mind when you see this video is you’ll be like, wow, I have to do a lot of stuff. But the good use is that’s only one time. Because once you’ve done it, so what’s got to do with the videos, you’ll go through all the steps that you need to do one time. And then you’ll do a second deployment so you get an idea on how much work it is to do the second deployment. The other benefit of this recorded video is we don’t have to wait for the build to complete. Because there will be a cut when it’s waiting for the build to complete. It’s a bit quicker to put right. This is my easiest presentation of the week. I just hit white. Then Harios is going to do the sound, can I think? Today we’re going to demo servoy DevOps with Azure. Right. I’m going to do this one a little bit different. I’ve got to start more from scratch so you can see all the steps. You might see some mistakes, so that’s okay too. So we’re going to walk through how to get this thing deployed. So let’s start with what I’ve got here. So I have a cloud sample solution checked out. It is connected to our GitHub repository out here, servoy, war builder examples. And I have a branch Azure container registry. So that’s the one we’re going to be working on today. If you want to follow along, all the source code for this will be out there. So first thing we want to do is maybe send up a database server out in Azure. Right now I’ve got some connections to some other databases out in Digital Ocean. But I’m going to connect myself up to one in Azure. So let’s come out here and let’s, this is my Azure account I’ve created. We’re going to make a new database. And so I create. So it gives you a few options here. We’re going to stick with flexible. Otherwise there will be no sign of the recording. By the way, by the way, if you are a software company, most of you are, some of you are not. Is that right? Yeah. You’re not a software company. Microsoft has a fantastic program also. I’ll put the link in this code. That gives you free GitHub enterprise for a year and gives you $5,000 in credits in Azure. I don’t know that you can use for free. You’ve made nothing for that. Then once you use the credits, you can be cited as somewhere else. Maybe Google. I’m sure Google has a program as well. Because you want to learn how to free cloud hours. Sign up for the program. So we’ll hit create. We’re going to choose your subscription and resource group. So it doesn’t look like a have one. So I’ll create a new one. And we’ll call it demo one. Let me get to give it a surname. So it needs to be unique. So PG one. It’s demo PG. There we go. That’ll be Eastern US. Postgres 15 gives you some suggested workload types. It’ll automatically pick the size. You can always click configure if you want to do something different. So let’s do development. And that’s going to pull it down to $16 a month. And it’s going to be much simpler. Set up here. So availability zone. No preference. We’re not going to enable high availability for now. But that’s an option for you. And we’ll stick with postgres authentication. So let’s use a suggested password. So just paste that in. Paste that in. And. So we’re going to need to keep track of these things. So. I’m going to do a new one. And kind of put that there. And I use a name. So why. So keep those sitting there. Good networking. I’m going to give it a public IP that does not mean it’s open to the world. Still has a firewall in front of it. And we’re going to add our current my IP address. Why I’m now to the firewall rule. So it’ll allow me to connect to the postgres database. Later we’ll add another firewall rule to let our app server connect. So. Security will stick with that. Tatter options. Good there. And burstable. There we go. And let’s create. Okay. Well, that’s working. I’m going to get the database connections open here. And my server boy developer and ready to go. I’m going to feel like I’m going to be in the repository connection. I’m actually using in memory. That’s what I would suggest for everyone. But if you do want to use a real database connection, you can. Let’s go back and check on how we’re doing here. In progress. Okay. Well, that took a while. But a couple of minutes there. So let’s go. Take a look at it. So we’ve got a server name. We know our username and password. So let’s see if we can get connected to this thing. All right. So let’s go look at connection settings. So we can see our host name there. username, port number, password. It’s going to databases. That’s actually create those databases. So it looks like we have one call, for example. Let’s add another one. And that’s called svyscary. Okay. Let’s let those get created. And let’s plug a copy that host name. Paste it in there. Mix that in there. And then we’ll use a name as servoy. So we’ll drop that in there. And then we’ll copy our password. And let’s test it. Good. So we will see both of those. All right. So we’ve done that. But now as you can tell, we’re missing a bunch of tables and got a lot of additional errors. So let’s synchronize db server info. And we’re going to tell it to create all. And finish. And let’s do the same for servoy security. And let’s keep it clean. They clean up those errors. Okay. So you can see it’s connected to the database servers. They’re hosted in Azure. And it’s created the basic structure for me. You can use other tools. I think it actually has some examples here. So you could use, let’s bring this down. So you could use like pgadmin, db, bearer, whatever you want. And connect to that. Set up some sample data, whatever. So you can always directly connect to your database running in the cloud. Just keep in mind you do need to manage the firewall. So right now my IP is the only thing allowed through. Okay. Next step. So what did I do all that? Well, I did that because that’s the easiest way to do step one of DevOps, which is getting a property file into your repository. So that it knows what to use for the build and what to use for the war file. So we’re going to close this and let’s go take a look at that property file. Actually, this is copy at first. So we’re going to go into our war builder examples here. So this is just my local workspace. And I made a folder earlier called prop files. And I’m going to paste server with property file for my developer into this. And let’s open this guy up and take a look at it. So let’s go. It’s got my connections. It’s got my encrypted password. It’s got the admin repository. I don’t think I don’t like is the file service default folder. So I’m going to clear that out and serve boy will pick one automatically. So let’s get rid of that. All right. And save it. Okay. Let’s close that. I’ll close that. So step two is what’s the build is happening in the cloud. Not only does it need the property file, but it also needs like any extras that you have by extra as I mean like plugins, beans, things like that. So what we do is we overlay the application server folder with whatever you include in a folder that you designate. So let’s go back to our workspace here and we’re going to make a new folder. And we like to call our serve boy developer extras. And then the first thing you need to have inside in there is a new folder called application server. And then at that point, it just mimics your installation. So whatever stuff you have that’s different from the default install, you’ll mirror it. So here’s the application server folder that here’s my developer folder. I know I have some plugins that I want to add. So we’re going to make a new folder for plugins. Let’s go into the plugins folder and let’s pick the ones that I know I need to add. So Jasper reports is one that we added. So let’s get those. And that might be the only one in this project. We just give it another scan. That looks about right. So we’re going to copy those and paste it into there. So those are going to get included in the War file when it doesn’t build. Okay, next step. Step three, we’re going to set up the YAML file for the Docker action. So we’re going to come back here and we’re going to make a new folder called dot GitHub. And another folder called workflows. And then we’re going to make a new text document and we’ll call it Azure Container Registry. I don’t see that yet. Azure Container Registry dot. So then we’re going to open this guy up and we’re going to start with some examples we have out there. So if I come to our survey world war builder examples, I’ve got one that we did for digital ocean. So we’re going to try and kind of stick with that as a starting point. And then we’ll make some adjustments. So it’s called servoy build. We’re actually doing a build in to play here. So I’ll do a little and. The point so it’s going to show up in the action runs. And then you can set up like what branches for this run on. I’m happy to be working in a branch called Azure Container Registry. So we want that one to be hit. And then I have some options like when do you want this thing to run. So I don’t want it to run like every commit. I like to have a little bit more control there. So you can see we kind of do this bracket thing war is kind of a common one that we use. But I’ll call this like Azure deploy. There. So the first step is pretty much always the same. You’re going to check it out. Then you’re going to run. Builder. So you’re a specify the name to our GitHub action. And the servoy version that you want. And all of these settings are available out here. So if you go to the servoy war, war builder GitHub repo, you can see some samples. And then if you scroll all the way down, you sort of start to see what all those property names are and what they do. So if you’re familiar with exporting, you know, manually, these are basically like equivalent flags that you get. So let’s keep running through these. You’ll notice the use of secrets. So secrets are set up in your settings. Secrets of variables, actions. And here you have a list of repository secrets. So you hit new repository secret, give it an aim, give it a value. And then it’s stored and crypt it up at GitHub. And you can never see the current value. You can only overwrite it. But those variables are available at build time here. So these will get merged in with whatever the secret value was. Properties file. So. I’ll forget I’m actually just going to make my both the same. So. I’m going to wait until the same file. Here we go. And again, that’s that one that we made over here. So, sort of the phone. That’s going to be this guy. So. Profiles, we copied it that servoipropper. They made a few tweaks to it. So we’re just referencing that here. We’re going to build it off a DBI’s. So it’s not going to actually try to connect to the database. It’s just going to use the DBI files to know what’s in the database. Otherwise, you would have to let it connect to your, you know, open the firewall. Yeah. We’re going to collect cloud.war allow SQL changes, allow data model changes. And then here’s our extras folder. So that servoip developer extras. Let’s come back here. So that’s that guy. So we’re just telling it here’s the spot to overlay stuff into for all the custom things we have plugins, beans, wick. Okay, next up. So Docker login. So we’ve got to have a way to let Docker log in to our private container registry. Well, that means the first thing we have to do is actually create a container registry. So let’s save our progress here. Let’s go do that. So let’s come out to Azure. Let’s go back to home. And container registries. If you don’t see that by the way, you can search up top and find it. And let’s create a container registry. We’re going to put it in the same resource group. So we didn’t want. It could be in the east. Good next. And we’ll keep taking the defaults here. And let’s create. So let’s go take a look at it. Or token. So token along with the password, let’s you authenticate to the registry. So the registry is public and that it has a public IP, but you still have to authenticate to the registry in order to. I should pull. So. Let’s. And you want to call this. Get have actions. And we’re going to let this do a push. So it doesn’t look as generated it yet. So let’s make it generating one. I guess. There we go. So you can set an expiration date. So generate one for now. Yes. There we go. So let’s copy these. And. So it says you do a Docker login. That’s the username. That’s the password. And that’s the registry. Good. So that’s what we need. So let’s go back. To our yammerl. Yammer file. So here’s our Docker login. So we know where registry is. And we’re going to need to create secrets. For these, I think the username is acceptable drop in there. But I don’t want the password being public. So the words copy that guy. And let’s go back. Sample here. I think we had secrets. There we go. There we pause it. See, crit. And we’ll call that. Sure. Work to street. That’s for. Copy that. There we go. You can see that’s been added. So come back to our yammer file. I’m going to do secret. So let’s see. So let’s see. So let’s see. So let’s see. Let’s see. So let’s see. So let’s see. So let’s see. So let’s see. So let’s see. I’m going to do secrets that. Azure Container Registry password. So then that’s going to get it logged into the Azure Container registry. And then we’re going to do a push to it. So we’re going to use our GitHub action for Tom Camp Builder. That that does builds the Tomcat Docker image. Put your war inside of it. And then it’s going to do a push to this registry. So what I think we’re going to do is stick with kind of a standard way. So we put the registry name in there and we’re going to call it a serenewy topcat. So we’ll try and put it at the root directory because this already has our demo right there. So let’s save that and see what happens here. So I’ve got to remember my tag name is azurepoint. All right. So let’s go back to serenewy. Let’s open it up here. So let’s see if we have any outgoing changes. All right. So those files you saw us work with over the workspace there. There’s a hard, a YAML file for the workflow, the extras that we added. What else do we have here? Poor property files. All right. So we’ll do all those and we’ll call it first, it’ll test and we’re going to put that flag in there. So it should see our YAML file in the commit, which should look at this message here because it has the bracket as your deploy and that in theory, if we go take a look at our model here, that should trigger this to run. So still commit and there we go. Now we’re there. So let’s go take a look at the action. So it’s going to try to run. So good. Let’s take a look, watch it build. Let’s move down to the servoy part. It’s running our servoy builder, GitHub action. So this is where it’s actually trying to build the war file for you. Kind of see some of the steps that it’s going through. Okay. So it says it did the build. And it did the Docker log in. And now it’s attempting to push that new image. So it’s the Tomcat image with our war file inside of it. And it’s going to try and push that to our container registry. And it’s here. Let’s see. We kind of got a clock going up here. So it’s about three and a half minutes so far. So that was pretty good. Finish the dog. If you’re logging in, so it’s a successful build. So let’s see about that. So, okay. So let’s click on repositories. And there’s the servoy Tomcat. And you can see. So it defaulted to a date and time tag. Actually don’t like that. I’m not crazy about that. So, but we’ll change that later. So on the next build, we’ll give it a better tag. So let’s see if we can deploy this guy now. So we’ve got a database server in Azure. We have a Tomcat image now with our war file inside of it. So let’s see if we can make a container service to deploy it. So we’ll type container app. Excuse me. And let’s make a new one. Same description. Do a one container app name. We’ll call this Tomcat servoy. We begin. We’re going to want to put this in East. And that’s what a container we’re not, we’re not going to use the quick start image. We’re going to try to use ours. So as your container registry, there’s our registry we created. So we get an error. Let’s see. Because add credentials are disabled. So let’s go back and take a look at that. So container registry. So access keys. We’re going to try this. We’ll turn that on. Okay, let’s go back and give that another try. So make a container app. Create a new one. We source group demo. Call Tomcat servoy. Call for East US. And container. Don’t use the quick start image. Let’s pick up registry. And there we go. So Tomcat and there’s our tag choice. So again, we’re going to make these a little bit better next time. We’re going to do version tags. We have opportunities to overwrite the commands. Pick CPU and memory. So a little bit more there. And then you got environmental variables. So if you take a look at the documentation. So this is the war builder. But if you look at the Tomcat war builder, excuse me, the Tomcat builder, you’ll see. It’ll have some stuff in the documentation here of things you can you can override. So that would have been earlier actually in the builder step, but I could overrove these things. But you do have sort of the standard things you can override, the Catalina ops and stuff, a memory and we’ll update the documentation here to give you more examples. We’re just going to keep it simple for now and take the defaults. So let’s hit review, anchment. And it’s thinking about it. And I create. OK. Climate progress. Now I expect the war file. So Tomcat will launch, but our war file will most likely fail because it won’t be able to connect to the database. So that’s the firewall port part that we need to open up once this gets deployed. OK, it says it finished. So let’s take a look. See what we got here. So we’re going to take a look at the ingress here and we’re going to enable HTTP traffic. And I believe we default to run on 88. So let’s try that. And we actually want traffic from anywhere, not just inside the vNet. It’s going back to over a few here to see what that updated to. There we go. Also, there’s an application URL. And that’s the way it does. Gonna try the non HTTP port. There you go. They’re both loaded. So it’s redirected over. OK, so Tomcat’s running. Well, fairly certain cloud file is not. So yeah, we’re going to four on that. So let’s see what changes we need to make to what the container app connect to our database. Got an option down here. Service Connectors. So let’s give that a shot. So we’ve got our container. And then it’s going to let us pick what else we’re connecting to. So we’ve got flexible server for Postgres that we created earlier. And it’s automatically picked everything else and see. I also want to include the new put in an asterisk, but we have an end. Set these up. I’ll give you a production. You might choose something slightly different. But for the moment, I’m just going to drop in our. Credentials, like you had before. So we’re going to get a funny error there. So all we start to refresh the page and give it a try. So service type. Let’s call server from Postgres. I have your example. Give me a Java client. Connections, string. I used the password and credentials that we had. Previously saved. Let’s see if it’ll work. It’s done. OK, so it says. It made one. And those look like pretty much the same. SSL mode require isn’t in ours, but that looks like the same. Credentials. Now I’m expecting that that probably opened up a firewall port for all of the databases. So right now I’m not going to try and make another one. We’re just going to see if we can get that to work. Let’s go back and I’ve refreshed here and it looks like I was back up and running. So. All right, as set up our first user. Here there we go. So you can see our solutions are there. Let’s see if they’re actually right. So I’ll be that. And there we go. So let’s make some changes and see what the deployment looks like. Let’s also just poke around in the container here and see what’s going on first. So I’m going to scroll down to console. And it’s going to let me SSH basically into the container. And I know from the documentation of the Tomcat image that the default server user whole slash user slash. I’m going to slash server. And there’s a server file. I will look server and there’s a server with law file. So let’s take a look at it. See some referencing that it’s unhappy about not being able to set the default location for. The log file. So let’s go ahead. I’m sorry for the files again. Let’s go ahead and like copy this. And we’ll probably put it at. Slash above will be. Sorry. So let’s go back. We’ll close. We’ll close the solution. Just leave it there for now. But we will go back to develop them. We’ll make a small change. Change user name to user just so we can see that our changes will get deployed. And then let’s take a look at that. Yeah, we’ll file here. Let’s see. That’s actually not the one I want. I want to go to property file first. And want to change the folder location without value that I copied. And we’ll save that. So a year we’ll file. I don’t think there’s much we need to change about that. Think we’re okay with that. We’re going to do the tag of different. That’s not officially a tag. But the things inside the little brackets when we do the commit. We’re going to change those a little bit. So let’s come back here. And to commit. All right. So I just restarted it and it sees that property change. So that’s good. Let’s just go ahead and stage all those. And I need my has deployed. And I’m also going to specify a name by tagging. So let’s go take a look. So let’s go take a look at the actions I’ve ran in the past. And I see an example there that I’ve used. And I’ll be in the documentation as well. So let’s drop that tag name in. So this is going to be the Docker tag. So I’ll call it the moment point one. Since we’ll consider that other one sort of version one. Since I didn’t do that in the other commit, it just used like current date and time. So I’ll put those in there and we’ll give it a description. They will get more than and property. All right. So that’s going to trigger the deploy and then we’ll use that version number from tag. So here we go. Let’s come back up here. Okay. Actions again. There we go. That’s about the name. Because the first time this bit of work, so it usually does not do that. It just kind of issue updating. So actually says it ran through all the steps. The UI just wasn’t updating for me. So let’s just make sure that really happened. So what it said. That it did push. Oh god. Be 1.1. So let’s go see if that’s the case. So we’ll click on containers and what that. And instead of that date tag, there we go. Click version 1.1. Notice how useful this is by the way. So you can always roll back to prior versions. You basically have a image with everything you need inside of it, including your servo or profile to make that easy for you to roll forwards. And all right. So we’ll save that. And create it. Should see this die off fairly soon, because this is going to kill our current one. Successfully deployed. Let’s go look at the uptime. So one thing to keep in mind is the deployment is really the deployment of a concat deployment of your war file inside of top cact. We’ll take a little bit longer. If you want to watch what’s going on, we should be able to come down. Usually they got a way to watch the one. So again. So it should be. There we go. So in 44 seconds, our page has expired here, of course. So what we fresh in. And there’s our update with the change to two user. There you go. All right. So there are other things. Of course, you want to do custom domain names, things like that, making sure you got your RAM and CPU setup correctly. But this is just your basic how to get started. And then if you choose to use Azure, you’re going to invest some time in learning about managing Microsoft Azure Cloud. So you can make sure you get it configured correctly. But of course, if you need help, we’re always available. Thanks. All right. Thank you. Thank you. Thank you, Scott. Yeah, so as you can see, the first time it’s quite a hassle, compared to circle cloud, where you just do commit and it does all of its magic. So if you prefer the black box that survey cloud is, then that’s the way to go. But if you want to be able to get on server to an Azure server, to any other cloud, then this is a way to make things easier, especially after the first time, because first time you can see it’s with the whole config. But people just say, don’t purpose because this is what you will have to go through if you go to Azure or if you go to something else. All right. Once they’re all about pricing, well, yeah, even I. Could you decide to go share this for you guys? I said, you need to give the people at server camps and discounts. Because they came all the way in to spend a lot of money here. So you’re getting some discount. 25% off. So you can either license just this, which is $650, or you can get the whole shipping that I think Prose does, which are all his plugins and components. Does anybody have a license on them? 23. So we’re looking at very good. We’re looking at very good. Yeah, so they have a bunch of very good plugins. And you know, if you can get for a single developer $800 per year, you get everything including this. Or if you with more than one developer $1,200 for all the developers, you get all the stuff they, yeah, yeah, yeah. The workflow again by itself is what it is. And then 20%. I wonder if the 25% off is going to be for the lifetime of just the first year. Maybe Scott can light us down with the comments. And he thought so many questions for Scott because he’ll watch this video then post this questions in the Giskwetch channel. Right.

Close