Automate deployments using the Kudo project

This is a walkthough of my steps to get Kudo up and running on a server that is not in Microsoft Azure.

I really like to write code, but when it is coming to deploy of applications I am working on it is terribly boring. Often it is the exact same steps that needs to be done over and over again for each deploy. Therefore, I like to find ways to automate as most of the process as I possibly can. When I first looked into and testet Microsoft Azure and saw Kudo in action, I was quite impressed about how it worked. Some years later when I realized that Kudo was an open source project available at Github, I knew I had to test it out one time. That time is now and as I get through, I will document the process here.

Installing and setting up the requirements

My first attempt to get Kudo up and running, I checked the source control out from Github. The next I did was just starting Visual Studio as an administrator and pressed F5. That worked on my local machine and I though it was just right-click on Kudo.Web and publish. That did not work on the server that I was setting it up on.

First of all, the server I want to run Kudo is not a build agent, it is just a server running published applications. So after reading through the repository, it was clear that I needed quite a list of dependencies to get Kudo running. Luckilly, in the setup folder there are scripts that can do the job. By copying the setup folder to the server I could run KuduDevSetup.cmd as an administrator.

Setting up IIS

When it comes to deployment of Kudo, I ended up not building it myself, but rather pick the latest relase that was available on the Github repository release page. For me that was S62.

The actual folder structure about how it should be was described quite well in the documentation wiki page, Deploying to a server.

In IIS I created two new IIS Sites, one for Kudo Web and also one for Kudo Services Web. Both using the same application pool that is running under Local System user.

Hostename

When I am creating new applcations Kudo, all the sites are created on HTTP with different ports. But all the sites can be found in IIS. Therefore I go over to IIS and adding HTTPS binding to the sites.

https://myservice.mysite.com
https://scm-myservice.mysite.com

I typically use the form above so that it is easy to remember both application url and the service work application url.

Integration with Gitlab

Setting up Kudo with Continuous deployment is one of the main goals that I had. This wiki page at the Kudo repository is quite good at what needs to be done.

Now I created a local user account that I called kudo. I assign full rights to the applications folder for this user. This is the user that I also use in the PUSH-event a bit later.

/api/sshkey?ensurePublicKey=1

The first thing I do after I created an application in the Kudo web UI is to get the public key for the deployment site. The endpoint above is what needs to be called on the kudo service worker service. Then this key can be added to the project in Gitlab. For me that is on the project, Settings -> Integrations and there I can add an URL for the PUSH event. Since the server that I am configuring is using a domain SSL-certificate, I needed to uncheck the SSL validation.

https://kudouser:kudouserpwd@scm.mywebsite.com

Conclusion

When I am done setting up Kudo and look back at the process, it was quite easy to setup after I started to understand a little bit how the pieces hold together. My first attempt to setup and configure Kudo failed, but after reading up a lot more at all the documentation they have at Github it was a success at my next attempt.

Teis Lindemark

Software developer, beer brewer and AGENT backer

Bergen, Norway https://teilin.net