All posts in General

  • Deploying WordPress Using nix-docker

    Yesterday I wrote about nix-docker, a way to use Nix to provision Docker images in a nice way. Today I spent a little bit of time on a sample nix-docker configuration to deploy WordPress to a Docker container to demonstrate that nix-docker is not just a toy, but can be used to deploy a “real” complex-ish system implementing best practices like storing all state (mysql data, uploads, logs) that needs to persist between container restarts in a volume.

    The result can be found here. It’s ~130 lines long, but quite a bit of that is comments. It implements the following:

    • MySQL storing its data in the Docker volume /data under /data/mysql
    • Apache with PHP5 enabled listening on exposed port 80 and storing logs in /data/log
    • WordPress with an extra theme (to show how to do that), configured to store uploads in /data/uploads so that they, too, survive container restarts.

    That’s it!

    The result is a container that stores all important data in a volume, which you can mount from the host machine for easy back-up. To use:

    # nix-docker -b -t wordpress-app wordpress.nix
    # mkdir -p /data
    # docker run -v /data:/data -p 80:80 -t -i wordpress-app

    And voila!

    wordpress screenshot

  • Declaratively Provision Docker Images Using Nix

    I like Docker. If you don’t understand why, read the 3.5k word epic that I wrote about it at InfoQ. In this post I’ll assume you’ve read my InfoQ article, or are at least somewhat familiar with Docker and its features. Here’s two features that I care about in particular:

    • It makes applications portable to any cloud provider that supports Ubuntu 12.04+ (and in the upcoming 0.7 release CentOS too), which is basically every cloud provider in existence (although I hear that Google’s doesn’t yet support it. FAIL).
    • It makes trying out applications super simple: you no longer have to set up a hundred libraries and services that the applications to be able to run, everything comes in a single package, ready to run and ditch if it doesn’t work.

    After playing with Docker a while and deploying some apps with it, one thing that I feel could some help is the provisioning aspect of it: how do get your application and its dependencies into a container image? Read more

  • Opening the LogicBlox Gates

    As you may remember, I changed jobs at the beginning of the year and now work at LogicBlox, a very exciting company that aims to change the way software is developed by making it much more declarative using the LogicBlox smart database. Until last week, only customers and academic collaborators could have a peek to see what LogicBlox is all about, but, finally, this is now changing step by step. I’m personally extremely happy about this, because it’s just not as much fun to work on something that you can’t share with the outside world (at least for me).

    Read more

  • Zed Update

    It’s been quiet around the Zed editor project for a while, but over the past days I’ve put some time into it again. As it turns out, I ended using it less and less over time. The reason is simple: it was too much hassle to get started editing files. The procedure always consisted of cloning the Zed repository on the remote server where I wanted to edit files, cd ing into the right directory and then firing up a Python script to start the WebFS server. Then figuring out if the server want to edit files on is directly accessible from the Zed editor over HTTP or I have to open up some ports on a firewall. Bleh. Too much hassle.

    Last week I figured out a way to improve this situation while reading a ZeroMQ book. Even though I did not end up using ZeroMQ (which is amazing by the way) to keep dependencies low, it did lead me onto the idea of a proxy solution. But before I get into the technical nitty gritty, let’s have a look at what the flow looks like now.

    Read more

  • Who Needs Git When You Got ZFS?

    I’ve been playing a little bit with ZFS, Oracle’s (previously Sun’s) next-generation file system. Originally developed for Solaris, but since it’s open source also ported to Linux (as of 0.6.1 considered stable for production use) and Mac. While called a file system, ZFS is also a volume manager, so also takes over the job of partitioning your disk as well. Why is ZFS cool? It includes protection against data corruption, built-in support for RAID, snapshots and copy-on-write clones, and flexible and efficient ways of transferring data, e.g. for backups. To show what’s possible and push the limits somewhat, I’ll show how we get implement various features of Git, the version control system (or any version control system, for that matter) using ZFS. Of course, I’m not seriously suggesting you’d ditch a “proper” version control system, but it gives a good sense of what’s possible at the file system level.

    Read more

  • Parenthesical Culture and ParEdit

    After a few years of doing zero Clojure hacking, recently I’ve picked up a side project in Clojure again. Rather than using my usual editors to edit Clojure code, I chose to go the all-in hardcore Lisp route: Emacs with Paredit (I followed these instructions to set it up). And during that time I developed a theory of why people feel like they drown in the parentheses in Lisps and why the Lisp community fails to be bothered by this issue. Hint: ParEdit.

    Read more

  • Deploying a Simple Node.js Application with NixOps

    In a previous post I described how Nix could be used to easily set up a development environment without the use of virtual machines alternatives like Vagrant require. As an example I used setting up a development environment for a simple “Hello world” node.js application. At the very end I teased that the work we did could easily be reused to actually deploy our node.js application:

    Because we’re essentially unifying development environments and deployment environments, we have now also specified a lot of information that NixOps needs to actually deploy this application to a server. We’ll get into that in a future post.

    It’s time to make good on that promise. Let’s see how we can deploy our awesome hello world application to a newly created VirtualBox VM. Then, when we convinced ourselves this works correctly, let’s reuse the same Nix configuraton to deploy to EC2

    Read more

  • Setting Up Development Environments With Nix

    I remember my first day at Cloud9 IDE well. It was very similar to my first day Technical University of Delft as a PhD student, and my first day at LogicBlox: a day spent on installing a bunch of software, tweaking configuration files, environment variables, running services to get my system into a state so that I could actually start contributing. In some cases it took a few hours, in others it took a day. Either way, it was an utter waste of time. Worse, this setup problem often not a one-time thing. It gets really interesting if you have to develop on two projects (or two branches of the same project) that have incompatible software environment requirements. For instance, at some point, at Cloud9 we had a branch that worked only on node.js 0.4, but not on 0.6 and a separate branch that worked on 0.6. Every time I switched between these projects I had to make sure that the right version of node.js was active. Tools like nvm helped, but they’re a hassle and very specific to the particular platform. What about the Redis version that that particular project required, for instance? In aggregate weeks, months, years are wasted solving problems related to their development environment.

    Read more