Ein Guide für Systemadministratoren für die ersten Schritte mit Ansible –SCHNELL!

Gehören Sie zu den typischen Systemadministratoren mit zu viel Arbeit und zu wenig Zeit? Lässt Sie die Aussicht auf eine einfache DNS-Server-Änderung oder eine Anpassung der Kernel-Parameter in Ihrer gesamten Serverfarm erschaudern? Oder schlimmer noch, Änderungen aufgrund variabler Systemeigenschaften wie installiertem Speicher oder Release-Version? Sprechen die Entwickler in Ihrem Unternehmen mit dieser ganzen DevOps-Sache eine andere Sprache als Sie?  

Red Hat Ansible Automation ist ein agentenloses, von Menschen lesbares Automatisierungstool. Es nutzt SSH, um Konfigurationsmanagement, Anwendungs-Deployment und Provisionierung in einer flachen oder mehrschichtigen Umgebung zu orchestrieren. Es basiert auf der Open Source-Technologie Ansible, die sich zu einer der weltweit beliebtesten Open Source-IT-Automatisierungstechnologien entwickelt hat.

Mit diesem Blog-Beitrag können Sie die Grundlagen von Ansible verstehen und erfahren, wie Sie es in Ihrer Rolle als Systemadministrator einsetzen können, um Ihre Systeme effizienter zu verwalten.

Bevor wir beginnen, sollten wir einige Begriffe definieren:

Kontrollknoten: der Host, auf dem Sie Ansible verwenden, um Aufgaben auf den gemanagten Knoten auszuführen.

Gemanagter Knoten: ein Host, der vom Kontrollknoten konfiguriert wird.

Host Inventory: eine Liste der gemanagten Knoten.

Ad-hoc-Befehl: eine einfache, einmalige Aufgabe.

Playbook: eine Reihe von wiederholbaren Aufgaben für komplexere Konfigurationen.

Modul: Code, der eine bestimmte allgemeine Aufgabe ausführt, wie das Hinzufügen eines Nutzenden, die Installation eines Pakets usw.

Idempotenz: eine Operation ist idempotent, wenn das Ergebnis einer einmaligen Ausführung genau dasselbe ist wie das Ergebnis einer wiederholten Ausführung ohne Zwischenschritte.

Umgebung

Die Umgebung in diesem Beitrag besteht aus einem Kontrollknoten (vm1) und vier gemanagten Knoten (vm2, vm3, vm4, vm5), die alle in einer virtuellen Umgebung mit einer minimalen Red Hat Enterprise Linux 7.4 Installation ausgeführt werden. Der Einfachheit halber hat der Kontrollknoten die folgenden Einträge in der Datei /etc/hosts:

192.168.102.211 vm1 vm1.redhat.lab
192.168.102.212 vm2 vm2.redhat.lab
192.168.102.213 vm3 vm3.redhat.lab
192.168.102.214 vm4 vm4.redhat.lab
192.168.102.215 vm5 vm5.redhat.lab

Der Einfachheit halber gebe ich meinem Systemnutzenden in dieser Demonstration das passwortlose sudo, Ihre Sicherheitsrichtlinien können davon abweichen, und Ansible kann mit einer Vielzahl von Use Cases zur Eskalation von Berechtigungen umgehen. Dieses Nutzerkonto wurde über den folgenden Eintrag in der Datei /etc/sudoers für die Eskalation von Berechtigungen konfiguriert:

%wheel ALL=(ALL) NOPASSWD: ALL

Dies ist nur ein Beispiel, und Sie können Ihre eigene Variante der sudo-Konfiguration verwenden.  

Schließlich wurde die SSH-Authentifizierung mit dem Public Key für dieses Nutzerkonto vom Kontrollknoten zu jedem der gemanagten Knoten konfiguriert und getestet.

Installation

Ansible for Red Hat Enterprise Linux 7 ist im Extras Channel zu finden. Wenn Sie Red Hat Enterprise Linux 6 verwenden, aktivieren Sie das EPEL-Repository. Für Extra Packages for Enterprise Linux (EPEL) kann diese Lösung im Kundenportal ebenfalls hilfreich sein. Auf Fedora-Systemen finden Sie Ansible im Basis-Repository.

