Matt's Linux Blog
My linux problems (and their respective solutions)Sunday, May 22, 2011
Dancing with Erlang
So I decided to create a highly-available IRC bot in Erlang. This is probably overkill, but I was mesmerized by the prospect of on-the-fly code reloading, one of the major features of the OTP stack.
Some "gotchas" that I came across:
- The vocabulary: the terms "release" and "application" are a little skewed from how I originally conceived them. "application" really means a piece of your high-level application, something I would normally call a "module" (but that itself has a meaning to Erlang developers), and a "release" is what the high-level application really is — it's called a "release" just because it specifies versions of each of the constituent "applications".
- What you actually name the .rel file means nothing, aside from naming the .tar.gz file that systools gives you. Hence, I can actually let git manage the file — I was afraid I was going to have to copy it for each and every release I wanted to push out.
- Making sure the latest BEAM file is loaded: it's easiest just to use the shell's "c(modulename)" function, which compiles and loads the new version for you, or exit the interpreter completely. Trying to use code:purge, code:delete, and code:load_file just gets awkward and annoying. I don't suggest it.
- Creating the relup file to deploy a new version of an application requires both versions of the application in the code path, even if the appup file for the new version tells the whole story and only reloads functional modules. This is somewhat interesting to integrate into a workflow with Git; I'm still working on that part.
- Creating a system instance to deploy to is a pain in the butt, especially if you want the processes to run in the background. I ended up mostly following the Erlang System Principles guide, but I did most of the things manually instead of copying their script — I learned a lot about the target's filesystem structure.
- Remotely accessing an Erlang node is really really picky about the name you use to access it.
Biggest lesson: Erlang is an operating system by itself, with its own idea of package management and directory structure. I had to throw away what I normally think of as packaging to gain the power of the Erlang release handling system.
There is more on most of these points to come.
Archives
May 2007 June 2007 August 2007 October 2007 April 2008 May 2008 January 2009 May 2011
Subscribe to Posts [Atom]