deploy_revision or Capistrano?

Chef Infra (archive)
1

I am using the chef resource “deploy_revision” to deploy a python code on
my nodes. I started this initially for a dev enviroment but now slowly
there is a need for this to expand and i am not sure - if this is a good
choice. Below is the simple code.

data_bag = Chef::EncryptedDataBagItem.load("#{node.chef_environment}",
"#{node.chef_environment}")

deploy_revision “/opt/mount/#{node[:application_name]}” do
repo "#{node[:application_repo]}"
user "deployer"
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

Its pulls down the new code whenever there is one, during the automatic
chef-run at happen every 30mins on the nodes. This is cool but not so cool
in other nodes which are not a part of the developement enviroment. I have
4 enviroments:
dev
test
stage
prod

If i create 4 remote branches on the git, Is there a way on how to make
this deploy from specific branch on specific environments? Something like,
the dev nodes deploy the dev remote branch, test deploys the test remote
branch and so on… This way, i can put a gate on the auto deploys that
happening every 30mins. i referred the chef docs, there is this
"deploy_branch" but i not sure it just says its the same as
"deploy_revision"
https://docs.chef.io/resource_deploy.html#layout-modifiers

If you guys, think deployment using chef is not a good idea. Do you think-
i should look out for Capistrano?

2

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

On Tue, Apr 7, 2015 at 1:21 PM, niristotle okram nirish.okram@gmail.com
wrote:

I am using the chef resource "deploy_revision" to deploy a python code on
my nodes. I started this initially for a dev enviroment but now slowly
there is a need for this to expand and i am not sure - if this is a good
choice. Below is the simple code.

data_bag = Chef::EncryptedDataBagItem.load("#{node.chef_environment}",
"#{node.chef_environment}")

deploy_revision "/opt/mount/#{node[:application_name]}" do
repo "#{node[:application_repo]}"
user "deployer"
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

Its pulls down the new code whenever there is one, during the automatic
chef-run at happen every 30mins on the nodes. This is cool but not so cool
in other nodes which are not a part of the developement enviroment. I have
4 enviroments:
dev
test
stage
prod

If i create 4 remote branches on the git, Is there a way on how to make
this deploy from specific branch on specific environments? Something like,
the dev nodes deploy the dev remote branch, test deploys the test remote
branch and so on.. This way, i can put a gate on the auto deploys that
happening every 30mins. i referred the chef docs, there is this
"deploy_branch" but i not sure it just says its the same as
"deploy_revision"
https://docs.chef.io/resource_deploy.html#layout-modifiers

If you guys, think deployment using chef is not a good idea. Do you think-
i should look out for Capistrano?

--
Regards
nirish okram

3

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

4

I suggest using chef to pre-deploy new code to a versioned path, and then
you can use cap or such to handle snapping correct symlinks and service
restarts in an orchestrated fashion. That's actually how I handle updates
to most of our Atlassian services, so that I can ensure I take a mysqldump
and vmware snapshot first.
On Apr 7, 2015 1:51 PM, "Daniel DeLeo" dan@kallistec.com 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

5

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:
  4. Encourages checking in configuration in the code, like all your
    environment details. This is pain if you environment changes, hosts get
    added etc
  5. 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:
  3. deployment is tied with system changes/rollout
  4. 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 dan@kallistec.com 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

6

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am trying to
make "deploy_revision" to deploy the codes from the specific remote branch
to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the 'dev'
branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in par
with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same on
dev, stage and prod .. while test have a different version. The deploy job
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com 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

7

You should either remove the quotes around node.chef_environment, or
string-ize it as "#{node.chef_environment}". Putting quotes around it but
not string-izing it just leads to it being interpreted literally.

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram nirish.okram@gmail.com
wrote:

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am trying to
make "deploy_revision" to deploy the codes from the specific remote
branch to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the 'dev'
branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in par
with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same on
dev, stage and prod .. while test have a different version. The deploy job
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com 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

8

oops sorry, i had corrected while i was committing the code. This is what i
have and which is not working

deploy_revision "/opt/mount1/#{node[:application_name]}" do

repo "#{node[:application_repo]}"

user "python"

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[oss]"

end

On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne stormerider@gmail.com
wrote:

You should either remove the quotes around node.chef_environment, or
string-ize it as "#{node.chef_environment}". Putting quotes around it but
not string-izing it just leads to it being interpreted literally.

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram nirish.okram@gmail.com
wrote:

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am trying
to make "deploy_revision" to deploy the codes from the specific remote
branch to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the 'dev'
branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in par
with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same on
dev, stage and prod .. while test have a different version. The deploy job
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com 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

--
Regards
nirish okram

9

And what does chef-client -l info show around that resource?

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram nirish.okram@gmail.com
wrote:

oops sorry, i had corrected while i was committing the code. This is what
i have and which is not working

deploy_revision "/opt/mount1/#{node[:application_name]}" do

repo "#{node[:application_repo]}"

user "python"

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[oss]"

end

On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne <stormerider@gmail.com

wrote:

You should either remove the quotes around node.chef_environment, or
string-ize it as "#{node.chef_environment}". Putting quotes around it but
not string-izing it just leads to it being interpreted literally.

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram <nirish.okram@gmail.com

wrote:

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am trying
to make "deploy_revision" to deploy the codes from the specific remote
branch to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the 'dev'
branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in
par with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same on
dev, stage and prod .. while test have a different version. The deploy job
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com 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

--
Regards
nirish okram

10

unfortunately i didn't enable the debug, for a node which deployed the
code. But i can try that after pushing something new to the remote dev
branch alone.
Below is the entry from the debug log that doesn't specify anything
regarding the branch from which its trying to deploy.

