Configuring Deployment Server(s)


Now that we've looked at what Deployer is, its directory structure, and installed it, it's time to start configuring our setup, so that we can get ready to run a deployment on our code.

The Main Configuration File

Deployer looks for a file in the current working directory called deployer.php.

At its simplest, it's nothing more than a PHP file which contains the configuration Deployer will need to know where, and how to deploy.

Conceptually, you can break this down in to several parts.

Firstly, you setup the servers which can be deployed to, whether local, remote, or both.

Then you have runtime settings, such as the code repository, and number of releases to keep (for rollbacks).

Then you have the task configuration.

You don't need to add in custom tasks, as you can make use of a range of in-built ones. But if you need to, which may often be the case, you can add them.

Then you configure your core deployment task, which can be either a custom task itself, or the composition of one or more existing tasks. After that you specify any hooks which run either before or after a task, such as a notice to say that the deployment's done, or reloading Apache or Nginx.

Now, let's step through up until the server settings.

In the next lesson, we'll pick up with creating and configuring tasks.

Setting Up Your Server Configuration

Firstly, we need to include the composer autoload script, which is common place today.

Then I'll include an existing recipe. As I hinted at earlier, a recipe is, essentially, a set of existing tasks, based around a particular use-case.

In this case, the composer recipe is a simple set of tasks which could be expected to be needed in a simple, composer-based application. It includes running composer, creating directories, creating symlinks and so on. Perfect for my simple application.

The manual indicates that, in time, there will be recipes for a number of the major PHP frameworks, Zend Framework, Yii and Laravel. Fortunately, a basic Symfony recipe is already in place.

Local Server

In my simple scenario, I'm creating one local server, which will be my local testing copy of the application, and one remote server, for production.

First I'll create the local server configuration, mainly as it's the simplest.

I'll do that by calling the localServer(), giving it a name, that being testing.

Then, using the available fluent interface, I'll specify the user to use, which is my local user account, the stage name, testing, and then set an environment variable, which is the deployment path, by specifying the key of 'deploy_path', and the key to the path to deploy the files to.

I don't need a special configuration in this case, so one environment variable's enough. But if you need other environment variables, then add more calls to env(), as required.

Remote Server

Now let's setup the remote server.

As it's remote, it'll require some authentication to obtain access.

User Credentials

Similar to localServer(), this time, to work on a remote server (which can be a virtual machine), I'll call server(), passing in the name, hostname or IP address, and the port.

After that, I'll specify the user and password credentials, the stage, and the deployment path, as before.

SSH Keys

Nice and simple right?

Deploying to this host, Deployer would login to 192.168.10.10, using the credentials of vagrant/vagrant and deploy to /home/vagrant/deployer.

But what if you're working with a host such as Digital Ocean, which uses SSH keys? Then you're going to need a slightly different approach.

In that case, remove the call to password, replacing it with a call to identityFile().

What this does is to make use of your ssh public and private keys during the authentication process. I'll assume that, if you need to take this approach, that you've already setup your public key on your remote host, after creating them locally.

Assuming that your ssh keys are stored in the default location of .ssh, then you don't need to pass anything to the method. If they're not, or you want to be specific, you can pass to the method, firstly your public key path, then your private key path, then the pass phrase, if required.

To learn about public keys, and generating them, check out this post from GitHub.

SSH Config Files

Now using SSH keys is better than specifying credentials, as it's more secure.

But what about adding a bit of extra simplicity and avoiding code?

If that's what you're keen on, then you have two options.

You can either use an ssh config file, or a Server config file.

An ssh config file is a little outside the scope of this series, but in essence, is a way of specifying how to work with a server. Take the following example

Host dev
    HostName dev.example.com
    Port 22000
    User fooey

This file specifies that when an attempt is made to connect to dev.example.com, to connect on port 22000 and provide the username of fooey.

If that sounds like a good approach, or one which you're required to use, you can find out more about them in this great post from Joël Perras.

***To use them, remove the calls to the pass, and identityFile() method, instead making a call to configFile(), passing the path to your SSH config file.

 Server Config Files

Now let's look at one more option, a server file. This allows us to specify all of the options outside of code, which can often time be a good thing.

Have a look at the following example:

prod:
  host: domain.com
  user: www
  identity_file: ~
  stage: production
  deploy_path: /home/www/

Using the YAML file format, this provides all of the details we've seen so far; those being the environment, hostname, user, whether to use an identity file or not, and the deployment path. Personally I quite like this approach, as I find it neater and simpler.

To use it, once the file's created, in deploy.php, I'll add a call to serverList(), passing the name of the configuration file.

Then, in my server configuration, I only need to make a call to stage(). The configuration file handles the rest.

There is one final option, which is a PEM file. But I'm not covering that in this series.

Episodes

# Title Duration
1 Introduction to Deployer 04:41
2 Installing Deployer 05:17
3 Configuring Deployment Server(s) 07:14
4 Deployer Settings 06:43
5 Running Your First Deployer Deploy 04:53