fuel-library/docs/pages/production-considerations/0020-deployment-pipeline.rst

3.4 KiB
Raw Blame History

Redeploying an environment

Because Puppet is additive only, there is no ability to revert changes as you would in a typical application deployment. If a change needs to be backed out, you must explicitly add a configuration to reverse it, check this configuration in, and promote it to production using the pipeline. This means that if a breaking change did get deployed into production, typically a manual fix was applied, with the proper fix subsequently checked into version control.

Fuel combines the ability to isolate code changes while developing with minimizing the headaches associated with maintaining multiple environments serviced by one puppet server by creating environments

Environments

Puppet supports putting nodes into separate 'environments'. These environments can map cleanly to your development, QA and production life cycles, so its a way to hand out different code to different nodes.

  • On the Master/Server Node

    The Puppet Master tries to find modules using its modulepath setting, which is typically something like /etc/puppet/modules. You usually just set this value once in your /etc/puppet/puppet.conf. Environments expand on this idea and give you the ability to use different settings for different environments.

    For example, you can specify several search paths. The following example dynamically sets the modulepath so Puppet will check a per-environment folder for a module before serving it from the main set:

    [master]
      modulepath = $confdir/$environment/modules:$confdir/modules
    
    [production]
      manifest   = $confdir/manifests/site.pp
    
    [development]
      manifest   = $confdir/$environment/manifests/site.pp
  • On the Agent Node

    Once the agent node makes a request, the Puppet Master gets informed of its environment. If you dont specify an environment, the agent uses the default production environment.

    To set an environment agent-side, just specify the environment setting in the [agent] block of puppet.conf:

    [agent]
      environment = development

Deployment pipeline

  • Deploy

    In order to deploy multiple environments that don't interfere with each other, you should specify the $deployment_id option in /etc/puppet/manifests/site.pp. It should be an even integer value in the range of 2-254.

    This value is used in dynamic environment-based tag generation. Fuel also apply that tag globally to all resources on each node. It is also used for the keepalived daemon, which evaluates a unique virtual_router_id.

  • Clean/Revert

    At this stage you just need to make sure the environment has the original/virgin state.

  • Puppet node deactivate

    This will ensure that any resources exported by that node will stop appearing in the catalogs served to the agent nodes:

    puppet node deactivate <node>

    where <node> is the fully qualified domain name as seen in puppet cert list --all.

    You can deactivate nodes manually one by one, or execute the following command to automatically deactivate all nodes:

    cert list --all | awk '! /DNS:puppet/ { gsub(/"/, "", $2); print $2}' | xargs puppet node deactivate
  • Redeploy

    Fire up the puppet agent again to apply a desired node configuration