pixel
Seite wählen

NETWAYS Blog

Orchestration-Automation in einem Rutsch

Gerade für Testzwecke ist es von Vorteil, wenn man z.B. in der Cloud virtuelle Maschinen (VM’s) ohne großen Aufwand installieren und verwalten kann. Nur kommt noch die Installation von Programmen und Tools dazu, um die Testumgebung fertig zu bekommen, damit Test-Szenarien abgebildet werden können. Tools wie Terraform, Ansible oder Puppet und Bolt kommen da meistens zum Einsatz. Aber wie wäre es, wenn zum Beispiel sein Terraform-Deployment Verzeichnis  mit den .tf files schon vorhanden ist und nur alles in einem Rutsch ausrollen möchte. Da ich mich mit puppet-bolt schon mal auseinander gesetzt hatte, suchte ich nach einer Lösung und wurde fündig, denn Bolt kann terraform apply  ausführen, puppet-agent darauf installieren und der anschließend ein Puppet Manifest ausrollen. In meinem Kurz-Beispiel wird eine Ubuntu  VM erzeugt, Apache2 installiert und eine Webseite erstellt.

Wie das funktioniert erkläre ich in diesem Post:
Voraussetzung:
Terraform, puppet-agent und puppet-bolt müssen installiert sein.

Ich habe mir ein Verzeichnis angelegt z.B. terraform_puppet und in diesem sind folgende Dateien abgelegt:

├── bolt-project.yaml
├── data
│   └── common.yaml
├── files
│   └── site.html
├── hiera.yaml
├── inventory.yaml
├── manifests
├── plans
│   └── init.pp

Wichtig von den Dateien ist die bolt-project.yaml, die inventory.yaml und die init.pp, deren Inhalt sieht folgendermaßen aus:

bolt-project.yaml
---
name: terraform_puppet
modulepath: ~/puppet/modules

inventory.yaml
---
groups:
- name: terraform
targets: []
config:
transport: ssh
ssh:
private-key: ~/.ssh/passwordlesskey/id_rsa
user: ubuntu
host-key-check: false

Die ganze Magie passiert aber in dem Skript init.pp

plan terraform_puppet(String $tf_path) {
$localhost = get_targets('localhost')

# Create infrastructure with terraform apply
run_command("cd ${tf_path} && terraform apply --auto-approve && sleep 20", $localhost)
$ip_string = run_command("cd ${$tf_path} && terraform output instance_ips",
$localhost).map |$r| { $r['stdout'] }
$ips = Array($ip_string).map |$ip| { $ip.strip }

# Turn IPs into Bolt targets, and add to inventory
$targets = $ips.map |$ip| {
Target.new("${$ip}").add_to_group('terraform')
}

# Deploy website
apply_prep($targets, _run_as => 'root', _required_modules => ['apache'])

apply($targets, _run_as => 'root') {
include apache
file { '/var/www/html/index.html':
ensure => 'file',
source => 'puppet:///modules/terraform_puppet/site.html',
}
}
return $ips
# Or diagnose issues across your terraform infrastructure
run_command('uptime', $targets)
}

Ich habe das ganz bei uns im Openstack umgesetzt, es kann aber auch in anderen Cloud Umgebungen übernommen werden und muss diesbezüglich angepasst werden.

So um das ganze jetzt in Gang zu setzen führt man folgendes Kommando in diesem terraform_puppet Verzeichnis aus:

bolt plan run terraform_puppet -i inventory.yaml tf_path=~/terraform/vmdir

Für alle die, die Puppet und Ruby Wissen haben, sollte das selbsterklärend sein, ansonsten grobe kurze Erklärung:

Bolt führt ein Skript aus das ein Terraform apply triggert und die IP als Variable speichert und als inventory Host-Target zu den groups hinzufügt,
damit diese als $target Variable vom Bolt inventory und dann per puppet apply genutzt werden kann. Das puppet Module Apache wird dazwischen auch mit eingelesen und genutzt.
Das schöne ist, die Funktion von bolt apply_prep, diese sorgt dafür, das für das per terraform installierte VM-OS der puppet-agent installiert und ausgeführt werden kann, wenn man das ganze laufen lässt sieht man es als command durchlaufen.
Anschließend wird per bolt apply ein puppet code  per puppet apply ausgeführt, der in unserem Fall den Apache2 installiert und einen index.html an die entsprechende Stelle kopiert (die man vorher unter files selber anlegen muss) und dann den Apache2 Service startet.

