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 blockdeploy_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 < " target="_blank"> > 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" < " target="_blank"> > 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 idioms3) Custom deployment strategies, like blue-gree/canary/dark launching etc are lot easier with cap (most of them end up grouping hostsCons:1) Encourages checking in configuration in the code, like all your environment details. This is pain if you environment changes, hosts get added etc2) 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/rollout2) 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 hosts2) 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 hostOver all, i'll recommend consider you requirement and your team's strength above everything, at the end they are the one who will maintain itcheersranjibOn Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo < " target="_blank"> > 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
Archive powered by MHonArc 2.6.16.