200 verteilte Oracle- Server mit Ansible ausrollen

© OPITZ CONSULTING 2020 öffentlich
 Digitale Service Manufaktur
© OPITZ CONSULTING 2020
Uwe Küchler, OPITZ CONSULTING
#DOAG2020, 18. November 2020
200 verteilte Oracle-
Server mit Ansible
ausrollen? Läuft.

© OPITZ CONSULTING 2020 öffentlich Seite 2
Agenda
1
2
3
4
Problemstellung im Projekt
Exkurs: Ansible
ansible-oracle
Umsetzung im Projekt
200 Oracle DB-Server mit Ansible ausrollen

Problemstellung im Projekt
1

Die Ausgangssituation

Die Ausgangssituation (2)
 Aus der Zentrale sind ca. 200 Standorte zu betreuen
 Dort stehen lokale ESX Hosts mit Oracle-VMs + tomcat, cups und mehr
 Bisheriger Ansatz der Softwareverteilung: Golden Image
 Wird in der Zentrale erstellt
 Per Internet oder per USB-Stick im Auto zum Standort verbracht
 VM wird auf Basis des Golden Images erstellt
 Customizing der VM erfolgt aus der Ferne, mit eigenen Skripten oder auch manuell
 Bisher seltenes Patching muss künftig wegen verschärfter Regulierung
häufiger gemacht werden.
 Dafür wurde ein Ansatz zur besseren Automatisierung gesucht.

Nachteile des bisherigen Ansatzes
 Golden Image kann nur für neue Deployments verwendet werden.
 Bestehende Deployments müssen anderweitig angepasst werden.
 Golden Image bzw. „Golden VM“ muss bei Updates mit nachgeführt werden!
 Patching an den Standorten ist aufwendig
 Oracle RDBMS-Patches sind groß; Übertragungszeiten teilweise lang
 OS-Patches werden nicht über ein festes Image gemacht
 ➔ Keine einheitlichen Patch-Stände über die Standorte hinweg gewährleistet
 ➔ Anreiz, aus Zeit-/Kostengründen möglichst wenig zu Patchen
 Manuelles Customizing ist aufwendig
 Und potentiell uneinheitlich!

Lastenheft
 Automatisierung der Neuinstallationen von Oracle-Servern
 Einschließlich zusätzlicher Packages (tomcat, cups)
 Automatisierung des Patchings von OS und RDBMS
 Vereinheitlichung aller ausgerollten Systeme
 Einsatz von Oracle Linux 7 (latest) mit UEK
 Upgrade auf Oracle 19c
 Bei dieser Gelegenheit: Einführung der Container-Architektur
 Erhöhung der Sicherheit
 Passwortloses Oracle-Login mit Wallets
 Personalisierte Proxy-User für den Support
 SELinux und firewalld

Exkurs: Ansible
2

Ansible - Historie
 Open Source Projekt auf github
 https://github.com/ansible/ansible
 Vollständig in Python entwickelt
 Entwickler: Michael DeHaan
 Februar 2012: Projektstart
 März 2013: Gründung AnsibleWorks
 später Ansible Inc.
 Oktober 2015: Übernahme durch Red Hat
 Ansible Tower als Steuerungszentrale
 Kommerziell von Red Hat vertrieben
 Community-Alternative: AWX

Ansible - Designziele
 Minimalisitisch
 Keine Agenten, keine zusätzliche Software auf Zielsystemen notwendig
 Typischerweise reicht Python 2.6+ auf den Zielsystemen aus
 Sicher
 Nutzung von etablierten Komponenten wie ssh
 Leicht erlernbar
 YAML (Yet another Markup Language) als Sprache
 Jinja2 für Templates
 Leicht lesbarer Code
 → Versionierbar ➔ „Infrastructure as Code“

Ansible - Einsatzgebiete
 Konfigurationsmanagement
 Administration
 Orchestrierung
 Ad-hoc Kommandos

Beispiel: Jinja2-Template
 „ansible_managed“
