Profitbricks bietet neben dem Datacenter Designer auch eine API um Aktionen im Datacenter durchzuführen. Das geht über einen Client, aber auch über ganz normale SOAP-Webservice-Requests. Beispielsweise mit der Microsoft Powershell. Grundlage der hier geposteten Infos sind die Tutorials aus dem Profitbricks Blog von Thomas Vogel.
Wie bereits im vorigen Post erwähnt, kann man beim IaaS Anbieter Profitbricks seine Ressourcen über einen sog. Datacenter Designer so provisionieren, wie man sie zum aktuellen Zeitpunkt benötigt. So lässt sich auch der verfügbare Storage nachträglich erweitern. Einfach den Regler von bspw. 35 GB auf 100 GB ziehen, auf Provisionieren klicken, kurz warten und das war's... oder nicht? Natürlich gehts bei Storage nicht ganz so einfach wie bei Kernen und/oder RAM. Denn das Betriebssystem hat ja Partitionstabellen geschrieben und da pfuscht Profitbricks gottseidank nicht rein.
Aufgrund kürzlicher Erfahrungen mit dem Cloud Computing Anbieter Profitbricks, möchte ich hier ein paar Tipps & Tricks posten. Profitbricks bietet - ähnlich wie Amazon Web Services oder Google Cloud Platform - ein Infrastructure as a Service (Iaas) Angebot. Dabei werden keine fest definierten virtuellen oder physikalischen Maschinen gebucht und bezahlt, sondern man bezahlt minutengenau für die Performance, die man auch bucht. Zum jetzigen Zeitpunkt kostet das wiefolgt:
Wer seinen Drupal Commerce Shop an Google Merchant Center anbinden möchte, kann dafür einfach das bestehende Modul nutzen. Allerdings ist das Modul ziemlich fest an die vorgegebene Struktur und den Aufbau von Drupal Commerce gebunden.
Afterbuy ist eines dieser Tools, die man ernsthaft in Betracht ziehen sollte, auch wenns einem beim ersten Kontakt kalt den Rücken runterläuft. Denn kaum eine Anwendung ist so hässlich und grausam unintuitiv wie Afterbuy. Ich würde jetzt sagen das Preis-Leistungs-Verhältnis ist gut, aber wem es bei Leistung nicht nur auf Funktionen, sondern auch auf Bedienbarkeit ankommt, dem sei geraten weiterzusuchen. Da ich kürzlich in den zweifelhaften Genuss kam, die Afterbuy Schnittstelle in eine Drupal-Commerce-Instanz einzubauen, schreibe ich hier einen kleinen Leitfaden, wie's funktioniert.
Eine wertvolle Neuerung aus Drupal 7 ist die EntityFieldQuery API. Hiermit können programmatische Inhalts-Abfragen über jede definierte Entität getätigt werden. Wollte man in Drupal 6 programmatisch eine Datenbankabfrage über bestimmte CCK-Felder machen, empfahl es sich aus Kompatibilitätsgründen mit Views eine Abfrage zu erstellen, diesen dann im Code zu laden und auszuführen. So war sichergestellt, dass kein Update am CCK Modul oder Veränderungen an der Datenstruktur zu Kompatibilitätsproblemen mit dem eigenen db_query()-Call führten. EntityFieldQuery ist eine alternative und deutlich bessere Abstraktionsschicht für diesen Anwendungsfall, denn es ist eine Drupal 7 Core Funktionalität und kein Modul in dessen Abhängigkeit man sich begibt, es arbeitet für simple Calls deutlich performanter als Views und es kann extrem flexibel eingesetzt und sogar um eigene Methoden erweitert werden. Die Fähigkeiten und Performance dieser API gehen soweit, dass es zu einer Grundüberlegung gemacht werden sollte, ob man für eine Darstellung von Inhalt das Views Modul oder doch lieber ein eigenes Modul mit EntityFieldQuery nutzen sollte.
Performance Optimierung ist ein wichtiges Thema bei der Arbeit mit Drupal 7. Denn Drupal ist ein System, dass zum Installationszeitpunkt schnell ist, wie der Wind, aber sich mit wachsender Seitenkonfiguration nach und nach verlangsamt. Das hat zum einen mit der Tatsache zu tun, dass Drupal eine starke Bindung an seine Datenbank hat und die Abfragen bei jedem Page-Request bei unvorsichtiger Konfiguration schnell mal in den dreistelligen Bereich steigen können. Zum anderen liegt das auch an der modularen Architektur, denn bei jedem Bootstrap werden alle aktivierten Module inkl. ihrer Hooks und Konfigurationseinstellungen abgearbeitet und zusammengestellt. Der Segen des Einen wird zum Fluch des Anderen, denn verzichtet man auf Module, schränkt man genau die Vorteile von Drupal ein, die das CMS möglicherweise überhaupt erst zum System der Wahl gemacht haben. Aber natürlich gibt es Abhilfe und eine High Performance Seite auf Basis von Drupal ist mit ein paar Grundregeln und einigen Anpassungen möglich.
Hier ein Code-Snippet, wie man mit der Funktion drupal_http_request() einen Webservice abfragen kann.
Hin und wieder ist es nötig zu prüfen, ob der aktuelle Besucher der Seite ein Bot ist. Z.B. dann wenn man einen kostenpflichtigen Webservice nutzt und verhindern möchte, dass Suchmaschinen-Bots und -Crawler die Rechnung in die Höhe treiben. Das geht recht zuverlässig über den User-Agent-String.
Wer eine simple Volltextsuche für seine Drupal-7-Seite benötigt, aber nicht jedesmal den gesamten Node-Bestand mit SQL LIKE Statements durchforsten möchte, kann sich dem Core-Modul Search bedienen. Das geht auch programmatisch im eigenen Modul, wenn man z.B. andere Bedingungen festlegen möchte
