Alle öffentlichen Logbücher

Dies ist die kombinierte Anzeige aller in devops.straight8.de geführten Logbücher. Die Ausgabe kann durch die Auswahl des Logbuchtyps, des Benutzers oder des Seitentitels eingeschränkt werden (Groß-/Kleinschreibung muss beachtet werden).

• 17:08, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Transparent Data Encryption (TDE) (Die Seite wurde neu angelegt: „== Transparent Data Encryption (TDE) == '''Transparent Data Encryption (TDE)''' ist eine Technologie, die von großen Datenbankherstellern (wie Microsoft SQL Server, Oracle und Azure SQL) eingesetzt wird, um ruhende Daten (Data-at-Rest) automatisch zu verschlüsseln. Der Name „transparent“ leitet sich daraus ab, dass die Anwendung, die auf die Datenbank zugreift, von der Verschlüsselung nichts bemerkt. === 1. Funktionsweise === TDE arbeitet auf d…“)
• 17:02, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Application Level Encryption (ALE) (Die Seite wurde neu angelegt: „== Application Level Encryption (ALE) == Während die Standard-Cloud-Verschlüsselung meist auf der Infrastrukturebene (z. B. Festplattenverschlüsselung) stattfindet, setzt die '''Application Level Encryption (ALE)''' direkt beim Entstehen der Daten an. Hierbei verschlüsselt die Anwendung sensible Informationen, ''bevor'' sie über das Netzwerk an eine Datenbank oder einen Speicher gesendet werden. === 1. Funktionsweise === Im Gegensatz zur transpar…“)
• 16:55, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Daten-Verschlüsselung in der Cloud (Die Seite wurde neu angelegt: „== Daten-Verschlüsselung in der Cloud == Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern. === 1. Encryption in Transit (Datenübertragung) === '''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk b…“)
• 16:52, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Shared Responsibility Model (Die Seite wurde neu angelegt: „== Das Shared Responsibility Model == Das '''Shared Responsibility Model''' ist eine vertragliche und operative Abgrenzung zwischen einem Cloud-Service-Provider (CSP) wie AWS, Azure oder Google Cloud und dem Kunden. Die goldene Regel lautet: Der Anbieter ist verantwortlich für die Sicherheit '''der''' Cloud, der Kunde ist verantwortlich für die Sicherheit '''in''' der Cloud. === 1. Verantwortung des Cloud-Anbieters === Der Anbieter schützt die Infr…“)
• 16:45, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Resilienz-Mechanismen: Rate Limiting & Circuit Breaking (Die Seite wurde neu angelegt: „== Resilienz-Mechanismen: Rate Limiting & Circuit Breaking == In verteilten Systemen können Fehler in einem einzelnen Dienst kaskadierende Effekte auslösen, die das gesamte System lahmlegen. Um dies zu verhindern, kommen Schutzmechanismen zum Einsatz, die die Stabilität der Architektur sicherstellen. === 1. Rate Limiting (Drosselung) === '''Rate Limiting''' kontrolliert die Anzahl der Anfragen, die ein Nutzer oder ein Client innerhalb eines bestimmte…“)
• 16:41, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Einführung: Sidecar-Proxy mit Envoy (Die Seite wurde neu angelegt: „== Einführung: Sidecar-Proxy mit Envoy == Das '''Sidecar-Muster''' ist ein Entwurfsmuster in der Softwarearchitektur, bei dem eine Hilfsanwendung (der Sidecar) neben einer Hauptanwendung platziert wird. Der weltweit am häufigsten eingesetzte Proxy für dieses Muster ist '''Envoy''', ein hochperformanter C++ Open-Source-Proxy. === 1. Was ist Envoy? === Envoy wurde ursprünglich von Lyft entwickelt und ist heute ein Projekt der Cloud Native Computing…“)
• 16:34, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Hochverfügbarkeit (Die Seite wurde neu angelegt: „== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung == '''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht. === 1. Die drei S…“)
• 16:22, 5. Feb. 2026 89.247.173.51 Diskussion erstellte die Seite Container-Orchestrierung in der Cloud (Die Seite wurde neu angelegt: „== Container-Orchestrierung in der Cloud == Während ein einzelner Container (z. B. Docker) eine Anwendung verpackt, kümmert sich die '''Orchestrierung''' um das Management von hunderten oder tausenden dieser Container über einen Cluster von Servern hinweg. Der Marktführer in diesem Bereich ist zweifellos '''Kubernetes (K8s)'''. Hier sind die zentralen Konzepte und Aufgaben einer Orchestrierungslösung: === 1. Kernaufgaben der Orchestrierung === Ein…“)