Sobald das entsprechende Repository konfiguriert wurde, ist die Installation schnell und einfach:

[curtis@vm1 ~]$ sudo yum install -y ansible 

Prüfen wir die Version:

[curtis@vm1 ~]$ ansible --version
ansible 2.4.1.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/home/curtis/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/site-packages/ansible
 executable location = /bin/ansible
 python version = 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Beachten Sie die Standardkonfigurationsdatei und dass Python erforderlich und in unserer minimalen Red Hat Enterprise Linux 7.4 Installation vorhanden ist.

Konfiguration

Da wir die gemanagten Knoten bereits mit einem Nutzerkonto, Berechtigungserweiterung und SSH-Authentifizierung mit einem Public Key konfiguriert haben, fahren wir mit der Konfiguration des Kontrollknotens fort.

Die Konfiguration des Kontrollknotens besteht sowohl aus einer Ansible-Konfigurationsdatei als auch aus einer Host-Inventory-Datei.

Konfigurationsdatei

Wie wir gerade festgestellt haben, ist die Standardkonfigurationsdatei /etc/ansible/ansible.cfg.

Sie können diese globale Konfigurationsdatei ändern oder eine Kopie für ein bestimmtes Verzeichnis erstellen. Die Reihenfolge, in der sich eine Konfigurationsdatei befindet, ist wie folgt:

• ANSIBLE_CONFIG (environment variable)

• ansible.cfg (per directory)

• ~/.ansible.cfg (home directory)

• /etc/ansible/ansible.cfg (global)

In diesem Beitrag werde ich eine minimale Konfigurationsdatei im Stammverzeichnis des zuvor hinzugefügten Nutzerkontos verwenden:

[curtis@vm1 ~]$ cat ansible.cfg
[defaults]
inventory = $HOME/hosts

Host Inventory

Die Standard-Host-Inventory-Datei ist /etc/ansible/hosts, kann aber über die Konfigurationsdatei (wie oben gezeigt) oder mit der Option -i des ansible-Befehls geändert werden. Wir werden eine einfache statische Inventory-Datei verwenden. Dynamische Inventories sind ebenfalls möglich, liegen aber außerhalb des Rahmens dieses Beitrags.

Unsere Host-Inventory-Datei lautet wie folgt:

[webservers]
vm2
vm3

[dbservers]
vm4

[logservers]
vm5

[lamp:children]
webservers
dbservers

Wir haben vier Gruppen definiert: Webserver auf vm2 und vm3, dbservers auf vm4, logservers auf vm5 und lamp, die aus den Gruppen webservers und dbservers besteht.

Bestätigen wir, dass alle Hosts mit dieser Konfigurationsdatei gefunden werden können:

[curtis@vm1 ~]$ ansible all --list-hosts
 hosts (4):
   vm5
   vm2
   vm3
   vm4

Ähnlich verhält es sich mit einzelnen Gruppen, beispielsweise der Gruppe der Webserver:

[curtis@vm1 ~]$ ansible webservers --list-hosts
 hosts (2):
   vm2
   vm3

Nachdem wir nun unser Host Inventory validiert haben, sollten wir kurz überprüfen, ob alle unsere Hosts funktionieren. Wir werden dies mit einem Ad-hoc-Befehl tun, der das Ping-Modul verwendet:

[curtis@vm1 ~]$ ansible all -m ping
vm4 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm5 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm3 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm2 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}

Aus der obigen Anzeige geht hervor, dass alle Systeme ein erfolgreiches Ergebnis geliefert haben, dass sich nichts geändert hat und dass das Ergebnis jedes „ping“ „pong“ war.

Eine Liste der verfügbaren Module erhalten Sie mit:

[curtis@vm1 ~]$ ansible-doc -l 

Die Anzahl der eingebauten Module wächst mit jeder Ansible-Version weiter an:

[curtis@vm1 ~]$ ansible-doc -l | wc -l 
1378 

