Het zou ongepast zijn om te zeggen dat de besten onder ons
vreugde vinden door lijden.
Ludwig van Beethoven
Ik ben Sergei, ik werk bij Yandex.Money in het team voor prestatieonderzoek. Ik wil jullie het begin van ons verhaal vertellen over onze weg naar het gebruik van orchestration – hoe we de tools hebben gekozen en wat we daarbij in overweging hebben genomen. Alle gebeurtenissen in het artikel vinden in real-time plaats, dus jullie, beste lezers, volgen de ontwikkelingen bijna live.
Waarom hebben we een dirigent in het team?
Wie is een dirigent? Afgeleid van het Franse woord diriger – beheren, leiden, aansteken – in de wereld van de muziek is dit de persoon die de repetitie en uitvoering van ensemble muziek leidt. In ons geval nemen orkestratiesystemen en automatisering deze rol op zich.
Hun rol verschilt niet van die van de dirigent in de muziek – ze zijn nodig om het team te helpen, te leiden en hun spel te organiseren.
Gewoonlijk heeft een team een bepaalde set capaciteiten – laten we ze servers noemen, waarop ze hun projecten uitvoeren.
De benadering voor het verkrijgen en gebruiken van deze servers is divers. Enkele voorbeelden:
- Het team doet een aanvraag, bijvoorbeeld aan de exploitatiegroep, om hen middelen met specifieke parameters te leveren.
- De exploitatiegroep biedt hen het benodigde aantal – cloud of bare metal ("stoere hardware") – en verplicht zich om ze in goede staat te houden volgens de SLA. De configuratie wordt ook door de exploitatiegroep uitgevoerd.
- Het team ontvangt alleen cloud of bare metal middelen van de exploitatiegroep, de configuratie wordt door hen zelf gedaan.
- Het team "koopt" zelf middelen en onderhoudt/configureert deze volledig zelfstandig.
In ons team gebruiken we servers die moeten worden onderhouden – besturingssystemen bijwerken, nieuwe pakketten installeren, enzovoort.
We hebben ze ingedeeld in twee hoofdtypes:
- tankgroep,
- servicegroep.
De tankgroep bestaat uit hosts met Yandex.Tank.
De servicegroep omvat alles wat met dienstverlening te maken heeft – het zijn verschillende services voor het ondersteunen van de releasecyclus, het genereren van automatische rapporten, enzovoort.
Op een gegeven moment werd het moeilijk om dit alles handmatig te beheren, en we dachten na over het automatiseren van het hele proces, van het 'vullen' van servers tot de ontwikkeling, uitrol en lancering van onze interne service.
Waarom is een dirigent nodig, ook al kan het orkest zelf spelen?
In eerste instantie hebben we Ansible onder de knie gekregen en zijn we begonnen met het 'vullen' van onze bare metal servers, zodat we minder afhankelijk zijn van systeembeheerders — hierdoor winnen we allemaal, we verwerven nieuwe vaardigheden en ontlasten de beheerders van een deel van het werk dat zij al zonder ons altijd genoeg hebben. We streven naar ontwikkeling buiten onze specialisatie en teamautonomie, voor zover mogelijk.
Bij het bedrijf is het werken met Ansible al geruime tijd opgezet en gereguleerd, dus we hebben onze oplossing gemakkelijk in dit proces geïntegreerd.
Momenteel bestaat de hosting uit drie Ansible-rollen:
- de eerste rol installeert het besturingssysteem,
- de tweede past basisinstellingen toe voor de host, zoals LDAP-authenticatie,
- en de derde installeert Yandex.Tank in een docker-container, samen met de benodigde afhankelijkheden.
Laten we overgaan naar de services die we binnen het team gebruiken.
Voor onze taken gebruiken we in gelijke mate Kotlin en Python, en ook een beetje Golang. Om de ontwikkeling en implementatie van onze services te uniformeren, hebben we besloten ze in docker-containers te verpakken. Dit biedt de vrijheid in programmeertaalkeuze en reguleert tegelijkertijd een uniforme levering van onze applicaties.
Een kleine opmerking over ipv6 in Docker
Een deel van de services waarmee we interageren, is alleen via ipv6 toegankelijk, dus moesten we uitzoeken hoe we ipv6 voor de containers kunnen inschakelen.
Volgens de documentatie over ipv6 op de officiële Docker-website, wordt ipv6 ingeschakeld door parameters toe te voegen aan daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}De provider moet echter een ipv6-subnet toewijzen, dat u moet invullen in fixed-cidr-v6.
Wij hebben echter voor een andere optie gekozen — ipv6 NAT, en hier is waarom:
- Momenteel kan je docker alleen met ipv6.
- Het hebben van een globaal routbare adres in elke container betekent dat alle poorten (zelfs niet-gepubliceerde) voor iedereen toegankelijk zijn, tenzij er extra filtering plaatsvindt.
- userland proxy voor het publiceren van poorten, .
ipv6 NAT is , dat zelf de regels in ip6tables beheert en deze bewerkt bij het toevoegen van een nieuwe container.
Om deze oplossing correct te laten functioneren, moesten er nog een aantal handelingen worden verricht. Het is essentieel om ip6table_nat in het systeem te initialiseren. De aanwezigheid van de module in het systeem garandeert niet dat de module bij het opstarten in de kernel wordt geladen. We kwamen dit tegen toen we de volgende fout kregen bij het opstarten van een container met NAT op een nieuw systeem:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: kan map 'lib/modules' niet wijzigen: Bestemming niet gevonden
ip6tables v1.6.2: kan ip6tables tabel `filter` niet initialiseren: Tabel bestaat niet (moet u insmod uitvoeren?)Het probleem was opgelost na het toevoegen van de initiatie in de Ansible-rol met behulp van de modprobe-module en het laden bij het opstarten van het besturingssysteem met behulp van lineinfile:
- name: Voeg ip6table_nat-module toe
modprobe:
name: ip6table_nat
state: present
- name: Voeg ip6table_nat toe aan boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Overigens is er een goed artikel op Habr , dat kort en duidelijk de voor- en nadelen van verschillende methoden voor ipv6-werking in Docker beschrijft.
Maar laten we teruggaan naar onze vraag, die aan het begin werd gesteld:
Waarom is een dirigent nodig, ook al kan het orkest zelf spelen?
Nu weten ze allemaal hoe ze in ons team moeten spelen:
- het proces van het ‘bijvullen’ van servers is opgezet,
- de ontwikkeling en uitrol van diensten zijn verenigd.
Er rijst een legitieme vraag — hoe kunnen we onze diensten in Docker-containers effectief en zo geautomatiseerd mogelijk uitrollen, bijwerken en beheren?
Ondanks het feit dat elke deelnemer van het orkest zijn partij kent, kan hij afdwalen, zich van het oorspronkelijke idee verwijderen. Hier komen we tot de conclusie dat zonder een dirigent ons orkest niet effectief kan repeteren en harmonieus kan spelen. De dirigent is verantwoordelijk voor alle uitvoeringsparameters, ervoor zorgend dat alles samenkomt in een uniform tempo en stemming.
Hoe krijg je met minimale kosten een goede dirigent?
Het onderwerp orkestratie is behoorlijk goed ontwikkeld op de markt. Maar laten we eerst spreken over de ondersteunende tools die de dirigent kunnen helpen.
— een systeem dat twee hoofdfuncties biedt:
- serviceontdekking (service discovery),
- verspreide sleutel-waarde opslag.
In ons orkest zal Consul verantwoordelijk zijn voor het registreren van diensten en het opslaan van hun configuraties. Er zijn twee registratie-opties:
- Actief — dit is wanneer de dienst zichzelf registreert met behulp van de HTTP API;
- Passief — de dienst moet handmatig worden geregistreerd.
Vault is a storage solution that standardizes and unifies the secure storage and management of secrets — passwords, certificates.
Here are the advantages we will gain by using this tool:
- A single center for creating and storing secrets, managing their lifecycle via HTTP API.
- Transit Secrets Engine — encrypting-decrypting data without storing it. The ability to transmit data encrypted over unsecured communication channels.
- Access policies that can be easily configured.
- Audit access to secrets.
- The ability to create your own CA (Certificate Authority) to manage self-signed certificates within your infrastructure.
Considering all our requirements, two options were suitable for the role of the orchestrator — Kubernetes and Nomad.
Kubernetes
So many articles and books have already been written about it (here's , for example), and there have been presentations, so I will keep it brief — it is a universal tool that can do almost everything. The cost of this is not always an easy setup and cluster maintenance on Kubernetes.
Nomad
from HashiCorp, a company known for the aforementioned consul and vault.
Nomad seemed to us to be simpler to install and configure than Kubernetes. One binary file works both in server and client mode. At the same time, Nomad covers the entire list of tasks we want it to solve: cluster management, fast scheduler, support for multi-datacenter. Plus, with the use of consul and vault, we get closer integration for orchestrating our services.
What is currently in progress:
- servers prepared for deploying Consul,
- the Consul will include the configuration of the nomad cluster, with which nomad should be deployed automatically,
- at the same time we will install vault for storing secrets.
Question to the audience — should we establish an orchestrator for such tasks, or is orchestrating well without it? Share your thoughts in the comments.
Subscribe to our blog and stay tuned — soon we will tell you what the results were and whether we configured the nomad cluster as we wanted.
Join our cozy , where you can always ask for advice, help colleagues, and just chat about performance research and more.
Bron: habr.com
