A talk about methods and tools to automate deployment of Plone sites. With a few steps an environment is prepared for a new Plone site on a test, staging or production layer. These steps take a couple of minutes, doing this manually took around one hour.
We use Puppet to prepare our hosts/clusters to get an environment to deploy to. Fabric is used to deploy Plone on this environment and to extend the webserver configuration under the hood. These complementary techniques provide a complete solution to get a working Plone site, including rollbacks.
Presentation by: Pawel Lewicki and Kim Chee Leong
CHEAP Call Girls in Pushp Vihar (-DELHI )🔝 9953056974🔝(=)/CALL GIRLS SERVICE
Plone deployment made easy
1. Plone deployment
made easy
Pawel Lewicki
Kim Chee Leong
Goldmund, Wyldebeast & Wunderliebe
{ lewicki, leong } @gw20e.com
2. Outline
● From manual to automatic deployment
● How Puppet and Fabric are used for
deployment
● Deployment demo in screencast
● Puppet server orchestration
● Fabric in detail
3. From manual to
automatic deployment
our path to automatic deployment
4. Typical Plone release
@GWW
● Mark eggs/modules using git tag
● Update mr developer sources with tag
● SSH to server
● Clone new buildout in releases directory
● Bootstrap buildout and execute
● Switch previous release to new release
● If on a cluster set-up, rinse and repeat
5. Plone release @GWW
using Fabric
● All previous steps in one Fabric script
● Allows ‘dummy-proof’ releases
Run:
fab make_tag
fab deploy
fab switch
And Bob is your uncle!
7. Why automatic
deployment?
● Avoid repetitive tasks
● Error-proof
● Immune to typo’s
● Consistent environments
● Time efficient
8. Why automatic
deployment?
● Avoid repetitive tasks
● Error-proof
● Immune to typo’s
● Consistent environments
● Time efficient
nothing* should be done manually
on the server
10. Initial server setup with
Puppet
● Puppet is used for server orchestration
● Puppet prepares the servers
● When Puppet is done, Fabric is used to
deploy buildouts
12. Buildout deployment with
Fabric
● Uses tst, acc and prd layers
● Knows configuration for buildout
● Deploys and runs buildouts
● Does several other tasks
17. Puppet tasks
● User accounts for TAP environments:
o app-mysite-prd in /opt/APPS/mysite/prd
o app-mysite-acc in /opt/APPS/mysite/acc
o app-mysite-tst in /opt/APPS/mysite/tst
● Webserver config is mapped to each
application user
$ cat /etc/apache2/sites-enabled/zzz-app-mysite-prd
Include /opt/APPS/mysite/prd/sites-enabled/
● SSH Keys of developers are synced
● Buildout cache is enabled
19. Plone Fabric features
● Automatic deployment
● Push buildout config using jinja templates
● Extended TAP-layers
● Switching between releases
● But also; supports git branches, virtual host
for webserver, copying zodb to local
buildout.
20. Release switch using
Fabric
1. Update current symlink
rm -f ~/current
ln -s ~/releases/20141028 ~/current
1. Start supervisor daemon in new buildout
~/releases/20141028/bin/supervisord
1. For each service in supervisor:
a. Stop service in old buildout
b. Start service in new buildout
2. Shutdown supervisor in old buildout
~/releases/20130101/bin/supervisorctl shutdown
21. ● Fabric is controlled from the local buildout:
./bin/fab -l
Available commands:
deploy Create new buildout in release dir
switch Switch supervisor to latest buildout
test Test if the connection is working
● Deploying to test environment:
./bin/fab deploy:layer=tst,branch=new-feature
In this talk we’ll explain how we automated the deployment of Plone sites and which tools are used.
Gradually we made the moved from manual deployment to automatic.
Shared experience with Django deployments
Ask who deploys Plone buildouts for a customer, company or organisation?
First explain how our typical Plone setup looks like.
Collection of building blocks, based on best practices.
We have ours, you probably have yours.
Cluster, buildout-template with varnish and TAP
What is a release?
Modules with specific functionality, such as content/theme
Mr developer specific from prd env
In the past we used eggs
Explain how we used the release checklist/procedure at our customer
This is much easier :]
Ofcourse first release on test and acc, too weed out possible problems
Accurate depiction
Start automating tasks you’re familiar with
Releases are not happening often! Possibly mention release calendar
Repetitive tasks: it easy to mess up when doing a rep. task
Error-proof: you should have encountered possible errors on tst and acc
Typo’s and consistent env: with automatic deployment. naming git tags and dirs is done for you. manual..
Time efficient: in the long run you’ll save time
next slide contains “nothing* should be done manually on the server”
nothing should be done using SSH shell except for debugging purposes
Fabric is the base of our automatic deployment, but there is more… (ba dum tss)
Puppet is one way todo server orchestration, Chef and Ansible are popular tools.
Also used to setup server monitoring and do system upgrades
Written in Ruby, reasonable easy to write modules. Many modules available.
No SSH login, uses separate agen
Agents update periodalcialy
Why are we using seperate user accounts?
Webserver config is managable
Buildout cache is enabled per user
Explain why Puppet should not be used to deploy buildouts. It should be explicit.
Use SSH forward agent to git clone repositories on remote server
Why are we using seperate user accounts?
Webserver config is managable
Buildout cache is enabled per user
What is missing here?
Why are we using seperate user accounts?
Webserver config is managable
Buildout cache is enabled per user
Also explain why Puppet should not be used to deploy buildouts
Also explain why Puppet should not be used to deploy buildouts
Supervisor is socket based
Explain production setup; three tier architecure
fe with apache, varnish and haproxy
be with ZODB