How best to reprepresent a hosted site in Chef?


#1

Hello,

thanks to anyone, with your advices finally I’ve finished preparations
and I’ve started cooking my server.

I described some basic stuff like web server configuration till now.

Now I have more questions. It’s main function is serving about two
dozens of sites we developed and currently supporting. Adding a new site
is multi-step process. Script I wrote adds an user, setups a repository,
creates a database, adds a config for webserver and log analysis system.

There is currently no way to remove the site and no central repository
where the current configuration is stored. Also, there is a separate
host used for backups, it makes commits through ssh on a regular basis
and fetches them from the server. It’s scripts need tweaking after
adding a new site too.

I feel all this chaos can be greatly reduced with Chef. I hope, at
least. But I’m not sure, how best to represent “the site” in terms of
chef. For me it looks like some kind of resource having it’s attributes
like domain name, ip, username, passwords(?). Is it feasible to write an
extension to Chef? I’ve read it’s quite easy.

But also site can be described in terms of operations needed to set it
up, like add this user, create this file, put that file there and so on.
This way I may use Chef as is, but such imperative descriptions give me
an uncomfortable feeling.

I’d like to hear some thoughts from the community regarding my situation
and pros and conses of various approaches possible.

Best wishes,
Dmitry


#2

On Wed, Jun 2, 2010 at 10:14 AM, Dmitry V’yal akamaus@gmail.com wrote:

Hello,

thanks to anyone, with your advices finally I’ve finished preparations and
I’ve started cooking my server.

I described some basic stuff like web server configuration till now.

Now I have more questions. It’s main function is serving about two dozens of
sites we developed and currently supporting. Adding a new site is multi-step
process. Script I wrote adds an user, setups a repository, creates a
database, adds a config for webserver and log analysis system.

There is currently no way to remove the site and no central repository where
the current configuration is stored. Also, there is a separate host used for
backups, it makes commits through ssh on a regular basis and fetches them
from the server. It’s scripts need tweaking after adding a new site too.

I feel all this chaos can be greatly reduced with Chef. I hope, at least.
But I’m not sure, how best to represent “the site” in terms of chef. For me
it looks like some kind of resource having it’s attributes like domain name,
ip, username, passwords(?). Is it feasible to write an extension to Chef?
I’ve read it’s quite easy.

But also site can be described in terms of operations needed to set it up,
like add this user, create this file, put that file there and so on. This

Well, if you write a custom resource then that resource can have
resource actions associated to it. Just like any other chef resource.
You are free to define these actions as you see fit.

IMHO, it sounds like writing a chef resource is a good way to go. But
dont forget to look at definitions too.

way I may use Chef as is, but such imperative descriptions give me an
uncomfortable feeling.

I’d like to hear some thoughts from the community regarding my situation and
pros and conses of various approaches possible.

Best wishes,
Dmitry


#3

On Wed, Jun 2, 2010 at 3:50 AM, Dreamcat Four dreamcat4@gmail.com wrote:

On Wed, Jun 2, 2010 at 10:14 AM, Dmitry V’yal akamaus@gmail.com wrote:

Hello,

thanks to anyone, with your advices finally I’ve finished preparations and
I’ve started cooking my server.

I described some basic stuff like web server configuration till now.

Now I have more questions. It’s main function is serving about two dozens of
sites we developed and currently supporting. Adding a new site is multi-step
process. Script I wrote adds an user, setups a repository, creates a
database, adds a config for webserver and log analysis system.

There is currently no way to remove the site and no central repository where
the current configuration is stored. Also, there is a separate host used for
backups, it makes commits through ssh on a regular basis and fetches them
from the server. It’s scripts need tweaking after adding a new site too.

I feel all this chaos can be greatly reduced with Chef. I hope, at least.
But I’m not sure, how best to represent “the site” in terms of chef. For me
it looks like some kind of resource having it’s attributes like domain name,
ip, username, passwords(?). Is it feasible to write an extension to Chef?
I’ve read it’s quite easy.

But also site can be described in terms of operations needed to set it up,
like add this user, create this file, put that file there and so on. This

Well, if you write a custom resource then that resource can have
resource actions associated to it. Just like any other chef resource.
You are free to define these actions as you see fit.

IMHO, it sounds like writing a chef resource is a good way to go. But
dont forget to look at definitions too.

way I may use Chef as is, but such imperative descriptions give me an
uncomfortable feeling.

I’d like to hear some thoughts from the community regarding my situation and
pros and conses of various approaches possible.

Best wishes,
Dmitry

Ohai!

If the sites are all very similar except for some data, you can just
create them in a loop. Our documentation for libraries shows an
example of creating vhosts based on data in a SQL database:

http://wiki.opscode.com/display/chef/Libraries

If this looks appealing, but you don’t currently have the data in a
database, you might want to use data bags to store the data:

http://wiki.opscode.com/display/chef/Data+Bags

HTH,
Dan DeLeo


#4

Ohai!

If the sites are all very similar except for some data, you can just
create them in a loop. Our documentation for libraries shows an
example of creating vhosts based on data in a SQL database:

http://wiki.opscode.com/display/chef/Libraries

If this looks appealing, but you don’t currently have the data in a
database, you might want to use data bags to store the data:

http://wiki.opscode.com/display/chef/Data+Bags

Hello Daniel.

Data bags seem like a way to go. Now, speaking in terms of example at
wiki page you gave, what if I want to remove some admins after I ran the
recipe? I modify the bag, and what’s next? Is there a way to give a more
declarative semantics to things?

Best wishes,
Dmitry


#5

On Wed, Jun 2, 2010 at 1:31 PM, Dmitry V’yal akamaus@gmail.com wrote:

Ohai!

If the sites are all very similar except for some data, you can just
create them in a loop. Our documentation for libraries shows an
example of creating vhosts based on data in a SQL database:

http://wiki.opscode.com/display/chef/Libraries

If this looks appealing, but you don’t currently have the data in a
database, you might want to use data bags to store the data:

http://wiki.opscode.com/display/chef/Data+Bags

Hello Daniel.

Data bags seem like a way to go. Now, speaking in terms of example at wiki
page you gave, what if I want to remove some admins after I ran the recipe?
I modify the bag, and what’s next? Is there a way to give a more declarative
semantics to things?

Chef doesn’t provide any out-of-the-box policy enforcement features,
so it will not automatically remove something if you’ve removed it
from a recipe. You’ll have to handle this on a case-by-case basis, but
in this case, you could move admins to a deleted admins databag and
handle it that way, or possibly determine which ones have been removed
by comparing etc/passwd with the databag. The Etc module could be
useful for this:

http://ruby-doc.org/stdlib/libdoc/etc/rdoc/classes/Etc.html

HTH,
Dan DeLeo

Best wishes,
Dmitry