78 lines
3.4 KiB
ReStructuredText
78 lines
3.4 KiB
ReStructuredText
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 it’s 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 don’t 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
|
||
|
||
|
||
Links
|
||
^^^^^
|
||
|
||
* http://puppetlabs.com/blog/a-deployment-pipeline-for-infrastructure/
|
||
* http://docs.puppetlabs.com/guides/environment.html
|