[Chicago] How do you deploy?

[Daniel Griffin]

I work for http://www.opdemand.com/ so I'll try not to sell this too hard.

To run on EC2 you absolutely do need to get your whole installation down to
1 script that you can run over and over. We made some choices early on to
try to get people to use masterless puppet(we are otherwise a python shop),
but it's easy to sub in your own.


I am planning to be in Chicago in April if anyone is interested in a
presentation about how we use python and how to host python apps.




On Mon, Feb 25, 2013 at 5:53 AM, Adam "Cezar" Jenkins <
emperorcezar at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/8c109943/attachment.html>