fügt einen Kommentar
ein, um vor manuellen
Änderungen zu
warnen.
 Per Schleife kann eine
Liste von Werten
eingefügt werden.
$ cat ./roles/common/templates/chrony.conf.j2
1. # {{ ansible_managed }}
2. # List of NTP servers to use.
3. {% for server in chrony_config_server %}
4. server {{ server }} iburst
5. {% endfor %}
$ cat ./roles/common/defaults/main.yml
1. chrony_config_server:
2. - 192.168.56.71
3. - 192.168.56.72
Ergebnis:
$ cat /etc/chrony.conf
1. # Ansible managed
2. # List of NTP servers to use.
3. server 192.168.56.71 iburst
4. server 192.168.56.72 iburst

Ansible - Komponenten
 Inventory
 beschreibt Hosts und Hostgruppen zur Bestimmung der Ziele
 Task
 Ausführen einer Aktion eines Moduls.
 Installation eines RPMs:
yum: name=autofs state=installed
 Role
 Sammlung von mehreren Tasks
 beschreibt einen Satz von Tasks, z.B. oraswdb-install

Ansible - Komponenten
 Playbook
 Definiert, welche Roles und/oder Tasks für Inventory ausgeführt werden
 Module
 Enthält Logik für Tasks
 Ansible liefert sehr viele Module als Standard
 Z.B. „nfs“, „user creation“, „cron“, …
 Öffentliches Repository Ansible Galaxy

Warum Ansible?
1. Warum Konfigurationsmanagement?
 Standardisierung
 Automatisierung
 Änderungen an vielen/allen Hosts einfacher
 Effizientere Verwaltung der Infrastruktur
 Zentrale Versionskontrolle
 „Infrastructure as Code“: Code und Versionshistorie dienen auch als
Dokumentation.

Warum Ansible?
2. Ansible vs. Puppet vs. Chef
Ansible Puppet Chef
Python, YAML, Jinja2 Custom DSL auf Basis von Ruby Reines Ruby
Prozedural Deklarativ Prozedural
Controller verteilt Änderungen an
Hosts per SSH oder WinRM (und
Python auf dem Host)
→ Kein Agent erforderlich
Master/Slave Setup: Puppet Master
synchronisiert Änderungen zu Puppet
Nodes.
→ Agent muss installiert werden
Chef-Workstation pusht/pollt
Änderungen zum/vom Chef-Server, der
sie an die verwalteten Knoten pusht.
→ Agent muss installiert werden
Jede Maschine kann Ansible Controller
sein.
Puppet Master ist festgelegt. Chef-Server ist festgelegt.
Sequentielle Ausführung von Tasks Nicht-sequentielle Ausführung von
Tasks
Sequentielle Ausführung von Tasks
Installation und Konfiguration sind
einfach
Installationsprobleme sind schwer zu
diagnostizieren. Konfiguration ist
kompliziert.
Ersteinrichtung erfordert
Programmierkenntnisse. Installation ist
kompliziert.
YAML-Syntax ist vergleichsweise leicht
erlernbar und lesbar.
Erfordert Programmierkenntnisse
(Ruby)
Erfordert Programmierkenntnisse
(Ruby)

ansible-oracle
3

ansible-oracle - Historie
 OpenSource Projekt auf github
 https://github.com/oravirt/ansible-oracle
 https://oravirt.wordpress.com
 Entwickler: Mikael Sandström
 August 2014: Projektstart
 Dezember 2014: ansible-oracle goes „RAC Attack“
 Juli 2016: Erste Mitarbeit von OPITZ CONSULTING am Projekt
 Mai 2018: großes Refactoring
 Bei OPITZ CONSULTING eingesetzter Fork
 https://github.com/opitzconsulting/ansible-oracle