Die Dokumentation zu den einzelnen Modulen finden Sie unter http://docs.ansible.com/ansible/latest/modules_by_category.html.

Die letzte Einrichtungsaufgabe in unserer Umgebung besteht darin, vm1 mit Apache und einem Red Hat Enterprise Linux 7 yum-Repository zu konfigurieren, damit die gemanagten Knoten zusätzliche Pakete installieren können:

[root@vm1 ~]# yum install -y httpd
[root@vm1 ~]# systemctl enable httpd
[root@vm1 ~]# systemctl start httpd
[root@vm1 ~]# mkdir /media/iso
[root@vm1 ~]# mount -o loop /root/rhel-server-7.4-x86_64-dvd.iso /media/iso
[root@vm1 ~]# ln -s /media/iso /var/www/html/rhel7

Fertig, los, Ansible!

Jetzt ist unsere Umgebung konfiguriert und einsatzbereit, und wir können richtig mit Ansible arbeiten.

Da auf den gemanagten Knoten einige zusätzliche Pakete installiert werden müssen, besteht unsere erste Aufgabe darin, ein yum-Repository auf jedem Host mithilfe dieser Konfigurationsdatei zu konfigurieren:

[curtis@vm1 ~]$ cat dvd.repo
[RHEL7]
name = RHEL 7
baseurl = http://vm1/rhel7/
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
gpgcheck = 1

Wir können diese Datei auf jeden der gemanagten Knoten mit einem Ad-hoc-Befehl mit dem Kopiermodul unter Verwendung der Option -m kopieren und die erforderlichen Argumente mit der Option -a wie folgt angeben:

[curtis@vm1 ~]$ ansible all -m copy -a 'src=dvd.repo dest=/etc/yum.repos.d owner=root group=root mode=0644' -b
vm5 | SUCCESS => {
   "changed": true, 
   "checksum": "c15fdb5c1183f360ce29a1274c5f69e4e43060f5", 
   "dest": "/etc/yum.repos.d/dvd.repo", 
   "failed": false, 
   "gid": 0, 
   "group": "root", 
   "md5sum": "db5a5da08d1c4be953cd0ae6625d8358", 
   "mode": "0644", 
   "owner": "root", 
   "secontext": "system_u:object_r:system_conf_t:s0", 
   "size": 135, 
   "src": "/home/curtis/.ansible/tmp/ansible-tmp-1516898124.58-210025572567032/source", 
   "state": "file", 
   "uid": 0
}

[...]

Die zusätzlichen Ergebnisse der übrigen Hosts wurden aus Gründen der Übersichtlichkeit entfernt.

An dieser Stelle sind einige Punkte erwähnenswert:

1. Jeder Knoten meldet SUCCESS und "changed": true, was bedeutet, dass die Ausführung des Moduls erfolgreich war und die Datei erstellt/geändert wurde. Wenn wir den Befehl erneut ausführen, enthält die Ausgabe "changed" : false, was bedeutet, dass die Datei bereits vorhanden und wie erforderlich konfiguriert ist. Mit anderen Worten: Ansible nimmt die erforderlichen Änderungen nur vor, wenn sie noch nicht vorhanden sind. Dies wird als „Idempotenz“ bezeichnet.

