Der Support für Debian 11 endete am 31.08.2026, der für CentOS 7 am 30.06.2024 (Stand: 2026-10). Wir bringen Ihren Server auf den aktuellen Stand oder planen den Umstieg auf Debian und führen ihn durch. Ebenso arbeiten wir mit Proxmox VE 8 und mit physischen Servern, die wir auf Proxmox umziehen.
Ansible für Linux-Server: Konfiguration als Code im Repository
Wir beschreiben die Konfiguration Ihrer Linux-Server mit Ansible, in einem Git- oder SVN-Repository mit getrennten Inventaren für Produktion und Test. So ist jedes Detail dokumentiert, und jeder Server lässt sich in wenigen Minuten neu aufbauen, ohne dass sich jemand an Änderungen von Hand erinnern muss.
- Ansible mit getrennten Inventaren für Produktion und Test
- Full Stack und DevOps seit 2012
- Repository in der Regel bei Ihnen
Wo wir Ansible einsetzen
Ansible beschreibt die Konfiguration von Linux-Servern in Textdateien: Pakete, Dienste, Benutzer und SSH-Schlüssel, Konfigurationsdateien und Firewall-Regeln. Die Dateien liegen in einem Git- oder SVN-Repository. Ansible verbindet sich per SSH mit den Servern und bringt sie in den beschriebenen Zustand, ohne dass dort ein eigener Agent laufen muss.
Wir setzen Ansible für Server ein, die bisher von Hand gepflegt werden, und überall dort, wo mehrere Server gleich eingerichtet sein sollen. Unsere Ingenieure arbeiten mit Ansible und getrennten Inventaren für Produktion und Test. Den laufenden Betrieb der Server beschreibt Linux & DevOps. Mit Ansible richten wir auch Hosts für Docker und virtuelle Maschinen auf Proxmox einheitlich ein, etwa nach einem Umzug vom Hosting in den Container.
Wenn Server über Jahre von Hand gepflegt wurden
Ansible lohnt sich vor allem in diesen Lagen:
- Die Server wurden von Hand eingerichtet, und ihre Konfiguration steht nur auf den Servern selbst.
- Niemand weiß genau, was zuletzt geändert wurde und warum.
- Test und Produktion unterscheiden sich, und Fehler zeigen sich erst in der Produktion.
- Ein neuer Administrator braucht lange, bis er die Server kennt.
Änderungen von Hand schreibt in der Praxis kaum jemand auf. Nach einigen Monaten weiß niemand mehr, was auf welchem Server geändert wurde, und das Wissen über die Konfiguration geht verloren. Mit Ansible geht jede Änderung über das Repository und steht dort als Commit mit Datum, Autor und Beschreibung, und jedes Detail der Konfiguration ist dokumentiert und reproduzierbar. Für einen einzelnen Server, der sich selten ändert, lohnt sich der Aufwand oft nicht. Dann genügen eine gute Dokumentation und ein Runbook.
Typische Aufgaben mit Ansible
- Bestandsaufnahme der bestehenden Server: Pakete, Dienste, Konfigurationsdateien, Benutzer, Cronjobs und Firewall-Regeln.
- Ein Git- oder SVN-Repository mit Rollen für wiederkehrende Bausteine wie Webserver, PHP oder Lucee, Datenbank, Mailversand, Benutzer und SSH-Zugang.
- Getrennte Inventare für Produktion und Test. Unterschiede wie Servernamen und Adressen stehen als Variablen im jeweiligen Inventar.
- Passwörter und Schlüssel verschlüsselt im Repository statt im Klartext.
- Updates und Sicherheitseinstellungen wie SSH-Härtung und Firewall-Regeln auf viele Server ausrollen, zuerst auf die Testserver.
- Server für Docker vorbereiten und virtuelle Maschinen auf Proxmox einheitlich einrichten.
- Dokumentation im Repository und ein Runbook für Ihr Team.
Ein Server, der sich aus dem Repository neu aufbauen lässt
Ein Ansible-Lauf ändert nur, was vom beschriebenen Zustand abweicht, und ein zweiter Lauf direkt danach meldet keine Änderungen mehr. Wurde eine beschriebene Einstellung von Hand geändert, zeigt der nächste Lauf die Abweichung und stellt den beschriebenen Zustand wieder her. Neue Rollen und Änderungen prüfen wir zuerst auf den Testservern, danach folgt die Produktion in einem mit Ihnen abgestimmten Zeitfenster.
Fällt ein Server aus oder zieht er auf neue Hardware oder in eine virtuelle Maschine um, entsteht seine Konfiguration aus dem Repository neu. Datenbanken und hochgeladene Dateien stehen nicht in der Beschreibung, sie kommen aus der Sicherung. Deshalb gehören Sicherungen mit Wiederherstellungstest dazu. Das Repository liegt in der Regel bei Ihnen, und ein neuer Administrator oder ein anderer Dienstleister liest dort nach, wie die Server eingerichtet sind.
So führen wir Ansible auf bestehenden Servern ein
-
Bestandsaufnahme
Wir erfassen, was auf den Servern eingerichtet ist, und vergleichen Test und Produktion. Die Liste der Unterschiede erhalten Sie schriftlich.
-
Repository und Rollen
Wir legen das Repository an, in der Regel bei Ihnen, und beschreiben die Server in Rollen und getrennten Inventaren für Produktion und Test.
-
Abgleich auf dem Test
Wir richten einen Testserver aus der Beschreibung ein und vergleichen ihn mit der Produktion, bis jeder Unterschied erklärt ist.
-
Erster Lauf auf der Produktion
Plan, Zeitpunkt und Rückweg stimmen wir vorher mit Ihnen ab. Vor dem Lauf prüfen wir die Sicherung, danach kontrollieren wir Dienste und Anwendung.
-
Dokumentation und Übergabe
Im Repository steht, wie ein Lauf gestartet wird, welche Inventare es gibt und wo die verschlüsselten Passwörter liegen. Dazu kommt ein Runbook für Ihr Team.
Verwandte Ausgangslagen mit Servern
-
-
Wir ziehen Ihre Lucee-, ColdFusion- oder PHP-Anwendung vom klassischen Hosting in Container um, ohne sie neu zu schreiben. So lässt sich die Umgebung nachbauen, aktualisieren und verlegen. Manche Hoster berechnen Aufschläge für alte PHP-Versionen, für PHP 8.2 enden die Sicherheits-Updates am 31.12.2026 (Stand: 2026-10).
-
Ihr System läuft, aber niemand kennt es genau. Wir erfassen Anwendung, Datenbank, Server und E-Mail, bewerten Risiken, empfehlen schriftlich den weiteren Weg und übernehmen auf Wunsch den Betrieb.
Der erste Schritt: ein Server-Check mit schriftlichem Ergebnis
Server-Check
Für Unternehmen mit Linux-Servern, die niemand mehr genau kennt: vor einem Upgrade, nach dem Weggang des Administrators oder wenn ein Kunde nach Backups fragt.
- Version und Support-Stand von Betriebssystem und Diensten
- Härtung: SSH-Zugang, Firewall, offene Dienste und TLS-Zertifikate
- Updates: was fehlt und wie sie bisher eingespielt werden
- Backups: was gesichert wird und ob ein Wiederherstellungstest belegt ist
- Monitoring und Logs: was überwacht wird und was fehlt
- Liste der Ergebnisse nach Priorität
In dieser Phase ändern wir nichts am Server. Anwendung und Code sind nicht Teil des Checks, dafür gibt es den Legacy-Review. Umfang und Preis legen wir im Erstgespräch fest und bestätigen sie schriftlich, bevor wir beginnen. Auf Wunsch erhalten Sie danach ein Angebot für die Betreuung.
Was das Ergebnis enthält
Eine schriftliche Liste der Befunde nach Priorität mit Empfehlungen zu Härtung, Updates, Backups und Monitoring, dazu ein Upgrade-Plan mit Wartungsfenstern. Beides gehört Ihnen.
Was vor dem Start oft gefragt wird
Was ist, wenn uns Zugangsdaten fehlen?
Das lässt sich meist lösen. Wir beginnen mit dem, was Sie in der Hand haben: Vertrag und Kundenkonto beim Hoster, Zugang zur Domain und, soweit vorhanden, Zugriff auf Repository und Backups. Server-Zugänge lassen sich über den Hoster oft zurücksetzen, wenn Sie als Vertragspartner auftreten. Zugang zu einem System verschaffen wir uns nur mit Ihrer ausdrücklichen Zustimmung.
Arbeiten Sie mit Jira, Git und SVN?
Ja, mit Git und mit SVN. Aufgaben führen wir in Jira oder in dem Werkzeug, das Sie bereits nutzen. Der Code liegt in Ihrem eigenen Repository und bleibt damit in Ihrer Hand.
Was passiert, wenn bei Ihnen jemand ausfällt?
Eine Vertretung stellen wir auf Wunsch. Auch die Dokumentation erstellen wir auf Wunsch, und das Repository liegt in der Regel bei Ihnen, sodass der Code in Ihrer Hand bleibt. Wie wir zusammenarbeiten, beschreibt die Seite So arbeiten wir.
Kennen Sie sich mit Linux und Windows Server aus?
Linux ist unsere Hauptplattform: Debian und Ubuntu, Webserver, Datenbank-Cluster und Virtualisierung mit KVM und Proxmox. Windows Server mit IIS betreuen wir seit 2015 im Produktivbetrieb. Wir empfehlen den Umzug nach Linux, außer Sie möchten bei Windows bleiben.
Wann können Sie starten?
Eine erste Antwort erhalten Sie innerhalb eines Werktags. Wann wir mit der Arbeit beginnen, hängt von der aktuellen Auslastung und vom Umfang ab. Das sagen wir Ihnen im Erstgespräch verbindlich. Ist es dringend, beginnt die 48-Stunden-Einschätzung, sobald wir Zugriff auf das System haben.
Wie hoch ist Ihr Stundensatz?
Das hängt von Umfang, Art der Zusammenarbeit und Dringlichkeit ab. Schildern Sie uns kurz Ihre Situation, dann erhalten Sie nach einem Gespräch ein Angebot. Ein Budget brauchen wir dafür nicht. Feste Preise nennen wir bei den Einstiegsprodukten.
Beschreiben Sie Ihre Server in drei Sätzen
Nennen Sie Anzahl und Betriebssystem der Server, den Standort (bei Ihnen oder bei einem Hoster) und ob es bereits eine Testumgebung gibt.