Clojars.org Sysadmin Guide
This describes the production deployment on clojars.org. It's aimed at the clojars.org maintainers. You might find it interesting if you're trying to run your own repository though.
There's a user "clojars" which runs all the clojars webapp bits. The
repository lives in
We always run two instances of the webapp:
clojars-backup. They're started by Upstart as defined in:
/etc/init/clojars.conf http://clojars.org:8001/ /etc/init/clojars-backup.conf http://clojars.org:8002/
The nginx configuration will try to direct all requests to
only if it's down use
clojars-backup. There's a basic TCP load
balancer "balance" which does the same thing for the nailgun port for
the scp access.
The reason for running two instances is:
It allows us to have outage-free deploys (sessions aren't persisted at the moment so logged in users will get kicked out though).
clojars-backupis deployed first so that you can do a last minute sanity test on http://clojars.org:8002/ that the release built correctly and is working in the production environment.
Failover in case anything goes wrong with the primary instance. I'm in the habit of this from badly-behaved Java applications with massive GC pauses, deadlocks etc but Clojars tends to be pretty stable.
As the server's MOTD says, the release process is:
sudo -iu clojars deploy-clojars $GIT_TAG
That's just a simple shell script
- Checks out the given tag into a fresh directory.'
- Runs the tests and ensures they pass.
- Creates a release jar with
- Copies the uberjar into
- Updates the symlink
It will then ask you to do any last minute testing and then you can run "sudo restart clojars" yourself to update the primary webapp instance.
clojars-web-current.jarsymlink back to the previous version:
sudo -u clojars ln -sf clojars-web-0.8.1-standalone.jar ~clojars/releases/clojars-web-current.jar
Restart the backup instance.
sudo restart clojars-backup
Wait until clojars-backup has started up to avoid outages.
Restart the primary instance (if you need to):
sudo restart clojars