Voer plannen met meerdere stappen uit via SSH, zonder iets op uw servers te installeren.

Een plan is een geordende lijst van stappen die draaien op de hosts die u noemt. Stel het op met de hand, uit een gewoon verzoek of uit een git-repository, toon het vooraf op elke host en draai het nu of volgens schema. Dit is de runbook-automatisering die uw team al wil. De goedkeuring en de vastlegging komen erbij.

Wat het automatiseert

Het dagelijkse werk op een server, één keer opgeschreven en steeds hetzelfde uitgevoerd.

De tools staan in de toolcatalogus (in het Engels). Al het andere is een script dat een stap uploadt en uitvoert.

Plannen via SSH: Een plan is een geordende lijst van stappen, elk met een tool of een script tegen genoemde hosts. Opafra verbindt via gewone SSH. De host heeft één regel in authorized_keys nodig en er draait niets op.
Configuratiebeheer: Bewerk een bestand of zet een template uit op veel servers tegelijk. Elke host toont eerst zijn eigen diff, en elke revisie van de template blijft bewaard, met terugdraaien.
Ansible-playbooks als stappen: Houd de playbooks die u vertrouwt en draai ze als stap in een plan, naast de tools en scripts eromheen.
Herbruikbare modules: Staan dezelfde vier stappen in een derde plan, maak er dan een module van met parameters en vastgelegde uitvoer. Een fout in de module verhelpen, verhelpt hem in elk plan dat de module aanroept.
Schema's: Draai een plan volgens een cronschema, met bescherming tegen overlap, nieuwe pogingen en afhankelijkheden tussen schema's. Een nachtelijke proefrun van een plan dat niets mag wijzigen is driftdetectie.
Git-synchronisatie: Wijs Opafra naar een repository en het importeert er plannen, scripts en templates uit, in één richting. Een gesynchroniseerd plan is alleen-lezen in de builder, dus een wijziging gaat via een pull request.
Discovery: Ontdek servers uit Terraform, Kubernetes of een eigen endpoint, toon vooraf wat er in de inventaris zou veranderen en pas het dan toe.

Opgesteld door de AI-composer

Beschrijf het resultaat in gewone taal. Krijg een plan van echte stappen terug.

De composer ziet uw inventaris, uw omgevingen en de toolcatalogus, en stelt een plan op dat u kunt lezen, bewerken en als proefrun draaien zoals elk ander. Het blijft een concept tot u het bewaart, en het voert zelf niets uit.

Fig. 1, het concept dat de AI-composer teruggaf op het verzoek van @alex

Plans /Patch nginx across prod

Draft

Request

@alex

14:28:31

Patch nginx across prod and keep TLS 1.3 only.

Drafted by the composer

14:28:55

4 steps, 3 hosts, environment prod derived from the targets

1Back up current configfile.backupreads
2Upgrade nginx to 1.25.3apt.upgradechanges
3Write nginx.conf and reloadfile.templatechanges
4Verify TLS on :443http.probereads

Targetsweb-01web-02web-03

Sent to the model: your request, host and group names, and the names of scripts and templates.

Never sent: credentials, secret values, script bodies, host output.

The composer cannot run anything.

Vooraf getoond op elke host

Een proefrun verbindt met elk doel en meldt wat daar zou gebeuren.

Hosts verschillen, en dat verschil ziet u vóór de wijziging, niet halverwege. Een stap met een leescontrole meldt per host of hij iets zou aanmaken, iets zou wijzigen of niets zou veranderen. Elke andere stap toont de exacte tekst die zou draaien.

Fig. 2, proefrun van #4f2a, revisie 7, op 3 hosts

Dry run #4f2a, revision 7

14:29:40Passed on 3 hosts

What the dry run found on each host
Host	Changes	Destructive	Time
web-01	4	0	810 ms
web-02, diff shown	4	0	790 ms
web-03	4	0	840 ms
Total	12	0
Since the last run	+2	0
ssl_session_tickets added

Diffweb-02

/etc/nginx/nginx.conf+3/−2

 --- a/etc/nginx/nginx.conf
 +++ b/etc/nginx/nginx.conf
 @@ -1,7 +1,7 @@
  user  www-data;
−worker_processes  4;
+worker_processes  auto;
  pid /run/nginx.pid;
 @@ -31,6 +31,7 @@
      ssl_prefer_server_ciphers on;
−    ssl_protocols TLSv1.2;
+    ssl_protocols TLSv1.3;
+    ssl_session_tickets off;

Patchcampagne voor het hele park

Patch een heel serverpark in golven, en stop zodra de fouten de drempel overschrijden.

Een campagne draait één plan over het serverpark met gefaseerde uitvoering: telkens een golf hosts, met een foutdrempel die u instelt. De pagina wijzigingsbeheer behandelt de vastlegging van wat is gepatcht en wat is overgeslagen.

Golven: Hosts patchen in groepen van de grootte die u kiest, de ene golf na de andere, zodat een slechte patch eerst een paar hosts raakt en niet het hele park.
Een foutdrempel: Stel in hoeveel fouten de campagne toelaat. Overschrijden de fouten de drempel, dan stopt ze voordat de volgende golf begint.
Per host de uitkomst: De vastlegging leest gepatcht, mislukt of overgeslagen voor elke host, met de reden voor elke host die is weggelaten.

Wat Opafra toevoegt

Automatisering die antwoordt op wie het draaide, en met wiens goedkeuring.

Beide volgen het werk. Zie de toepassing wijzigingsbeheer en de vastlegging van de wijziging op de bewijspagina. De Cyberbeveiligingswet vraagt maatregelen die schriftelijk zijn vastgelegd en aantoonbaar toegepast. De vastlegging van elke run is bewijs van die toepassing.

De goedkeuring: Een omgeving kan goedkeuring vereisen, en dan wacht elke run die haar raakt op een met naam genoemd persoon met toegang tot die omgeving. De goedkeuring geldt voor één exacte revisie, dus het bewerken van het plan daarna maakt haar ongeldig.
De vastlegging: Wie het vroeg, wat is opgesteld en door wat, wie goedkeurde, wat elke stap deed op elke host. Ze blijft in het append-only auditlog staan nadat het plan is bewerkt, en het log exporteert als CSV of NDJSON.

Draai uw eerste plan op uw eigen hosts.

Vertel ons wat u beheert en wat u nu met de hand doet. U krijgt een demo en uw prijs schriftelijk binnen één werkdag, zonder gesprek.

Vraag een demo aan