Skip to content

Deploying to our servers

rossbruniges edited this page Dec 14, 2012 · 6 revisions

Deployment

We're making heavy use of Fabric and Puppet to automate deployment. Deployment has been tested on a Ubuntu 10.04 box, and puppet recipes will likely fail on later versions of Ubuntu (or any Debian version), and certainly would on RHEL / CentOS systems.

Note that we're using Puppet 0.25, because that's what comes with Ubuntu 10.04. It's old, you'll find a lot of newer recipes and examples out on the web won't run unmodified on it.

Important note - as the deploy pushes new tags to our main github repo you need to have push/pull admin access. This is administered through a github team.

Prequisites

  • A machine set up for local development or at minimum the code checked out (remember the --recursive),
  • dev dependencies installed (run pip install -r requirements/dev.txt from inside the make.mozilla.org repo after creating a virtual env)
  • be able to connect to the Mozilla-MPT VPN,
  • sudo access to the dev/stage/production VMs,
  • your public key in the .ssh/authorized_keys on each server they wish to deploy to,
  • a member of the webmaker-deploy-team github team and
  • the remote for each of development/staging/master branches to be pointing to this (mozilla) repo (see below):
[remote "mozilla"]
    url = git@github.com:mozilla/make.mozilla.org.git

[branch "master"]
    remote = mozilla
    merge = refs/heads/master
[branch "staging"]
    remote = mozilla
    merge = refs/heads/staging
[branch "development"]
    remote = mozilla
    merge = refs/heads/development
```

## Regular deployment

````bash
fab deploy
```

This doesn't run the Migrations. To deploy and run migrations run:

```bash
fab deploy_with_migrations
```

### Deploying to a specific server

The install options are:

* 'development' (default - https://make-dev.mozillalabs.com/)
* 'staging' (staging server - https://make-stage.mozillalabs.com/)
* 'production' (live server - https://webmaker.org/)

As an added safe guard you can also only deploy to each server from their equivalent branches on your local machine. fabric will warn if you try and deploy from the wrong branch to a server it's not already deployed to.

If you're not deploying to the default server (you can change the default on line 21 of `fabfile.py`) then you need to specify which set of hosts to use:

```
TO=production fab deploy
```

If your sudoer's username on the box you're deploying too doesn't match your local username:

```
fab -u remote_username deploy
```

If you need to do both the above mods:

```
TO=production fab -u remote_username deploy
```

Provided there are no bugs in the puppet recipes, running `fab puppet.apply` should only do something if there's a change to apply - it's safe to run multiple times, and even if there are no new changes.

## Updates to Puppet

```bash
fab puppet.apply
```

## Initial setup 

**ONLY DOES THIS ONCE PER VM, it will create a totally new install each time it's run**

```bash
fab puppet.setup
fab puppet.apply
fab deploy.cold
```

`fab puppet.setup` installs the Puppet packages on the box.
`fab puppet.apply` uploads and applies the current puppet recipes. Note that this is not done from Git, but from the deployers working directory, so be careful about uncommitted changes.
`fab deploy.cold` Actually deploys the app, performing first-run setup and running DB migrations.

### Notes on the Puppet setup

The main Puppet manifest is `puppet/manifests/dev.pp`, which in turn includes all the rest of the resources in a single class, then includes that class - puppet then tries to make sure all the resources described in `puppet/manifests/classes/*.pp` are included and brought up to date. If you need to add more things to the Puppet recipes, add them in a file in `puppet/manifests/classes` and then put an include line into `puppet/manifests/dev.pp`

E.g., add resources to `puppet/manifests/classes/my_file.pp` and then, in `dev.pp`:

```
class dev {
  include app_users
  ...
  include my_file
}
```

I don't think this is an entirely standard way of doing things, but it works well with a single-machine single-OS deployment.
Clone this wiki locally