Das Ergebnis sollte dann die Webseite der index.html sein , wenn man die IP-Adresse der VM im Browser (http://$ipaddress_vm eingibt.

Das ist natürlich nur ein ganz vereinfachtes Beispiel, aber die Möglichkeiten die man damit hat, finde ich genial.

Natürlich bieten wir zum Thema Puppet auch Trainings an, wo man die Grundlagen der Automatisierung mit Puppet vermittelt bekommt.

Viel Spaß und Erfolg beim Ausprobieren.

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Orchestration mit Puppet Bolt

Viele von den SysAdmins kennen das Tool mit dem A und deswegen möchte einen kleinen Einstieg zu Puppet Bolt geben.
Um Bolt nutzen zu können muss auf der Distribution seiner Wahl das Repository https://yum.puppet.com eingebunden sein und das Paket puppet-tools installiert sein. Zusätzlich brauchen wir für unseren kleinen Test das Paket docker und docker-compose, das auf dem System zu Verfügung stehen muss, da wir das die Aktionen auf Docker Containern deployen wollen.

Zuerst werden wir ein Bolt-Projekt Verzeichnis erstellen, wo dann das Modul-Verzeichnis darin erstellt wird:
mkdir my_infra && cd my_infra

Verzeichnis als bolt Arbeitsverzeichnis verifizieren:
bolt project init my_infra
In dem Verzeichnis befindet sich eine bolt-project.yaml womit Einstellungen für das Projekt vorgenommen werden können und eine inventory.yaml für zukünftige Hosts / Hostgruppen

Modul-Verzeichnis anlegen:
mkdir -p apache/plans && mkdir -p apache/files

So sollte die Struktur jetzt aussehen:
|── bolt-project.yaml
├── inventory.yaml
└── apache
├── files
└── plans

Jetzt erstellen wir den Container via Dockerfile, wo bolt später die Pakete installiert:
vim Dockerfile
FROM rastasheep/ubuntu-sshd
RUN apt-get update && apt-get -y install libssl-dev
EXPOSE 80
CMD ["/usr/sbin/sshd", "-D"]

kurze Erklärung: Hier wird ein Docker Container mit einem lauschenden SSH-Service unter Ubuntu erstellt, da Bolt auch über SSH kommuniziert

Dann erstellen wir die docker-compose.yaml, in dieser Datei wird festgelegt, wie viele Container erstellt werden und mit welchen Port diese von Außen erreichbar sind.
vim docker-compose.yaml
version: '3'
services:
target1:
build: .
ports:
- '3000:80'
- '2000:22'
container_name: webserver1
target2:
build: .
ports:
- '3001:80'
- '2001:22'
container_name: webserver2

Hier werden zwei Container erstellt auf dem der Port 22 auf 2000 und 2001 gebunden ist sowie der Port 80 auf 3000/3001.

Um die Container jetzt bauen zu lassen brauchen wir folgenden Befehl:
docker-compose up -d --build
Es werden jetzt Container-Images heruntergeladen und die beiden Container gebaut

Damit Bolt weiß wo das ganze dann angewendet werden soll, vervollständigen wir das inventory.yaml
vim inventory.yaml
groups:
- name: containers
targets:
- uri: 127.0.0.1:2000
name: webserver1
- uri: 127.0.0.1:2001
name: webserver2
config:
transport: ssh
ssh:
user: root
password: root
host-key-check: false

Um jetzt zu testen ob das Inventory File passt, prüft man mit folgendem Kommando:
bolt command run whoami -t all

Damit jetzt auf den Container Pakete installiert werden, müssen wir einen Task anlegen:
vim module/apache/plans/install.yaml
parameters:
targets:
type: TargetSpec

steps:
- name: install_apache
task: package
targets: $targets
parameters:
action: install
name: apache2
description: "Install Apache using the packages task"

Ich denke viel Erklärung braucht es hier nicht sollte selbsterklärend sein

Mit folgendem Kommando kann man den Plan ausführen um Apache auf dem Containern zu installieren:
bolt plan run apache::install -t containers

Das Ergebnis kann man sehen, wenn man im Browser http://127.0.0.1:3000 eingibt

Als keine Einführung in Puppet Bolt sollte das vorerst genügen, weiteres kann noch modifiziert und erweitert werden, siehe Quelle.

Quelle des Artikels: https://puppet.com/docs/bolt/latest/getting_started_with_bolt.html

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

openSUSE-Kubic getestet…

Schon mal von openSUSE-Kubic gehört? Nein? Okay, als Fan des Chamäleons habe ich davon schon öfter gelesen, aber ausprobiert habe ich es  noch nie.
Also dann beschreibe ich kurz was sich hinter Kubic versteckt.

Kubic ist eine zertifizierte Kubernetes Distribution, die auf openSUSE-MicroOS basiert und dem openSUSE-Tumbleweed (Rolling-Release) zu Grunde liegt.
Es ist sozusagen ein fertiges Betriebssystem für den Einsatz von Kubernetes, alle nötigen Tools sind schon vorinstalliert, damit man sofort beginnen kann
seinen K8s Cluster aufzusetzen oder z.B. Docker Container zu bauen.
Hier wurde ein transactional Server eingerichtet, das heißt, es ist ein read-only BTRFS Filesystem gemountet und man kann nicht wie unter openSUSE/SLES bekannt zypper
per Kommandozeile benutzen um Software-Paket nach zu installieren, aber ich werde noch CodeSnippets mit einbauen wo das ersichtlich wird. Sondern jedes neu installiertes Software-Paket wird vorerst als Snapshot zur Verfügung gestellt, der dann nach dem Reboot des Servers mit einbezogen wird.
Diese Distribution Kubic kann man sich in verschiedenen Formaten herunterladen, z.B. als RaspberryPI, openStack oder ISO-Image uvm siehe Link. Ich habe mir das in unserer openStack Umgebung als Image geladen und getestet.

So dann schauen wir uns das mal auf der Kommandozeile an:
kubic:~ # rpm -qa |grep kube*
patterns-containers-kubic_worker-5.0-25.1.x86_64
hello-kubic-k8s-yaml-1.4-1.3.noarch
kube-prometheus-k8s-yaml-0.5.0+git20200729.f0955e0-1.5.noarch
kuberlr-0.3.1-1.6.x86_64
kubernetes1.22-client-1.22.2-1.1.x86_64
patterns-containers-kubeadm-5.0-25.1.x86_64
patterns-containers-kubic_admin-5.0-25.1.x86_64
kubic-haproxycfg-0.12.2-1.1.x86_64
kubernetes1.22-client-common-1.22.2-1.1.x86_64
kubicctl-0.12.2-1.1.x86_64
kubernetes-client-1.22.2-21.2.x86_64
health-checker-plugins-kubic-1.6-1.1.noarch
kubicd-0.12.2-1.1.x86_64
kubernetes1.22-kubelet-1.22.2-1.1.x86_64
kubernetes1.22-kubelet-common-1.22.2-1.1.x86_64
patterns-containers-kubic_loadbalancer-5.0-25.1.x86_64
kubernetes1.21-kubelet-1.21.5-2.1.x86_64
kubernetes-kubelet-1.22.2-21.2.x86_64
kubernetes1.22-kubeadm-1.22.2-1.1.x86_64
cri-o-kubeadm-criconfig-1.22.0-1.2.x86_64
patterns-containers-container_runtime_kubernetes-5.0-25.1.x86_64
kubernetes-kubeadm-1.22.2-21.2.x86_64
kubic:~ # rpm -qa |grep helm
helm-3.6.3-2.1.x86_64

Das Paket Docker musste ich noch nachinstallieren und mich noch in die Gruppe docker hinzufügen, damit ich mit dem Tool Minikube meine ersten Kubernetes Cluster testen konnte.

Da ich das schon im Vorfeld getan habe zeige ich nochmal kurz den Befehl mit dem ich das Paket Docker, Tmux installiert habe:
ransactional-update pkg install tmux docker
Checking for newer version.
transactional-update 3.6.2 started
Options: pkg install tmux docker
Separate /var detected.
2021-11-29 13:42:32 tukit 3.6.2 started
2021-11-29 13:42:32 Options: -c10 open
2021-11-29 13:42:32 Using snapshot 10 as base for new snapshot 11.
2021-11-29 13:42:32 Syncing /etc of previous snapshot 9 as base into new snapshot "/.snapshots/11/snapshot"
ID: 11
2021-11-29 13:42:33 Transaction completed.
Calling zypper install
zypper: nothing to update
Removing snapshot #11...
2021-11-29 13:42:34 tukit 3.6.2 started
2021-11-29 13:42:34 Options: abort 11
2021-11-29 13:42:34 Discarding snapshot 11.
2021-11-29 13:42:34 Transaction completed.
transactional-update finished

Diese Meldung kommt jetzt, da diese Pakete schon vorhanden sind, sonst würde zypper im Hintergrund die Pakete installieren.
Anschließend muss man einen Reboot durchführen, sonst wird das nicht live geschaltet.
Dann noch folgendes:
usermod -a username -G docker
Damit man mit einem bestimmten $user docker run … ausführen kann.

Hier nochmal zur Vollständigkeit eine Installation vom Paket LXC
transactional-update pkg install lxc
Checking for newer version.
transactional-update 3.6.2 started
Options: pkg install lxc
Separate /var detected.
2021-11-30 08:37:36 tukit 3.6.2 started
2021-11-30 08:37:36 Options: -c11 open
2021-11-30 08:37:36 Using snapshot 11 as base for new snapshot 12.
2021-11-30 08:37:36 Syncing /etc of previous snapshot 10 as base into new snapshot "/.snapshots/12/snapshot"
ID: 12
2021-11-30 08:37:36 Transaction completed.
Calling zypper install
2021-11-30 08:37:37 tukit 3.6.2 started
2021-11-30 08:37:37 Options: callext 12 zypper -R {} install lxc
2021-11-30 08:37:37 Executing `zypper -R /.snapshots/12/snapshot install lxc`:
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 5 NEW packages are going to be installed:
libcap-progs liblxc1 lxc lxcfs lxcfs-hooks-lxc

5 new packages to install.
Overall download size: 860.6 KiB. Already cached: 0 B. After the operation, additional 2.6 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):

