[chef] Re: Re: Re: Re: Re: Re: Re: deploy_revision or Capistrano?

[Daniel DeLeo < >]

The deploy resource can detect a rollback if you set the desired revision to 
a revision that exists in the deploy cache. So you can store the desired 
revision in a data bag item or something and then control the versioning that 
way.  

--  
Daniel DeLeo


On Tuesday, April 28, 2015 at 3:37 PM, Yoshi Spendiff wrote:

> Not really chef related, but if you can get a deploy working there should 
> be nothing stopping a rollback working with cap [stage] deploy:rollback
>  
> For what it's worth we were in a similar position to you but decided we 
> wanted our application deployment separate from our Chef management also, 
> Chef just didn't quite seem flexible enough to do what we wanted with 
> little fuss. We're heading towards using CodeDeploy (we're on AWS) as it 
> lets us pick a build and deploy to any environment, but still on Cap for 
> now.
>  
> On Mon, Apr 27, 2015 at 4:35 PM, niristotle okram 
> <
 
>  
> (mailto:
 )>
>  wrote:
> > Just wanted to bring this thread to closure with what i finally end up 
> > doing.  
> > My desire to deploy codes using the chef's "deploy_revision" from 
> > specific branches of the repo was achieved with the below block
> >  
> > deploy_revision "/opt/mount1/#{node[:application_name]}" do  
> > repo "#{node[:application_repo]}"
> > user "python"
> > revision node.chef_environment
> > keep_releases 10
> > action :deploy
> > migrate false
> > symlink_before_migrate.clear
> > create_dirs_before_symlink
> > purge_before_symlink.clear
> > symlinks.clear
> > symlinks {}
> > notifies :restart, "service[oss]"
> > end
> >  
> >  
> > But i have decided to use capistrano, because i don't think there is a 
> > much flexibility with chef when it comes to roll back. I think i would 
> > have to change the action :deploy to :rollback. then push the change to 
> > chef-server and then perform chef-client. Just too much work!!!
> >  
> > With the cap, i created a jenkins job and use some clicks to perform 
> > deploy. So far, i dont have a job for rollback yet. I have just started 
> > to test the deploy job.. Keeping the fingers crossed
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> > On Wed, Apr 8, 2015 at 6:18 PM, Bill Warner 
> > <
 
> >  
> > (mailto:
 )>
> >  wrote:
> > > I really like having my build system (jenkins) use fpm to create 
> > > packages and upload them to a repository. I maintain different 
> > > repository for dev qa staging and prod and can promote the packages 
> > > through the cycle. Jenkins also controls the deployment to dev and qa 
> > > automagically after successful build/test. As we build confidence we 
> > > may eventually have it deploy to prod as well but still have a lot of 
> > > testing to do.  
> > > -Bill
> > > On Apr 7, 2015 3:20 PM, "Ranjib Dey" 
> > > <
 
> > >  
> > > (mailto:
 )>