ansible-oracle – Auswahl von Features
 OS: RPMs, User, Kernel-Parameter, HugePages, Transparent HugePages…
 Abhängigkeiten OL, RHEL, SLES werden berücksichtigt
 Storage: Filesystem, LVM, ASM
 RDBMS: Installation, Patching (Opatch, Datapatch, Golden Image)
 RAC, Rac One Node, Single Instance, SIHA, CDB+PDBs, Data Guard
 Datenbank: Parameter, User, Rollen, Grants, Tablespaces
 RMAN: Cron-Jobs + vorgefertigte Scripts
➔ Alles quasi deklarativ über YAML-Files und Jinja2 Templates!

Ansible – Zerstörungsfreie Änderungen
 Bsp.: Vor Änderungen an Datei „sqlnet.ora“ wird automatisch ein Backup
erzeugt:

ansible-oracle – Anforderungen Management-Host
 Ansible 2.5+
 Oracle Linux/CentOS/RHEL 7
 Oracle Linux/CentOS/RHEL >= 6.4
 Seitens Red Hat nicht supported – geht aber eingeschränkt
 Ansible-vault und SLES12SP3 geht nicht
 cx_Oracle
 Benötigt zur Verwaltung von: User, Rollen, Tablespaces
 InstantClient
 Nur wenn Management Host <> Datenbank Host
 Wird von cx_Oracle benötigt
 Management Host kann auch Datenbankserver sein

ansible-oracle – Was ist möglich?
 OS
 OS mit „Standardinstallation“ reicht aus
 RPMs, User, Kernel-Parameter, HugePages, Transparent HugePages…
 Abhängigkeiten OL, RHEL, SLES werden berücksichtigt
 Storage
 Filesystem (inkl. Aufbau mit LVM)
 ASMlib oder udev
 Konfiguration oracleasm

ansible-oracle – Was ist möglich? (2)
 Datenbank
 RAC, RAC OneNode, Flex ASM
 Single-Instance
 Single-Instance mit High Availability (SIHA)
 Clusterware und Datenbank 11.2.0.4 – 19.8.0.0

 Installation Grid Infrastructure / Restart
 Installation ‚mandatory‘ Release Update für 12.2
 Zusätzliche Diskgruppen anlegen
 External, Normal und High Redundancy möglich
 Installation Datenbanksoftware
 Konfiguration bash Profile für Software + Datenbanken
 Systemd/init V für Single Instance

 Datenbanken verwalten
 Anlegen und Löschen von Datenbanken
 Zeichensatz, init.ora-Parameter
 Mulltitenant Support
 Verschlüsselte Kennwörter mittels Ansible Vault

ansible-oracle – Datenbankverwaltung
 Benötigt cx_Oracle auf dem Management Node!
 Tablespaces
 Rollen, User, Grants, Proxy-User (Nov. 2020)
 Datenbankparameter
 Redo Log Groups
 Alles berücksichtigt bei Bedarf die Multitenant Option
 Pluggable Databases

ansible-oracle – Datenbankverwaltung (2)
 RMAN
 Konfiguration von cronjobs
 Backup-Scripts werden mitgeliefert
 OPatch für Datenbanken
 Patching mit OPatch + datapatch
 Alternative ab 19c: „Gold Image“ + datapatch
 Data-Guard Physical Standby

ansible-oracle – Work in Progress
 RMAN
 optional Oracle-Wallet für Katalog
 Einrichtung autofs für NFS
 Beispiele für Backup in Filesystem + EMC Networker
 Mittels Templates erweiterbar
 Proxy-User
 Nov. 2020: Pull Request existiert; Idempotenz muss noch optimiert werden
 OPatch Rolling Update für Standby und RAC
 Lizenzkonforme Installation
 chopt für Binaries
 Per Default in 12.2 alle Optionen deaktiviert!
 Data Dictionary Optionen schon einstellbar

ansible-oracle – geplant
 Weiteres Refactoring von Variablenstrukturen
 Refactoring Mai 2018 war für Administration mittels cx_Oracle notwendig
 Sind u.a. für Data-Guard notwendig
 2014 begann das Projekt recht klein…

