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