2. Die Option -b (siehe http://docs.ansible.com/ansible/latest/become.html) veranlasst die entfernte Aufgabe, die Eskalation der Berechtigungen (d. h. sudo) zu verwenden, die erforderlich ist, um Dateien in das Verzeichnis /etc/yum.repos.d zu kopieren.

3. Sie können herausfinden, welche Argumente das Copy-Modul benötigt:

[curtis@vm1 ~]$ ansible-doc copy 

Playbooks

Während Ad-hoc-Befehle für Tests und einfache einmalige Aufgaben nützlich sind, können Playbooks verwendet werden, um eine Reihe von wiederholbaren Aufgaben zu erfassen, die in Zukunft ausgeführt werden sollen. Ein Playbook enthält einen oder mehrere Plays, die eine Reihe von zu konfigurierenden Hosts und eine Liste von auszuführenden Aufgaben definieren.

In unserem Szenario müssen wir Webserver, Datenbankserver und einen zentralen Protokollierungsserver konfigurieren. Die spezifischen Anforderungen lauten:

1. Das httpd-Paket wird auf den Webservern installiert, aktiviert und gestartet

2. Jeder Webserver hat eine Standardseite mit dem Text „Welcome to<hostname> on <ip address>“

3. Jeder Webserver verfügt über ein Nutzerkonto mit entsprechendem Zugang für die Verwaltung der Inhalte

4. Das MariaDB-Paket wird auf den Datenbankservern installiert, aktiviert und gestartet

5. Der Protokollserver-Host ist so konfiguriert, dass er Fernprotokollierungsmeldungen akzeptiert

6. Die Hosts der Gruppen webservers und dbservers senden eine Kopie der Protokollnachrichten an den Host des Protokollservers

Das folgende Playbook (myplaybook.yml) wird alles konfigurieren, was wir benötigen.

Bitte beachten Sie bei der Prüfung des Playbooks die folgenden Punkte:

1. Das Nutzermodul benötigt einen Hash des Klartext-Passworts (siehe „ansible-doc user“ für Details).   Dies kann wie folgt erreicht werden:

   • [curtis@vm1 ~]$ python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())" Password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.

2. Der Inhalt der Standard-Webseite wird anhand von „Fakten“ erstellt, die vom Host gesammelt werden. Mit dem Einrichtungsmodul können Sie Host-Fakten ermitteln und verwenden:

[curtis@vm1 ~]$ ansible vm2 -m setup

---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest

   - name: enable and start Apache server
     service:
       name: httpd
       enabled: yes
       state: started

   - name: open firewall port
     firewalld:
       service: http
       immediate: true
       permanent: true
       state: enabled

   - name: create web admin group
     group:
       name: web
       state: present

   - name: create web admin user
     user:
       name: webadm
       comment: "Web Admin"
       password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
       groups: web
       append: yes

   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s

   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r

- hosts: dbservers
 become: yes
 tasks:
   - name: install MariaDB server
     yum:
       name: mariadb-server
       state: latest

   - name: enable and start MariaDB server
     service:
       name: mariadb
       enabled: yes
       state: started

- hosts: logservers
 become: yes
 tasks:
   - name: configure rsyslog remote log reception over udp
     lineinfile:
       path: /etc/rsyslog.conf
       line: "{{ item }}"
       state: present
     with_items:
       - '$ModLoad imudp'
       - '$UDPServerRun 514'
     notify:
       - restart rsyslogd

   - name: open firewall port
     firewalld:
       port: 514/udp
       immediate: true
       permanent: true
       state: enabled

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

- hosts: lamp
 become: yes
 tasks:
   - name: configure rsyslog
     lineinfile:
       path: /etc/rsyslog.conf
       line: '*.* @192.168.102.215:514'
       state: present
     notify:
       - restart rsyslogd

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

Das Playbook ausführen

Unser Playbook kann mit Folgendem ausgeführt werden:

[curtis@vm1 ~]$ ansible-playbook myplaybook.yml 

Aus der folgenden Darstellung geht hervor, dass die Webserver-Konfiguration nur auf vm2 und vm3 (Play 1) erfolgt, während die Datenbank auf vm4 (Play 2) installiert wird und der Logserver (vm5) mit Play 3 konfiguriert wird. In Play 4 schließlich werden die Webserver- und Dbserver-Hosts über die Gruppe „lamp“ für die Fernprotokollierung konfiguriert.

PLAY [webservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm2]
ok: [vm3]

TASK [install Apache server] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [enable and start Apache server] *************************************************
changed: [vm2]
changed: [vm3]

TASK [open firewall port] *************************************************************
changed: [vm2]
changed: [vm3]

TASK [create web admin group] *********************************************************
changed: [vm3]
changed: [vm2]

TASK [create web admin user] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [set content directory group/permissions] ****************************************
changed: [vm3]
changed: [vm2]

