The documentation describes this procedure under the Note for Remote SQL Server Instances, but for whatever reason (most likely the Network Service account didn’t have permissions to my non-express SQL 2012 database) I had to do it even though I was using a local install. The first was that I had to use a different service user for the Octopus Windows Service that got installed, and the user of the Octopus Portal application pool that it created in IIS.
#OCROPUS WINDOWS INSTALLER INSTALL#
There were a couple of minor things I had to do that weren’t as simple as clicking through the install wizard, however. I just followed the steps under the “Installation” section on the Installing Octopus page. So now I finally had a VM setup and ready to go. Moving back to installing Octopus again, everything now went pretty easily. Since SQL Server 2012 recently came out and I haven’t had much hands-on time with it yet, I decided to use that, and installed a local copy on the VM. It isn’t currently specified in the docs (at least not that I could see) which versions it would run against, but it did say that it could use SQL Express, and provided a link to SQL Express 2008 R2. Octopus requires a Microsoft SQL Server database. Net Framework 4, running %WinDir%\Microsoft.NET\Framework\v9\aspnet_regiis.exe -i to make sure IIS had the root bound to the 4.0 Framework, I was nearly ready to go. Then after installing SP1, going through a couple of passes in the Server Manager to add all of the listed Roles and Features, installing the.
Deciding to read some more docs and see what else might be missing, I found the requirements on the Installing Octopus page and pored over them for a bit. I was met, however, with a nice message indicating that Win2K8 R2 SP1 was needed before I could proceed. I wanted to make a dedicated VM for this and, since I have a background that is primarily ‘softie in nature, I fired up a VM in Hyper V and installed Windows Server 2008 R2.Įxcited and eager to get going after waiting 200 years for my VM install to finish, I blindly tried to run the central server installation. I decided to start by setting up the central server. The Octopus orchestrates things, and the Tentacles (which are to be installed on every deploy location) are responsible for receiving install packages, extracting them, putting them in the correct locations, and executing other commands sent out by the central server. Still in beta (and consequently free) at the time of this post, I decided that I would see how hard it would be for me to use Octopus to deploy a really simple project.Īfter reading through the Octopus installation guide, I learned that Octopus (the deployment tool suite) was made up of two parts – a central server (also sometimes referred to as just “Octopus”), and a number of remote agents called “Tentacles”. Recently, awesome blogger and DBA Rob Sullivan mentioned over lunch that he was using it, and my interest was again sparked. Unfortunately, I never got around to actually doing anything with it after it became usable. One of the tools that I watched a bit during its infancy was the Octopus deployment tool.
0 kommentar(er)
