Using Starkits for Easy Deployment of Server Applications
Total Page：16
File Type：pdf, Size：1020Kb
Using Starkits for Easy Deployment of Server Applications Mark Roseman CourseForum Technologies [email protected] Abstract have limited resources and patience available to fix things if they go wrong. As with other types of software, free or trial versions of Advances in consumer technology are leading to demand for server applications are now commonly downloaded and network server applications that are being run by less technically experimented with, rather than being installed and run only after inclined users, making ease of deployment critical. The Starkit financial and resource commitments have already been made. framework makes Tcl deployment in general much easier, but can be enhanced for servers. Using the CourseForum and For these users, applications that are hard to install or configure ProjectForum applications as examples, issues such as reducing are simply non-starters. For developers of such applications, dependencies, installation and configuration, starting and hoping to reach this new audience, easy deployment of their stopping, and various platform specific issues are explored. software is critical. Experiences show that in this important application niche, Tcl, based on Starkits and the techniques described here, provides a This paper starts by examining the root causes of hard to deploy strong deployment advantage. server applications, and details some of the resulting problems. It then turns to building such applications in Tcl, using the Starkit 1. A New Generation of Server Applications technology as a basis. While Starkits get us much of the way Easy deployment? For server applications? Just the thought of it towards a deployment solution, for network server applications seems at odds with reality. We are used to thinking about network additional issues like reducing dependencies, installation and server operations being managed in dedicated centers, composed configuration, starting and stopping all need to be concerned. As of extremely complex hardware, and run by extremely technically well, there are many platform-specific issues, particularly on oriented information technology workers. Vast complexity, high Windows and Mac OS X, that if addressed can greatly ease degrees of configurability, and flexibility in the face of unique deployment. network setups are the norm for network server applications, aren’t they? Using the CourseForum and ProjectForum applications as examples, this paper provides a “cookbook” approach to assist Though the impenetrable data centers are still safe, we are seeing others in developing easy to deploy network applications, building today a new type of environment where an ever-increasing range on the existing Starkit technology. Deployment has been a of new server applications are being run: in homes, personal particular strength of Tcl when compared with many other offices, small workgroups. These changes have been spurred on development tools, and this work shows that advantage can be by dramatic growth in consumer and SOHO (Small Office / Home particularly significant in the domain of network server Office) networking products like always-on broadband applications. connections, wireless networks and devices, coupled with consumer operating systems (e.g. Windows XP, Mac OS X) that 2. Deployment Today are powerful and robust enough to work as network servers, We know that Tcl makes building network servers particularly alongside regular desktop use. easy. Here is the canonical network server application in Tcl, just a few lines of code that works on any platform. We are seeing applications like Userland’s Radio or Manilla products [17], which provide individual and small group weblog socket -server Accept $portnum and content management support, or Amphetadesk, a personal proc Accept {sock args} { news aggregator [2]. Both run as applications under Windows or fconfigure $sock -blocking 0 Mac OS X, but work as web servers that are accessed via the fileevent $sock readable “Readable $sock” user’s web browser, rather than via a normal application user } proc Readable {sock} { interface. We also see a range of calendars, personal web-mail, # … do something interesting document management, file sharing, MP3 streaming, project } management and other similar applications, which run as servers on users’ desktop computers, but are made accessible via a Similarly, tools like Rivet [3], which runs under Apache, or network. various CGI packages make writing Tcl scripted web pages as easy as: Unlike the traditional network administrators found in the bowels of corporate data centers, users of this new breed of network <? server applications are not generally trained in the technical puts "Hello World" intricacies of deploying and administering networks. Applications ?> need to be installed and setup with a minimum of fuss, and they Despite the simplicity in coding, there are still a lot of steps • download the latest source code involved in taking those simple fragments, and getting them to run • open up Terminal.app (the Unix shell on Mac OS X) smoothly on someone else’s machine. • unpack the code in your Sites directory with “tar zxf” • make sure Apache is running (done via a system preferences 2.1. How Server Applications are Built panel, since Apache actually is included with Mac OS X) • via ‘sudo’ open /etc/httpd/httpd.conf in a text editor Most of today’s network server applications, most particularly • uncomment two lines to activate the PHP interpreter web applications, are neither short nor simple. They are also • add four lines to tell Apache about PHP files generally not written simply using the facilities of a base • restart Apache programming language, as in our canonical Tcl example. • download MySQL (luckily someone packaged that one up nicely for Mac OS X, so its not much more than just a double- Most such applications today are constructed to rely on a myriad click to install) of other technologies, including a mix of web servers, application • check that its running (another command line) servers, middleware, scripting languages, databases, programming • set a password for the root account of MySQL libraries, external tools and applications, protocol handlers, and • setup a user for PhpWiki in MySQL plugins. Each requires its own separate installation and • create a database for PhpWiki to use configuration, usually via hand editing of multiple text-based • do some other MySQL setup for PhpWiki via a SQL script configuration files. Static HTML files, images, scripts, libraries, provided in the PhpWiki distribution configuration files and data files are scattered in many places • edit the index.php file to tell PhpWiki the database name and throughout a complex directory structure. password, as well as where to find the database • open your web browser and type in the address of your This is not an unreasonable approach, particularly if you are machine, followed by “~” and your username then “/phpwiki/” developing applications to be installed only on your own custom and PhpWiki’s home page will load dedicated computers housed at a central location, as was traditionally done. While the installation may take some amount of additional time, that time may be more than made up for by 2.3. Deployment Problems and their Costs savings in development time that these various tools provide. As you might expect, for a platform where the user’s expectation of running new software is supposed to be drag-and-drop then As the deployment of many network applications are now being double-click, and where most users don’t even need to know how decentralized and distributed though, this equation changes. Now to get to the Unix shell, let alone how to use it, this kind of you are asking each of your users, which depending on your installation is simply just wrong. Unfortunately, its not just application may potentially be a large number of people, to each PhpWiki that suffers from this, but many hundreds of other tools, pay the price of additional installation complexity, to cover your most originally developed on Unix. savings in development time. Multiplying out the time, and factoring in resources available to the users, suddenly this tradeoff It is probably unfair picking on PhpWiki here, as the same may not be so appealing. example could be made of any number of other tools. The software was never explicitly designed to run on Mac OS X, The problems are being exacerbated as we’re seeing traditional which admittedly lives in a world all its own. Many of the steps Unix server tools (where most of these applications originated) above would still be required on traditional Unix platforms being made available on consumer operating systems. Common though, and are particularly sensitive to changes in system infrastructure tools like Apache, MySQL, and PHP are readily configuration (hardly unheard of on Linux for example). For a available for modern versions of Windows, and Mac OS X (which software package touted as ready-to-run right out of the box, that is Unix underneath, after all). Because of this, we’re seeing a great is perhaps stretching the truth somewhat. number of Unix packages being “ported” directly to Windows or Mac OS X, using the same installation and deployment techniques Generally, the developers of these tools are very talented that have “worked so well” for years in Unix. individuals, who have put great effort into their creations. In many ways it’s a huge shame that complicated deployment options are 2.2. A Typical Example keeping their work from benefiting a much broader audience. It’s a tribute to the quality of the software that enough people are A recent O’ReillyNet article [16] described in excruciating detail willing to persevere through complicated installations to get the the author’s experiences installing PhpWiki [11] on Mac OS X. benefits of using the software, even like with PhpWiki on Mac OS PhpWiki is a pretty standard Wiki application written in the X, where it was never explicitly designed to run. But those people scripting language PHP.