Checking for file conflicts: [......done]
Warning: 5 packages had to be excluded from file conflicts check because they are not yet downloaded.

Note: Checking for file conflicts requires not installed packages to be downloaded in advance in
order to access their file lists. See option '--download-in-advance / --dry-run --download-only'
in the zypper manual page for details.
2021-11-30 08:37:54 Application returned with exit status 0.
2021-11-30 08:37:55 Transaction completed.
Trying to rebuild kdump initrd
2021-11-30 08:37:55 tukit 3.6.2 started
2021-11-30 08:37:55 Options: close 12
2021-11-30 08:37:55 New default snapshot is #12 (/.snapshots/12/snapshot).
2021-11-30 08:37:55 Transaction completed.

Wichtig hier:
Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #12 (/.snapshots/12/snapshot).
transactional-update finished

Wie man jetzt zum Testen von Kubernetes mit z.B. Minikube kommt, werde ich hier nicht beschreiben, denn dazu gibt es
genügend Informationen im Internet. Vor allem kann ich das Kubernetes , das wir hosten, sehr empfehlen, einfach Anfrage bei uns starten.

Nur wie gesagt, wer den Einstieg in ein selbst gehostetes K8s lernen möchte, ist der Einstieg mit openSUSE-Kubic sehr vorteilhaft, da vieles schon vorkonfiguriert ist.

