Naar de inhoud

    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

    1. 1Back up current configreads
    2. 2Upgrade nginx to 1.25.3changes
    3. 3Write nginx.conf and reloadchanges
    4. 4Verify TLS on :443reads
    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
    HostChangesDestructiveTime
    web-0140810 ms
    web-02, diff shown40790 ms
    web-0340840 ms
    Total120
    Since the last run+20
    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. Bij een CyFun-verificatie telt bewijs van de uitvoering mee in de score, niet alleen de documentatie.

    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.