Fazit
 ansible-oracle ist erwachsen geworden
 Refactoring eröffnete viele neue Möglichkeiten
 Sehr guter Kontakt von OC zum Autor Mikael Sandström
 Produktiv im Einsatz bei OPITZ CONSULTING
 RAC, Oracle Restart, ASM und Single Instance Deployments laufen
 Reproduzierbare Installationen
 Grundlagenwissen von Ansible sehr empfehlenswert
 Ansible ist auch für andere Einsatzzwecke sehr gut geeignet
 Zum Einstieg in Ansible bitte nicht mit ansible-oracle anfangen (Frustrationsgefahr)

Zwischenfazit: Entscheidung pro ansible-oracle
 Ansible:
 Installation ist einfach
 YAML-Syntax leicht erlernbar und lesbar
 Mit Red Hat (IBM) und starker Community auf solidem Fundament
 Im DevOps-Umfeld häufiges Tool
 Daher oft schon im Unternehmen im Einsatz (nicht in diesem Projekt)
 → Breitere Wissensbasis
 ansible-oracle:
 Quasi-deklarativer Ansatz beschreibt den Soll-Zustand
 Keine Entwicklung in Python nötig; a.-o. bringt (fast) alles mit
 Hat sich schon in vielen Umfeldern bewährt

Umsetzung im Projekt
4

Rückblende: Ausgangssituation

Zielarchitektur

Neue Elemente in der Systemarchitektur
 Ansible als zentrale Steuerung des Deployments.
 Yum-Server mit einer Spiegelung der Paketquellen von Oracle Linux.
 Apache http-Server, der als Yum-Server sowie zum Zugriff auf weitere
Installationsquellen, z.B. für das Oracle RDBMS, dient.
 Golden Image ist nicht ganz verschwunden, sondern durch eine minimale
Linux-Installation ersetzt.
 Datenbank wird als CDB mit einer PDB angelegt.

Yum Mirror
 Aus Sicherheitsgründen haben die VMs an den Standorten keinen direkten
Zugriff ins Internet.
 Paketquellen für das Betriebssystem können also nicht von einem öffentlichen Server (hier
yum.oracle.com) heruntergeladen werden.
 Daher werden die Paketquellen in der Zentrale vorgehalten.
 Die Spiegelung ermöglicht außerdem stabile Versionsstände
 Der Spiegel bleibt dann für einen Patch-Zyklus unverändert.
 Mit mehreren Spiegeln können verschiedene Versionsstände für Entwicklung, Test und
Produktionssysteme bereitgestellt werden.
 Updates auf die Spiegel werden manuell zu Beginn eines neuen Zyklus ausgelöst.

Yum Mirror (2):
Feste Versionsstände während eines Patch-Zyklus

Photo by Bill Oxford on Unsplash
Einrichtung Ansible +
Ansible-Oracle

Einrichtung Ansible + Ansible-Oracle
1. Paketinstallation
 Python
 In diesem Projekt: Python 2.7.x
 Versionswechsel können zu Inkompatibilitäten führen!
 ggf. separate Installation, wenn Python auf dieser Maschine noch anderweitig verwendet wird.
 Ansible
 In diesem Projekt: Ansible 2.8.4
 Git
2. Ansible-Oracle von GitHub klonen
3. Inventory einrichten
 Hosts und Gruppen
 Deklarationen für Deployments
 Mit git versionieren

Einrichtung Ansible + Ansible-Oracle
 Ansible + git aus Linux
Paketquellen holen
 Ansible-User
einrichten
 ansible-oracle von
GitHub klonen
 Submodules einbeziehen!
1. ## Als root
2. # tig ist optional, aber praktisch zum Navigieren auf der Kommandozeile
3. yum install -y ansible git tig
4. # Vorsichtshalber Ansible und Python gegen automat. Updates sperren
5. yum versionlock ansible python*
6. yum versionlock delete python-firewall
7. # Account und Basis-Verzeichnis
8. useradd ansible
9. su - ansible
10. mkdir git
11. cd git
12. export GIT_SSL_NO_VERIFY=true
13. # Ggf. Proxy angeben
14. #export http_proxy=192.168.xxx.yyy:8080
15. #export https_proxy=192.168.xxx.yyy:8080
16. # Klonen der aktuellen Version von Ansible-Oracle
17. # WICHTIG: Submodule mitnehmen!
18. git clone --recurse-submodules https://github.com/opitzconsulting/ansible-
oracle.git
19. # Konfigurationsdateien werden separat gepflegt:
20. git clone https://github.com/opitzconsulting/ansible-oracle-config.git

