Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging


 
„Das @netways Blog kann man auch generell einfach mal empfehlen: https://www.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.
Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!
Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!
CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!
Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.
Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.
Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.
Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.
Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

JSON in bequem

Wenn man mit diversen Tools arbeitet, die wir in diesem Blog immer wieder bearbeitet, stößt man unweigerlich irgendwann auf JSON formatierte Texte. Während es sicher für den einen oder anderen IT-God kein Problem ist, das JSON im Hirn zu parsen und JSON-formatierter Text höchstens eine angenehme Erleichterung zu Bytecode ist, möchte ich hier kurz zweieinhalb Wege für Sterbliche vorstellen, um im
Wirrwarr von Klammern nicht die Übersicht zu verlieren.
Dabei bringen manche Dienste bereits eine Möglichkeit mit, den Output einfacher lesbar zu machen, andere verlassen sich dabei ganz auf externe Tools. Warum er nicht immer “einfach” gehalten wird, lässt sich ganz einfach damit erklären, das JSON eingentlich eh nur entworfen wurde, um von Maschinen verarbeitet zu werden und Menschen in den Wahnsinn zu treiben. Da sorgen Zeilenumbrüche und Einrückungen nur dafür, dass unnötig viele Daten übertragen werden.
Die REST API von Elasticsearch bietet je nach Endpunkt mal schön formatiertes, mal unformatierters JSON an.