TASK [create default page content] ****************************************************
changed: [vm3]
changed: [vm2]

PLAY [dbservers] **********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm4]

TASK [install MariaDB server] *********************************************************
changed: [vm4]

TASK [enable and start MariaDB server] ************************************************
changed: [vm4]

PLAY [logservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm5]

TASK [configure rsyslog remote log reception over udp] ********************************
changed: [vm5] => (item=$ModLoad imudp)
changed: [vm5] => (item=$UDPServerRun 514)

TASK [open firewall port] *************************************************************
changed: [vm5]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm5]

PLAY [lamp] ***************************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm3]
ok: [vm2]
ok: [vm4]

TASK [configure rsyslog] **************************************************************
changed: [vm2]
changed: [vm3]
changed: [vm4]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm3]
changed: [vm2]
changed: [vm4]

PLAY RECAP ****************************************************************************
vm2                        : ok=11 changed=9 unreachable=0    failed=0 
vm3                        : ok=11 changed=9 unreachable=0    failed=0 
vm4                        : ok=6 changed=4 unreachable=0    failed=0 
vm5                        : ok=4 changed=3 unreachable=0    failed=0 

Und das wars!

Sie können die Webserver-Hosts überprüfen:

[curtis@vm1 ~]$ curl http://vm2
Welcome to vm2 on 192.168.102.212
[curtis@vm1 ~]$ curl http://vm3
Welcome to vm3 on 192.168.102.213 

und die Fernprotokollierung mit dem logger-Befehl auf den Hosts webservers und dbservers:

[curtis@vm1 ~]$ ansible lamp -m command -a 'logger hurray it works'
vm3 | SUCCESS | rc=0 >>

vm4 | SUCCESS | rc=0 >>

vm2 | SUCCESS | rc=0 >>

Bestätigung auf dem zentralen Protokollserver:

[curtis@vm1 ~]$ ansible logservers -m command -a "grep 'hurray it works$' /var/log/messages" -b
vm5 | SUCCESS | rc=0 >>
Jan 30 13:28:29 vm3 curtis: hurray it works
Jan 30 13:28:29 vm2 curtis: hurray it works
Jan 30 13:28:29 vm4 curtis: hurray it works

Tipps und Tricks

Wenn Sie mit YAML noch nicht vertraut sind, kann die Syntax anfangs knifflig sein, insbesondere was die Abstände (keine Tabulatoren) betrifft.

Bevor Sie ein Playbook ausführen, können Sie so die Syntax überprüfen:

$ ansible-playbook --syntax-check myplaybook.yml

Die Verwendung von vim mit Syntaxhervorhebung ist nicht nur hilfreich beim Erlernen von yaml, sondern auch beim Auffinden von Syntaxproblemen. Eine schnelle Möglichkeit, vim für die yaml-Syntax zu aktivieren, ist das Hinzufügen der folgenden Zeile zu Ihrer ~/.vimrc-Datei:

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

Wenn Sie etwas mit ein paar mehr Funktionen, einschließlich Farbe, möchten, finden Sie ein entsprechendes Plugin hier.
Wenn Sie es vorziehen, emacs anstelle von vim zu verwenden, aktivieren Sie das EPEL-Repository und installieren Sie das Paket emacs-yaml-mode.

Sie können ein Playbook testen, ohne tatsächlich Änderungen an den Zielhosts vorzunehmen:

$ ansible-playbook --check myplaybook.yml 

Es kann auch nützlich sein, ein Playbook durchzugehen:

$ ansible-playbook --step myplaybook.yml 

Ähnlich wie bei einem Shell-Skript können Sie Ihr Ansible-Playbook ausführbar machen und das Folgende am Anfang der Datei hinzufügen:

#!/bin/ansible-playbook 

Um beliebige Ad-hoc-Shell-Befehle auszuführen, verwenden Sie das Befehlsmodul (das Standardmodul, wenn -m nicht angegeben ist). Wenn Sie Umleitungen, Pipelines usw. benötigen, sollten Sie stattdessen das Shell-Modul verwenden.

