On Wed, Jan 15, 2014 at 8:44 AM, John Shaver <[email protected]> wrote:
> Hey Grant, > > We need a presenter this month (the month I'm finally able to attend again > :). Any chance you, or anyone else really, want to give a presentation > this month on developing an app to be auto-scalable via something like > OpenShift? It seems to me that it would be at least a little different > than your typical LAMP (the P stands for Python!) stack. It's something > I'm interested in and haven't had a chance to really dive into yet. > I would but I live in Phoenix, AZ. Red Hat will typically pay to have me go and speak somewhere but I would need a little bit more notice to reduce the cost of airfare. Plus, I hate the snow and its the reason I moved away from Utah. So a nice spring or summer meeting sounds better. :) > > -John > > > On Wed, Jan 15, 2014 at 12:18 AM, S. Dale Morrey <[email protected] > >wrote: > > > No worries, that actually works in my favor. App wants mongodb 2.4+ for > > some reason and I really didn't want to have to create a custom cartridge > > or whatever you guys call it. :) > > > > > > On Wed, Jan 15, 2014 at 12:14 AM, Grant Shipley <[email protected]> > > wrote: > > > > > On Wed, Jan 15, 2014 at 12:04 AM, S. Dale Morrey < > [email protected] > > > >wrote: > > > > > > > Grant, I'm a little confused. It looks like OpenShift only supports > > > > MongoDB 2.2 deployment. I need 2.4 or better, but I can't find how > to > > > > deploy it anywhere. > > > > > > > > > This is actually an embarrassing bug that I hope will be fixed very > soon > > > (next week or two). Even though it says MongoDB 2.2, it is actually > 2.4. > > > We just missed updating the text. :( I just verified it by creating a > > > test application, embedded mongodb-2.2 and then ssh in and ran mongo > > > command: > > > > > > [test-packt.rhcloud.com 52d634074382ec6197000043]\> mongo > > > MongoDB shell version: 2.4.6 > > > connecting to: 127.2.184.130:27017/admin > > > > > > > > > Sorry for the confusion. > > > > > > > > > > Some of the comments in the forums indicate that an > > > > upgrade path exists, but I don't see any information on how to do > this > > > > especially in a way that would scale. > > > > Are you just supposed to login to the gear and run an update or is > that > > > > even possible? > > > > > > > > Thanks! > > > > > > > > > > > > On Tue, Jan 14, 2014 at 10:39 PM, Grant Shipley <[email protected]> > > > > wrote: > > > > > > > > > comments inline. Thanks for the very well thought out and detailed > > > > > comments! > > > > > > > > > > > > > > > On Tue, Jan 14, 2014 at 10:03 PM, Richard Esplin > > > > > <[email protected]>wrote: > > > > > > > > > > > Last summer I did a hobby project on OpenShift. I really like the > > > > > platform, > > > > > > but left with the following lessons: > > > > > > > > > > > > * OpenShift is a neutered Git repo, so deployment to OpenShift > is a > > > git > > > > > > push. > > > > > > This has a number of ramifications: you have to understand git's > > > arcane > > > > > > syntax > > > > > > for simple stuff, you have to commit a change to get anything to > > > update > > > > > on > > > > > > the > > > > > > server, code on the server is ephemeral so the results of > debugging > > > > have > > > > > > to be > > > > > > copied off the server to be checked in, initial deployment is > > > > cumbersome, > > > > > > etc. > > > > > > > > > > > > > > > > This is mostly accurate. OpenShift recommends that all source code > > > > > deployments happen via git. However, the platform does support > > binary > > > > > deployments for languages where that is the standard (Java for > > > example). > > > > > > > > > > You can view logs a couple of different ways on the platform. You > > can > > > > use > > > > > the 'rhc tail' command which really just opens up a tail command > over > > > ssh > > > > > to your logs files. You can also SSH in to the server and view the > > log > > > > > files like you normally do. > > > > > > > > > > > > > > > > > * The development workflow with OpenShift took some getting used > > to. > > > > The > > > > > > deployment process is all through git. I moved an existing repo > to > > > > > > OpenShift, > > > > > > so the initial push to took a fork on Github, a merge with my > repo, > > > and > > > > > > another merge with OpenShift. Then I can push to either my Github > > > repo > > > > or > > > > > > my > > > > > > OpenShift repo. > > > > > > > > > > > > * OpenShift is a fast moving platform. Last summer I found a lot > of > > > > rough > > > > > > edges, strange bugs, and out-of-date documentation. Things change > > > like > > > > > what > > > > > > version of Django works with what version of Python and > PostgreSQL. > > > > Some > > > > > of > > > > > > the problems I found last summer appear to have been fixed. > > However, > > > > > > something > > > > > > appears to have changed and broken my app. I couldn't get it > > working > > > > > again > > > > > > after thirty minutes of poking around. > > > > > > > > > > > > It went GA in June of last summer. We were in beta before then > and > > > > > absolutely moved at a lightening pace. We continue to do so and > > strive > > > > to > > > > > always allow backwards compatibility. Sometimes this doesn't > happen. > > > > Now > > > > > that we are production and have actual paying customers, things are > > > > getting > > > > > better. > > > > > > > > > > > > > > > > * Last Summer there were strange limitations like you have to > > declare > > > > > your > > > > > > application to be scale-able when you first initialize the > > cartridges > > > > > > (though > > > > > > you can cap how it scales). When we decided we wanted to start > > > > scaling, I > > > > > > had > > > > > > to destroy and re-create the application from scratch. (At least > I > > > had > > > > > good > > > > > > instructions the second time.) > > > > > > > > > > > > > > > > This is still the case. Once you create a non-scalable > application, > > > you > > > > > can't convert to a scalable app on the fly. You can take a > snapshot > > of > > > > > your app and then recreate it with the scaling flag. You will see > > > > downtime > > > > > while doing this. This will be fixed in the future but I don't > have > > a > > > > date > > > > > yet. Speaking of which, because this is a true open source > project, > > > all > > > > > roadmaps and dates are on the public trello boards for people to > > > follow. > > > > > > > > > > > > > > > > > * We ran three separate accounts with copies of our repository: > one > > > for > > > > > > development, one for testing, and one for production. Each > account > > > had > > > > > > three > > > > > > gears: one for Python Django + HAProxy, one for the database, and > > one > > > > for > > > > > > Python Django at scale. Staging and production on OpenShift work > > > well, > > > > > > except > > > > > > you should be aware that HAProxy eats all the errors so we had to > > > > disable > > > > > > it > > > > > > to debug. The advantage is that on the production server we can > > > remove > > > > > the > > > > > > scalability limits with a paid account and still have everything > > > > working > > > > > in > > > > > > the same way. > > > > > > > > > > > > * I thought OpenShift would let me get out of setting up a local > > dev > > > > > > environment, but doing actual development on OpenShift is > annoying. > > > The > > > > > > deployment process is too slow, getting access to the logs is not > > > > great, > > > > > > and > > > > > > having to do everything through git makes it hard to experiment. > > > > > > > > > > > > > > > > Two options here. You can enable hot_deploy which will no longer > > > restart > > > > > the server (apache etc) for each deployment. This speeds things > up a > > > > lot. > > > > > However, for my development that still wasn't fast enough. What I > > do > > > is > > > > > configure my IDE to use SFTP to immediately copy the files to my > > server > > > > as > > > > > I save them. This allows me to have close to local speed > > development. > > > > By > > > > > the time I refresh the webpage, the new file is already running on > > the > > > > > openshift server. I wrote a blog post a while ago on how to do > this > > > for > > > > > PHP: > > > > > > > > > https://www.openshift.com/blogs/getting-started-with-sftp-and-openshift > > > > > > > > > > > > > > > > > > > > > > * It took me a long time to figure out and understand how the > > service > > > > is > > > > > > structured. However, once I understood it I really liked it. > Having > > > the > > > > > > source > > > > > > available on Github is awesome. There is very little coupling > > between > > > > my > > > > > > code > > > > > > and the OpenShift environment, so my code is very portable and no > > > > > lock-in. > > > > > > My > > > > > > code can detect if it is on my local environment, staging, or > > > > production, > > > > > > and > > > > > > adapt accordingly. > > > > > > > > > > > > > > > > This was one of the top design goals of the platform. No vendor > lock > > > in > > > > at > > > > > all. Developers should not have to modify their code to run on the > > > > > OpenShift platform. We still have a few minor things to cleanup > > before > > > > > this is 100% but we are getting closer. Mostly I am talking about > > some > > > > > weird directory structures we have for some languages. PHP is a > good > > > > > example of this where openshift expects your source code (app-root) > > to > > > be > > > > > in a directory named 'php' in your application directory. This > will > > be > > > > > going away soon. > > > > > > > > > > > > > > > > > > > > > > * Compared to Google AppEngine and Amazon Elastic Beanstalk, I > > found > > > > > > OpenShift > > > > > > to be much closer to a normal Linux development environment. The > > fact > > > > > that > > > > > > I > > > > > > can inspect the entire service helped me a lot. I loved not > having > > to > > > > use > > > > > > all > > > > > > the crazy libraries that Google and Amazon require. > > > > > > > > > > > Under the covers, OpenShift in running on Red Hat Enterprise Linux > 6. > > > > > Security is handled via SELinux. Process and memory allocations > via > > > > > Cgroups and we use pam_namespaces for polyinstantiated directories. > > > > > > > > > > > > > > > > > I think a lot of my complaints would apply to any PaaS; hosting > an > > > > > > application > > > > > > on a third-party platform means giving up some flexibility and > > > control. > > > > > It > > > > > > looks like OpenShift has already addressed some of my other > > concerns. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I really like OpenShift and hope to use it for my next project. I > > > hope > > > > it > > > > > > continues to mature in capability and stability, and I hope it > > gets a > > > > lot > > > > > > of > > > > > > adoption. > > > > > > > > > > > > As a side note, I spent way too long developing on Drupal, and I > > > would > > > > > not > > > > > > recommend it to others. If you are interested in my reasoning, I > > put > > > a > > > > > > rant up > > > > > > on my blog (http://richard.esplins.org/siwi/70/ ). > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Richard > > > > > > > > > > > > On Tuesday, January 14, 2014 19:27:29 S. Dale Morrey wrote: > > > > > > > Ok so this is not intended as flamebait or a troll or anything. > > > > > > > But earlier I mentioned my site running on Drupal is basically > > > > falling > > > > > > down > > > > > > > under it's own weight. > > > > > > > > > > > > > > I have an extremely limited budget upfront. I'm open to > > completely > > > > > > > dropping Drupal at this point and exploring other options. > > > > > > > > > > > > > > One of the options I'm looking at is KeystoneJs. It looks > really > > > > nice, > > > > > > and > > > > > > > I figure if I go with with it, I may as well go whole hog and > > move > > > > > > > providers as well. > > > > > > > > > > > > > > Keystone requires nodejs & mongo. For obvious reasons I would > > > > greatly > > > > > > > prefer to have a development environment and a production > > > > environment. > > > > > > > Since Redshift offers 3 servers I can see myself setting it up > as > > > > > > > "development 1 box all inclusive", "production 2 boxes, 1 would > > be > > > > node > > > > > > and > > > > > > > 1 would be mongo". > > > > > > > > > > > > > > I know we have someone from OpenShift on the list, so I > figured I > > > > would > > > > > > ask > > > > > > > if that is feasible. Also is there any way to spin up > additional > > > > > > instances > > > > > > > based on load similar to AWS's AutoScale feature. > > > > > > > > > > > > > > For the rest of the list, does structuring my environment this > > way > > > > make > > > > > > > sense? Or would it be better to have the development box > talking > > > to > > > > > the > > > > > > > production DB? > > > > > > > Also has anyone actually used OpenShift to power a site that > > > > > experiences > > > > > > > reasonably heavy loads? > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > /* > > > > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > > > > Unsubscribe: http://plug.org/mailman/options/plug > > > > > > Don't fear the penguin. > > > > > > */ > > > > > > > > > > > > > > > > /* > > > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > > > Unsubscribe: http://plug.org/mailman/options/plug > > > > > Don't fear the penguin. > > > > > */ > > > > > > > > > > > > > /* > > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > > Unsubscribe: http://plug.org/mailman/options/plug > > > > Don't fear the penguin. > > > > */ > > > > > > > > > > /* > > > PLUG: http://plug.org, #utah on irc.freenode.net > > > Unsubscribe: http://plug.org/mailman/options/plug > > > Don't fear the penguin. > > > */ > > > > > > > /* > > PLUG: http://plug.org, #utah on irc.freenode.net > > Unsubscribe: http://plug.org/mailman/options/plug > > Don't fear the penguin. > > */ > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