So ich denke für den ersten Überblick von Kubic reicht das vorerst, ich wünsche schon mal viel Spaß beim ausprobieren und besucht unser K8s Training!

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Music Home-Recording unter Linux

Heute möchte ich ein Thema aufgreifen, das für alle diejenigen ist, die ein Instrument spielen und Musik machen. Meine Wenigkeit spielt E-Gitarre (Heavy Metal) und wie oft kommt es vor, man spielt mit dem Drumcomputer mit und plötzlich hat man eine super klasse Akkord-Folge (Riff-Folge) die man in Schleife spielt. Man denkt sich, Mensch die muss ich aufnehmen, aber wie?

Falls man sich mit der Thematik “Home-Recording” unter Linux noch nicht beschäftigt hat, steht man da jetzt wie der “Ochs vorm Berg”. Da das Thema riesengroß ist, werde ich nur etwas den Einstieg beleuchten, wie ABNAHME, LATENZ, SOFTWARE.

Abnahme Instrument

Hiermit ist gemeint, wie ich das Instrument z.B. E-Gitarre mit meinen Computer verbinde und was brauche ich dazu. Am einfachsten man besorgt sich ein sogenanntes Audio-USB-Interface, das normalerweise Eingänge für Klinkenstecker oder Mikrofon hat, um das Instrument anzuschließen. Der Vorteil von dem Interface ist, das man das Eingangssignal einstellen (auspegeln) kann und je nach Ausstattung einen Kopfhörer-Ausgang beziehungsweise weitere Features hat. Ich kann für Linux-User folgendes Interface empfehlen, welches ich auch verwende: Behringer U-Phoria UMC204HD. Dieses Gerät wird per USB an den Computer angeschlossen und sollte vom Linux-Kernel erkannt werden.

