3

I have few, relatively small, servers running Linux distros. Sometimes I need to re-install 1 or 2 of the "development" servers from scratch. Often I just forget to setup little things, eg. forwarding in sysctl.conf or forget to install update monitoring script, non-essential but useful packages etc.

Ideally, I would like to have exact setup among all of them.

1) How do you deal with documenting the 'deployment' process to tidy things up? Can you give me some examples?

2) Do you use some of the popular deployment tools? I've looked at stuff like chef and puppet, but they seem way over-complicated to me right now. Something simpler?

M_1
  • 363
  • 2
  • 10

4 Answers4

1

What do you dislike about Puppet (or Chef)? They're tools that are designed to do exactly what you need. If it's the complexity of the client/server setup, for either of them you can skip installing the server component and just run the client in "standalone" or "solo" mode.

sciurus
  • 12,678
  • 2
  • 31
  • 49
0

I'm ultimately moving to a Chef system to auto scale/discovery, but right now I actually control the server bootstrap process directly from the source code of the thing I need the server to be deployed on. Not sure if you're on the webstack, or if you're using ruby, but a really nice tool to use if you are is: recap (based on Capistrano)

It allows you to run scripts on any number of remote servers. It works by using a 'Capfile' to define your servers and such, and then has a few built in tasks that you can extend. One of them being the :bootstrap task. So I have a simple chain when provisioning new servers of

      before 'bootstrap', 'bootstrap:dependencies'

...

      namespace :bootstrap do
          task :dependencies do
              uname = capture('uname -r')
              abort('ENV Not Supported') unless uname.strip == "some uname version"
              sudo('apt-get -y install build-essential')
              run('echo 'America/New_York' | sudo tee /etc/timezone')
          end
      end

...

That's just a sample of a few things you can do using the 'capture', 'sudo' and 'run' commands that recap provides you. Of course, this example assumes the software that you're deploying is tied to the ruby stack, but the point is, there are tools like this for all kinds of languages / frameworks.

My suggestion is simply to tie the provisioning of the server to the code you're deploying on that server, unless you want to go for a tool like chef or puppet.

comjf
  • 156
  • 3
0

Some simple and swinging modularized bash scripts both as rollout method and self contained documentation? Until you go puppet/chef/somethingelse...

ErikE
  • 4,746
  • 1
  • 20
  • 27
-1

For dev environments I'm a massive fan of Vagrant. It's simpler (IMHO) thank chef and puppet and it basically allows you to setup your environment once, and then tear it down and reinstate to your heart's content.

Take a look; http://www.vagrantup.com/

As this is the second question this week I've recommended Vagrant for, I just want to state that I'm in no way affiliated with them and get nothing from recommended them!

sgtbeano
  • 340
  • 5
  • 14
  • Thanks for the answer. Vagrant won't work for me. The Linux boxes are virtualized on top of KVM, Xen (forgot to include that in post), so double layer of virtualization would be slow and I could only run approx. 1-2 vagrant containers given the memory constraints on those small boxes. – M_1 Nov 06 '13 at 11:46
  • fwiw: vagrant can use other backends than virtualbox. – Sirex Nov 19 '13 at 23:07
  • I don't see how vagrant alone answers the question. Most of the value would come from using vagrant to run a provisioner, such as chef or puppet. – sciurus Nov 20 '13 at 01:29
  • -1. Vagrant is a virtual machine management layer, not configuration management. – EEAA Nov 20 '13 at 04:29