{"id":35972,"date":"2019-10-31T22:08:54","date_gmt":"2019-10-31T19:08:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\/"},"modified":"2019-10-31T22:08:54","modified_gmt":"2019-10-31T19:08:54","slug":"avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","title":{"rendered":"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il SDSM \u00e8 finito, ma il desiderio incontrollato di scrivere \u00e8 rimasto. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/fs.linkmeup.ru\/images\/adsm\/0\/kdpv.jpg\"><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/2da9a566e92a782cf1205a6da716d4c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Per molti anni, il nostro collega ha sofferto nell'eseguire compiti ripetitivi, incrociando le dita prima del commit e dormendo poco a causa dei rollback notturni.<br \/>\nMa anche i tempi bui devono finire.<\/p>\n<p>Con questo articolo inizier\u00f2 una serie su come <i>me<\/i> la automazione \u00e8 percepita. <br \/>\nDurante il percorso, esamineremo le fasi dell'automazione, la gestione delle variabili, la formalizzazione del design, il RestAPI, NETCONF, YANG, YDK e programmeremo molto. <br \/>\n<i>Per me<\/i> significa che a) non \u00e8 una verit\u00e0 oggettiva, b) non \u00e8 l'approccio migliore in modo incondizionato, c) il mio punto di vista potrebbe cambiare anche durante il cammino dall'articolo iniziale all'ultimo - onestamente, dalla bozza alla pubblicazione ho riscritto tutto due volte. <\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Contenuto<\/h1>\n<p><\/p>\n<ol>\n<li> <b>Obiettivi<\/b>\n<ol>\n<li>La rete \u00e8 come un organismo unico<\/li>\n<li>Testare la configurazione<\/li>\n<li>Versioning<\/li>\n<li>Monitoraggio e auto-ripristino dei servizi<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Strumenti<\/b>\n<ol>\n<li>Sistema di inventario<\/li>\n<li>Sistema di gestione dello spazio IP<\/li>\n<li>Sistema di descrizione dei servizi di rete<\/li>\n<li>Meccanismo di inizializzazione dei dispositivi<\/li>\n<li>Modello di configurazione indipendente dal fornitore<\/li>\n<li>Interfaccia specifica del fornitore con driver<\/li>\n<li>Meccanismo di consegna della configurazione ai dispositivi<\/li>\n<li>CI\/CD<\/li>\n<li>Meccanismo di backup e ricerca delle anomalie<\/li>\n<li>Sistema di monitoraggio<\/li>\n<\/ol>\n<p>\n <\/li>\n<li> <b>Conclusione<\/b>\n <\/li>\n<\/ol>\n<p>\nProver\u00f2 a portare il ADSCM in un formato leggermente diverso dal SDSM. Ci saranno ancora articoli numerati ampi e tra di essi pubblicher\u00f2 piccole note dall'esperienza quotidiana. Cercher\u00f2 di combattere il perfezionismo e di non rifinire ognuno di essi. <\/p>\n<blockquote><p> \u00c8 curioso che per la seconda volta debba percorrere lo stesso cammino.<\/p>\n<p> Inizialmente ho dovuto scrivere articoli sulle reti perch\u00e9 non ce n'erano in Rete russa.<\/p>\n<p> Ora non sono riuscito a trovare un documento completo che sistematizzasse gli approcci all'automazione e esplorasse le tecnologie menzionate attraverso esempi pratici semplici.<\/p>\n<p> Potrei sbagliarmi, quindi inviatemi link a risorse valide. Tuttavia, questo non cambier\u00e0 la mia determinazione a scrivere, poich\u00e9 l'obiettivo principale \u00e8 imparare qualcosa per me stesso, e rendere la vita pi\u00f9 facile agli altri \u00e8 un gradevole bonus che arricchisce la diffusione della conoscenza.\n<\/p><\/blockquote>\n<p>Proveremo a prendere un data center di medie dimensioni, il LAN DC, e lavoreremo su tutto lo schema di automazione. <br \/>\nAlcune cose le far\u00f2 praticamente per la prima volta insieme a voi. <\/p>\n<blockquote><p> Nelle idee e negli strumenti descritti qui non sar\u00f2 originale. Dmitry Figol ha un ottimo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=MLeiShwb7Qo&amp;list=PLSwGHYY8t8JiGI9powOXDHTAXDSs7FZqt\">canale con streaming su questo argomento<\/a><\/noindex>. <br \/>\n Gli articoli si sovrapporranno in molti aspetti con i suoi. \n<\/p><\/blockquote>\n<p>Nel LAN DC ci sono 4 DC, circa 250 switch, una mezza dozzina di router e un paio di firewall. <br \/>\nNon \u00e8 Facebook, ma \u00e8 sufficiente per riflettere profondamente sull'automazione. <br \/>\nSi dice, comunque, che se hai pi\u00f9 di un dispositivo, hai gi\u00e0 bisogno di automazione. <br \/>\nIn realt\u00e0 \u00e8 difficile immaginare che qualcuno possa vivere senza almeno un pacchetto di script di automazione. <br \/>\nAnche se ho sentito che ci sono aziende dove la gestione degli indirizzi IP viene fatta in Excel e ogni migliaio di dispositivi di rete viene configurato manualmente con la propria configurazione unica. Certo, questo pu\u00f2 essere considerato arte moderna, ma i sentimenti di un ingegnere sarebbero sicuramente offesi. <\/p>\n<h1>Obiettivi<\/h1>\n<p>\nOra stabiliremo obiettivi massimamente astratti:<\/p>\n<ul>\n<li>La rete \u00e8 come un organismo unico<\/li>\n<li>Testare la configurazione<\/li>\n<li>Versionamento dello stato della rete<\/li>\n<li>Monitoraggio e auto-ripristino dei servizi<\/li>\n<\/ul>\n<p>\nSuccessivamente in questo articolo discuteremo quali strumenti utilizzeremo, e nei successivi sia gli obiettivi che i mezzi in dettaglio.<\/p>\n<h2>La rete \u00e8 come un organismo unico<\/h2>\n<p>\nLa frase determinante del ciclo, sebbene a prima vista possa sembrare insignificante: <b>configureremo la rete, non i singoli dispositivi.<\/b>. <br \/>\nNegli ultimi anni abbiamo assistito a un cambiamento di enfasi verso il trattamento della rete come una singola entit\u00e0, da cui nascono <i>Networking definito dal software<\/i>, <i>Reti guidate dall'intento<\/i> e <i>Reti autonome<\/i>. <br \/>\nInfatti, ci\u00f2 di cui le applicazioni hanno bisogno dalla rete in modo globale: connessione tra i punti A e B (e a volte +B-Y) e isolamento dagli altri applicativi e utenti. <\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/f8b43928ccc6d487722ce7724f5c4829.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE quindi, il nostro compito in questa serie \u00e8 <b>costruire un sistema<\/b>che supporti la configurazione attuale <b>di tutta la rete<\/b>che \u00e8 gi\u00e0 scomposta nella configurazione attuale di ciascun dispositivo in base al suo ruolo e posizione. <br \/>\n<b>Sistema<\/b> La gestione della rete implica che per apportare modifiche ci rivolgiamo a essa, e essa a sua volta calcola lo stato necessario per ciascun dispositivo e lo configura. <br \/>\nIn questo modo minimizziamo quasi a zero il ricorso al CLI manualmente - qualsiasi modifica nelle impostazioni dei dispositivi o nel design della rete deve essere formalizzata e documentata - e solo dopo essere implementate sugli elementi necessari della rete. <\/p>\n<blockquote><p> Cio\u00e8, ad esempio, se decidiamo che da ora in poi gli switch di rack a Kazan devono annunciare due reti invece di una, noi<\/p>\n<ol>\n<li>Documentiamo prima le modifiche nei sistemi<\/li>\n<li>Generiamo la configurazione target di tutti i dispositivi della rete<\/li>\n<li>Avviamo il programma di aggiornamento della configurazione di rete, che calcola cosa deve essere rimosso da ciascun nodo, cosa deve essere aggiunto e porta i nodi alla stato desiderato.<\/li>\n<\/ol>\n<p>\n In questo caso, apportiamo modifiche manualmente solo al primo passo.\n<\/p><\/blockquote>\n<h2>Testare la configurazione<\/h2>\n<p>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.wikisummaries.org\/wiki\/Visible_Ops\">\u00c8 noto<\/a><\/noindex>, che l'80% dei problemi si verifica durante la modifica della configurazione: una prova indiretta \u00e8 che durante le festivit\u00e0 di Capodanno normalmente tutto \u00e8 tranquillo. <br \/>\nHo personalmente assistito a decine di downtime globali a causa di errori umani: comandi sbagliati, eseguiti nella branch errata della configurazione, dimenticanze, cancellazione globale MPLS su un router, configurato cinque dispositivi, mentre sul sesto non ho notato l'errore, ho confermato vecchie modifiche fatte da un'altra persona. Gli scenari sono infiniti. <\/p>\n<p>L'automazione ci permetter\u00e0 di commettere meno errori, ma su una scala maggiore. Cos\u00ec si pu\u00f2 bloccare non un solo dispositivo, ma tutta la rete contemporaneamente. <\/p>\n<p>Da tempi immemori, i nostri antenati verificavano la correttezza delle modifiche apportate con un occhio attento, con nervi saldi e la funzionalit\u00e0 della rete dopo il rilascio. <br \/>\nQuegli antenati le cui operazioni portavano a inutilizzi e perdite catastrofiche lasciavano meno discendenti e dovevano estinguersi col tempo, ma l'evoluzione \u00e8 un processo lento, e per questo non tutti controllano le modifiche in laboratorio. <br \/>\nTuttavia, all'avanguardia del progresso ci sono quelli che hanno automatizzato il processo di test delle configurazioni e la loro applicazione sulla rete. In altre parole, hanno preso in prestito la procedura CI\/CD (<noindex><a rel=\"nofollow\" href=\"https:\/\/img.devrant.com\/devrant\/rant\/r_1535091_ErSUL.jpg\">Continuous Integration, Continuous Deployment<\/a><\/noindex>) dagli sviluppatori.<br \/>\nIn una delle sezioni parleremo di come realizzare questo utilizzando un sistema di controllo versione, probabilmente GitHub. <\/p>\n<blockquote><p> Una volta che vi abituerete all'idea di una CI\/CD di rete, il metodo di verifica della configurazione applicandola alla rete in produzione vi sembrer\u00e0 subito un'ignoranza medievale, circa come colpire un testata con un martello.\n<\/p><\/blockquote>\n<p>Un'estensione organica delle idee di <b>un sistema<\/b> gestione della rete e CI\/CD \u00e8 una piena versionatura della configurazione. <\/p>\n<h2>Versioning<\/h2>\n<p>\nConsidereremo che qualunque modifica, anche la pi\u00f9 insignificante, anche su un dispositivo poco visibile, fa s\u00ec che l'intera rete passi da uno stato a un altro.<br \/>\nE noi non eseguiamo mai un comando su un dispositivo, ma cambiamo lo stato della rete. <br \/>\nChiamiamo questi stati versioni?<\/p>\n<p>Diciamo che la versione attuale \u00e8 1.0.0.<br \/>\n\u00c8 cambiato l'indirizzo IP dell'interfaccia Loopback su uno dei ToR? Questa \u00e8 una versione minore \u2014 ricever\u00e0 il numero 1.0.1.<br \/>\nSe abbiamo rivisto le politiche di importazione dei percorsi in BGP \u2014 un po' pi\u00f9 serio \u2014 \u00e8 gi\u00e0 1.1.0.<br \/>\nDecidiamo di abbandonare l'IGP e passare solo a BGP \u2014 questo \u00e8 gi\u00e0 un cambiamento di design radicale \u2014 2.0.0.<\/p>\n<p>Inoltre, diversi DC possono avere versioni diverse \u2014 la rete si evolve, viene installato nuovo hardware, in alcuni casi si aggiungono nuovi livelli di spine, in altri no, ecc.<\/p>\n<p>Riguardo <noindex><a rel=\"nofollow\" href=\"https:\/\/semver.org\">versionamento semantico<\/a><\/noindex> ne parleremo in un articolo separato.<\/p>\n<p>Ripeto \u2014 ogni modifica (eccetto i comandi di debug) \u00e8 un aggiornamento di versione. Gli amministratori devono essere informati di qualsiasi deviazione dalla versione attuale.<\/p>\n<p>Lo stesso vale per il rollback delle modifiche \u2014 non \u00e8 l'annullamento degli ultimi comandi, non \u00e8 un rollback effettuato dal sistema operativo del dispositivo \u2014 \u00e8 riportare l'intera rete a una nuova (o vecchia) versione. <\/p>\n<h2>Monitoraggio e auto-ripristino dei servizi<\/h2>\n<p>\nQuesta \u00e8 un compito ovvio nelle reti moderne che sale a un nuovo livello.<br \/>\nSpesso, nei grandi provider di servizi si pratica l'approccio per cui un servizio che \u00e8 caduto deve essere rapidamente ripristinato e una nuova istanza avviata, invece di indagare su cosa sia successo.<br \/>\n\"Rapidmente\" significa che da tutti i lati \u00e8 necessario assicurarsi di avere una sorveglianza abbondante, in grado di rivelare le pi\u00f9 piccole deviazioni dalla norma in pochi secondi.<br \/>\nE qui non sono sufficienti le metriche abituali, come il carico dell'interfaccia o la disponibilit\u00e0 del nodo. Non basta neppure il monitoraggio manuale dell'operatore.<br \/>\nPer molte cose, in realt\u00e0, dovrebbe esserci <noindex><a rel=\"nofollow\" href=\"https:\/\/www.irisns.com\/self-healing-network-tomorrow-look-like\/\">Self-Healing<\/a><\/noindex> \u2014 i monitor sono accesi di rosso e vanno a mettere una foglia di piantaggine dove fa male.<\/p>\n<p>E qui monitoriamo non solo singoli dispositivi, ma anche la salute dell'intera rete, sia in bianco che in nero, il che \u00e8 relativamente chiaro, ma anche pi\u00f9 complesso.<\/p>\n<p>\nDi cosa abbiamo bisogno per realizzare tali ambiziosi piani?<\/p>\n<ul>\n<li>Avere un elenco di tutti i dispositivi nella rete, la loro posizione, ruoli, modelli, versioni del software. <br \/>\n <i>kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.<\/i>\n <\/li>\n<li>Avere un sistema di descrizione dei servizi di rete. <br \/>\n <i>IGP, BGP, L2\/3VPN, Policy, ACL, NTP, SSH.<\/i><\/li>\n<li>Essere in grado di inizializzare un dispositivo. <br \/>\n <i>Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF<\/i><\/li>\n<li>Configurare il dispositivo e riportare la configurazione alla versione desiderata (comprese le versioni precedenti).<\/li>\n<li>Testare la configurazione<\/li>\n<li>Controllare periodicamente lo stato di tutti i dispositivi per eventuali anomalie e comunicare a chi di dovere.<br \/>\n <i>Di notte, qualcuno ha aggiunto silenziosamente una regola nell'ACL.<\/i>.<\/li>\n<li>Monitorare la funzionalit\u00e0.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Strumenti<\/h1>\n<p>\nSembra abbastanza complesso per cominciare a decomporre il progetto in componenti.<\/p>\n<p>E saranno dieci:<\/p>\n<ol>\n<li>Sistema di inventario<\/li>\n<li>Sistema di gestione dello spazio IP<\/li>\n<li>Sistema di descrizione dei servizi di rete<\/li>\n<li>Meccanismo di inizializzazione dei dispositivi<\/li>\n<li>Modello di configurazione indipendente dal fornitore<\/li>\n<li>Interfaccia specifica del fornitore con driver<\/li>\n<li>Meccanismo di consegna della configurazione ai dispositivi<\/li>\n<li>CI\/CD<\/li>\n<li>Meccanismo di backup e ricerca delle anomalie<\/li>\n<li>Sistema di monitoraggio<\/li>\n<\/ol>\n<blockquote><p> Questo, tra l'altro, \u00e8 un esempio di come \u00e8 cambiata la visione degli obiettivi del ciclo: nella bozza dei componenti c'erano 4.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/91132e29d359a4042b213529511f6d7d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNell'illustrazione ho rappresentato tutti i componenti e il dispositivo stesso. <br \/>\nI componenti sovrapposti interagiscono tra loro. <br \/>\nMaggiore \u00e8 il blocco, maggiore \u00e8 l'attenzione necessaria a questo componente. <\/p>\n<p><\/p>\n<h2>Componente 1. Sistema di inventario<\/h2>\n<p>\n\u00c8 evidente che vogliamo sapere quale attrezzatura si trova dove, e a cosa \u00e8 collegata. <br \/>\nIl sistema di inventario \u00e8 una parte essenziale di qualsiasi azienda. <br \/>\nSpesso le aziende hanno un sistema di inventario separato per i dispositivi di rete, che si occupa di compiti pi\u00f9 specifici. <br \/>\nNel nostro ciclo di articoli ci riferiremo a questo come DCIM - Data Center Infrastructure Management. Anche se il termine DCIM, rigorosamente parlando, include molto di pi\u00f9.<\/p>\n<p>Per i nostri scopi, in esso memorizzeremo le seguenti informazioni sul dispositivo:<\/p>\n<ul>\n<li>Numero di inventario<\/li>\n<li>Nome\/descrizione <\/li>\n<li>Modello (<i>Huawei CE12800, Juniper QFX5120 ecc.<\/i>)<\/li>\n<li>Parametri distintivi (<i>schede, interfacce ecc.<\/i>)<\/li>\n<li>Ruolo (<i>Leaf, Spine, Border Router ecc.<\/i>)<\/li>\n<li>Posizione (<i>regione, citt\u00e0, data center, rack, unit\u00e0.<\/i>)<\/li>\n<li>Interconnessioni tra i dispositivi<\/li>\n<li>Topologia di rete<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/fac708b1bf3640a943f90247bff8216e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 chiaro che vogliamo sapere tutto questo. <br \/>\nMa sar\u00e0 utile per l'automazione? <br \/>\nAssolutamente. <br \/>\nAd esempio, sappiamo che in questo data center sui Leaf switch, se \u00e8 Huawei, le ACL per filtrare un certo traffico devono essere applicate su VLAN, mentre se \u00e8 Juniper, su un'unit\u00e0 0 dell'interfaccia fisica. <br \/>\nOppure \u00e8 necessario distribuire un nuovo server Syslog su tutti i border del regione.<\/p>\n<p>In esso memorizzeremo anche dispositivi di rete virtuali, come router virtuali o route reflectors. Possiamo aggiungere server DNS, NTP, Syslog e in generale tutto ci\u00f2 che in un modo o nell'altro riguarda la rete. <\/p>\n<h2>Componente 2. Sistema di gestione dello spazio IP<\/h2>\n<p>\nS\u00ec, e ai giorni nostri ci sono gruppi di persone che tengono traccia di prefissi e indirizzi IP in un file Excel. Ma l'approccio moderno \u00e8 comunque un database, con un frontend su nginx\/apache, API e ampie funzionalit\u00e0 per la registrazione di indirizzi IP e reti con suddivisione in VRF.<br \/>\nIPAM - Gestione degli indirizzi IP. <\/p>\n<p>Per i nostri scopi, in esso memorizzeremo le seguenti informazioni:<\/p>\n<ul>\n<li>VLAN<\/li>\n<li>VRF<\/li>\n<li>Reti\/Sottoreti<\/li>\n<li>Indirizzi IP<\/li>\n<li>Associazione degli indirizzi ai dispositivi, reti alle posizioni e numeri VLAN.<\/li>\n<\/ul>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6d476d48f95ed663d84cae052a86d129.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAncora una volta \u00e8 chiaro che vogliamo essere certi che, assegnando un nuovo indirizzo IP al loopback del ToR, non inciampiamo nel fatto che sia gi\u00e0 stato assegnato a qualcun altro. O che lo stesso prefisso sia stato utilizzato due volte in diversi punti della rete. <br \/>\nMa come aiuter\u00e0 questo nell'automazione? <br \/>\nFacile. <br \/>\nRichiediamo al sistema un prefisso con funzione Loopbacks, in cui siano disponibili indirizzi IP da assegnare: se viene trovato, assegniamo l'indirizzo, se no, richiediamo la creazione di un nuovo prefisso. <br \/>\nOppure, nella creazione della configurazione di un dispositivo, possiamo scoprire tramite questo stesso sistema in quale VRF dovrebbe trovarsi l'interfaccia. <br \/>\nE quando avviamo un nuovo server, uno script consulter\u00e0 il sistema, scoprendo in quale switch server si trova, in quale porta e quale sottorete \u00e8 assegnata all'interfaccia: da essa verr\u00e0 assegnato l'indirizzo del server. <\/p>\n<p>\nSorge il desiderio di unire DCIM e IPAM in un unico sistema, per evitare di duplicare funzioni e gestire due entit\u00e0 simili. <br \/>\nCos\u00ec faremo. <\/p>\n<h2>Componente 3. Sistema di descrizione dei servizi di rete<\/h2>\n<p>\nSe i primi due sistemi memorizzano variabili che devono ancora essere utilizzate in qualche modo, il terzo descrive per ogni ruolo del dispositivo come dovrebbe essere configurato. <br \/>\n\u00c8 utile distinguere due tipi diversi di servizi di rete: <\/p>\n<ul>\n<li>Infrastrutturali<\/li>\n<li>Client.<\/li>\n<\/ul>\n<p>I primi sono destinati a garantire la connettivit\u00e0 di base e la gestione del dispositivo. Qui rientrano VTY, SNMP, NTP, Syslog, AAA, protocolli di routing, CoPP ecc. <br \/>\nI secondi offrono un servizio al cliente: MPLS L2\/L3VPN, GRE, VXLAN, VLAN, L2TP ecc. <br \/>\nNaturalmente ci sono anche casi limite: come classificare MPLS LDP, BGP? Inoltre, i protocolli di routing possono essere utilizzati anche per i clienti. Ma non \u00e8 fondamentale. <\/p>\n<p>Entrambi i tipi di servizi si scompongono in primitive di configurazione:<\/p>\n<ul>\n<li>interfacce fisiche e logiche (tag\/antitag, mtu)<\/li>\n<li>Indirizzi IP e VRF (IP, IPv6, VRF)<\/li>\n<li>ACL e politiche di gestione del traffico<\/li>\n<li>Protocolli (IGP, BGP, MPLS)<\/li>\n<li>Politiche di routing (liste di prefissi, comunit\u00e0, filtri ASN).<\/li>\n<li>Servizi di supporto (SSH, NTP, LLDP, Syslog\u2026)<\/li>\n<li>Ecc.<\/li>\n<\/ul>\n<p>\nNon sono sicuro di come procederemo, ne discuteremo in un articolo separato.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/092bc3a4b875f4a6422ee13fb580ba4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe vogliamo renderlo pi\u00f9 concreto, potremmo descrivere quello che<br \/>\nGli switch Leaf devono avere sessioni BGP con tutti gli switch Spine connessi, importare nella rete connessa e accettare solo le reti da parte degli switch Spine che appartengono a un determinato prefisso. Limitare il CoPP IPv6 ND a 10 pps, ecc. <br \/>\nA sua volta, gli Spine mantengono sessioni con tutti i Leaf connessi, fungendo da route reflectors, e accettano solo rotte di una certa lunghezza e con una specifica community.<\/p>\n<h2>Componente 4. Meccanismo di inizializzazione dispositivo<\/h2>\n<p>\nSotto questo titolo unisco una serie di azioni che devono avvenire affinch\u00e9 il dispositivo appaia nei radar e possa essere raggiunto da remoto.<\/p>\n<ol>\n<li>Registrare il dispositivo nel sistema di inventario.<\/li>\n<li>Assegnare un indirizzo IP di gestione.<\/li>\n<li>Configurare l'accesso di base a esso: <br \/>\nNome host, indirizzo IP di gestione, percorso nella rete di gestione, utenti, chiavi SSH, protocolli \u2014 telnet\/SSH\/NETCONF<\/li>\n<\/ol>\n<p>Esistono tre approcci:<\/p>\n<ul>\n<li>Completamente manuale. Il dispositivo viene portato su un tavolo di test, dove una persona normale lo registrer\u00e0 nei sistemi, si connetter\u00e0 tramite console e lo configurer\u00e0. Pu\u00f2 funzionare in piccole reti statiche.<\/li>\n<li>ZTP \u2014 Zero Touch Provisioning. L'hardware \u00e8 arrivato, si \u00e8 attaccato, ha ottenuto un indirizzo tramite DHCP e si \u00e8 configurato autonomamente. <\/li>\n<li>Infrastruttura di server console, dove la configurazione iniziale avviene attraverso la porta console in modalit\u00e0 automatica.<\/li>\n<\/ul>\n<p>Di tutti e tre parleremo in un articolo separato.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6d8d061e53b508edbbcbd98fe496ca91.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 5. Modello di configurazione vendor-agnostico<\/h2>\n<p>\nFino ad ora, tutti i sistemi erano patchwork disomogenei, fornendo descrizioni variabili e dichiarative di ci\u00f2 che ci piacerebbe vedere nella rete. Ma prima o poi, dovremo affrontare la specificit\u00e0. <br \/>\nIn questa fase, per ogni dispositivo specifico, primitive, servizi e variabili vengono combinati in un modello di configurazione che descrive effettivamente la configurazione completa del dispositivo specifico, solo in modo vendor-indipendente. <br \/>\nQual \u00e8 il vantaggio di questo passaggio? Perch\u00e9 non formare immediatamente la configurazione del dispositivo che pu\u00f2 essere semplicemente caricata? <br \/>\nIn realt\u00e0, permette di affrontare tre compiti:<\/p>\n<ol>\n<li> Non dover adattarsi a un'interfaccia specifica di interazione con il dispositivo. Che si tratti di CLI, NETCONF, RESTCONF, SNMP \u2014 il modello sar\u00e0 identico.<\/li>\n<li> Non mantenere un numero di template\/script pari al numero di vendor nella rete, e in caso di modifica del design, cambiare la stessa cosa in pi\u00f9 posti.<\/li>\n<li> Caricare la configurazione da un dispositivo (backup), organizzandola in un modello esattamente uguale e confrontando direttamente la configurazione target con quella attuale per calcolare la differenza e preparare una patch di configurazione che modifichi solo le parti necessarie o per identificare le deviazioni.<\/li>\n<\/ol>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/a154c42ebe7978fcc5b2ce4f235516c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA seguito di questo passaggio otteniamo una configurazione vendor-indipendente.<\/p>\n<h2>Componente 6. Driver specifico per interfaccia vendor<\/h2>\n<p>\nNon dobbiamo illuderci di poter configurare Cisco esattamente come Juniper, semplicemente inviando su di esse chiamate assolutamente identiche. Nonostante la popolarit\u00e0 crescente dei whitebox e l'emergere del supporto per NETCONF, RESTCONF, OpenConfig, il contenuto specifico fornito da questi protocolli varia da fornitore a fornitore, ed \u00e8 una delle loro distinzioni competitive che non cederanno facilmente. <br \/>\nQuesto \u00e8 esattamente simile a OpenContrail e OpenStack, che hanno REST API come interfaccia NorthBound, e si aspettano chiamate completamente diverse. <\/p>\n<p>Pertanto, nel quinto passaggio, il modello vendor-indipendente deve assumere la forma che andr\u00e0 sull'hardware. <br \/>\nE qui tutti i mezzi sono buoni (no): CLI, NETCONF, RESTCONF, SNMP \u2014 tutto pu\u00f2 andar bene.<\/p>\n<p>Quindi avremo bisogno di un driver che traduca il risultato del passaggio precedente nel formato necessario per il specifico vendor: un insieme di comandi CLI, una struttura XML.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/6ed8e935183075fda60a209477f84937.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 7. Meccanismo di consegna della configurazione al dispositivo<\/h2>\n<p>\nLa configurazione l'abbiamo generata, ma deve ancora essere consegnata ai dispositivi \u2014 e, chiaramente, non manualmente. <br \/>\n<b>In primo luogo<\/b>Ora si pone la questione: quale trasporto utilizzeremo? E la scelta oggi \u00e8 gi\u00e0 ampia:<\/p>\n<ul>\n<li>CLI (telnet, ssh)<\/li>\n<li>SNMP<\/li>\n<li>NETCONF<\/li>\n<li>richieste RESTCONF<\/li>\n<li>REST API<\/li>\n<li>OpenFlow (anche se esce dalla lista poich\u00e9 \u00e8 un modo per consegnare FIB e non configurazioni)<\/li>\n<\/ul>\n<p>Chiarendo i termini. CLI \u00e8 legacy. SNMP\u2026 ehm.<br \/>\nRESTCONF \u00e8 ancora una bestia sconosciuta, le REST API non sono supportate quasi da nessuno. Pertanto, nel ciclo ci concentreremo su NETCONF.<\/p>\n<p>In realt\u00e0, come gi\u00e0 compreso dal lettore, a questo punto abbiamo gi\u00e0 stabilito l'interfaccia \u2014 il risultato del passaggio precedente \u00e8 gi\u00e0 presentato nel formato di quell'interfaccia che \u00e8 stata scelta.<\/p>\n<p><b>In secondo luogo<\/b>E quali strumenti utilizzeremo per farlo?<br \/>\nQui la scelta \u00e8 ampia:<\/p>\n<ul>\n<li>Script personalizzato o piattaforma. Armati di ncclient e asyncIO e facciamo tutto noi. Cosa ci impedisce di costruire un sistema di deployment da zero?<\/li>\n<li>Ansible con la sua ricca libreria di moduli di rete.<\/li>\n<li>Salt con la sua limitata gestione della rete e integrazione con Napalm.<\/li>\n<li>Proprio Napalm, che conosce alcuni vendor e poi basta, arrivederci.<\/li>\n<li>Nornir \u2014 un altro strumento che analizzeremo in futuro.<\/li>\n<\/ul>\n<p>Qui non \u00e8 ancora stato scelto un favorito \u2014 stiamo esplorando.<\/p>\n<p>Cosa \u00e8 importante qui? Le conseguenze dell'applicazione della configurazione. <br \/>\nSe ha successo o meno. Rimane l'accesso all'hardware o meno. <br \/>\nSembra che un commit con conferma e validazione di ci\u00f2 che \u00e8 stato caricato nel dispositivo possa aiutare. <br \/>\nQuesto, combinato con una corretta implementazione di NETCONF, restringe notevolmente il numero di dispositivi compatibili \u2014 gli impegni standard non sono supportati da molti produttori. Ma questo \u00e8 solo uno dei requisiti in <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%97%D0%B0%D0%BF%D1%80%D0%BE%D1%81_%D0%BF%D1%80%D0%B5%D0%B4%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D1%8F\">RFP<\/a><\/noindex>. Alla fine nessuno si preoccupa che nessun fornitore russo soddisfi il requisito di 32*100GE interfaccia. O si preoccupa?<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/59d8ad3b55b9c107642550bb06fc759a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Componente 8. CI\/CD<\/h2>\n<p>\nA questo punto abbiamo gi\u00e0 configurato tutti i dispositivi di rete.<br \/>\nScrivo \"tutti\" perch\u00e9 parliamo di versionamento dello stato della rete. E anche se \u00e8 necessario cambiare le impostazioni di un solo switch, vengono calcolati i cambiamenti per tutta la rete. Ovviamente, questi possono essere nulli per la maggior parte dei nodi.<\/p>\n<p>Ma, come gi\u00e0 detto sopra, non siamo barbarici per lanciare tutto direttamente in produzione. <br \/>\nLa configurazione generata deve prima passare attraverso il Pipeline CI\/CD.<\/p>\n<blockquote><p>CI\/CD significa Integrazione Continua, Distribuzione Continua. Questo approccio consente al team di non pubblicare un nuovo rilascio principale ogni sei mesi, sostituendo completamente il vecchio, ma di implementare regolarmente nuova funzionalit\u00e0 in piccole porzioni, ognuna delle quali viene testata a fondo per compatibilit\u00e0, sicurezza e funzionalit\u00e0.\n<\/p><\/blockquote>\n<p>A tal fine abbiamo un sistema di controllo versione che tiene traccia delle modifiche alla configurazione, un laboratorio dove verifichiamo che il servizio clienti non venga interrotto, un sistema di monitoraggio che verifica questo fatto, e l'ultimo passo \u2014 il rilascio delle modifiche alla rete operativa.<\/p>\n<p>Ad eccezione dei comandi di debug, tutte le modifiche sulla rete devono passare attraverso il Pipeline CI\/CD \u2014 questo \u00e8 la nostra garanzia di una vita tranquilla e una carriera lunga e felice.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/101a5ff87c7a9c7b6776aca9daf762a4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 9. Sistema di backup e rilevamento delle anomalie<\/h2>\n<p>\nNon c'\u00e8 bisogno di parlare troppo dei backup. <br \/>\nLi salveremo semplicemente cronologicamente o in base alle modifiche della configurazione in git.<\/p>\n<p>Ma la seconda parte \u00e8 pi\u00f9 interessante \u2014 qualcuno deve sorvegliare questi backup. In alcuni casi, questa persona deve ripristinare tutto, mentre in altri, avvisare qualcuno che c'\u00e8 un problema. <br \/>\nAd esempio, se compare un nuovo utente che non \u00e8 elencato nelle variabili, \u00e8 meglio rimuoverlo per evitare intrusioni. E nel caso di una nuova regola firewall \u2014 meglio non toccarla, potrebbe essere che qualcuno abbia semplicemente attivato il debug, oppure un nuovo servizio, trascurato, non l'ha impostata secondo le linee guida, e ora gli utenti ci stanno accedendo.<\/p>\n<p>Non possiamo evitarci dalle piccole deviazioni su scala dell'intera rete, nonostante qualsiasi sistema di automazione e una mano ferma nella gestione. Per il debugging dei problemi, comunque nessuno apporter\u00e0 modifiche alla configurazione nei sistemi. Soprattutto, poich\u00e9 il modello di configurazione potrebbe non prevederle nemmeno. <\/p>\n<blockquote><p>Ad esempio, una regola firewall per il conteggio dei pacchetti su un determinato IP, per localizzare il problema \u2014 \u00e8 una configurazione temporanea del tutto ordinaria.\n<\/p><\/blockquote>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/390f78139d336f1fc2c60573bccfe76c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h2>Componente 10. Sistema di monitoraggio<\/h2>\n<p>\nInizialmente non intendevo trattare il tema del monitoraggio \u2014 \u00e8 un argomento complesso, dibattuto e ampio. Ma si \u00e8 rivelato essere una parte integrante dell'automazione. E non si pu\u00f2 semplicemente ignorarlo, nemmeno senza pratica. <\/p>\n<p>Sviluppando il pensiero \u2014 \u00e8 una parte organica del processo CI\/CD. Dopo il rilascio della configurazione sulla rete, dobbiamo essere in grado di determinare se ora va tutto bene. <br \/>\nE non si tratta solo e non tanto dei grafici di utilizzo delle interfacce o della disponibilit\u00e0 dei nodi, quanto di questioni pi\u00f9 sottili \u2014 la presenza delle rotte necessarie, attributi su di esse, numero di sessioni BGP, vicini OSPF, funzionalit\u00e0 End-to-End dei servizi superiori.<br \/>\nE se i syslog non stanno pi\u00f9 accumulandosi su un server esterno, o se l'agente SFlow non \u00e8 guasto, o se non ci sia un aumento dei drop nelle code, o se non sia compromessa la connettivit\u00e0 tra una certa coppia di prefissi?<\/p>\n<p>In un articolo separato rifletteremo anche su questo.<\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/08aeee4939081abb21e61abadd0ce5de.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><img decoding=\"async\" alt=\"Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione\" src=\"\/wp-content\/uploads\/2019\/07\/13c186070c85fd00f7b6923df154f1b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h1>Conclusione<\/h1>\n<p>\nCome base ho scelto uno dei design moderni delle reti di data center \u2014 L3 Clos Fabric con BGP come protocollo di routing.<br \/>\nQuesta volta costruiremo la rete su Juniper, perch\u00e9 ora l'interfaccia JunOs \u00e8 una meraviglia.<\/p>\n<p>Ci complicheremo la vita utilizzando solo strumenti Open Source e una rete multivendor \u2014 quindi oltre a Juniper sceglier\u00f2 anche un altro fortunato.<\/p>\n<p>Il piano delle prossime pubblicazioni \u00e8 pi\u00f9 o meno questo:<br \/>\nInizier\u00f2 a parlare delle reti virtuali. Prima di tutto perch\u00e9 mi va, e in secondo luogo perch\u00e9 senza questo il design della rete infrastrutturale sar\u00e0 poco chiaro.<br \/>\nPoi parler\u00f2 del design della rete: topologia, routing, politiche.<br \/>\nCostruiremo una lab stand.<br \/>\nRifletteremo e, forse, faremo pratica con l'inizializzazione di un dispositivo in rete.<br \/>\nE poi approfondiremo ogni componente in dettagli intimi.<\/p>\n<p>E s\u00ec, non prometto di concludere elegantemente questo ciclo con una soluzione pronta. \ud83d\ude42<\/p>\n<h5>Link utili<\/h5>\n<p><\/p>\n<ul>\n<li>Prima di addentrarci nella serie, \u00e8 consigliabile leggere il libro di Natasha Samoylenko <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.gitbook.io\/pyneng\/\">Python per ingegneri di rete<\/a><\/noindex>. E, forse, anche seguirlo con <noindex><a rel=\"nofollow\" href=\"https:\/\/natenka.github.io\/pyneng-online\/\">corso<\/a><\/noindex>.<\/li>\n<li>Sar\u00e0 utile anche leggere <noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7938\">RFC<\/a><\/noindex> sul design delle fabbriche di data center da Facebook, scritto da Petr Lapukhov.<\/li>\n<li>La documentazione sull'architettura ti dar\u00e0 un'idea di come funziona il SDN basato su Overlay. <noindex><a rel=\"nofollow\" href=\"https:\/\/tungstenfabric.github.io\/website\/Tungsten-Fabric-Architecture.html\">Tungsten Fabric<\/a><\/noindex> (precedentemente Open Contrail).<\/li>\n<\/ul>\n<h5>Grazie<\/h5>\n<p>\nRoman Gorge. Per i commenti e le correzioni.<br \/>\nArtyom Chernobai. Per KDPV.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/453516\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c. \u0414\u043e\u043b\u0433\u0438\u0435 \u0433\u043e\u0434\u044b \u043d\u0430\u0448 \u0431\u0440\u0430\u0442 \u0441\u0442\u0440\u0430\u0434\u0430\u043b \u043e\u0442 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u0440\u0443\u0442\u0438\u043d\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b, \u0441\u043a\u0440\u0435\u0449\u0438\u0432\u0430\u043b \u043f\u0430\u043b\u044c\u0446\u044b \u043f\u0435\u0440\u0435\u0434 \u043a\u043e\u043c\u043c\u0438\u0442\u043e\u043c \u0438 \u043d\u0435\u0434\u043e\u0441\u044b\u043f\u0430\u043b \u0438\u0437-\u0437\u0430 \u043d\u043e\u0447\u043d\u044b\u0445 \u0440\u043e\u043b\u0431\u044d\u043a\u043e\u0432. \u041d\u043e \u0442\u0451\u043c\u043d\u044b\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0430\u043c \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442 \u043a\u043e\u043d\u0435\u0446. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0451\u0439 \u044f \u043d\u0430\u0447\u043d\u0443 \u0441\u0435\u0440\u0438\u044e \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u043d\u0435 \u0432\u0438\u0434\u0438\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f. \u041f\u043e \u0445\u043e\u0434\u0443 \u0434\u0435\u043b\u0430 \u0440\u0430\u0437\u0431\u0435\u0440\u0451\u043c\u0441\u044f \u0441 \u044d\u0442\u0430\u043f\u0430\u043c\u0438 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435\u043c \u043f\u0435\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0445, \u0444\u043e\u0440\u043c\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0435\u0439 \u0434\u0438\u0437\u0430\u0439\u043d\u0430, \u0441 RestAPI, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26891,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35972","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0434\u043b\u044f \u0441\u0430\u043c\u044b\u0445 \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043d\u0443\u043b\u0435\u0432\u0430\u044f. \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:08:54+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automazione per i pi\u00f9 piccoli. Parte zero. Pianificazione | ProHoster","description":"Il SDSM \u00e8 finito, ma il desiderio incontrollato di scrivere \u00e8 rimasto.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0434\u043b\u044f \u0441\u0430\u043c\u044b\u0445 \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445. \u0427\u0430\u0441\u0442\u044c \u043d\u0443\u043b\u0435\u0432\u0430\u044f. \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u0421\u0414\u0421\u041c \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0441\u044f, \u0430 \u0431\u0435\u0441\u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u043e\u0435 \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u043f\u0438\u0441\u0430\u0442\u044c \u2014 \u043e\u0441\u0442\u0430\u043b\u043e\u0441\u044c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-dlya-samyh-malenkih-chast-nulevaya-planirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:08:54+00:00","article:modified_time":"2019-10-31T19:08:54+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35972","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 01:28:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 09:58:22","updated":"2026-01-22 01:28:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35972","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35972"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35972\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26891"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35972"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35972"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35972"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}