I’ve been using AppLogic for exactly one month today, and I’ve learned a whole heckuva lot about what it takes to build an infrastructure using the AppLogic grid operating system. One of the very first things I learned is that there is just a TON of documentation, but a very large portion of it is really heady, high-level theoretical stuff. The real practical, nuts-n-bolts, ‘click-here-type-this’, how-to-style knowledge can be had from there, but it’s kinda lost in all the nebulous conceptual stuff. I got fantastic help from 3tera in their forums, as well as from TGL, which is our actual grid host, so I wanted to take a moment and write down some tips here for my own reference, and to help anyone else who is tired of searching forum posts for this information.
1. Creating placeholder volumes, at time of writing, isn’t documented, and is a really important operation you’re going to need to know how to do. The point of confusion is that when you use a catalog appliance, you can see in the “Volumes” tab of the class editor that there’s a volume mounted to /dev/hdaN, and maybe some other volumes defined by default. This sets the expectation that if *you* create a volume, map it to /dev/hdaN, and then map a User Volume to that, then when the appliance starts up again, everything will magically fall into place. This is not how AppLogic works. You *still* need to start the application, log into the appliance, create the mount point, and edit /etc/fstab to get the mount to actually happen. You can test if it works without restarting your application by running ‘mount -a’ after you edit /etc/fstab. If that doesn’t work, then you might’ve forgotten to save the application after you created the volume. Save and restart, and try again.
2. Getting shell access to the controller is one of the first things you’ll want to do after finding your way around. The controller gives you access to all applications, all components of those applications, and all volumes used by those components. It’s quite powerful. You can get a shell on the controller from the dashboard just after you log in, but it’s kinda slow and clunky (“java-like” if you will), so you’ll want to use your own terminal application. In order to access the controller, you *must* use an ssh key. You can’t log in with a password at time of writing (and I prefer it that way). Generate an ssh key, and either send your public key to a support person and tell them to put it in place, or you can try using the “Shell Login” button on the dashboard and running this command in the resulting window:
user set <username@domain.com> sshkey="ssh-dss AAAAB3NzaC...afdk5lqEGOfJJnM+L4="
Once you do that, you can log in as root@ip.of.controller.host from your local terminal application. If you’re using openssh, you can create a ~/.ssh/config file and put in the following so that running “ssh controller” will take you to the right place automagically:
Host controller
HostName ip.of.controller.host
IdentityFile id_rsa
User root
3. If you’ve set up SSH access to the controller, you can save yourself the trouble of setting up a development box or similar that acts as the only machine with write access to your web content by uploading content directly through the controller. Here’s the general syntax:
scp myfile root@controller:/app/<appname>/<component>/mnt/data/.
That will copy ‘myfile’ in the current working directory on my local machine to /mnt/data on the component named in <component> in the app named <app>.
Since the controller has write access to everything, all you need to know is the upload path, and your web developers can use sftp to manage the site’s files. I haven’t set up my developers yet – but I’m using this sftp/scp access to volumes mounted on *running* appliances already myself during the infrastructure building and testing phase. The ability to do this through the controller has saved me a lot of headaches, as well as some disk, network, cpu, and memory resources. It also keeps you from trying what I tried: creating a placeholder volume mounted read-only by the web servers, but read-write by a dev server. It is *documented* that this will corrupt the volume. The controller would appear to be an exception to that rule.
4. If you’re using the bash shell, you might find these client side macros for bash useful!
5. In setting up MySQL, you typically do a ‘GRANT <somerights> TO <someuser>@<somehost> IDENTIFIED BY…’ to give appropriate rights to your web application. However, you’ll find at this point an interesting tidbit: your database cannot resolve your web server, and can’t otherwise connect to it except in response to calls made by the web server to the database server over the terminal you’ve defined on the web server for the sole purpose of talking to the database server. This terminal, in all default template applications at least (and it’s recommended, I would imagine), is defined to only support calls to a mysql database, and can only connect to the database server. Further, assuming it’s the only thing connected to the database server, you *can* use ‘<someuser>@’%” in your GRANT statement. In MySQL, “%” is a wildcard meaning ‘any’. If you need to give different rights to connections coming in from different hosts to the same server and database on that server, I guess the expectation is that you do that by defining different users, which seems reasonable.
6. If your app fails, the first thing you should do is run ‘log list n=30’, which spits out the last 30 lines of the controller’s log. If a particular component causes your whole app to fail to start, you can stop the app, make changes to that component, mark the component as ‘standby’, bring up the app (which will now succeed because the troubled component isn’t in the startup list), and you can then use ‘component <name> start’ and ‘component <name> stop’ to see if it’s working properly. Also, try using ‘app start –debug’! Unfortunately, changes to the appliance in the GUI editor require an application restart to take effect. I hear they’re working on that :-/
7. Stuff I am still working on which isn’t documented but which I know is possible: creating assemblies (in other words, creating a single component from multiple logical components), and linking *applications* together as if they’re components, which would be awesome to be able to do, because then if you have, say, 4 web servers, you can group them into two separate applications, separate from everything in the main application, and if you need to make changes to the web servers that would require a whole-app restart, you can just restart the app containing the two web servers. I’m working on figuring both of these out, but it’s undocumented, and I’m not sure if it’s necessarily safe for production use or not. More learning to be done, as usual.
More tips? Put ’em in the comments!!
Blogged with Flock