Configuring Octopus Deploy and Tentacles

You may also like...

3 Responses

  1. Paul Stovell says:

    This is a great series Ian, I look forward to seeing the rest of the articles!

    Another interesting thing about the ports is they can even be different on both sides if you need to use port forwarding – e.g., Octopus sends commands to port 10933, but the router/firewall port forwards that to the Tentacle listening on port 10934.

    I’m glad to hear that you see Nancy+Raven as a positive. Early betas of Octopus used SQL Server, and while it may be a more easily accepted technology, it tends to need to be owned by DBA’s (some organisations have policies that prevent using SQL Express, for example) and comes with various licensing and other considerations. RavenDB tends to be invisible on the other hand, and for what it’s worth, RavenDB is really just a wrapper around ESENT which is the same technology that powers Microsoft Exchange and Active Directory. I’m not sure many organisations would have a problem with that given they probably use one of those technologies 🙂

    Likewise, we used IIS until Octopus 2.0. IIS is great, but people tend to customise it a lot, so it’s difficult to develop software that runs reliably on every IIS server out there (e.g., once a customer couldn’t manage to get Octopus working; eventually we found out that it’s because they deleted the default MIME types in IIS for another application, which meant Octopus couldn’t work anymore). So we do what SQL Server Reporting Services does, and we run on top of HTTP.sys, the Windows kernel driver that also powers IIS. So, in some ways we’re still using the HTTP/HTTPS server that IIS uses, but without all the extra stuff on top.

    D’oh, I think I got carried away there, sorry for skipping ahead! Love the series!


  2. ianpaullin says:

    Thanks so much for the comments, Paul! Please get carried away! 🙂

    I really think that the port configuration is a really big feature that doesn’t get enough credit. For larger enterprises, a product that’s able to adapt to the environment is a big feature. Keep in mind I was testing out InCycle/MS Release Management 2013 which required one port available for all agents, servers, the web client and the desktop client! This was a huge hurdle just for our pilot testing. The thought of deploying it company-wide would give me nightmares.

    As for SQL Server, the current organization I’m implementing Octopus at uses it almost exclusively. Now, there are some parts of the company that use other databases but by and large it is the standard. Some managers like the ability to view raw data from some of their vendors’ products within SQL Server. I think from a troubleshooting or debugging perspective, it’s useful to have access which is probably the underlying motive, however the Raven Studio within Octopus should suffice to meet the troubleshooting requirement. I would say though that running on SQL Server was more or less a matter of options, not requirements. Again, for larger companies with available resources, it may be something they want, but not realize they don’t need it.

    During my testing of Release Management, we were easily able to view into the SQL database in which it was installed on, view all the tables, data, sprocs, views, etc. Was it a major bonus that we could peek behind the scenes? Meh, not really, but it was nice to see everything if they needed to troubleshoot or do some sort of reporting or analysis. But in reality, that ability doesn’t add value to the product’s primary goal: automating deployments.

    I personally view RavenDB as a better option for a number of reasons, but as your blog post mentioned, installation is a _lot_ better without resorting to SQL Server. Likewise with NancyFX. Honestly, I wouldn’t gain much if at all if Octopus was on IIS as well. The added value of SQL Server and IIS compared to Raven and NancyFX is practically zero to me as an end user. Octopus runs fine without them, so what’s the benefit of using them?

    Obviously, I really like a lot of your design choices. Initially, some of them didn’t seem so clear to me and forced me to rethink my perspective about Octopus, our deployments and how your design choices met our needs. In the end, Octopus has flourished so far and I really haven’t seen any negative outcomes from omitting the usual SQL Server and IIS requirements. If anything, it’s made Octopus better.

    So, rather than just keep gushing over Octopus, I’m just going to keep on writing my articles and hope you’ll get a chance to read them. Thanks so much for your comments!

    Talk about getting carried away.. gah. Sorry!


  1. September 10, 2014

    […] server, you have to specify at least one role for that tentacle. I’ve covered tentacles previously in the Octopus Deploy series. When typing in the role field, you’ll see that you can type anything that you want in […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.