È difficile non dire che le migliori persone
trovano gioia attraverso la sofferenza.
Ludwig van Beethoven
Sono Sergey, lavoro in Yandex.Money nel team di ricerca delle prestazioni. Voglio raccontarvi l'inizio della nostra storia sull'uso dell'orchestrazione: come abbiamo scelto gli strumenti e cosa abbiamo considerato. Tutti gli eventi di questo articolo si svolgono in tempo reale, quindi, cari lettori, seguite lo sviluppo della situazione quasi in diretta.
Perché abbiamo bisogno di un direttore d'orchestra nel team?
Chi è in realtà il direttore d'orchestra? Da fr. diriger — gestire, dirigere — nel mondo della musica, è la persona che guida lo studio e l'esecuzione della musica d'insieme. Nel nostro caso, questo ruolo è ricoperto da sistemi di orchestrazione e automazione.
Il loro ruolo non è diverso da quello del direttore d'orchestra nella musica: sono necessari per aiutare il team, dirigere e organizzare il suo lavoro.
Di solito, il team ha a disposizione un certo insieme di capacità—chiamiamoli server—su cui realizzano i loro progetti.
L'approccio all'acquisizione e all'utilizzo di questi server è vario. Ecco alcuni esempi:
- Il team invia una richiesta, ad esempio al gruppo operativo, per la fornitura di risorse con parametri specifici.
- Il gruppo operativo fornisce il numero necessario di risorse — cloud o bare metal («hardware dedicato») — e si impegna a mantenerle in buone condizioni secondo SLA. Anche la configurazione viene effettuata dal gruppo operativo.
- Il team riceve solamente le risorse cloud o bare metal dal gruppo operativo, mentre la configurazione viene gestita autonomamente.
- Il team acquisisce autonomamente le risorse e si occupa completamente della loro manutenzione e configurazione.
Nel nostro team utilizziamo server che devono essere mantenuti — aggiornare il sistema operativo, installare nuovi pacchetti, ecc.
Per noi li abbiamo suddivisi in due tipologie principali:
- gruppo tank,
- gruppo di servizio.
Il gruppo tank è composto da host con Yandex.Tank.
Il gruppo di servizio comprende tutto ciò che riguarda il supporto — vari servizi per garantire il ciclo di rilascio, generazione di report automatici, ecc.
A un certo punto, è diventato scomodo gestire tutto questo manualmente, e abbiamo iniziato a pensare all'automazione dell'intero processo, dalla configurazione dei server fino allo sviluppo, al rilascio e al lancio del nostro servizio interno.
Perché è necessario un direttore d'orchestra, anche se l'orchestra sa già suonare?
Inizialmente abbiamo imparato Ansible e abbiamo iniziato a configurare i nostri server bare metal, per essere meno dipendenti dagli amministratori di sistema: qui tutti vincono, acquisendo nuove competenze e liberando gli amministratori da parte del lavoro che hanno sempre in abbondanza. Ci sforziamo di svilupparci oltre la nostra specialità e di ottenere l'autonomia del team, per quanto possibile.
In azienda, il lavoro con Ansible è ormai ben strutturato e regolamentato, quindi abbiamo facilmente integrato la nostra soluzione in questo processo.
Attualmente, la configurazione degli host consiste in tre ruoli di Ansible:
- il primo ruolo installa il sistema operativo,
- il secondo applica le impostazioni di base per l'host, come l'autenticazione LDAP, ad esempio,
- e il terzo installa Yandex.Tank in un contenitore Docker e le relative dipendenze.
Passiamo ai servizi che utilizziamo all'interno del team.
Per i nostri progetti, utilizziamo in ugual misura Kotlin e Python, e un po' di Golang. Per unificare lo sviluppo e il deployment dei nostri servizi, abbiamo deciso di imballarli in contenitori Docker. Questo ci offre la libertà di scelta del linguaggio di programmazione e simultaneamente regola un formato unico per la distribuzione della propria applicazione.
Una breve nota su ipv6 in Docker
Alcuni servizi con cui interagiamo sono disponibili solo su ipv6, quindi abbiamo dovuto capire come abilitare l'ipv6 per i contenitori.
Secondo la documentazione su ipv6 sul sito ufficiale di Docker, l'ipv6 viene abilitato aggiungendo parametri a daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}A tal proposito, il provider deve fornire una sottorete ipv6, che dovrete indicare 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 contenitore 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 container.
Per far funzionare correttamente questa soluzione, era necessario eseguire ulteriori operazioni. È fondamentale inizializzare ip6table_nat nel sistema. La presenza del modulo installato nel sistema non garantisce che il modulo venga caricato nel kernel al momento dell'avvio. Ci siamo imbattuti in questo problema quando abbiamo ricevuto il seguente errore all'avvio del container con NAT su un host fresco:
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 al ruolo Ansible l'inizializzazione tramite il modulo modprobe e il caricamento all'avvio del sistema operativo utilizzando lineinfile:
- name: Aggiungi il modulo ip6table_nat
modprobe:
name: ip6table_nat
state: present
- name: Aggiungi ip6table_nat all'avvio
lineinfile:
path: /etc/modules
line: 'ip6table_nat'A proposito, su Habr c'è un buon articolo , che descrive in modo chiaro e conciso i vantaggi e gli svantaggi di ciascun metodo di gestione di ipv6 in docker.
Ma torniamo alla nostra domanda iniziale:
Perché è necessario un direttore d'orchestra, anche se l'orchestra sa già suonare?
Ora tutti sanno come giocare nella nostra squadra:
- il processo di 'riempimento' dei server è stato creato,
- lo sviluppo e il deployment dei servizi sono unificati.
Sorge una domanda legittima: come possiamo deployare, aggiornare e controllare i nostri servizi nei contenitori Docker in modo efficace e massimamente automatizzato?
Anche se ogni membro dell'orchestra conosce la propria parte, può ancora deviare dall'intento originale. Qui scopriamo che senza un direttore d'orchestra, la nostra orchestra non potrà provare ed esibirsi in modo efficace e coordinato. Il direttore è responsabile di tutti i parametri dell'esecuzione, garantendo 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 è già ben sviluppato sul mercato. Ma prima parliamo degli strumenti ausiliari che possono aiutare il direttore.
— un sistema che offre due funzioni principali:
- scoperta dei servizi (service discovery),
- archivio distribuito chiave-valore.
Nel nostro orchestra, Consul si occuperà della registrazione dei servizi e della memorizzazione della loro configurazione. Ci sono due opzioni per la registrazione:
- Attiva — quando il servizio si registra autonomamente utilizzando l'API HTTP;
- Passivo — il servizio deve essere configurato manualmente.
Vault — è uno storage che standardizza e unifica la gestione sicura e l'archiviazione dei segreti: password, certificati.
Ecco i vantaggi che otterremo utilizzando questo strumento:
- Unico centro per la creazione e l'archiviazione dei segreti, gestione del loro ciclo di vita tramite HTTP API.
- Transit Secrets Engine — crittografia e decrittografia dei dati senza memorizzarli. Possibilità di trasmettere dati in forma crittografata su canali non sicuri.
- Politiche di accesso facilmente configurabili.
- Audit degli accessi ai segreti.
- Possibilità di creare una propria CA (Certificate Authority) per gestire certificati autofirmati all'interno della propria infrastruttura.
Considerando tutte le nostre esigenze, due opzioni si attestano per il ruolo di orchestratore: Kubernetes e Nomad.
Kubernetes
Quante articoli e libri sono già stati scritti su di esso (ecco , ad esempio), sono stati tenuti così tanti discorsi che ne scriverò brevemente — è un combine universale, che può praticamente fare tutto. Il prezzo da pagare è che la configurazione e il supporto del cluster su Kubernetes non sono sempre facili.
Nomad
di HashiCorp, azienda nota per consul e vault menzionati sopra.
Nomad ci è sembrato abbastanza semplice da installare e configurare, rispetto a Kubernetes. Un singolo file binario funziona sia in modalità server che client. Inoltre, Nomad copre tutta la lista di compiti che desideriamo che svolga: gestione del cluster, pianificazione veloce, supporto multidatacenter. In aggiunta, utilizzando Consul e Vault otteniamo un'integrazione più stretta per l'orchestrazione dei nostri servizi.
Cosa stiamo attualmente facendo:
- abbiamo preparato i server per il deployment di Consul,
- in Consul verrà inserita la configurazione del cluster Nomad, che permetterà a Nomad di essere distribuito automaticamente,
- contemporaneamente installeremo Vault per la memorizzazione dei segreti.
Domanda aperta: vale la pena di introdurre un orchestratore per tali compiti o l'orchestrazione è sufficientemente buona senza di esso? Fateci sapere nei commenti cosa ne pensate.
Iscrivetevi al nostro blog e rimanete in contatto — presto vi racconteremo cosa abbiamo ottenuto e se siamo riusciti a configurare il cluster Nomad come desideravamo.
Visitate il nostro accogliente , dove potete sempre chiedere consigli, aiutare i colleghi e semplicemente chiacchierare su temi di ricerca delle prestazioni e non solo.
Fonte: habr.com
