Difficilmente sarebbe sbagliato dire che è il migliore degli uomini
trovare la gioia attraverso la sofferenza.
Ludwig van Beethoven
Sono Sergey, lavoro presso Yandex.Money nel team di ricerca sulle prestazioni. Voglio raccontarvi l'inizio della storia del nostro percorso verso l'uso dell'orchestrazione: come abbiamo scelto gli strumenti e cosa abbiamo preso in considerazione. Tutti gli eventi dell'articolo si svolgono in tempo reale, quindi voi, cari lettori, seguite lo sviluppo della situazione quasi in diretta.
Perché abbiamo bisogno di un conduttore nella nostra squadra?
Chi è un conduttore? Da p. diriger - gestire, dirigere, condurre - nel mondo della musica - questa è una persona che è il leader dell'apprendimento e dell'esecuzione della musica d'insieme. Nel nostro caso, questo posto è occupato dai sistemi di orchestrazione e automazione.
Il loro ruolo non è diverso da quello di un direttore d'orchestra nella musica: sono necessari per aiutare la squadra, guidare e organizzare il suo gioco.
Di norma, un team dispone di un certo insieme di capacità, chiamiamole server, su cui implementa i propri progetti.
L'approccio per ottenere e utilizzare questi server è vario. Alcuni esempi:
- La squadra richiede, ad esempio, al gruppo operativo di fornire loro risorse con determinati parametri.
- Il team operativo fornisce loro la quantità richiesta – cloud o bare metal – e si impegna a mantenerli in condizioni adeguate secondo lo SLA. L'allestimento viene effettuato anche dal team operativo.
- Il team riceve solo risorse cloud o bare metal dal gruppo operativo e le configura autonomamente.
- Il team stesso “acquista” le risorse e le mantiene/imposta in modo completamente indipendente.
Il nostro team utilizza server che devono essere supportati: aggiornamento del sistema operativo, installazione di nuovi pacchetti, ecc.
Per quanto ci riguarda, li abbiamo divisi in due tipologie principali:
- gruppo di carri armati,
- gruppo di servizi.
Il gruppo di carri armati è composto da host con Yandex.Tank.
Il gruppo di servizi comprende tutto ciò che riguarda la manutenzione: si tratta di vari servizi per fornire supporto per il ciclo di rilascio, generare report automatici, ecc.
Ad un certo punto tutto questo è diventato scomodo da gestire manualmente e abbiamo pensato di automatizzare l'intero processo, partendo dal “caricamento” dei server per finire con lo sviluppo, il rilascio e il lancio del nostro servizio interno.
Perché è necessario un direttore d'orchestra, anche se l'orchestra stessa può suonare?
Per cominciare, abbiamo padroneggiato Ansible e abbiamo iniziato a "versare" i nostri server bare metal per essere meno dipendenti dagli amministratori di sistema: qui vincono tutti, acquisiamo nuove competenze e solleviamo gli amministratori da parte del lavoro che hanno sempre abbastanza senza di noi . Ci sforziamo di svilupparci il più possibile oltre la nostra specialità e l'autonomia del team.
In azienda, il lavoro con Ansible è configurato e regolamentato da molto tempo, quindi abbiamo integrato facilmente la nostra soluzione in questo processo.
Attualmente, il pool host è costituito da tre ruoli Ansible:
- il primo ruolo installa il sistema operativo,
- il secondo esegue le impostazioni di base per l'host, l'autorizzazione LDAP, ad esempio,
- e il terzo installa Yandex.Tank e le relative dipendenze in un contenitore docker.
Passiamo ai servizi che utilizziamo all'interno del team.
Per i nostri compiti utilizziamo allo stesso modo Kotlin e Python e un po’ di più Golang. Per unificare lo sviluppo e l'implementazione dei nostri servizi, abbiamo deciso di impacchettarli in contenitori Docker. Questo ti dà la libertà di scegliere un linguaggio di programmazione e allo stesso tempo regola un formato di consegna uniforme per la tua applicazione.
Una piccola nota su IPv6 in Docker
Alcuni dei servizi con cui interagiamo sono disponibili solo tramite ipv6, quindi abbiamo dovuto capire come creare ipv6 per i contenitori.
Secondo la documentazione ipv6 sul sito web ufficiale di Docker, ipv6 viene abilitato aggiungendo parametri a daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}In questo caso, il provider deve emettere una sottorete IPv6, nella quale ti registrerai fixed-cidr-v6.
Tuttavia, abbiamo scelto un'altra opzione: IPv6 NAT, ed ecco perché:
- Ora finestra mobile solo con IPv6.
- Avere un indirizzo instradabile a livello globale in ciascun contenitore significa che tutte le porte (anche quelle non pubblicate) sono esposte a tutti a meno che non venga eseguito un ulteriore filtraggio.
- proxy dell'area utente per la pubblicazione dei porti, .
IPv6 NAT è , che a sua volta gestisce le regole in ip6tables e le modifica quando si aggiunge un nuovo contenitore.
Affinché questa soluzione funzioni correttamente, è stato necessario effettuare una serie di altre manipolazioni. Assicurati di inizializzare ip6table_nat sul sistema. La presenza di un modulo installato sul sistema non garantisce che il modulo verrà caricato nel kernel all'avvio. L'abbiamo riscontrato quando abbiamo ricevuto questo errore durante l'esecuzione di un contenitore con NAT su un nuovo host:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)Il problema è stato risolto dopo aver aggiunto l'inizializzazione al ruolo Ansible utilizzando il modulo modprobe e caricandolo all'avvio del sistema operativo utilizzando lineinfile:
- name: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'A proposito, ce n'è uno buono sull'hub , che descrive brevemente e chiaramente i vantaggi e gli svantaggi dell'uno o dell'altro metodo per eseguire ipv6 nella finestra mobile.
Ma torniamo alla nostra domanda posta all'inizio:
Perché è necessario un direttore d'orchestra, anche se l'orchestra stessa può suonare?
Ora tutti immaginano come giocare nella nostra squadra:
- è stato creato il processo di “versamento” dei server,
- lo sviluppo e l'implementazione dei servizi sono unificati.
Sorge una domanda ragionevole: come distribuire, aggiornare e controllare i nostri servizi nei contenitori Docker in modo efficiente e nel modo più automatico possibile?
Nonostante ogni membro dell'orchestra conosca la sua parte, può confondersi e deviare dall'idea originale. Qui arriviamo alla conclusione che senza un direttore la nostra orchestra non proverà in modo efficace e suonerà in modo coerente. Il direttore d'orchestra è responsabile di tutti i parametri dell'esecuzione, assicurandosi che tutto sia unito da un unico tempo e umore.
Come ottenere un buon direttore d'orchestra con un investimento minimo?
Il tema dell’orchestrazione è abbastanza ben sviluppato nel mercato. Ma prima parliamo degli strumenti ausiliari che possono aiutare il conduttore.
- un sistema che prevede due funzioni principali:
- scoperta del servizio,
- archiviazione distribuita di valori-chiave.
Nella nostra orchestra, il Console sarà responsabile della registrazione dei servizi e della memorizzazione delle loro configurazioni. Sono disponibili due opzioni di registrazione:
- Attivo è quando il servizio si registra utilizzando l'API HTTP;
- Passivo: il servizio deve essere registrato manualmente.
Vault è un repository che standardizza e unifica l'archiviazione sicura e la gestione dei segreti: password, certificati.
Ecco i vantaggi che otterremo utilizzando questo strumento:
- Un unico centro per la creazione e l'archiviazione dei segreti e la gestione del loro ciclo di vita utilizzando l'API HTTP.
- Transit Secrets Engine: crittografia e decrittografia dei dati senza salvarli. La capacità di trasmettere dati in forma crittografata su canali di comunicazione non protetti.
- Policy di accesso facili da configurare.
- Controllo dell'accesso ai segreti.
- La possibilità di creare la propria CA (Certificate Authority) per gestire i certificati autofirmati all'interno della propria infrastruttura.
Considerando tutte le nostre esigenze, due opzioni erano adatte per il ruolo di conduttore: Kubernetes e Nomad.
kubernetes
Quanti articoli e libri sono già stati scritti su di lui (qui , per esempio), ci sono rapporti che scriverò brevemente: questa è una mietitrice universale che può fare quasi tutto. Il prezzo da pagare è che configurare e mantenere un cluster su Kubernetes non è sempre facile.
Nomade
da HashiCorp, società nota per il console e il caveau sopra menzionati.
Abbiamo riscontrato che Nomad è molto più semplice da installare e configurare rispetto a Kubernetes. Un file binario funziona sia in modalità server che client. Allo stesso tempo, Nomad copre l'intero elenco di attività che vogliamo che risolva: gestione dei cluster, pianificazione veloce, supporto multidatacenter. Inoltre, quando utilizziamo console e vault, otteniamo un'integrazione più stretta per orchestrare i nostri servizi.
Cosa c'è attualmente in corso:
- server preparati per l'implementazione del Console,
- la configurazione del cluster nomad verrà inserita in Consul, con l'aiuto del quale nomad dovrebbe essere distribuito automaticamente,
- Parallelamente, installeremo il vault per archiviare i segreti.
Domanda per il pubblico: vale la pena assumere un direttore per tali compiti o l'orchestra sta andando bene senza di lui? Raccontaci nei commenti cosa ne pensi di questo.
Iscriviti al nostro blog e rimani in contatto: presto ti racconteremo cosa è successo alla fine e se abbiamo configurato il cluster nomade come lo volevamo.
Vieni nel nostro accogliente , dove puoi sempre chiedere consigli, aiutare i colleghi e semplicemente parlare di ricerche sulla produttività e altro ancora.
Fonte: habr.com
