I have an offline package deployment that deploys a package and creates a windows scheduled task. It runs fine on my local computer, but fails to resolve the variable #{Octopus.Action[OsloVavAreaChangeImporter].Output.Package.InstallationDirectoryPath}\ISY.Proaktiv.OsloVavAreaChangeImpoter.exe
This variable refers to the previous process step to get the path for the .exe to use when setting up the scheduled task. Om my computer, this path is resolved as expected, but when deployed on the actual server, the variable is not evaluated, and the scheduled task is created with “#{Octopus.Action[OsloVavAreaChangeImporter].Output.Package.InstallationDirectoryPath}\ISY.Proaktiv.OsloVavAreaChangeImpoter.exe” as the action-path.
Are there any prerequisites to deploying offline packages other than copying the packagefolder and executing the cmd-file? All other steps of the deployment runs correctly. The cmd-file is run from a commandprompt with admin privileges.
Would it be possible to work around this using a polling tentacle instead of an offline package?
Untill now, I’ve only used Octopus to deploy to severs in our local network, and our octopus server is installed in our LAN. To be able to use polling tentacles, I need to enable clients to connect to our Octopus server.
Is it possible to “just move” the server from our LAN to our DMZ. This would result in the server having a new ip-adress? How would the Octpous config handle this?
Or could I set up a reverse proxy to forward requests from the polling tentacles to our DMZ and to the octopus server in our LAN? In that case, which ports must be forwarded? 443 and 10943?
Offline deployments are best suited for scenarios where you cannot install a tentacle on the machine you are deploying to. If you can install a tentacle then that is the recommended approach.
A polling tentacle will have to contact the server. However can you set up a listening tentacle instead? That way the server has to be able to contact the target, but the target doesn’t have to be aware of the server at all.
We are hoping to use this approach for about 80-100 clients.
We are hoping to avoid having them to open up for incoming request, as this would complicate the installation a lot.
Ultimately offline drops are our least preferred solution because they have numerous problems including less than full support for variables, lack of feedback, etc.