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