Recently we came across disk space issues on our main Octopus server. The dev team were wondering why this happens; if the build tool (TeamCity in our case) is the one that pushes packages to the Octopus server, why is the disk full error appearing on Octopus when a release is deployed?
That got me thinking: how does the deployment actually work? Does Octopus first unpack the zip inside the Octopus server and then push the files to the app server? That would explain the disk getting full during a deployment. But isn’t that inefficient use of space? Wouldn’t it be cleaner to push the zip to the app server, unpack it there (assuming the right permissions are granted of course), and delete the zip once unpacking was successful?
Also, if there are pages on the Octopus documentation where I can read more about this process, it would be great if you could point me towards them.
What I suspect is happening here is a combination of a few different settings/options, but first I’ll give you a bit of an overview as to how a package flows through Octopus.
As you can see, by default, packages go from your build server (Teamcity in this case), to Octopus then from your Octopus Server to your Tentacles.
In your scenario the first thing I would check is how you are feeding packages into Octopus. Are you pushing them from Teamcity to the Octopus built in package feed, or is Octopus pulling from Teamcity as an external feed? We have docs available which should help you determine how you have it configured.
If you are pushing to the built in Octopus feed the next step I would be looking at is your package retention policy. This defines how many versions of a given package is stored in your Octopus instance, or how long they are stored for.
If, however, you have Octopus configured to use TeamCity as an external feed the next option I would be looking for is a combination of release retention and setting a variable that allows you Tentacles to pull packages directly from your TeamCity feed. This can be done by setting Octopus.Action.Package.DownloadOnTentacle to TRUE for each project where you want the Tentacle to download the package directly.
As your going I would also check you Tentacle retention policies (same location in Octopus as the release retention) to make sure you are cleaning up your endpoints correctly.
I’m hoping that helps with what you need to know, if you have any follow up questions please let me know.
Thank you very much for the quick summary! We do push packages to Octopus from TeamCity. We should be able to modify the retention policy to clean up the disk more quickly. I will explore this more and get back in case I have more questions.
