Running the Server in the Cloud
The Amazon EC2 instance we created and used as a reverse proxy in Chapter 3, Using the Cloud to Connect, can also make an excellent general-purpose pair-programming environment. It’s easily accessible by both parties, and the instances can be stood up and torn down almost as easily as with Vagrant. We can even use the same Puppet scripts.
The scripts we wrote for Vagrant need one little tweak before we can run them in the cloud. Our scripts assume the presence of a vagrant user, but on EC2 this will be an ubuntu user. To fix this, replace the first line in the site.pp file with this code:
| pairing-server/puppet/manifests/site.pp | |
| | case $::virtual { |
| | 'virtualbox' : { |
| | $username = "vagrant" |
| | } |
| | default : { |
| | $username = "ubuntu" |
| | } |
| | } |
This conditional statement checks the platform the scripts are running on before setting the $username variable. Now we’re ready to deploy the scripts to the cloud.
We’ll package our puppet scripts into a zip file so we can deploy them in one step. If the zip program is installed on our Mac or Linux systems, we can run this command from the directory with the Vagrant configuration.
| | $ zip -r puppet puppet/ |
If you’re on Windows you’ll need to open Windows Explorer, locate the puppet directory, right-click, and choose Send To -> Compressed (Zipped) Folder.
Now we can transfer the archive to our EC2 server. Because we already have SSH access, we can do this on Linux and Mac with the scp program by running the following command.
| | $ scp -i ~/.ssh/amazon.pem puppet.zip |
| | > [email protected]:~ |
On Windows, you’ll need to install WinSCP; download it from the official site and run the executable.[74] You can also use PuTTY and the pscp command with the same arguments shown in the scp command earlier.
The -i flag, as you’ll remember from Chapter 3, Using the Cloud to Connect, instructs the SSH command to use the amazon.pem key file, which the server uses to authenticate us. Next, we’ll log into the EC2 server like this:
| | $ ssh -i ~/.ssh/amazon.pem |
| |
Now we see the ubuntu@domU-0-0-0-0:~ $ prompt again, which means we’re logged into the server.
Cloning the Fulcrum repository doesn’t require an SSH key, but if the application you’re working on in the future requires one, this would be a good time to create and register it with the server hosting your Git repository. To create the key, run this command, use the default file location, and enter a password.
| | ubuntu@domU-0-0-0-0:~ $ ssh-keygen -t rsa -C "[email protected]" |
| | Generating public/private rsa key pair. |
| | Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): [Press enter] |
| | Enter passphrase (empty for no passphrase): [Type a passphrase] |
| | Enter same passphrase again: [Type passphrase again] |
| | Your identification has been saved in /home/ubuntu/.ssh/id_rsa. |
| | Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub. |
| | The key fingerprint is: |
| | 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 [email protected] |
An id_rsa.pub file was created in the ~/.ssh directory. You can upload this to your Git server. We’ll continue without this step because we won’t be pushing our changes to the Fulcrum repository.
Next, we’ll update the package manager and install two packages needed to run our puppet scripts, like this:
| | ubuntu@domU-0-0-0-0:~ $ sudo apt-get update |
| | ubuntu@domU-0-0-0-0:~ $ sudo apt-get install zip puppet-common |
The first command updates the local list of package versions, and the second command installs an up-to-date version of the two dependencies. The zip package is a tool for unzipping the puppet.zip file, and puppet-common is the program to run them. We can do the unzipping like so:
| | ubuntu@domU-0-0-0-0:~ $ unzip puppet.zip |
This creates a puppet directory with the decompressing scripts. Now we must switch to root mode and move into the new directory, like so:
| | ubuntu@domU-0-0-0-0:~ $ sudo -i |
| | root@domU-0-0-0-0:~ $ cd /home/ubuntu/puppet |
Be careful of the commands you enter in this mode. You can cause a great deal of damage as root. Let’s do what we need to do and get out. Enter the following command to run the puppet scripts.
| | root@domU-0-0-0-0:/home/ubuntu/puppet $ puppet apply |
| | > --modulepath=modules manifests/site.pp |
Our configuration has been applied, and we can exit root mode.
| | root@domU-0-0-0-0:/home/ubuntu/puppet $ exit |
| | ubuntu@domU-0-0-0-0:~ $ |
We’re ready to start pair-programming. All you need to do is create a tmux session, and find a partner to join you.
You probably won’t want to run these steps every time you pair with someone. That’s why it’s helpful to capture an image of this EC2 instance in its current state. You can do this from the EC2 dashboard by selecting your instance, opening the Actions dialog at the top of the screen, and selecting Create Image (EBS AMI). The next time you need a new instance, select Launch Instance and, from the My AMIs tab, choose the image you created.
However, it’s perfectly acceptable to leave your pairing server running, or provision it from Puppet scripts each time you start a session. This makes sense if your configuration will change often or if the cost of managing Amazon images is greater than the time it takes to run the Puppet scripts. As with everything else, it depends on the people, processes, and technologies in your organization.