2012-12-30T09:52:00-06:00 Laminas_Feed_Writer https://mwop.net/blog/tag/cloud 2012-12-30T09:52:00-06:00 2012-12-30T09:52:00-06:00 https://mwop.net/blog/2012-12-30-openshift-cron-and-naked-domains.html Matthew Weier O'Phinney contact@mwop.net https://mwop.net As an experiment, I migrated my website over to OpenShift yesterday. I've been hosting a pastebin there already, and have found the service to be both straightforward and flexible; it was time to put it to a more thorough test. In the process, I ran into a number of interesting issues, some of which took quite some time to resolve; this post is both to help inform other potential users of the service, as well as act as a reminder to myself. Cron OpenShift offers a Cron cartridge, which I was excited to try out.1 The basics are quite easy. In your repository's .openshift directory is a cron subdirectory, further divided into minutely, hourly, daily, weekly, and monthly subdirectories. You drop a script you want to run into one of these directories, and push your changes upstream. The problem is: what if I want a job to run at a specific time daily? or on the quarter hour? or on a specific day of the week? As it turns out, you can manage all of the above, just not quite as succinctly as you would in a normal crontab. Here, for example, is a script that I run at 5AM daily; I placed it in the hourly directory so that it can test more frequently: #!/bin/bash if [ `date +%H` == "05" ] then ( export PHP=/usr/local/zend/bin/php ; cd $OPENSHIFT_REPO_DIR ; $PHP public/index.php phlycomic fetch all ; $PHP public/index.php phlysimplepage cache clear --page=pages/comics ) fi And here's one that runs on the quarter-hour, placed in the minutely directory: #!/bin/bash MINUTES=`date +%M` for i in "00" "15" "30" "45";do if [ "$MINUTES" == "$i" ];then ( export PHP=/usr/local/zend/bin/php ; cd $OPENSHIFT_REPO_DIR ; $PHP public/index.php githubfeed fetch ) fi done The point is that if you need more specificity, push the script into the next more specific directory, and test against the time of execution. Naked Domains Naked domains are domains without a preceding subdomain. In my case, this means "mwop.net", vs. "www.mwop.net". The problem that cloud hosting presents is that the IP address on which you are hosted can change at any time, for a variety of reasons. As such, you typically cannot use DNS A records to point to your domain; the recommendation is to use a CNAME record that points the domain to a "virtual" domain registered with your cloud hosting provider. However, most domain registrars and DNS providers do not let you do this for a naked domain, particularly if you also have MX or other records associated with that naked domain. Some registrars will allow you to forward the A record to a subdomain. I tried this, but had limited success; I personally found that I ended up in an infinite loop situation when doing the DNS lookup. Another solution is to have a redirect in place for your naked domain to the subdomain, which can then be a CNAME record. Typically, this would require you have a web server under your control with a fixed IP that then simply redirects to the subdomain. Fortunately, there's an easier solution: wwwizer. You simply point your naked domain A record to the wwwizer IP address, and they will do a redirect to your www subdomain. I implemented wwwizer on my domain (which is why you'll see "www.mwop.net" in your location bar), and it's been working flawlessly since doing so. Private repositories I keep my critical site settings in a private repository, which allows me to version them while keeping the credentials they hold out of the public eye. This means, however, that I need to use GitHub deploy keys on my server in order to retrieve changes. This was simple enough: I created an ssh subdirectory in my $OPENSHIFT_DATA_DIR directory, and generated a new SSH keypair. The problem was telling SSH to use this key when fetching changes. The solution is to use a combination of ssh-agent and ssh-add, and it looks something like this: #!/bin/bash ssh-agent `ssh-add $OPENSHIFT_DATA_DIR/ssh/github-key && ( cd $OPENSHIFT_DATA_DIR/config ; git fetch origin ; git rebase origin/mwop.net.config )` After testing the above, I put this in a pre_build script in my OpenShift configuration so that I can autoupdate my private configuration on each build. However, I discovered a new problem: when a build is being done, the ssh-agent is not available, which means the above cannot be executed. I'm still trying to find a solution. Fin I'm pretty happy with the move. I don't have to do anything special to automate deployment, and all my cronjobs and deployment scripts are now self-contained in the repository, which makes my site more portable. While a few things could use more documentation, all the pieces are there and discoverable with a small amount of work. I'll likely give some other PaaS providers a try in the future, but for the moment, I'm quite happy with the functionality and flexibility of OpenShift. Footnotes 1 Zend Server's JobQueue can also be used as a cron replacement, but I was not keen on exposing the job functionality via HTTP. OpenShift, Cron, and Naked Domains was originally published 30 December 2012 on https://mwop.net by Matthew Weier O'Phinney. 2012-11-01T15:25:00-05:00 2012-11-01T15:25:00-05:00 https://mwop.net/blog/2012-11-01-openshift-zf2-composer.html Matthew Weier O'Phinney contact@mwop.net https://mwop.net I was recently shopping around for inexpensive cloud hosting; I want to try out a couple of ideas that may or may not have much traffic, but which aren't suited for my VPS setup (the excellent ServerGrove); additionally, I'm unsure how long I will maintain these projects. My budget for this is quite small as a result; I'm already paying for hosting, and am quite happy with it, so this is really for experimental stuff. I considered Amazon, Orchestra.io, and a few others, but was concerned about the idea of a ~$50/month cost for something I'm uncertain about. When I asked in #zftalk.dev, someone suggested OpenShift as an idea, and coincidentally, the very next day Zend announced a partnership with RedHat surrounding OpenShift. The stars were in alignment. In the past month, in the few spare moments I've had (which included an excellent OpenShift hackathon at ZendCon), I've created a quick application that I've deployed and tested in OpenShift. These are my findings. ZF2 I didn't really have to do anything different to have zf2 work; the standard .htaccess provided in the skeleton application worked flawlessly the first time (I've worked with some cloud environments where this is not the case). The only frustration I had was the default directory structure OpenShift foists upon us: data/ libs/ misc/ php/ This is not terrible, by any stretch. However, it's attempting to dictate the application structure, which I'm not terribly happy with — particularly as my structure may vary based on the framework I'm using (or not!), and because I may already have a project written that I simply want to deploy. In particular, the php directory is galling — it's simply the document root. Most frameworks I've used or seen call the equivalent directory public, or web, or html — but never php (in large part because the only PHP file under the document root in most frameworks is the index.php that acts as the front controller). It would be nice if this were configurable. This conflicts a bit with how a ZF2 app is structured. I ended up doing the following: Removed php and symlinked my public directory to it. Removed libs and symlinked my vendor directory to it. Removed misc as I had no need to it. Nothing too big, thankfully — but problematic from the perspective of, "I've already developed this app, but now I have to make changes for it to work on a specific cloud vendor." Composer My next question was how to use Composer during my deployment process, and some some googling found some answers for me. Basically, I needed to create a deploy task that does two things: Unset the GIT_DIR environment variable. Evidently, the build process operates as part of a git hook, and since Composer often uses git repositories, this can lead to problems. Change directory to OPENSHIFT_REPO_DIR, which is where the application root (not document root!) lives. Once I did those, I could run my normal composer installation. The deploy task looks like this: #!/bin/bash # .openshift/action_hooks/deploy ( unset GIT_DIR ; cd $OPENSHIFT_REPO_DIR ; /usr/local/zend/bin/php composer.phar install ) This leads into my next topic. Deployment First off, as you probably guessed from that last secton, there are hooks for deployment — it doesn't have to be simply git. I like this, as I may have additional things I want to do during deployment, such as retrieving and installing site-specific configuration files, installing Composer-defined dependencies (as already noted), etc. Over all, this is pretty seamless, but it's not without issues. I've been told that some of my issues are being worked on, so those I won't bring up here. The ones that were a bit strange, and which caught me by surprise, though, were: Though the build process creates the site build from git, your submodules are not updated recursively. This tripped me up, as I was using EdpMarkdown, and had installed it as a submodule. I ended up having to import it, and its own submodule, directly into my project so that it would work. I installed the MongoDB cartridge. Ironically, it was not then enabled in Zend Server, and I had to go do this. This should be turnkey. /usr/bin/php is not the same as /usr/local/zend/bin/php. This makes no sense to me if I've installed Zend Server as my base gear. Considering they're different versions, this can be hugely misleading and lead to errors. I understand there are reasons to have both — so simply be aware that if you use the Zend Server gear, your tasks likely should use /usr/local/zend/bin/php. The good parts? You can alias an application to a DNS CNAME — meaning you can point your domain name to your OpenShift applications. Awesome! Simplicity of adding capabilities, such as Mongo, MySQL, Cron, and others. In most cases, this is simply a "click on the button" and it's installed and available. Zend Server. For most PHP extensions, I can turn them on or off with a few mouse clicks. If I want page-level caching, I don't have to do anything to my application; I can simply setup some rules in the Zend Server interface and get on with it, and enjoy tremendous boosts to performance. I used to enjoy taming and tuning servers; most days anymore, I just want them to work. SSH access to the server, with a number of commands to which I've been given sudoer access. If you're going to sandbox somebody, this is a fantastic way to do it. Oh, also: SSH tunnels to services like Mongo and MySQL just work (via the rhc-port-forward command). Summary Over all, I'm quite pleased. While it took me a bit to find the various incantations I needed, the service is quite flexible. For my needs, considering I'm doing experimental stuff, the price can't be beat (the current developer preview is free). Considering most stuff I do will fall into this or the basic tier, and that most cartridges do not end up counting against your alotment of gears, the pricing ($0.05/hour) is extremely competitive. OpenShift, ZF2, and Composer was originally published 1 November 2012 on https://mwop.net by Matthew Weier O'Phinney.