Automated Deployment Based on fabric and Hg

Label FabricHgPython
690 people read comments(0) Collection Report

Automated Deployment

Fabric is a very good use of automated deployment tools, although the function than puppet, saltstack and the like to be weak, but the use of python, and the installation of the server.

Of course you want to say docker better I agree, but I often use FreeBSD, but there are some 32 bit low distribution system, is not suitable for use docker. Not to mention the virtual machine.

The purpose of automated deployment is to simplify the manual deployment of trouble, including the initial installation of the deployment and the deployment of the updated code updates. Initial deployment is the installation of the basic environment, initialization database, etc.. Update the deployment is more trouble, you need to modify the basic environment configuration, change the database structure, etc.. In contrast to the code release and update is the most simple, with a version control tool can be.

I am more accustomed to using Hg code version management, of course, here to change the GIT Hg can also, but I just like Hg, you bite me ah.


Fabric's official website is, the basic usage can look at the official documents, where only a few commonly used to make a simple note.

Installation is very simple, as long as the local PIP installation fabric can, remote as long as there is SSH service can, do not need to install additional things, this than puppet and saltstack and save time.

Use is also very simple, the most critical is the deployment of the script is to use python, compared to ruby with the puppet, it is more in my taste.

The default script file name:, of course, you can also use other names, but it is not convenient to use, similar to the Makefile to use the default make file name is convenient.

Perform default script command: Fab < function name >[<[parameter name: >]] value

One of the functions called in the definition of any function (when the use of @task can only use the decorative device has been decorated with the function), you can also bring parameters. For a specific host or user, you can also add a role to the function of the decorative device.

Examples of running local commands are as follows:

Fabric.api import local from
Deploy_1 def ():
Local ("commit Hg")
Local ("push Hg")
Deploy_1 Fab

Examples of running remote commands are as follows:

Fabric.api import run from
Deploy_2 def ():
Run ("pull Hg")
Run ("update Hg")
Deploy_2 -H hostname_or_ip Fab

Switch to the current directory:

With LCD ("path") # local directory
With CD ("path") # distal

Error handling: any operation that returns a value of 0 will result in an exception, unless...

Settings with (warn_only=True)

And use the.Failed attribute of the command to judge the result of the execution.

Env for the preservation of the relevant configuration environment, such as KEY's SSH file: key_filename, and the list of host names: hosts, role definition: roledefs, etc.

Role of use:

Role1 'env.roledefs={': ["user1@server1:port1", "user2@server2:port2"],
"Role2": "user3@server3:port3"]}
@roles ("role1")
Deploy_3 def ():

Combining fabric and Hg deployment

With a simple web Python application as an example to illustrate.

A complete manual was first deployed broadly include the following (assuming the server system has been installed the necessary software, such as Hg, python, virtualenv, database, webserver, which database and webserver has already been configured, separate virtualenv has been created):

  • Install the necessary dependencies in the virtualenv environment install -r requirements.txt pip
  • Release the code to deploy Hg push ssh://user@host/path [local] [remote] update by Hg; Hg
  • Initialize database
  • Start (by gunicorn, supervisord, etc.)

After the code has been modified to deploy again involves the following:

  • Update dependency package
  • Update code
  • Update database structure
  • Restart service

Taking into account the possible need to deploy to the test environment and the formal environment, but also need to consider the following issues:

  • The test environment and the formal environment involve different configurations (such as different databases, different ports, and even different paths).
  • Must be the version that is tested in a test environment before it can be updated to a formal environment.
  • Formal environment has more strict authority management (development department can not be directly deployed to the formal environment, and even can not contact the formal environment configuration information)

As a result, we need at least two code warehouses: one is the development code library (repo_dev), including the test configuration, and the other is the formal configuration repository (repo_prod).

Then, the basic deploy_dev function of the generally has the following:

Local ("push repo_dev Hg")
CD with ("/target"):
Run ("pull repo_dev Hg")
Run ("update Hg")
Run ("workon venv") # switch to the specified virtualenv
Run ("install -r requirements.txt PIP")
# initialization or update the database structure database
Sudo ("supervisorctl restart XXX") # gunicorn can't with supervisor to restart, discontinued because of the need to wait for a period of time, it is recommended with a kill signal to soft reset

You can configure the remote server specified by the repo_dev to test the host testhost. After the test host is tested, the test part can be deployed to the official prodhost.

CD with ("/prodconf"):
Run ("pull repo_prod Hg")
CD with ("/prod"):
Run ("Hg pull testhost") # update code from the test host
Run ("Hg update Rev") # note, here to update the version specified test
Run ("CP /prodconf/config.") # use formal configuration replacement test configuration
Run ("venv workon")
Run ("install -r requirements.txt PIP")
# update database structure
Sudo ("restart XXX supervisorctl")

This deployment function uses another user role, as long as the control of the role of only the test department has the right to, the development department, even if you accidentally run the deployment function, but also because there is no authority to fail.

Guess you're looking for
View comments
* the above user comments only represent their personal views, does not represent the views or position of the CSDN website
    personal data
    • Visit1216373 times
    • Integral:Fifteen thousand two hundred and thirty-six
    • Grade
    • Rank:349th name
    • Original243
    • Reproduced:0
    • Translation:0
    • Comments:1660 article
    Article Archive
    Latest comments
    2 non technology BLOG