Anybody uses custom deploy.sh scripts within application cookbook to
deploy over ssh ?
For example:
You using chef solo and you have a git repo which is an application
cookbook of one server.
This cookbook has a deploy.sh script, which is connecting to server,
creating a container, bootstrap it with a chef-solo, install all prereqs
and setup you application.
If this is a normal practice ? Or may be this is not a deploy.sh or
somthing else. Please give me an advice.
How to assing server hostname, port, password. How to store them ? And
where to store them ?
Sometimes that deploy can take a long time.
How you save time in this use case?
I’ am using:
- apt cache /var/cache/apt/archives mount in container
- cache remote_files on the other filesystem, which is not recreating
when I am delete container
- using custom squid_deb_proxy recipe to setup container os for use our
proxy server.
May be you can advice another useful examples ?
How I can cache rvm installing and gems ?
–
Best regards,
CVision Lab System Administrator
Vladmir Skubriev
If you were using vagrant for bringing up and provisioning your nodes you
would simply have a Vagrantfile and call ‘vagrant up’ instead of a custom
deploy.sh script.
As an additional benefit you could use the vagrant-cachier plugin, which
does all the caching you describe below…
HTH,
Torben
On Nov 19, 2013 5:04 PM, “Vladimir Skubriev” skubriev@cvisionlab.com
wrote:
Anybody uses custom deploy.sh scripts within application cookbook to
deploy over ssh ?
For example:
You using chef solo and you have a git repo which is an application
cookbook of one server.
This cookbook has a deploy.sh script, which is connecting to server,
creating a container, bootstrap it with a chef-solo, install all prereqs
and setup you application.
If this is a normal practice ? Or may be this is not a deploy.sh or
somthing else. Please give me an advice.
How to assing server hostname, port, password. How to store them ? And
where to store them ?
Sometimes that deploy can take a long time.
How you save time in this use case?
I’ am using:
- apt cache /var/cache/apt/archives mount in container
- cache remote_files on the other filesystem, which is not recreating
when I am delete container
- using custom squid_deb_proxy recipe to setup container os for use our
proxy server.
May be you can advice another useful examples ?
How I can cache rvm installing and gems ?
–
Best regards,
CVision Lab System Administrator
Vladmir Skubriev
19.11.2013 20:43, Torben Knerr ???:
If you were using vagrant for bringing up and provisioning your nodes
you would simply have a Vagrantfile and call ‘vagrant up’ instead of a
custom deploy.sh script.
As an additional benefit you could use the vagrant-cachier plugin,
which does all the caching you describe below…
HTH,
Torben
On Nov 19, 2013 5:04 PM, “Vladimir Skubriev” <skubriev@cvisionlab.com
mailto:skubriev@cvisionlab.com> wrote:
Anybody uses custom deploy.sh scripts within application cookbook
to deploy over ssh ?
For example:
You using chef solo and you have a git repo which is an
application cookbook of one server.
This cookbook has a deploy.sh script, which is connecting to
server, creating a container, bootstrap it with a chef-solo,
install all prereqs and setup you application.
If this is a normal practice ? Or may be this is not a deploy.sh
or somthing else. Please give me an advice.
How to assing server hostname, port, password. How to store them ?
And where to store them ?
Sometimes that deploy can take a long time.
How you save time in this use case?
I' am using:
1. apt cache /var/cache/apt/archives mount in container
2. cache remote_files on the other filesystem, which is not
recreating when I am delete container
3. using custom squid_deb_proxy recipe to setup container os for
use our proxy server.
May be you can advice another useful examples ?
How I can cache rvm installing and gems ?
--
Best regards,
CVision Lab System Administrator
Vladmir Skubriev
Oh thank you very much for vagrant-cache plugin . I don’t know about it.
–
Best regards,
CVision Lab System Administrator
Vladmir Skubriev