How do you organize your deployment enviroment

[DK]

Hi,

I am having a django project that  is being frequently deployed on clean linux installation. After a few deployments I have noticed that this process is very time consuming for me (every time I am preparing run scripts for everything, configuring cronjobs, paths to log files, etc) but this could be easily automated.

What are a ready solutions to manage such deployments?

My typical workflow is:

1) install packages on debian/ubuntu via aptitude (like database, etc)

2) creating new virtualenv + getting pip

3) pip install -r requirements (to setup enviroment)

4) fetch django project from code repository

5) setup runtime dir (I keep there: run - for pid files, logs, conf - for some config variables or scritps, scripts - some starting srcipts)

6) setup crontab jobs 

7) setup webserver + django wsgi to be started 

Sure - I can write some custom made installer for that, but wondering if there is some generic tool for such things.

PS. I have heard about fabric, but didn't investigate this tool yet. 

[Malcolm Box]

I'd heartily recommend chef - chef.opscode.com. 

Large library of scripts for almost any package or tool you're likely to want, scales out to lots of nodes but can be run in a simple solo mode for small deployments. Only downside is it's ruby but mostly you use the configuration language so not really a problem. 

I use Chef plus fabric to automate deployments of hundreds of nodes. 

Malcolm

Sent from my iPhone, please excuse any typos

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[Sam Walters]

Hi
I make a shell script as i performs the steps for the first time.
Basically it means learning bash or something similar.

Disadvantage is its pretty inflexible however if its exactly the same
linux distro every time then its not too bad.

cheers

sam_w

[Jonas Geiregat]

I'm using Fabric for my deployment it's python based although it still leans on some shell scripting.

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Jonas Geiregat
jo...@geiregat.org

[Mateusz Marzantowicz]

I really think that writing custom bash script is the easiest way. I'm doing it right now because I need quick and idiot proof way of deploying Django based project. Be sure to do some preliminary tests of your environment.

I also recommend you deploying a virtual machine for Ubuntu/Debian (if it's what you want or can do).

[Henrik Genssen]

you can also use ANT http://ant.apache.org/
and the ant-deb-task http://code.google.com/p/ant-deb-task/
to create debian packages from your source or config

regards

Henrik

>reply to message:
>date: 23.05.2011 13:26:00
>from: "Mateusz Marzantowicz" <mmarza...@gmail.com>
>to: django...@googlegroups.com
>subject: [<django-users.googlegroups.com>] Re: How do you organize your deployment enviroment

[DK]

What is your optimal filesystem folder scheme?

I've used to keep everything in one directory (project-enviroment, that was itself a virtualenv directory) and then put everything there, but now I am finding hard to manage this as it became a little mess. Now I think about something like:

/

   home/

       project_user/

             env/    (<- virtual env goes here, no custom things, set up with pip requiremnts )

             some_project/  ( <- this is project directory easily keeping up to date with some versioning system)

             runmanager/         ( <- collection of generic scripts for running django projects etc,  versioned )

             runtime/      (<- here goes all runtime stuff, like run, logs, conf, this should be preconfigured by invoking a specific command from runmanager, this cannot be versioned, these are installation specific files)

any better idea/practices?

[Brian Bouterse]

I use fabric and chef together.  Usually fabric bootstraps my chef environment, and then chef takes over.  I also don't use cron anymore, but instead use celery.

Best,

Brian

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

--
Brian Bouterse
ITng Services

[Jonas Geiregat]

I'm just wondering how you could handle database changes.

Let's say you have a existing working project and the client asks for some changes.

These changes force you to create an extra table and modify some tables (models).
On the development server I could modify the changes to the database and the models files myself.
But deploying these changes to the production server seems a bit harder to overcome without the fear of loosing your data.

I don't think the newly created models and database tables would form a problem. Simply running ./manage.py syncdb would create the table(s) for us without any problems.
But what about tables (models) that are modified ?

How would you best handle such cases of deployment ?

Op 23-mei-2011, om 09:00 heeft DK het volgende geschreven:

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Jonas Geiregat
jo...@geiregat.org

[Daniel Roseman]

On Wednesday, May 25, 2011 1:22:40 PM UTC+1, jonas wrote:

I'm just wondering how you could handle database changes.

Let's say you have a existing working project and the client asks for some changes.

These changes force you to create an extra table and modify some tables (models).
On the development server I could modify the changes to the database and the models files myself.
But deploying these changes to the production server seems a bit harder to overcome without the fear of loosing your data.

I don't think the newly created models and database tables would form a problem. Simply running ./manage.py syncdb would create the table(s) for us without any problems.
But what about tables (models) that are modified ?

How would you best handle such cases of deployment ?

That's what South is for.

--

DR. 

[DK]

100% south migration :)

[DrBloodmoney]

On Wed, May 25, 2011 at 9:31 AM, DK <cypr...@gmail.com> wrote:
> 100% south migration :)

This.
I know that they have said that they weren't going to be putting South
into django (contrib?), but I wish they would. Most django devs should
be using it.

[Shawn Milochik]

This isn't entirely true.

http://www.aeracode.org/2010/6/2/django-and-migrations/

[DrBloodmoney]

Yeah. That was the post I was thinking about. For some reason I
thought that it came from the core dev team. I still think that
migrations should be a part of a full-stack framework like django
(south is the first app I install in a new project). They might as
well pick the best-in-breed and throw it in.

[Alexis Bellido]

I think Fabric is the easiest solution, the tutorial is pretty good [http:/fabfile.org], Katie wrote about how she uses Fabric [http://therealkatie.net/blog/2011/nov/28/katie-finally-talks-about-her-fabfiles/], and I tried to extend the idea a little to setup a server from scratch just with a couple of Fabric commands [https://github.com/alexisbellido/The-Django-gunicorn-fabfile-project]

Regards!