[Chicago] How do you deploy?

[Adam "Cezar" Jenkins]

Rex looks interesting.

I do have to disagree about Chef/Puppet a little. It's true it does take
some setup, but it's also for configuring the entire machine and
infrastruture. DB machines, load balancers, etc. In that case I think the
trade-off is worth it. That said, I believe Ansible runs locally and
reaches into the machines to do setup.

One way to get around all that is using Amazon OpsWorks (
https://aws.amazon.com/opsworks/) That runs Chef and everything and you
just give it the recipies (scripts).

>From the experiences I hear, a PaaS works for many for a while. When they
hit the configurability wall at some point in their apps lifecycle they
move it over to something custom. For me, I've actually enjoyed the
restrictions of Ubuntu. A long time ago when I hit one of their wall, which
was 30 second max request time, I was annoyed, but like significant
whitespace in Python, I've found the restrictions to have increased the
quality of the architecture of my apps. In this example, if somethings
going to take over 30 seconds, it should be pushed off. Celery for
processes, and directly to S3 for uploads.

I do think everyone should know how to deploy by hand though. So do that at
least once.


On Sun, Feb 24, 2013 at 11:37 PM, Tal Liron <tal.liron at threecrickets.com>wrote:

> I've developed my own deployment container that I may present to ChiPy in
> the future.
>
> Otherwise, I have a rule of thumb: don't use deployment solutions that
> themselves need deployment. Fabric and Puppet both break that rule, and I
> prefer not to use them. I've used Chef in the past, and was thoroughly
> frustrated when Chef itself broke.
>
> So, I recommend (R)ex?: http://rexify.org/
>
> It uses SSH for its transport, so it will always work, even on clean
> nodes. And its Perl scripts are actually very friendly to use, no less so
> than the Ruby-based tools. It has great industry support, is rock-solid and
> has lots of plugins, including integration with Gearman for really big
> deployments that can benefit from concurrency (that, of course, does
> require deploying Gearman). Documentation is imperfect, but I recommend
> investing in learning it.
>
> Also, I am assuming you want to deploy Python: you absolutely want to use
> virtualenv, and also Supervisor if you need to run multiple servers.
>
> Finally, in terms of versioning, consider packaging in .deb or .rpm, and
> managing your own repository. More learning up front, for sure, but it
> makes installation/upgrades dead easy, and also safe (no orphaned files).
>
> Another pro-tip: I strongly recommend the "configuration by script"
> approach. Instead of hardcoded (or generated) configuration files that you
> have to deploy to each node, have your Python (or other language) apps know
> how to configure themselves upon startup according to interrogation of
> their runtime environment. All cloud implementations have some sort of API
> (sometimes REST-based) for that. It's more work to do this, but it means
> that you never have to worry about configuration files, especially
> *different* configuration files per node. You just need to restart services
> in order to "reconfigure" them.
>
> PaaS ends up costing you more in the long-run, and you may hit various
> walls in terms of flexibility. Consider rolling your own solution, which
> you completely own and can fine-tune.
>
> -Tal
>
> On Sun, Feb 24, 2013 at 10:57 PM, Adam "Cezar" Jenkins <
> emperorcezar at gmail.com> wrote:
>
>> Wondering what most people are doing. Seems to me deployments are
>> currently in a few groupings.
>>
>> - Fabric to personal server or AWS
>> - By hand to personal server or AWS
>> - Something custom, like a custom git-hook
>> - Pushing to Heroku or another PaaS like OpenShift, Stackato etc.
>>
>> What is your prefered method?
>>
>> Mine personally is Heroku for most things. I prefer a PaaS if I can get
>> away with it. If I need custom, I prefer Chef (maybe Ansible/Salt in the
>> future). Custom is going to be much easier now that EC2 has Chef support
>> built in.
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> http://mail.python.org/mailman/listinfo/chicago
>>
>>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20130225/e92636cd/attachment.html>