ansible.cfg
 Voreinstellungen für
Ansible
 Liegt im Verzeichnis
von ansible-oracle-
config
 Muss beim Aufruf von
ansible referenziert
werden
1. [defaults]
2. roles_path = ${PWD}/../ansible-oracle/roles/
3. library = ${PWD}/../ansible-oracle/library/
4. # Check for ssh host keys (known_hosts)
5. host_key_checking = False
6. # DEBUG: Auch uebersprungene Tasks anzeigen
7. display_skipped_hosts = false
8. # Ausgabe nur schwarz/weiss
9. #nocolor = 1
10. # Unterbinde Erzeugen von „Retry“-Dateien
11. retry_files_enabled = False
12. [ssh_connection]
13. # Pipelining behaelt die SSH-Session fuer alle Tasks bei.
14. # Das erspart die Zeit fuer den Auf- und Abbau der Session bei jedem Task.
15. pipelining = True

Inventory
 Wird als eigenes Git-Repository angelegt
 Für die Variablen können Vorlagen aus dem Repo „ansible-oracle-config“
verwendet werden
 Oder das geklonte „ansible-oracle-config“ wird dafür zweckentfremdet.

Inventory anlegen
 Git-Repository
regelmäßig sichern!
 Oder auf externem Git
Host verwalten.
 Ab sofort alle
Änderungen über das
Repository pflegen.
 Manuelle Konfigurations-