[2015-04-07T23:45:32+00:00] INFO: Processing
deploy_revision[/opt/mount/oss] action deploy
(python_app::python-app-deploy line 36)
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss] finding
current git revision
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss]
resolving remote reference
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss] is the
latest version

I always see this printed "fetch updates for origin"

Thanks

On Wed, Apr 8, 2015 at 12:06 PM, Morgan Blackthorne stormerider@gmail.com
wrote:

And what does chef-client -l info show around that resource?

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram nirish.okram@gmail.com
wrote:

oops sorry, i had corrected while i was committing the code. This is what
i have and which is not working

deploy_revision "/opt/mount1/#{node[:application_name]}" do

repo "#{node[:application_repo]}"

user "python"

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[oss]"

end

On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne <
stormerider@gmail.com> wrote:

You should either remove the quotes around node.chef_environment, or
string-ize it as "#{node.chef_environment}". Putting quotes around it but
not string-izing it just leads to it being interpreted literally.

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram <
nirish.okram@gmail.com> wrote:

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am trying
to make "deploy_revision" to deploy the codes from the specific remote
branch to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the
'dev' branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in
par with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same on
dev, stage and prod .. while test have a different version. The deploy job
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com 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

--
Regards
nirish okram

--
Regards
nirish okram

11

Where does chef gets this value from #{node.chef_environment}?

On Wed, Apr 8, 2015 at 12:37 PM, niristotle okram nirish.okram@gmail.com
wrote:

unfortunately i didn't enable the debug, for a node which deployed the
code. But i can try that after pushing something new to the remote dev
branch alone.
Below is the entry from the debug log that doesn't specify anything
regarding the branch from which its trying to deploy.

[2015-04-07T23:45:32+00:00] INFO: Processing
deploy_revision[/opt/mount/oss] action deploy
(python_app::python-app-deploy line 36)
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss]
finding current git revision
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss]
resolving remote reference
[2015-04-07T23:45:32+00:00] DEBUG: deploy_revision[/opt/mount1/oss] is the
latest version

I always see this printed "fetch updates for origin"

Thanks

On Wed, Apr 8, 2015 at 12:06 PM, Morgan Blackthorne <stormerider@gmail.com

wrote:

And what does chef-client -l info show around that resource?

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than we
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram <nirish.okram@gmail.com

wrote:

oops sorry, i had corrected while i was committing the code. This is
what i have and which is not working

deploy_revision "/opt/mount1/#{node[:application_name]}" do

repo "#{node[:application_repo]}"

user "python"

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[oss]"

end

On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne <
stormerider@gmail.com> wrote:

You should either remove the quotes around node.chef_environment, or
string-ize it as "#{node.chef_environment}". Putting quotes around it but
not string-izing it just leads to it being interpreted literally.

--
~~ StormeRider ~~

"Every world needs its heroes [...] They inspire us to be better than
we are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram <
nirish.okram@gmail.com> wrote:

hi,
I tried out today, but it doesn't seem to pull down the code from the
parameterized branch names. This is what i have for the deploy_revision:

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

I have 4 environments (dev, test, staging & production) and i am
trying to make "deploy_revision" to deploy the codes from the specific remote
branch to the specific environment.

And the branches on the repo are:

$ git branch -a

  • (detached from origin/test)
    master
    remotes/origin/HEAD -> origin/master
  • remotes/origin/dev*
    remotes/origin/master
  • remotes/origin/production*
  • remotes/origin/staging*
  • remotes/origin/test*

To test it, i pushed a new code to the master. Then merge that the
'dev' branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in
par with the dev.

$ git checkout origin/test
Previous HEAD position was 63c6388... version change
HEAD is now at ad262df...

$ git checkout origin/staging
HEAD is now at ad262df...

$ git checkout origin/production
HEAD is now at ad262df...

But strange that, when i run chef-client : the code version are same
on dev, stage and prod .. while test have a different version. The deploy
job says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo dan@kallistec.com
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

--
Regards
nirish okram

--
Regards
nirish okram

--
Regards
nirish okram

12

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" dey.ranjib@gmail.com 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:
  4. Encourages checking in configuration in the code, like all your
    environment details. This is pain if you environment changes, hosts get
    added etc
  5. 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:
  3. deployment is tied with system changes/rollout
  4. 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 dan@kallistec.com 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

13

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 bill.warner@gmail.com 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" dey.ranjib@gmail.com 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:
  4. Encourages checking in configuration in the code, like all your
    environment details. This is pain if you environment changes, hosts get
    added etc
  5. 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:
  3. deployment is tied with system changes/rollout
  4. 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 dan@kallistec.com 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

14

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 nirish.okram@gmail.com
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 bill.warner@gmail.com 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" dey.ranjib@gmail.com 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:
  4. Encourages checking in configuration in the code, like all your
    environment details. This is pain if you environment changes, hosts get
    added etc
  5. 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:
  3. deployment is tied with system changes/rollout
  4. 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 dan@kallistec.com 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: yoshi.spendiff@indochino.com

15

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 <nirish.okram@gmail.com (mailto:nirish.okram@gmail.com)> 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 <bill.warner@gmail.com (mailto:bill.warner@gmail.com)> 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" <dey.ranjib@gmail.com (mailto:dey.ranjib@gmail.com)> 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:
  4. Encourages checking in configuration in the code, like all your environment details. This is pain if you environment changes, hosts get added etc
  5. 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:
  3. deployment is tied with system changes/rollout
  4. 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 <dan@kallistec.com (mailto:dan@kallistec.com)> 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: yoshi.spendiff@indochino.com (mailto:yoshi.spendiff@indochino.com)