Bei Instrumenten die nicht per Kabel direkt ans Interface angesteckt werden können, müssen per Mikrofon abgenommen und das ans Interface angeschlossen werden z.B. Saxophon.

Früher hatte ich auch Verstärker-Preamp-Out direkt mit dem Mic-Eingang der Soundkarte verbunden, was aber nicht sehr flexibel ist, da ich das Eingangsignal immer im Computer anpassen musste und man eine gute Soundkarte braucht, die speziell für Audio-Aufnahmen sein sollte, was diese nicht war.

Bei mir:

  • Audio-USB-Interface via USB am Computer
  • Preamp-Out Verstärker per Klinken-Kabel mit dem Eingang Audio-USB-Interface verbunden
  • Alternative E-Gitarre direkt ins Audio-USB-Interface und auf Instrument schalten sonst ist es Line-In.

Latenz

Um es simpel zu beschreiben, ist die Verzögerungszeit vom praktisch gespielten Ton (Instrument) bis zum hörbaren Ton aus dem Computer-Lautsprecher. Der Computer muß das In -und Output-Signal verarbeiten und das am besten in Realtime. Dafür braucht man unter Linux einen Realtime-Kernel, der bei manchen Linux-Distributionen (z.B. openSUSE-Leap, Ubuntu-Studio) bereits als RT-Kernel Paket zum installieren in den Repositories vorhanden ist. Was auch noch wichtig ist, das die Desktop-Oberfläche schlank ist und nicht wertvollen Arbeitsspeicher im Betrieb verbraucht (z.B. XFCE, LXDE, Enlightenment)

Diese Latenz lässt sich mit der Software JACK (JACK Audio Connection Kit) einstellen um das gewünschte Ergebnis zur erhalten, dazu könnte man schon alleine einen Blogbeitrag füllen. Die Standard-Einstellung sollte für die ersten Versuche ausreichend sein.

Software

Mittlerweile gibt es einiges an Open Source Software unter Linux, die auch von diversen Distributionen über Repositories installiert werden kann, hier mal eine kleine Auswahl:

Für Einsteiger würde ich die ALL-in-One Lösung Qtractor wählen, da diese einfacher und verständlicher zu bedienen ist, JACK braucht jeder um die Eingänge und Ausgänge zu steuern. Wer jetzt schon mit MIDI herum experimentiert, kann sich Rosegarden anschauen, Nachteil Audiospuren editieren, hier muss eine passende Software in den Einstellungen wie z.B.  Audacity mit verknüpft werden.

Je nachdem was man jetzt für eine Software zum Recording verwendet, braucht man eine gewisse Zeit bis man sich in diese eingearbeitet hat und da gehen schon Stunden ins Land. Deswegen würde ich jetzt nicht ins Detail gehen das würde hier den Rahmen sprengen, aber im Netz findet man jede Menge HowTo’s zu der jeweiligen Software, die die tiefere Anwendung beschreiben.

So jetzt wünsche ich jedem viel Erfolg bei seiner ersten Aufnahme und falls diese Schrott wird, keine Bange ich weiß schon gar nicht mehr wie viel Schrott ich am Anfang produziert habe, hier gilt die Devise, einfach weitermachen, es ist noch kein Meister vom Himmel gefallen.:-)

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

PostgreSQL Einstieg unter openSUSE-Leap 15.2

da die meisten User sich zwar mit MySQL oder MariaDB auskennen, werde ich heute mal auf PostgreSQL eingehen, wie man dieses Paket installiert und ein paar Kommandos zur Verwaltung einer Datenbank.
PostgeSQL ist von den Kommandos ähnlich wie zum Beispiel MariaDB. Sie wird auch als ein freies, objektrelationales Datenbankmanagementsystem (ORDBMS) betitelt, somit auch Opensource ist.