änderungen auf Hosts
sind zwar machbar, aber
tabu.
1. ## Als User ansible
2. # Basis-Verzeichnis fuer Inventory
3. mkdir -p /home/ansible/git/app-inventory/inventory/ORAVM
4. mkdir -p /home/ansible/git/app-inventory/templates
5. cd /home/ansible/git/app-inventory
6. # Vorlagen kopieren
7. cp ~/git/ansible-oracle-config/* .
8. cp ~/git/ansible-oracle-config/inventory/dbfs19/* ./inventory/ORAVM/
9. cp ~/git/ansible-oracle-config/templates/dbca_193*.dbt ./templates/
10. git init
11. git add .
12. # Nun werden die Vorlagen an die neue Umgebung angepasst
13. # und regelmaessig versioniert:
14. git commit -m "Initiale Einrichtung"

Inventory: Hosts
 Hosts können
gruppiert werden
 DB-/App-Server/…
 Dev/Test/Prod
 Land, …
 Gruppen können
Untergruppen haben
 Auflösung per DNS,
sonst Alias+IP-Adresse
1. [orasrv:children]
2. orasrv_entw
3. orasrv_test
4. orasrv_prod
5. [orasrv_entw]
6. entw01 ansible_host=192.168.56.81
8. [orasrv_test]
9. test01 ansible_host=192.168.56.101
11. [orasrv_prod]
12. standort01.kunde.de
15. standort04.kunde.pl

Inventory-Check
 Hosts können
gruppiert werden
 DB-/App-Server/…
 Dev/Test/Prod
 Land, …
 Gruppen können
Untergruppen haben
 Auflösung per DNS,
sonst Alias+IP-Adresse
$ ansible-inventory --inventory=hosts --graph --vars
@all:
|--@orasrv:
| |--@orasrv_entw:
| | |--entw01
| | | |--{ansible_host = 192.168.56.81}
| | |--entw02
| | | |--{ansible_host = 192.168.56.82}
| |--@orasrv_prod:
| | |--standort01.kunde.de
| | |--standort04.kunde.pl
| | |--standort05.kunde.pl
| |--@orasrv_test:
| | |--test01
| | | |--{ansible_host = 192.168.56.101}
| | |--test02
| | | |--{ansible_host = 192.168.56.102}
|--@ungrouped:

Inventory: Stolperfalle
 Vorsicht bei Hosts in mehreren Gruppen
 Variablen können mehrfach definiert werden, wenn
ein Host mehrfach gelistet ist!
 Bei Attributen ist dann nicht gewährleistet, welches
„gewinnt“, und nur mit Glück gibt es Fehlermeldungen.
 ➔ Entweder vermeiden oder bei Playbook-Ausführung
nur Untergruppen verwenden.
1. [orasrv:children]
2. orasrv_entw
3. orasrv_test
4. orasrv_prod
5. [orasrv_entw]
8. [orasrv_test]
11. [orasrv_prod]
16. [orasrv_de]
19. [orasrv_pl]
$ ansible-inventory --inventory=hosts --host=test02
{
"ansible_host": "192.168.56.2"
}

Inventory: Struktur im Projekt
 Variablen werden hierarchisch überschrieben
 Gruppe „all“
 Dateien in Gruppenverzeichnissen („orasrv“)
 Dateien in „host_vars/<hostname>“
 So kann der Aufbau von Generalisierung zu
Spezialisierung heruntergebrochen werden
 Host-Gruppierung an diesem Ansatz orientieren
 Im Rahmen des PoC war keine Spezialisierung auf Host-
Ebene erforderlich
 Host-Spezifika konnten durch Templates abgebildet werden (z. B.
SID=hostname)
 → K.I.S.S.
$ tree
.
└── ORAVM
├── group_vars
│ ├── all
│ └── orasrv
│ ├── app-host.yml
│ ├── databases.yml
│ ├── db-homes.yml
│ ├── host.yml
│ ├── listener.yml
│ ├── passwords.yml
│ ├── pdbs.yml
│ └── tomcat.yml
├── hosts
└── host_vars
└── entw01

Beispiel: host.yml
---
oracle_stage: /pro/orafra/stage # Wohin sollen die Installationsquellen kopiert werden?
autostartup_service: true # Anlegen eines Dienstes zum automatischen Start von Listenern + DB'en
configure_host_disks: true # Sollen Volume Groups angelegt werden?
disable_EE_options: True # Deaktivieren von lizenzpflichtigen Optionen
configure_hugepages_by: memory # Absolute (memory) oder relative (percent) Menge an HugePages
size_in_gb_hugepages: 0 # Wie viele HugePages sollen im OS eingerichtet werden?
host_fs_layout: # Hierueber koennen alle Disks und Filesysteme erstellt werden
- vgname: vg11
state: present
filesystem:
- {mntp: /pro/app/oracle, lvname: lvora, lvsize: 100%FREE, fstype: xfs}
disk:
- {device: /dev/sdh, pvname: /dev/sdh}
- vgname: vg12
state: present
filesystem:
- {mntp: /pro/app/oracle/diag, lvname: lvoradiag, lvsize: 100%FREE, fstype: xfs}
(...)

Beispiel: pdbs.yml
oracle_pdbs:
- home: db193-latest
pdb_name: "{{ ansible_hostname }}P" # Der Name der PDB wird hier dynamisch ueber den Hostnamen erzeugt
listener_port: 1521
datafile_dest: /pro/oradata/
cdb: "{{ ansible_hostname }}C" # Die CDB wird in databases.yml naeher definiert
state: present
profiles:
- name: DEFAULT
state: present
attributes:
- { name: password_life_time, value: unlimited }
- name: PW_UNLIMIT
state: present
attributes:
- { name: password_life_time, value: "UNLIMITED" }
- { name: password_grace_time, value: 7 }
- { name: password_lock_time, value: 1 }
- { name: password_verify_function, value: "null" }
init_parameters:
- {name: db_create_file_dest, value: '/pro/oradata/', scope: both, state: present}
services:
- { name: "{{ ansible_hostname }}.firma.de", state: started }

Los geht‘s!
### Ist die Zielmaschine für Ansible erreichbar?
$ ansible zielvm -i ~/git/inventory/ORAVM/hosts -m ping -u root -k
zielvm | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
$ cd ~/git/inventory
### Oracle Deployment mit Limit auf die Zielmaschine ausführen
$ ansible-playbook -i ~/git/inventory/ORAVM/hosts single-instance-fs.yml --limit="zielvm"

Erkenntnisse und Fazit
5

Sind wir schon live?
Nope.

Erkenntnisse
 Tests und Roll-out wegen Pandemie leider noch nicht abgeschlossen
 Durch die Komplexität, die das Setup erreichen kann, kann man in einige
Fallen von Ansible tappen.
 Vorsicht vor Upgrades von Python oder Ansible – Fallback einplanen.
 Mehrfache Definition von Variablen
 Eine gründliche Planung der Zielarchitektur und des Inventorys ist
unabdingbar. Auch, um Komplexität einzugrenzen.
 Die Automatisierung erleichtert die Arbeit auf Dauer, erfordert aber auch
Disziplin im Umgang mit Änderungen
 Änderungen immer im Inventory pflegen
 Änderungen immer versionieren

Fazit
 Ansible-Oracle
 ist komplex,
 deckt dafür aber viele Features ab
 hat einen hohen Reifegrad, der für den Produktiveinsatz taugt
 Löst viele Herausforderungen bei der Idempotenz, denen man sonst bei
Eigenentwicklungen gegenüberstehen würde
 Z. B. „ALTER TABLESPACE“ statt „DROP“ und „CREATE“, wenn schon vorhanden.
 Dennoch ist Vorsicht bei Änderungen an Datenbanken geboten. Testen, testen, testen!
 erfordert einige Einarbeitung und sorgfältiges Vorgehen, deren Aufwände sich aber schnell
rechnen.
 Lohnt sich gerade auch für Admins, die nicht auf Oracle spezialisiert sind, da wichtiges
Wissen und gute Praxis für Installation und Konfiguration im Code mitgeliefert werden.

Fragen / Diskussion

 Überraschend mehr Möglichkeiten
@OC_WIRE
OPITZCONSULTING
opitzconsulting
opitz-consulting-bcb8-1009116
WWW.OPITZ-CONSULTING.COM
Data matters.
Uwe M. Küchler
Manager Solutions
uwe.kuechler@opitz-consulting.com
Telefon +49 6172 66260 – 1515
Mobil +49 173 727 91 43

Referenzen

Referenzen
 Ansible-Oracle auf Github: https://github.com/oravirt/ansible-oracle
 OC-Fork: https://github.com/opitzconsulting/ansible-oracle
 Config Templates: https://github.com/Rendanic/ansible-oracle-config
 Puppet vs. Chef vs. Ansible vs. Saltstack - Vergleich der Configuration
Management Tools: https://www.kreyman.de/index.php/citrix/sonstige-
citrix-komponenten/145-puppet-vs-chef-vs-ansible-vs-saltstack-vergleich
 https://www.web3us.com/how-guides/why-we-use-terraform-and-not-
chef-puppet

Tips + Tricks
 Visual Studio Code als Ansible IDE
 + Remote – SSH
 „Remote Development using SSH“, https://code.visualstudio.com/docs/remote/ssh
 „Configuring key based authentication“,
https://code.visualstudio.com/docs/remote/troubleshooting#_configuring-key-based-authentication
 + Git
 „Visual Studio Code (7): Git als Quellcodeverwaltung einsetzen“, https://www.microsoft.com/de-
de/techwiese/know-how/visual-studio-code-07-git-als-quellcodeverwaltung-einsetzen.aspx

200 verteilte Oracle- Server mit Ansible ausrollen

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 200 verteilte Oracle- Server mit Ansible ausrollen

Ähnlich wie 200 verteilte Oracle- Server mit Ansible ausrollen (20)

200 verteilte Oracle- Server mit Ansible ausrollen