Difficilmente si può dire che le migliori persone
trovano gioia attraverso la sofferenza.
Ludwig van Beethoven
Sono Sergey, lavoro in 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 considerato. Tutti gli eventi dell'articolo si svolgono in tempo reale, quindi voi, cari lettori, seguite lo sviluppo della situazione praticamente in diretta.
Perché abbiamo bisogno di un direttore d'orchestra nel team?
Chi è il direttore d'orchestra? Dal francese diriger — gestire, dirigere — nel mondo della musica è la persona che guida l'apprendimento e l'esecuzione della musica d'insieme. Nel nostro caso, questo ruolo è ricoperto dai sistemi di orchestrazione e automazione.
Il loro ruolo non è diverso da quello del direttore d'orchestra nella musica: servono per aiutare il team, guidare e organizzare il loro gioco.
In genere, il team ha un certo insieme di capacità: chiamiamoli server, su cui realizzano i loro progetti.
L'approccio all'ottenimento e all'utilizzo di questi server è vario. Ecco alcuni esempi:
- Il team fa una richiesta, ad esempio al gruppo di gestione, per ottenere risorse con specifiche caratteristiche.
- Il gruppo di gestione fornisce loro il numero necessario di risorse — cloud o bare metal (“hardware nudo”) — e si impegna a mantenerle in buone condizioni secondo SLA. Anche la configurazione è effettuata dal gruppo di gestione.
- Il team riceve solo risorse cloud o bare metal dal gruppo di gestione, la configurazione è effettuata da loro stessi.
- Il team "acquista" autonomamente risorse e le mantiene/configura completamente da solo.
Nel nostro team utilizziamo server che devono essere mantenuti: aggiornare il sistema operativo, installare nuovi pacchetti, ecc.
Per noi, abbiamo identificato due tipi principali:
- gruppo di tank,
- gruppo di servizi.
Il gruppo di tank è composto da host con Yandex.Tank.
Il gruppo di servizi comprende tutto ciò che riguarda il supporto, inclusi vari servizi per garantire il supporto del ciclo di rilascio, generazione di report automatici, ecc.
Ad un certo punto, è diventato scomodo gestire tutto manualmente, e abbiamo iniziato a riflettere sull'automazione dell'intero processo, partendo dal "caricamento" dei server fino allo sviluppo, al deployment e all'avvio del nostro servizio interno.
Perché è necessario un direttore d'orchestra, anche se l'orchestra sa suonare da sola?
Per cominciare, abbiamo acquisito familiarità con Ansible e abbiamo iniziato a "caricare" i nostri server bare metal, per essere meno dipendenti dagli amministratori di sistema: qui ci guadagnano tutti, noi acquisendo nuove competenze e liberando gli amministratori da parte del lavoro che già hanno senza di noi. Puntiamo allo sviluppo al di fuori della nostra specializzazione e all'autonomia del team, per quanto possibile.
Nell'azienda, il lavoro con Ansible è stato già da tempo impostato e regolamentato, quindi abbiamo facilmente integrato la nostra soluzione in questo processo.
Attualmente, il caricamento degli host consiste in tre ruoli di Ansible:
- il primo ruolo installa il sistema operativo,
- il secondo applica impostazioni di base per l'host, come l'autenticazione LDAP, per esempio,
- e il terzo installa nel container Docker Yandex.Tank e le relative dipendenze.
Passiamo ai servizi che utilizziamo all'interno del team.
Per le nostre esigenze, utilizziamo in egual misura Kotlin e Python, e un po' di Golang. Per uniformare lo sviluppo e il deployment dei nostri servizi, abbiamo deciso di impacchettarli in container Docker. Questo consente di scegliere liberamente il linguaggio di programmazione e al contempo regola un formato unico per la fornitura della propria applicazione.
Una piccola nota su ipv6 in Docker
Alcuni servizi con cui interagiamo sono disponibili solo tramite ipv6, quindi abbiamo dovuto capire come abilitare ipv6 per i container.
Secondo la documentazione su ipv6 presente sul sito 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 fornire un sottorete ipv6, che dovrete specificare in fixed-cidr-v6.
Tuttavia, abbiamo scelto un'altra opzione: ipv6 NAT, ecco perché:
- Attualmente, Docker solo con ipv6.
- La presenza di un indirizzo globalmente instradabile in ogni container significa che tutte le porte (anche quelle non pubblicate) diventano accessibili a tutti, a meno che non venga eseguita un'ulteriore filtrazione.
- userland proxy per la pubblicazione delle porte, .
ipv6 NAT è , che gestisce autonomamente le regole in ip6tables e le modifica quando viene aggiunto un nuovo contenitore.
Affinché questa soluzione funzioni correttamente, era necessario effettuare ulteriori operazioni. È fondamentale inizializzare ip6table_nat nel sistema. La presenza del modulo installato nel sistema non garantisce che venga caricato nel kernel all'avvio. Ci siamo imbattuti in questo problema quando abbiamo ricevuto il seguente errore durante l'avvio di un contenitore con NAT su un host recente:
2019/01/22 14:59:54 in esecuzione [/sbin/ip6tables -t filter -N DOCKER --wait]: stato di uscita 3: modprobe: impossibile cambiare directory in '/lib/modules': Nessun file o directory
ip6tables v1.6.2: impossibile inizializzare la tabella ip6tables `filter': La tabella non esiste (hai bisogno di insmod?)Il problema si è risolto dopo aver aggiunto nella rol di Ansible l'inizializzazione tramite il modulo modprobe e il caricamento all'avvio del sistema operativo tramite lineinfile:
- nome: Aggiungi il modulo ip6table_nat
modprobe:
name: ip6table_nat
state: present
- nome: Aggiungi ip6table_nat all'avvio
lineinfile:
path: /etc/modules
line: 'ip6table_nat'A proposito, su Habr c'è un buon articolo , che descrive brevemente e in modo chiaro i vantaggi e gli svantaggi dei vari metodi per lavorare con ipv6 in docker.
Ma torniamo alla nostra domanda posta all'inizio:
Perché è necessario un direttore d'orchestra, anche se l'orchestra sa suonare da sola?
Ora tutti sanno come giocare nella nostra squadra:
- il processo di ‘riempimento’ dei server è stato creato,
- lo sviluppo e il deployment dei servizi sono stati unificati.
Sorge una domanda ragionevole: come possiamo implementare, aggiornare e monitorare i nostri servizi in contenitori docker in modo efficace e il più automatizzato possibile?
Nonostante ogni membro dell'orchestra conosca la sua parte, potrebbe deviare dall'idea originale. Qui arriviamo al punto in cui senza un direttore d'orchestra la nostra orchestra non sarà in grado di provare in modo efficace e suonare in modo armonioso. Il direttore d'orchestra è responsabile di tutti i parametri di esecuzione, affinché tutto sia unito da un unico tempo e da un'unica atmosfera.
Come ottenere un buon direttore d'orchestra con investimenti minimi?
Il tema dell'orchestrazione è abbastanza sviluppato sul mercato. Ma prima parliamo degli strumenti ausiliari che possono aiutare il direttore.
— un sistema che fornisce due funzioni principali:
- scoperta dei servizi (service discovery),
- archivio distribuito chiave-valore.
Nella nostra orchestra, Consul si occuperà della registrazione dei servizi e della conservazione delle loro configurazioni. Ci sono due modi di registrazione:
- Attiva — quando il servizio si registra autonomamente utilizzando l'API HTTP;
- Passiva — il servizio deve essere registrato manualmente.
Vault è un archivio che standardizza e unifica la memorizzazione sicura e la gestione dei segreti: password, certificati.
Ecco i vantaggi che otterremo utilizzando questo strumento:
- Unico centro per la creazione e la memorizzazione dei segreti, gestendo il loro ciclo di vita tramite API HTTP.
- Transit Secrets Engine — crittografia e decrittografia dei dati senza conservarli. Possibilità di trasmettere dati in forma crittografata tramite canali non sicuri.
- Politiche di accesso facili da configurare.
- Audit dell'accesso ai segreti.
- Possibilità di creare un proprio CA (Certificate Authority) per gestire certificati autofirmati all'interno della propria infrastruttura.
Considerando tutti i nostri requisiti, due opzioni si sono dimostrate adatte per il ruolo di orchestratore: Kubernetes e Nomad.
Kubernetes
Quante articoli e libri sono già stati scritti su di esso (ecco ), sono state fatte così tante presentazioni che scriverò brevemente: è un combinatore universale che può praticamente fare tutto. Il rovescio della medaglia è che la configurazione e la gestione di un cluster su Kubernetes non sono sempre semplici.
Nomad
di HashiCorp, un'azienda nota per i già citati consul e vault.
Nomad ci è sembrato sufficientemente semplice da installare e configurare, rispetto a Kubernetes. Un singolo file binario funziona sia in modalità server che client. Inoltre, Nomad copre tutta la gamma di compiti che vogliamo che risolva: gestione del cluster, pianificazione rapida, supporto multidatacenter. Inoltre, utilizzando consul e vault otteniamo un'integrazione più stretta per orchestrare i nostri servizi.
Cosa è attualmente in lavorazione:
- abbiamo preparato i server per il deployment di Consul,
- la configurazione del cluster nomad sarà inserita in Consul, tramite la quale nomad dovrà essere automaticamente distribuito,
- contemporaneamente installeremo vault per la memorizzazione dei segreti.
Domanda al pubblico: vale la pena avere un orchestratore per tali compiti o è sufficiente anche senza? Raccontateci nei commenti cosa ne pensate.
Iscrivetevi al nostro blog e rimanete in contatto: presto vi racconteremo cosa è venuto fuori, e se siamo riusciti a configurare il cluster nomad come lo desideravamo.
Entrate nel nostro accogliente , dove potete sempre chiedere consigli, aiutare colleghi e semplicemente chiacchierare sull'argomento delle prestazioni e non solo.
Fonte: habr.com
