Tag Archives: setup

Using CouchDB in Rookeries – Part 2 – Setting Up a Remote CouchDB Server

Posted on by

Overview

In the second instalment of my series on adding CouchDB support to
Rookeries, I’ll be talking about how I provisioned CouchDB on my remote
server.

Now it sounds counter-intuitive why I would talk about creating and
populating CouchDB databases first before writing about installing
CouchDB. The reason for this backwards step, is that I already have
CouchDB installed locally. At my daytime job at
Points we use CouchDB extensively, so I already have
CouchDB installed locally on my workstation. I have also worked with the
Operations team to provision CouchDB servers. However it is a different
story when trying to provision and configure CouchDB yourself on your
own servers. This blog post details some of the things I learned along the way.

Since the setup of Couch is a bit involved, I will divide this up over two blog
posts.

Provisioning Rookeries with Ansible

One of the stated goals of Rookeries is create a developer-friendly
blogging platform that is easier to install and setup than WordPress.
That is a tall order for a Python WSGI app, since there is some more
setup involved than just installing Apache and mod_php and unzipping
Wordpress into a folder. (Even with WordPress there is more involved
when doing a proper and maintainable setup.)

So while putting up a production ready Python WSGI app is more involved
technically, this does not mean the end-user needs to experience this.
That is where the Rookeries Ansible
role comes into
play. I created that Ansible role to encapsulate the complexity of the
installing Rookeries. (This role uses [the nginx-uwsgi-supervisord Ansible
role which I wrote to handle the actual setup of a WSGI app on an bare-bones
Ubuntu server]
(https://bitbucket.org/dorianpula/ansible-nginx-uwsgi-supervisor).) All of the
details concerning the setup and configuration of a CouchDB server for a
Rookeries installation is included in the Rookeries Ansible role.

Installing Latest CouchDB on Ubuntu Linux

I use the latest Ubuntu LTS (14.04) for both my development and
deployment environments. Having the same environment reduces the effort for meI
to take Rookeries from development to production. However the
latest version of CouchDB for Ubuntu 14.04 is 1.5.0 and I wanted to use
the latest stable version of CouchDB. While upgrading between CouchDB
versions is straightforward, I know that I am less likely to upgrade to the
latest version of CouchDB once Rookeries stabilizes. And there is no
point on starting off with an older version of your database right from
the start of a project.

Fortunately the CouchDB devs distribute the latest stable version of
CouchDB via a convenient
PPA. The
instructions on how to install CouchDB via the PPA is right on the
Launchpad page.

Installing via Console

# add the ppa
sudo add-apt-repository ppa:couchdb/stable -y
# update cached list of packages    
sudo aptitude update -y
# remove any existing couchdb binaries
sudo aptitude remove couchdb couchdb-bin couchdb-common -yf
# install the latest
sudo aptitude install couchdb

Provisioning via Ansible

The Rookeries Ansible role translates those instructions (minus the
removal of existing packages) to:

- name: add the couchdb ppa repository
  apt_repository: repo="ppa:couchdb/stable" state=present

- name: install couchdb
  apt: pkg=couchdb state=present
  with_items:
    - couchdb
    - couchdb-bin
    - couchdb-common

Running CouchDB

Now that we have CouchDB installed, we need to control it like we would any
other service on Linux server. Surprisingly enough when I tried to find the
packaged CouchDB service scripts (using the service command), I did not find
anything!

> sudo service --status-all
# ... A lot of entries but no couchdb ...

Turns out that CouchDB package comes with an Upstart script rather than
a traditional System V initrc script. (That itself is probably not a bad
thing.)

> sudo status couchdb
couchdb start/running, process 5311
# There it is.

Starting and stopping service through Upstart is done via the ‘start’ and
‘stop’ commands. There are also ‘reload’ and ‘restart’ commands.

> sudo restart couchdb
couchdb start/running, process 15987

Side Note About Upstart vs Services vs Systemd

Update: I found an article that explains the evolution and the current situation of Linux service management. It explains things much better than I do and in much more detail. I learn quite a bit from it.

If you follow Linux developments and news, you might have heard about the development and controversy around new init systems. I will try to explain \nthese developments briefly here since we are on the topic of service scripts.

The old System V style for service scripts (in /etc/init.d/ or\n/etc/rc.d/) is not flexible when it comes to managing dependencies and running outside of the prescribed run-levels that happen during boot and shutdown.
However there is disagreement about what would would be a better alternative. Upstart was Canonical/Ubuntu’s attempt to create a more flexible system for managing services. However Debian and many other Linux distributions have recently switched over to another such system called systemd. Part of the controversy about systemd stems from the architectural design of systemd (which seems monolithic at first glance as it tries to solve service management, logging and few other seemly unrelated system level issues).

Another part of the controversy stems from how the project lead’s handled his previous project: PulseAudio. I will admit that my first experiences with PulseAudio were pretty rocky, and I missed how well using plain old ALSA worked. However these issues have since gone away, and I can not think of any PulseAudio or any audio issues I’ve encountered in Linux recently. (Ironically Windows 7 gives me more grief with sounds issues than Linux nowadays.)

I personally don’t know enough about systemd to form an opinion. Sure I am a bit anxious to see how this all plays out. However this is a case of wait and see. In the meantime be aware that the exact semantics on how you interact with services will change in the near future.

Update #2: An interview with Lennart Poettering about systemd, its design and intentions

Provisioning with Ansible

Fortunately Ansible does not make a distinction of what the underlying
service script setup is used. The Ansible service module works with initrc,
service, Upstart and systemd services without complaint.

In the Rookeries Ansible restarting the CouchDB service becomes a single
task.

- name: stop couchdb server
  service: name=couchdb state=restarted

Next Up

In the next blog post I’ll write up about configuring and securing
CouchDB.

Linux… the Future of Computing

Posted on by

I’m a Linux user.  So I always like to strain my ear to hear news about Linux.  But this I didn’t expect.

Caroline and I did a bit of computer shopping before going to watch a film together on Saturday.  While we wandered the aisles in the nearby Futureshop, she turned and asked me what I knew about Linux.  I was surprised.  Caroline is a very smart and talented girl.  She finished statistics at the University of Toronto after all. But she is not a person who follows computer tech.  She further told me that her mother told her that Linux was the future of computing.  And then she asked whether Linux was for her.  To top it off, we bugged the local salesperson… and I had an intelligent conversation about what computer she should get.  (No offence to the smart Futureshop employees out there, but a good chunk of your coworkers are not all that knowledgeable about computing as they should.)  And the salesperson, said he that his life would be easier if PC came pre-loaded with Linux.  I took this all in… amazed.  After some thought on what she would be using the computer I told her to stick with Windows for now.  Why?

Linux and Linux-related technology looks like very much the future of computing.  Thanks to the free software licensing, active communities and flexibility of open source development methodologies, many vendors are looking toward using Linux.  For a vendor Linux provides a way out of the per unit licensing problem.  Also it lets the vendor to control the build out of  a product from top to bottom.  Linux appears creeping into non-desktop computing platforms.  We hear about Linux competing with Windows in the netbook market.  We hear of Linux taking on cellphones with projects such as LiMo, OpenMoko and Google’s Andriod.  The hyper-fast development pace makes Linux progress in leaps and bounds past its competitors.  Nokia heavily invested in Linux with their Maemo-powered Internet Tablets.  Intel invests in Linux with drivers and Moblin.  nVidia and ATI both crank out graphics drivers like no tomorrow.  Dell and HP are each trying to outdo each other selling Linux servers and laptops.  News articles compare Ubuntu Linux on the same level as Windows XP & Vista and Mac OS X.  So forth and so on.  Five years this was unimaginable.  When I installed Linux on my laptop and desktop machines in 2002 and 2001… I could not imagine Linux being more than a cool minor alternative.  Something to play with, and use for fun computing.

So with all these cool developments, why did I not sell Linux to Caroline?  I could of.  Linux could work for her.  But I didn’t because Linux is the future of computing.  Linux exists in the present of computing, but the technology is still in a transitionary stage.  The next few years is where we leap the chasim from novel innovator toys to mainstream consumers.  However along the way there are growing pains.  Graphics and sound need to get up to par.  Support companies need to spring up around the technology.  We are getting there.  But right now, I feel uncomfortable offering Linux to a mainstream consumer and leaving them to their own devices.  If I were to support the system, I could easily setup a Linux system that Caroline could use and enjoy.  A Linux system could be setup to let her do her surfing, watching TV, connecting her digital camera and media organization.  But she could only turn to me for help if something goes wrong.  This is not something I want to inflict on either her or myself.  In a few years time, yes, Linux will work for her.  But it will most likely be everywhere and work for everyone.