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. 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. */