Beschleunigen Sie das Schreiben von Playbooks, indem Sie den Abschnitt „EXAMPLES:“ in der Dokumentation für ein bestimmtes Modul überprüfen.

Verwenden Sie String-Quoting in Playbooks, um Probleme mit Sonderzeichen innerhalb eines Strings zu vermeiden.

Die Protokollierung ist standardmäßig deaktiviert. Um die Protokollierung zu aktivieren, verwenden Sie den Parameter log_path in der Ansible-Konfigurationsdatei.

Ich hoffe, dieser Beitrag hat Ihnen eine bessere Vorstellung davon vermittelt, wie Ansible funktioniert und wie Sie mithilfe von Playbooks Zeit und Mühe sparen können, indem Sie alltägliche Aufgaben mit Leichtigkeit und Genauigkeit dokumentieren und wiederholen. Weitere Informationen finden Sie unter http://docs.ansible.com und https://www.redhat.com/en/technologies/management/ansible.

Frohes Automatisieren!

Curtis Rempel, RHCA, ist ein Senior Platform TAM und Teamleiter in Kanada und ein ehemaliger Red Hat Certified Instructor und Examiner (RHCI/RHCX). Sein Weg zu Linux begann 1994 mit einer Red Hat Linux 2.1 CD von Jon „maddog“ Hall. Als TAM hat er Unternehmenskunden in der Finanz-, Telekommunikations- und Luftfahrtbranche mit Fachwissen in den Bereichen Automatisierung, Kernel und Storage unterstützt. Mehr über Curtis erfahren.

Ein Red Hat Technical Account Manager (TAM) ist ein spezialisierter Produktexperte, der mit IT-Organisationen zusammenarbeitet, um erfolgreiche Implementierungen strategisch zu planen und optimale Performance und Wachstum zu ermöglichen. Der TAM ist Teil der erstklassigen Organisation für Customer Experience and Engagement von Red Hat und bietet proaktive Beratung und Anleitung, damit Sie potenzielle Probleme erkennen und lösen können, bevor sie auftreten. Sollte ein Problem auftauchen, kümmert sich Ihr TAM darum und stellt die besten Ressourcen bereit, um es so schnell wie möglich und mit minimalen Unterbrechungen für Ihr Unternehmen zu lösen.

Lernen Sie TAMs auf einem Event von Red Hat Convergence in Ihrer Nähe kennen. Red Hat Convergence ist ein kostenloses Event, zu dem nur geladene Gäste Zutritt haben. Es bietet technischen Nutzenden die Möglichkeit, ihr Wissen über die Produkte von Red Hat zu vertiefen und neue Möglichkeiten zu entdecken, wie sie Open Source-Technologien zur Erreichung ihrer Geschäftsziele einsetzen können. Diese Events finden in Städten auf der ganzen Welt statt und bieten Ihnen eine bequeme, eintägige Möglichkeit, sich mit Fachleuten von Red Hat und Kolleginnen und Kollegen aus der Branche auszutauschen.

Open Source ist kollaborative Neugierde. Besuchen Sie uns auf dem Red Hat Summit vom 8. bis 10. Mai in San Francisco, um persönlich mit TAMs und anderen Fachleuten von Red Hat ins Gespräch zu kommen. Registrieren Sie sich jetzt für nur 1.100 USD mit dem Code CEE18.

Red Hat Cloud Success wurde entwickelt, um Ihre IT-Transformation zu vereinfachen und die Einführung von Cloud-Technologien mit fundiertem Produktwissen, Anleitung und Support zu beschleunigen. Vom Proof-of-Concept-Stadium bis zur Produktion stehen Ihnen hochqualifizierte technische Cloud-Fachleute zur Seite, die für Kontinuität sorgen und die erfolgreiche Implementierung Ihrer Cloud-Lösung unterstützen. Im Rahmen dieses zeitlich­ begrenzten Engagements kann Red Hat Cloud Success Sie bei der effektiven Planung und dem Deployment von Cloud-Lösungen und der langfristigen strategischen Planung unterstützen.