GWW Buildout with Fabric deployment
How to use this buildout
This buildout can be used as a local development buildout and using fabric remote servers can be controlled to deploy buildouts.
Deployment from local buildout
Each environment on testing, acceptance or production has it's own user account. The username of each account contains the name of the environment and the name of the env (tst, acc, prd).
For example; if we have an environment with the name example, three system users are needed: app-example-tst, app-example-acc and app-example-prd.
A Puppet module called puppet-appie can be used to automate the setup of the accounts.
First checkout the library/module which contains the fabric functionality:
git submodule init git submodule update
After the submodule is cloned there should be a
fabric_lib directory with
Create a virtual environment, bootstrap the buildout used for development and run buildout:
virtualenv . python bootstrap.py -c buildout-dvl.cfg ./bin/buildout -c buildout-dvl.cfg
Start the zeo server and run the instance in the foreground:
./bin/zeo start ./bin/instance fg
Configuring remote deployment
The configure remote deployment a server with SSH access is needed. In this example we will deploy a Plone buildout to a cluster.
deployment.py the config for the remote is stored. The following
attributes are used, change the attributes to your needs.
- This number is used to define port numbers for Plone, ZODB server, Varnish caching proxy and the HAProxy load balancer.
- The name of your enviroment, this can be the name of a customer or the name of the Plone site. The environment name is used in the user account, make sure only lower case is used and avoid white spaces.
- This is the id of the Plone site. It is used in the config for the webserver.
- The flying IP address of a cluster, omit this one if no cluster setup is used.
- Configure one ore more servers which are used for remote deployment. Each server has a name and a IP address or a domain name.
- Python eggs or Plone modules which are in own maintenance #TODO improve
- List third party modules which are used from source #TODO improve
- Sets the default enviroment, this is tst (test environment) by default.
Deploy to remote servers
- The attributes in
deployment.pyare changed to your the needs of your environment
- At least one user account with SSH access on the remote server(s), ie. app-example-prd
- Fabric to deploy, it is included in this buildout in the bin directory
- Configure SSH Agent Forwarding, forwarding can be used if you have private repositories. It allows you to use your local SSH keys.
First test if we have a SSH connection to the test environment on the server using:
The layer parameter can be omitted because the test environment is the default:
Each server should return an output similar to the one below:
# ./bin/fab test firstname.lastname@example.org Testing example tst connection for email@example.com [firstname.lastname@example.org] run: hostname ; whoami ; pwd [email@example.com] out: patia [firstname.lastname@example.org] out: app-example-tst [email@example.com] out: /opt/APPS/example/tst
To deploy a buildout run the following command. A deployment will run buildout on
the server(s) defined in the
_servers deployment attribute.
Further reading is in the fabric buildout library fabric_lib.
Migrating from existing buildout templates with DTAP-config. TODO
Make sure you've installed the depencencies which are required by Plone. Use `install.plone.dependencies`_ to install required packages.
When readline is failing because of the following error:
Getting distribution for 'readline'. /usr/bin/ld: cannot find -lncurses collect2: error: ld returned 1 exit status error: Setup script exited with error: command 'gcc' failed with exit status 1
sudo apt-get install libncurses5-dev
When bootstrap.py is failing because of following error:
Update setuptools using:
. ./bin/activate # Make sure we are in a virtual env pip install -U setuptools