Installation unter openSUSE-Leap 15.2:

Pakete sind in den offiziellen Repositories zu finden, die bei dem Setup von openSUSE-Leap gesetzt werden.

# sudo zypper in postgresql postgresql-server

Da da der Dienst von PostgreSQL nicht automatisch gestartet wird, wie z.B bei Debian basierten Linux-Distributionen muß dieser noch gestartet werden

# sudo systemctl start postgresql

Am besten prüft man nochmal ob der Dienst auch fehlerfrei läuft

# sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
 Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
 Active: active (running) since Tue 2020-11-03 08:31:17 UTC; 4h 23min ago
 Main PID: 1460 (postgres)
 Tasks: 8
 CGroup: /system.slice/postgresql.service
 ├─1460 /usr/lib/postgresql12/bin/postgres -D /var/lib/pgsql/data
 ├─1461 postgres: logger 
 ├─1463 postgres: checkpointer 
 ├─1464 postgres: background writer 
 ├─1465 postgres: walwriter 
 ├─1466 postgres: autovacuum launcher 
 ├─1467 postgres: stats collector 
 └─1468 postgres: logical replication launcher

Nov 03 08:31:15 opensuse-leap systemd[1]: Starting PostgreSQL database server...
Nov 03 08:31:15 opensuse-leap postgresql-script[1437]: Initializing PostgreSQL 12.4 at location /var/lib/pgsql/data
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.186 UTC [1460]LOG: starting PostgreSQL 12.4 on x86_64-suse-linux-gnu, compiled by gcc (SUSE L>
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.187 UTC [1460]LOG: listening on IPv6 address "::1", port 5432
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.187 UTC [1460]LOG: listening on IPv4 address "127.0.0.1", port 5432
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.193 UTC [1460]LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.204 UTC [1460]LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.221 UTC [1460]LOG: redirecting log output to logging collector process
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.221 UTC [1460]HINT: Future log output will appear in directory "log".
Nov 03 08:31:17 opensuse-leap systemd[1]: Started PostgreSQL database server.

Da wir jetzt wissen, das der Dienst ordnungsgemäß läuft, können wir loslegen, mit dem anlegen von der Datenbank und Tabellen.

PostgreSQL wird vom System-User postgres verwaltet, der alle Rechte hat, um z.B. Datenbanken oder auch Datenbankbenutzer anzulegen. Da dieser User ohne Passwort konfiguriert ist, was unter MariaDB oder MySQL teilweise auch so ist, sollte man dem User sicherheitstechnisch ein Passwort konfigurieren.

# sudo passwd postgres

Passwort nach Aufforderung eingeben und erneut wiederholen.

Unter PostgreSQL gibt es genauso ein Shell wie bei z.B. MySQL und in diese kommt man wie folgt:

# sudo -u postgres psql

Um diese Shell wieder zu verlassen

\q

eingeben

Anlegen vom User der Datenbanken verwalten darf

 # sudo sudo -u postgres createuser -P -d NUTZERNAME

Der Schalter -P <password> -d <create databases>

Anlegen von einer Datenbank

# sudo -u postgres createdb -O username DATABASENAME

Löschen einer Datenbank

# sudo -u postgress dropdb DATABASE

In der postgresql Shell sieht das anders aus

postgres=# CREATE DATABASE my_music;

Wechseln zwischen den Datenbanken

\c DATENBANK

Ein Tabelle mit den Spalten anlegen

postgres=# CREATE TABLE cds ( id int, interpreter varchar(100), album varchar(100), release date );

Daten in die Tabelle der Datenbank schreiben

INSERT INTO cds VALUES ( 1, 'Pretty Maids', 'Future World', '1987-04-12' );

Ausgeben der Daten

my_music=# select * from cds;
 id | interpreter  |       album        |  release   
----+--------------+--------------------+------------
  1 | Pretty Maids | Future World       | 1987-04-12
  2 | Metallica    | Ride the Lightning | 1984-04-12
(2 rows)

Als kleine Einführung in PostgreSQL sollte das erst mal ausreichen,  für mehr Wissen darüber bieten wir von NETWAYS auch eine PostgreSQL Schulung an.

Dann viel Spaß bei ausprobieren von PostgreSQL auf openSUSE.

 

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.