> > >  wrote:
> > > > I'll jot down my learning from practicing both chef based as well as 
> > > > cap based deployments extensively:
> > > > Cap:
> > > > Pros:
> > > > 1) Dev centric, you get control the exact order or time of 
> > > > deployments.
> > > > 2) Very easy to adopt for rails and similar projects, UX feels 
> > > > similar to func, but ruby compatible idioms
> > > > 3) Custom deployment strategies, like blue-gree/canary/dark launching 
> > > > etc are lot easier with cap (most of them end up grouping hosts
> > > > Cons:
> > > > 1) Encourages checking in configuration in the code, like all your 
> > > > environment details. This is pain if you environment changes, hosts 
> > > > get added etc
> > > > 2) Since everything is triggered from a central place, the whole 
> > > > process is susceptible to failure of the central node (can be a CI 
> > > > agent, can be a developers laptop)
> > > >  
> > > > Chef:
> > > > pros:
> > > > 1) Same style of deployment as capistrano (symlinks. hooks etc)
> > > > 2) decentralized, pull based. Things will be deployed eventually.
> > > > cons:
> > > > 1) deployment is tied with system changes/rollout
> > > > 2) you cant control the order of deployments (like what if you decide 
> > > > to do the db migration first, on one host, then do canary deployment 
> > > > in a subset etc)
> > > >  
> > > > You can go hybrid, mix n match things, like:
> > > > 1) cap can use chef to search and auto populate the hosts
> > > > 2) deploy via chef can be captured in a separate recipe which can be 
> > > > used in conjunction with the full blown chef run, or just via 
> > > > chef-client -o 'recipe[deploy]'
> > > > 3) you can use blender to orchestrate the chef runs (with or without 
> > > > deployment), this also opens up the possibilty to use serf or other 
> > > > non-ssh based deployment triggers, which works lot better when u have 
> > > > lot of servers, or network is flaky between the trigger point and 
> > > > deployment target host
> > > >  
> > > > Over all, i'll recommend consider you requirement and your team's 
> > > > strength above everything, at the end they are the one who will 
> > > > maintain it
> > > >  
> > > > cheers
> > > > ranjib
> > > >  
> > > >  
> > > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo 
> > > > <
 
> > > >  
> > > > (mailto:
 )>
> > > >  wrote:
> > > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > > > i just noticed 'branch' as an attribute. So, i added the line for 
> > > > > > the branch like this:
> > > > > >  
> > > > > > deploy_revision "/opt/mount/#{node[:application_name]}" do
> > > > > > repo "#{node[:application_repo]}"
> > > > > > user "deployer"
> > > > > > branch "node.chef_environment"
> > > > > > keep_releases 10
> > > > > > action :deploy
> > > > > > migrate false
> > > > > > symlink_before_migrate.clear
> > > > > > create_dirs_before_symlink
> > > > > > purge_before_symlink.clear
> > > > > > symlinks.clear
> > > > > > symlinks {}
> > > > > > notifies :restart, "service[abc]"
> > > > > > end
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > Does this look good and was this attribute designed for this. My 
> > > > > > test nodes are in a freeze state & hence i am unable to test out
> > > > > That will work the way you want.
> > > > >  
> > > > > As for whether you should do code deployments with chef, it’s a 
> > > > > complicated topic. To some degree, your application code and infra 
> > > > > code are coupled, as the point of the infra code is to get you a 
> > > > > system that can correctly run your app code. Since your app code 
> > > > > will have different requirements over time (need different versions 
> > > > > of your VM, supporting libraries, etc.), it makes sense to develop 
> > > > > and publish them together. The downside is that deployment of new 
> > > > > code is harder to orchestrate, since you normally want chef to run 
> > > > > on an interval to ensure your config is up to date. Which means you 
> > > > > need to be okay with deployments happening over a longer timespan, 
> > > > > or add some orchestration component (at small enough scale this can 
> > > > > just be knife ssh) to force chef-client runs to occur. Another 
> > > > > downside is that chef-client runs involve idempotency checks for 
> > > > > all the components beneath your app, which in turn means that your 
> > > > > deploys can fail if your other cookbooks depend on an unrelated 
> > > > > external resource (like an apt mirror or something) that happens to 
> > > > > be down. Also, chef-client will spend time running ohai and doing 
> > > > > idempotency checks on other resources before it deploys your 
> > > > > application, so it will be slower than using a different tool. This 
> > > > > can be mitigated with override run lists, but there are some rough 
> > > > > edges to those.
> > > > >  
> > > > > HTH,
> > > > >  
> > > > > --
> > > > > Daniel DeLeo
> > > >  
> > >  
> >  
> >  
> >  
> >  
> > --  
> > Regards
> > nirish okram  
>  
>  
>  
> --  
> Yoshi Spendiff
> Ops Engineer
> Indochino
> Mobile: +1 778 952 2025
> Email: 
> 
 
>  
> (mailto:
 )