# curl localhost:9200
{
  "name" : "y2G7v2X",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "1KYRb5mUQ8CaTSJDM-6djQ",
  "version" : {
    "number" : "6.3.2",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "053779d",
    "build_date" : "2018-07-20T05:20:23.451332Z",
    "build_snapshot" : false,
    "lucene_version" : "7.3.1",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

Dagegen sieht jeder Unterpunkt entsprechend unübersichtlich aus.

# curl localhost:9200/_cluster/health
{"cluster_name":"elasticsearch","status":"green","timed_out":false,"number_of_nodes":2,"number_of_data_nodes":2,"active_primary_shards":341,"active_shards":682,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":0,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":100.0}

Für Elasticsearch (und mittlerweile auch für Icinga 2!) gibt’s hier aber Abhilfe durch den Schalter ?pretty.

# curl localhost:9200/_cluster/health?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 341,
  "active_shards" : 682,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

Da man diverse JSON Monster aber auch mal als Datei vorliegen hat oder nicht alle Dienste solche Komfortfunktionen bieten, braucht man immer wieder externe Hilfe. Dafür gibt’s die Allroundlösung, die überall funktioniert, wo Python installiert ist, also quasi bei jedem ernst zu nehmenden Betriebssystem.

# curl -s localhost:9200/_cluster/health | python -m json.tool
{
    "active_primary_shards": 341,
    "active_shards": 682,
    "active_shards_percent_as_number": 100.0,
    "cluster_name": "elasticsearch",
    "delayed_unassigned_shards": 0,
    "initializing_shards": 0,
    "number_of_data_nodes": 2,
    "number_of_in_flight_fetch": 0,
    "number_of_nodes": 2,
    "number_of_pending_tasks": 0,
    "relocating_shards": 0,
    "status": "green",
    "task_max_waiting_in_queue_millis": 0,
    "timed_out": false,
    "unassigned_shards": 0
}

Das war’s dann aber auch schon mit dem, was man einfach auf diese Weise machen kann. Oft reicht das ja auch aus. Wer aber gern etwas mehr an Möglichkeiten haben will, sollte sich unbedingt mal jq installieren.

# curl -s localhost:9200/_cluster/health | jq
{
  "cluster_name": "elasticsearch",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 2,
  "number_of_data_nodes": 2,
  "active_primary_shards": 341,
  "active_shards": 682,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 100
}

Soweit so fad. Ausser, dass ich auf meiner Shell noch schöne farbliche Hervorhebungen sehe und Ihr im Blog hier nicht. 😛
Interessant wird’s dann aber, wenn man mit jq anfängt, den Output auch gleich zu filtern. Dazu ein Auszug eines API Outputs von Icinga 2.

{
  "results": [
    {
      "attrs": {
        "__name": "canis",
        "acknowledgement": 0.0,
        "acknowledgement_expiry": 0.0,
[...]
    },
    "joins": {},
    "meta": {},
    "name": "canis",
    "type": "Host"
  },
[...]

Wenn man den Output dann durch einen jq Aufruf inkl. Filtern schickt, kann man auf die eigentlich interessanten Daten filtern. Ich hab’ mir freundlicherweise genehmigt, die folgenden Beispiele aus dem Icinga 2 Buch zu entnehmen.

$ curl ... |jq '{name: .results[].name}'
{
  "name": "canis"
}
{
  "name": "fornax"
}
{
  "name": "virgo"
}
[...]

Diese Filter kann man dann beliebig erweitern.

$ curl ... |jq '{name: .results[].name, address: .results[].attrs.address}'
{
  "name": "sculptor"
  "address": "172.16.2.11"
}
{
  "name": "fornax"
  "address": "172.16.1.11"
}
...

Eine umfassende Anleitung für jq gibt’s auch. Je nach Bedarf kann es sich aber auszahlen, sich erstmal diverse Tutorials anzusehen, da hier oft der Zugang etwas leichter gemacht wird.

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Versteckte Perlen in Icinga Web 2

In Icinga Web 2 gibt es ein paar versteckte Parameter, die leider noch nicht dokumentiert sind aber sicher hier und da hilfreich sein können.
Entwicklermodus für JavaScript und CSS
Icinga Web 2 liefert eigentlich JavaScript und CSS komprimiert an den Client aus. Als Entwickler oder zur Fehlersuche ist aber hilfreich, die Kandidaten in ihrer Originalform auszuliefern. Dazu hängt man den Parameter _dev=1 an die URL.
Listen und Detail-Informationen exportieren
Die Listen zur Ansicht der Hosts, Services und Gruppen und der jeweiligen Detail-Bereiche lassen sich nach JSON und CSV exportieren. Dazu hängt man den format Parameter mit entweder json oder csv als Wert an, also z.B. icingaweb2/monitoring/list/services?format=json.

Vollbildmodus
Um eine Sicht in Icinga Web 2 in den Vollbildmodus zu bringen, hängt man einfach die zwei Parameter showCompact=1 und showFullscreen=1 an die URL. showCompact blendet die Kontrollelemente wie den Filter-Editor und Paginator aus und showFullscreen das Menü und den Header. Das ganz sieht dann so aus:

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Icinga2 API und BitBar auf MacOs

preview1Wir wollen APIs, warum? Weil sie schnell, einfach zu integrieren und zu bedienen sind. Nun hat Icinga2 eine API und es entstehen ganz viele Möglichkeiten diese zu nutzen. Wir bauen uns Dashboards mit Dashing oder zeigen den Status von Hosts in Foreman an.
Ich bin letztens über ein Tool BitBar gestolpert, dieses Tool kann mit einfachen Skripten die eigene “Mac OS X menu bar” erweitern. Hierfür braucht es nur die richtige Formatierung der Ausgabe und BitBar generiert ein weiteres Dropdown Menu.
Ich hab mir die Icinga2 API zu nutze gemacht und eine kleine Erweiterung gebaut um mir den Status von Icinga2 in meiner Menubar anzuzeigen.
Im Menu wird dann der globale Status entweder in grün oder rot, abhängig davon ob Hosts “down” und “unhandled” sind, angezeigt.
Der Aufruf dafür kann der Adresszeile im Browser entnommen werden.
/icingaweb2/monitoring/list/hosts?host_state=1&sort=host_severity&host_unhandled=1
Wenn wir am Ende dann ein “&format=json” an die URL hängen, haben wir ein gängiges Format um das Ergebnis in jeglichen Applikationen zu verwenden.
[{"host_icon_image":"","host_icon_image_alt":"","host_name":"web01","host_display_name":"web01","host_state":"1","host_acknowledged":"0","host_output":"DOWN","host_attempt":"1\/3","host_in_downtime":"0","host_is_flapping":"0","host_state_type":"1","host_handled":"0","host_last_state_change":"1474556541","host_notifications_enabled":"1","host_active_checks_enabled":"0","host_passive_checks_enabled":"1"},
Mehr dazu gibts auf Github unter icinga2_api_examples oder natürlich in der Icinga2 Dokumentation.

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

JSON-Streams über HTTP

Viele Anwendungen sind darauf angewiesen, in Echtzeit Benachrichtigungen zu bestimmten Ereignissen zu erhalten:

  • Der Benutzer soll sofort über neue E-Mails benachrichtigt werden.
  • Notifications von einem Monitoring-System sollen durch eine Anwendung in der Taskleiste angezeigt werden.
  • Nachrichten, die per Instant Messaging versendet werden, sollten zeitnah beim Empfänger ankommen.

Zur Umsetzung solcher Anwendungen bieten sich durch die Verwendung von bekannten Standardprotokollen wie HTTP signifikante Vorteile:

Vorhandene Tools und Infrastruktur

Für HTTP gibt es in nahezu jeder Programmiersprache nativ integrierte Libraries. Hierdurch sinkt für Entwickler, die einen neuen Client für das Protokoll schreiben wollen der initiale Aufwand. Zwar unterscheiden sich die Anwendungen trotzdem noch an einigen Stellen (Wie sehen einzelne Messages aus? Welche URLs werden verwendet?), dafür werden andere Themen wie Authentifizierung bereits durch den Standard abgehandelt.
Um im Fehlerfall bzw. während der Entwicklung Probleme zu analysieren gibt es bereits etliche Tools. Diese reichen von einfachen konsolen-basierten HTTP-Clients wie curl und wget über Protokoll-Analyse-Tools wie Wireshark hin zu speziell für HTTP entwickelten Debug-Hilfsmitteln wie Fiddler.
Zusätzlich unterstützt HTTP mittels HTTP-Proxies “Routing”, da es in jeder Anfrage alle notwendigen Adressinformationen bereithält.

Streaming über HTTP

Nun ist HTTP zunächst ein Protokoll, das darauf basiert, dass für eine Anfrage jeweils genau eine Antwort übermittelt wird. Wie können wir nun also dem HTTP-Client unaufgefordert Events schicken?
Die einfache Grundlage hierfür ist eine Technologie, die als “Long Polling” bekannt ist: Der HTTP-Client sendet hierbei zunächst einen Request und bekommt vom Server auch eine Antwort. Diese Antwort hat allerdings kein Ende: Der Server sendet über die noch bestehende Verbindung JSON-kodierte Ereignisse sobald sie vorliegen.
Der Client muss dazu die Möglichkeit haben, zwischen den einzelnen JSON-kodierten Ereignissen unterscheiden zu können. Am Beispiel von zwei JSON-Ereignissen möchte ich hier auf die unterschiedlichen Ansätze eingehen.
Beispiel:

  • { “id”: 1, “message”: “Hallo Welt” }
  • { “id”: 2, “message”: “Dies ist ein Test.” }

Inkrementeller JSON-Parser

Ein JSON-Parser, der den Datenstrom inkrementell parsen kann, hat die Möglichkeit, zu erkennen, an welcher Stelle eine JSON-Message aufhört und die nächste beginnt. Die Messages werden hierbei also einfach aneinander gehängt. Der Body der HTTP-Antwort würde dabei etwa so aussehen:

{ "id": 1, "message": "Hallo Welt" }{ "id": 2, "message": "Dies ist ein Test." }

Vorteil hierbei ist, dass die Implementation des Servers sehr einfach ist. Allerdings können nur wenige JSON-Parser inkrementell parsen, was die Entwicklung des Clients erschwert.

Eine JSON-Message pro Zeile

Hierbei werden einzelne JSON-Messages per Newline (“\n”) getrennt. Beim Encoden der Messages muss darauf geachtet werden, dass diese selbst keine Newlines beinhalten.

{ "id": 1, "message": "Hallo Welt" }
{ "id": 2, "message": "Dies ist ein Test." }

Auf Clientseite ist dies im Regelfall recht einfach umzusetzen. Die Entwicklung des Servers wird minimal dadurch erschwert, dass mit Newlines innerhalb der JSON-Messages richtig umgegangen werden muss.

Längenangabe vor jeder JSON-Message

Bei dieser Möglichkeit sendet der Server vor jeder eigentlichen Message die Länge der JSON-Daten gefolgt von einem Newline:

37
{ "id": 1, "message": "Hallo Welt" }
45
{ "id": 2, "message": "Dies ist ein Test." }

(Wer nachzählt kommt möglicherweise darauf, dass die Längenangaben um ein Byte zu groß sind. Hierbei ist zu beachten, dass ich für dieses Beispiel aus Gründen der Lesbarkeit nach den JSON-Messages ein Newline eingefügt habe, das dann auch Bestandteil der Message ist und mitgezählt werden muss.)
Im Regelfall sollte es sowohl für Client als auch Server recht einfach sein, dies umzusetzen.

Weekly Snap: OSDC 2012 from Start to Finish, with Zend JSON in Between

23 – 27 April was dedicated to the Open Source Data Center Conference with brief digression into Zend JSON context switches by the development team.
From the Puppet, OpenNebula and IPv6 workshops on the conference eve, to the engrossing presentations and evening event after, this year’s OSDC was a resounding success.
We hope you enjoyed the event as much as we did, and look forward to seeing you at the RootCamp in Berlin or Open Source Monitoring Conference later this year.

Zend JSON-Ausgabe

Um JSON mit dem Zend auszuliefern, könnte man auf die harte Tour, Header selbst setzen, Daten enkodieren und layouts deaktvieren oder man nutzt Funktionalitäten, die das Framework schon bietet. Um zum Beispiel JSON direkt zu senden, bedient man sich Zend_Controller_Action_Helper_Json:

class TestController extends Zend_Controller_Action
{
    public function indexAction()
    {
        $data = array(
            'test' => true
        );
        /**
         * Call Zend_Controller_Action_Helper_Json::direct
         */
        $this->_helper->json($data);
    }
}

Über die Url ../test erhalten wir die Ausgabe in JSON inklusive dem korrekten Content-type application/json.
Nachteil dieses Aufruf ist, dass die dispatch loop sofort unterbrochen wird und somit eventuelle Erweiterungen durch Plugins nicht mehr aufgerufen werden.
Besser ist es, den ContextSwitch Action-Helfer zu benutzen, welcher XML und JSON unterstützt, layouts deaktiviert und Header enstrechend setzt:

class TestController extends Zend_Controller_Action
{
    public function init()
    {
        $this->_helper
             ->contextSwitch()
             ->addActionContext('index', 'json')
             ->initContext();
    }
    public function indexAction()
    {
        $this->view->test = true;
    }
}

Die JSON-Ausgabe ist nun über die Url ../test?format=json erreichbar.
Um sich den format-Parameter zu sparen, kann man für alle actions im Controller das json-Format erzwingen:

public function init()
{
    /**
     * Force json format
     */
    $this->_request->setParam('format', 'json');
    ...
}

Zum weiterlesen: Zend ContextSwitch

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Einführung zu CouchDB

Bei CouchDB handelt es sich um ein in Erlang geschriebenes dokumentenbasiertes DBMS, das durch sein Design einige interessante Features anbietet.
Die meisten Linux-Distributionen bieten bereits vorgefertigte Pakete an. Unter Ubuntu kann CouchDB z.B. wie folgt installiert werden:
$ sudo apt-get install couchdb
Für den Zugriff auf CouchDB-Datenbanken sind keine speziellen Client-Anwendungen notwendig. Da CouchDB eine HTTP-basierte REST-Schnittstelle anbietet, kann nahezu jeder beliebige HTTP-Client (z.B. curl) verwendet werden, um auf die Daten zuzugreifen.
CouchDB bietet dennoch von Haus aus eine einfache Oberfläche zum Administrieren und Bearbeiten von Datenbanken an. Standardmäßig ist dieses unter http://localhost:5984/_utils/ erreichbar.
Im Gegensatz zu relationalen Datenbanksystemen ist es bei CouchDB nach dem Anlegen einer Datenbank nicht notwendig, ein Datenbankschema in Form von Tabellen zu definieren.
Stattdessen werden JSON-formatierte Dokumente direkt in der Datenbank abgelegt. Jedes Dokument verfügt dabei zunächst nur über zwei Felder:

  • _id: ein eindeutiger Bezeichner für das jeweilige Dokument; wird er vom Benutzer nicht mit angegeben, vergibt CouchDB automatisch eine einzigartige ID
  • _rev: die Revisionsnummer des Dokuments; sie wird bei jedem Update hochgezählt und intern von CouchDB zur Lösung von Konflikten verwendet

Weitere Felder können nach Bedarf beliebig hinzugefügt werden. Dabei ist es möglich, dass mehrere Dokumente unterschiedliche Felder enthalten.
Ein Zugriff auf die Dokumente ist über das _id-Feld möglich. Um über andere Felder nach Dokumenten zu suchen, müssen Views definiert werden. Diese bestehen aus JavaScript-Funktionen, die Dokumente bestimmten Schlüsseln zuordnet.
Um beispielsweise bei einem Blog alle Posts finden zu können, die an einem Donnerstag veröffentlicht wurden, könnte man eine View definieren, die den einzelnen Wochentagen jeweils die entsprechenden Blog-Posts zuordnet. Über die optionale Integration von Apache Lucene ist es auch möglich, Volltextsuchen durchzuführen.
Views werden beim Bearbeiten von Dokumenten aktualisiert und verwenden intern einen binären Baum, um eine ähnliche Performance anzubieten wie Indizes bei relationalen Datenbanksystemen.
Mehr Informationen zu CouchDB-Features wie z.B. Replikation, Dokumenten-Validierung und etlichen weiteren gibt es auf der offiziellen Webseite unter http://couchdb.apache.org/ und im online verfügbaren Buch “CouchDB: The Definitive Guide
” unter http://guide.couchdb.org/.