English is not my native language, please be tolerant
We are currently reviewing Octopus as the core deployment tool for our company, and while things fits and clings perfectly when we are talking about Windows deployment and C# (looking at Octopusās history, this was expected), things look different when reviewing Linux and especially AIX.
Our main issue is that thereās a dependency to Mono for the tentacle to be running. While this may not be such a huge issue on Linux environment, it is on AIX - Mono doesnāt support AIX. We could probably get it running using some effort, but the fact it is not supported rules it out of the equation immediatly in our environment (architects and security people wonāt let that happen).
We thus have two options left :
Deploy to a Windows machine, which will launch the deployment using a SSH script on AIX. Iām not that confident in that, seems way too complicated and kind of defeats the idea of a ācentralizedā deployment solution.
Have a tentacle running on AIX without any support for Mono
Iāve seen you separated Calamari from the tentacles, so, according to your documentation, tentacles arenāt āsmartā anymore.
Finally, to our question : Is there any documentation (or even source code, i may be dreaming here) to the network API and requirements for a tentacle to successfully register and answer Octopusās calls ? If tentacles really arenāt āsmartā anymore, we could develop one, perhaps simplified at first, that would suit our needs.
I found the following page http://docs.octopusdeploy.com/display/OD/SSH+Targets , related to SSH targets, which seems to indicate that you can bypass the whole tentacle part and use SSH to talk to the machine.
So the last thing we need would be to rewrite Calamari without any support for Mono.
I read that it is possible to do so, especially since the source code is available. If you have any insight on the complexity of the task, that would be greatly appreciated !
Thanks for getting in touch! Your English was great. Calamari itself is the part that relies on mono more than the Tentacle and itās communication.
Calamari is open source. We are planning to convert Calamari to .NET core, but have no hard date or estimation of when. This would remove the Mono dependency.
That all being said, Rob one of our devs recently did play with allowing SSH connections to run scripts that do not use Calamari or Mono. Just scripts to the SSH connection.
We are willing to give you a special build of this to have a test/play with. But it doesnāt have the feature set that our Clamari deployments do, it just runs scripts. So you would have to write a lot of the scripts yourself.
Also this is not a fully qualified and tested feature just a concept that was made for demonstration purposes. We can give you a build off our main branch now that includes this feature if you would like to try it. Everything else is stable, but that feature is not production ready. Also note that this also will not copy any packages across, they would have to be scripted or exist on the destination server. The unpack would also have to be scripted.
Let me know what you think and if you would like to trial with it.
Iām personally eager to toy with .Net core, but that wonāt solve our AIX problem, as Core wonāt be supported either on this platform. We will still run into the same issue as Mono : not being able to run Calamari on this OS.
Iām really happy to read that you have worked on this topic internally. Iām tempted to give a shot to my initial idea first : work on building a calamari - capable console application (even if really crippled in terms of features at first), without any mono links.
Correct my if Iām wrong, but if iām able to produce such a binary, everything will be handled out of the box by Octopus, from transferring the package over to the target system to installing it, using your SSH target feature.
We will build an internal POC system in the upcoming weeks to see if Octopus fill our needs before going on with the purchase - i intend to work a few days on such a calamari script to see if it is possible.
If it fails, iāll be really interested in testing the version you proposed - what would be the best way to contact you to get this version ?
I donāt think this will work as you think it may. Calamari is dependant on Mono as many of the third party libraries we use are dependant on Mono, and even if it moved to .NET core it would be the same as there is little we run that will get around this, including the file transfer.
You are welcome to see what you can come up with as it is OSS it is just something we also could not consider to do everything in the same way apart from simply running scripts.
We can try to help and guide, and you might see it very different to how we do.
When and if you want to test our script only version I can give you a link to download the build.
I will get back to you on this topic soon, as iāll work on a proof of concept starting from next week. Just give me a few weeks and iāll let you know.
My goal is not to port the existing Calamari source code from Mono to something else, especially since Mono ( or in the future .NET core) is the sole solution to getting that particular code to run on Linux/Unix OS, and those technologies cannot be used in our environment.
My goal is to rewrite (albeit a simple one first, limited in its features) Calamari, having access to its core through the existing source code, so that i can implement a new Calamari, using a different language, without any dependency. I can then instruct Octopus to use that particular calamari for our Linux/AIX instances. Iāll look into the most suitable solution, i was thinking of using a shell script at first, but it can be done for sure using C or C++.
This would make Octopus fully AIX compliant (one more platform supported for you !).
We have budgeted a few days of R&D (what a big word for something really simple) on that already, and iāll make sure you know the outcome.
We got started in our testing, and i have seen the inner workings of Octopus on Linux using SSH targets. I fully understand now what you were referring to by the custom distribution.
It wonāt be necessary as i found a way to use the standard SSH target process and launch a custom program instead of launching Calamari. Using a shell script, i was capable of unpacking Octopusās package and outputting it into a custom directory taken from the variables. The rest is then confirmed : it is doable.
It would perhaps require a few changes in Octopus : right now, the procedure used by Octopus involve a hard-coded dependancy to mono (in the health check and in the deploy - undeploy package). To support mono-less environments, that would have to be ruled out. Making the scripts editable is a solution (as you did in your custom solution), another one is being able to edit only the line invoking the deploy/undeploy (and health check). Both seems good to me.
Another quirk is that i didnāt find any way to customize Calamari for a particular OS. Especially, what would be great is to be able to configure a calamari to use per deploy target. I found a workaround, but Iām not dwelving into the details on purpose, as I donāt know if this is a proper place to talk about it. If you want to know more, contact me by email
Now, is a shell script sufficient, or should i move on to a higher level language ( parsing Json in a shell script is complicated, furthermore to cover all the functionality in Calamari it would get quite huge) is another question that popped up. For our needs, a Shell script would probably be enough, but if you want to leverage on it and make a fully fledged, mono-less Calamari, a shell script would end up hugeā¦ and its maintainability would be questionable at best.
Our POC has been successfull and we could deploy a sample application using Octopus on a CentOS distribution without any dependency to Mono.
The logic relies on a small batch file, that right now does 3 different things :
Unpack the package in the custom directory (found in the variables file)
Replace variables ( Replace every occurence of #{TEST} in specific files by its value found in the variables.json file if it is enabled)
execute a post deploy script if it is found
It all executes under an Octopus specific account.
This validates our POC. However, for Linux, this relies on a rather dirty hack to launch my custom intelligence that i cannot promote to production systems.
Iād like to contact you before concluding this POC, as iād like to give visibility to the people that can decide purchasing Octopus, on wether this would be feasible in the near future, or not.
Iām sending a contact email using my work email so that we can get in touch.
