Ansible

Ansible (click here to comment) 11. August 2022, Jochen
Max, Dominik und Jochen unterhalten sich diesmal
über Ansible. Dass Ansible selbst in Python geschrieben ist,
macht es für Python-Entwickler wie uns natürlich besonders
interessant. "Infrastructure as code" machen inzwischen ja
irgendwie auch alle - bleibt nur die Frage, ob man
Terraform von Ansible aus aufrufen sollte, oder umgekehrt
.

 
Shownotes

Unsere E-Mail für Fragen, Anregungen & Kommentare:
hallo@python-podcast.de
News aus der Szene

Django 4.1 released

django-widget-tweaks



Pydantic2

Pydantic v2 - The Plan - Podcast Episode 

Pydantic V2 Plan



EuroPython 2022

Build a production ready GraphQL API using Python -
Strawberry

Norvig's lispy: beautiful and illuminating Python code

Python's role in unlocking the secrets of the Universe
with the James Webb Space Telescope

The Design of Everyday APIs

Using python to predict Asset price reversals

How To Train Your Graphics Card (To Read)

How we are making Python 3.11 faster

Robyn: An async Python web framework with a Rust runtime

Multithreaded Python without the GIL

Let's talk about JWT

`typing.Protocol`: type hints as Guido intended

Super Search with OpenSearch and Python



Ansible

Ansible ist ein Werkzeug zum managen von
Servern. Benannt nach einen Science-Fiktion-Gerät, dass
FTL-Kommunikation möglich macht  (*Rocannon’s World*, by
Ursula K Le Guin, 1966).  Wird seitdem auch von anderen
Authoren in ihren Werken genutzt.  

ansible

chef

puppet

salt



Terraform

Jinja

archlinux

Debian “bullseye”

Jeff Geerling (geerlingguy)

NixOS

docker

poetry

#309 – John Carmack: Doom, Quake, VR, AGI, Programming, Video
Games, and Rockets

The twelve-factor app

Picks

Ibis

Two Sigma Presents Pandas at a Crossroads the Past
Present and Future with Jeff Reback



django-context-decorator

XONSH is a Python-powered shell

pytest-mock

Weeknotes: Joining the board of the Python Software
Foundation



FuckIt.py

Notizen von Max (vielen Dank dafür!)

Ansible ist ein Werkzeug zum managen von Servern.

Benannt nach einen Science-Fiktion-Gerät, dass
FTL-Kommunikation möglich macht  (*Rocannon’s World*, by
Ursula K Le Guin, 1966).  Wird seitdem auch von anderen
Authoren in ihren Werken genutzt.

Ansible wurde 2015 von Redhat gekauft, vorher Ansible
 Inc.

Deklarativ, man sagt also was man haben möchte und Ansible
setzt es dann um

Idempotent, man kann alles beliebig oft wiederholen ohne
negativen Effekt und man landet dann in seinem deklarierten
Zustand


Aufbau

Eigentlich wirft Ansible die Befehle in paramiko, einer
SSH Lib für Python, und sagt ssh.exec_command(command). Heute
ist alles natürlich komplizierter, aber wenn man sich den
ersten Commit zu Ansible ansieht




Inventory

Hier zieht Ansible sich die Informationen heraus, welche
Server bearbeitet werden sollen. Hier kann man dann auch
Gruppiern und schon ein paar Variablen deklarieren  




Statisches Inventory

Eine yml-Datei oder INI-Datei in der man seine Server
bzw. IPs zu den Servern einträgt




Dynamisches Inventory

Hier kann man seinen Cloudprovider anzapfen oder auch
LDAP und weiteres. Hierzu hat man Inventory-Plugins:
 darunter sind AWS, Docker, Kubernetes, Proxmox, Hetzner
DNS -> `ansible-doc -t inventory -l` 




Playbook

Enthalten die Beschreibung, was mit den Hosts im
Inventory passieren soll, dazu greifen diese auf
Plays zurück.

Änlich wie Runbooks oder Checklisten die abzuarbeiten
sind, nur automatisch




Plays

Hier wird beschrieben was ausgeführt werden soll und auf
welchem Host das passieren soll

Plays haben Jinja2 support - Yeah!

Loopen mit `with_items` und dann {{ item.src }} o.ä




Tasks

Eine Aktion die in einem Play passiert




Handlers

Tasks die von vorherigen Tasks ausgeführt werden, sofern
diese den Status auf dem Server geändert hat ('changed')




Role


​​​​​​​Eine Sammlung von Tasks, Variablen,
Plugins, Templates und Dateien, die in ein Play importiert
werden können




Ansible Galaxy


​​​​​​​Stellt Sammlungen
(Collections) von Playbooks aber auch
Rollen zu Verfügung. Etwa Github /
PyPI für Ansible

Collections können per `ansible-galaxy` command
installiert werden oder in einem `requirements.yml`-File
hinterlegt werden und werden dann bei Ausführung des
Playbooks heruntergeladen  
 




Privileges


​​​​​​​Ansible hat die Möglichkeit Tasks
mit verschiedenen Privilegien, also Benutzeraccounts,
auszuführen. Hierzu gibt es die `become`-Direktive. Der
Default ist hier `root`. Das Sudo-Passwort kann mit der
Flag `-K` abgefragt werden. Oder auch als Variable im
Playbook übergeben werden. Um Variablen sicher zu speichern
hat Ansible Vaults.  

Become und Windows - Zu einer Windowsmaschine kann man
sich nur als Priveligierter User verbinden. Become wird hier
nur genutzt um noch tiefere Privilegien zu bekommen
(`System`) oder um den Nutzer zu wechseln.




Best Practices


​​​​​​​Eigentlich wie immer: Verbindung
zum Server hin nur mit einem unpreviligierten Account (ähäm
Windows *räusper*)

Nur mit den rechten Arbeiten, die man auch braucht - dass
passiert eigentlich schon, wenn man mit einem
unpriviligierten Account verbindet, denn dann muss man immer
`become` unter den Task schreiben und mehr schreiben ist mehr
Aufwand und deshalb überlegt man schon gleich zweimal ob man
wirklich mehr Rechte braucht.  

Ansible Vault benutzen, wenn man
mit Passwörtern und sonstigen Geheimnissen arbeitet




Skalierung


​​​​​​​*Grillenzirpen* ... aja da
gibt es Ansible Tower... wollte ich immer mal reinschauen,
aber es ist sehr teuer wenn man es kauft und unmöglich
aufzusetzen wenn man es selbst hosten möchte... schon etwas
komisch, wenn man doch einfach ein Ansible Playbook
schreiben könnte  




Unterschiedliche Betriebssysteme


​​​​​​​Linux/Unix und die verschiedenen
Distributionen

Hier muss darauf geachtet werden, dass man den richtigen
Packagemanager erwischt und die Dateien am vermuteten Ort
liegen. Mit `ansible_os_familiy` kann man dann über die`when`
Direktive in unterschiedliche Entscheidungsbäume abgleiten
 




Windows


​​​​​​​Hier wird anstelle SSH und der
Shell PowerShell genutzt




Network Automation​​​​​​​

Liste der Integrationen




Terraform und Ansible


​​​​​​​Terraform baut dir die
Infrastruktur auf und Ansible konfiguriert dir diese. Dabei
kann Ansible auch wieder Terraform aufrufen usw..

ch will nie wieder zurück zu Bash, aber ich will etwas
local laufen lassen:  `#!/usr/bin/env
ansible-playbook` und im Play:
  ```
     ---
       - name: "Ansibel
Local"
         hosts:
localhost
  
      connection:
local 
  
      tasks:
  ```
 



Liste von Videotutorials