Hvordan vi skapte 96 valgte bekreftere

(Indika) (5. september, 2019)

Sist jeg publiserte en artikkel, var for fem år siden, og den hadde tittelen: Matlaging av en webserver med Chef . Fem år er lang tid å ikke skrive. Det er ikke det at jeg hadde mistet interessen for emnet; i stedet lærte jeg stille av det beste.

Diskusjonsemnet har imidlertid ikke endret seg, bortsett fra at det er en størrelsesorden større nå. Den gang lagde jeg en enkelt webserver, og nå gyter jeg 96 Valgte verifikatorer (EVs).

Hvorfor 96?

Ved Unification endrer vi den underliggende konsensusalgoritmen til Ethereum. Implementeringen av distribuert innsatsstyring involverer fire grupper på 24 elbiler, roterende inn og ut av blokkvalidering. Styringen av disse rotasjonene blir gjort lettere gjennom en prosess med stemmegivning og staking. Sluttresultatet er et mer distribuert konsortiumnettverk.

Teoretisering av dette emnet på whitepapers og i simuleringer kan bare ta oss så langt. Den beste måten å komme videre på er å produsere den, leke med den og oppleve mangler.

Kontinuerlig levering

Vi ønsker å være i posisjon til å evaluere våre ideer raskt . Testdrevet utvikling trenger ikke å være begrenset til å skrive enhetstester.

For en gitt Git SHA ønsker vi å spinne opp hvilken som helst versjon av Mainchain ved å utføre en enkelt kommando, evaluere tilstanden til den og deretter lage raffinement til DNA.

Vi vil fortsette å foredle denne prosessen, til vi tror vi har noe klart for produksjon. Prosessen med programvareutvikling er ikke noe mer enn denne enkle iterasjonen:

Jo mer komplekst et system blir, jo vanskeligere blir hver av disse delene. Instantiating 96 EVs er et ikke-trivielt problem, og er fokus for denne artikkelen.

Definisjon

Vi begynner med å definere hva vi vil distribuere. En instansert klynge består for det meste av elbiler, hvor noen få av dem har RPC aktivert og andre ikke. Klyngen kan også omfatte en UND-kran, en blokkutforsker og kanskje til og med en overvåkingsknute.

Disse klyngene er spesifisert av JSON-filer, og formålet med klargjøringsstakken kan gjøre dem slik.

Hver node i klyngen trenger et unikt håndtak, og følgende adresseringsskjema er valgt:

x = "{cluster\_name}-{configuration}-{instance\_type}-{index}"

For eksempel:

alpha-basic-ev-1

I over utsagnet, refererer ordet «basic» til en konfigurasjon der det er fire elbiler og en blokkutforsker. Ordet «alfa» er navnet på eksperimentet.

Stakken

Vi kunne ha gått med Kubernetes.

Vi ønsker imidlertid også å investere i lage verktøy som samfunnet vårt kan bruke til å lansere sine egne elbiler. Vi velger Ansible på grunn av sin enkelhet, og spillbøkene som er rettet mot CentOS vil fungere på hvilken som helst arkitektur, eller som lett kan tilpasses.

Selv om jeg tidligere har evaluert både Chef og Puppet, har jeg Jeg har kastet dem begge for enkelhet av Ansible. Chef og Puppet trenger programvarekomponenter på målmaskinen, men Ansible trenger bare en SSH-forbindelse.

Det er ingen kvantefysikk her med hensyn til stabelen; bare nødvendige skritt mot suksess. Stakken vår består av:

  • AWS-brukere og AWS API
  • AWS-lanseringsmal
  • AWS-koder
  • Minimalistisk bash-oppstart skript
  • Krøller et bash-skript fra Github
  • Konfigurer Ansible host vars fra tags
  • Sørg for verten ved hjelp av Ansible

AWS API og AWS brukere

AWS tilbyr ekstremt detaljert kontroll over sine tjenester via API og tillatte brukere. API-et kan nås ordentlig gjennom Python boto3-biblioteket. En forløper for bruk av API, er å lage den aktuelle brukeren gjennom IAM-grensesnittet. En bruker er typisk brukertilgangs-ID og hemmelig par.

En bruker kan knyttes til en av flere retningslinjer. En policy består av et sett med tillatte eller nektet handlinger på et sett med ressurser.

Vår spawn-bruker har en policy knyttet til minimalistiske handlinger for å opprette EC2-forekomst, og handlinger for å lese hele ressurssettet.

Start maler

En av nøkkelfunksjonene som AWS gir oss er Launch Templates.

Med en Launch Template kan man spesifisere en base AMI (identifikatoren for det virtuelle maskinbildet for å bygge en forekomst av) og forhåndskonfigurere innstillinger, inkludert to viktige komponenter: Tagger og et Run Script. I tillegg kan man spesifisere sikkerhetsgruppen maskinen skal tilhøre.

Startmaler kan versjoneres, og forekomster kan startes fra AWS-brukeren.

Merker

Hver EC2-forekomst er unik basert på kodene den er konfigurert med. Følgende informasjon sendes til noden:

  • Navn (unik identifikator for noden)
  • Klasse (type forekomst)
  • Indeks ( posisjonen til forekomsten)
  • Konfigurasjon (variasjonen av klyngen som blir instantiert)
  • SHA (en Git SHA)
  • RegistrationIP (IP-adressen til Registration Tower)

Hver av disse kodene er satt i Ansible hosts vars.

Bootstrapping with Bash

Bash bootstrap-skriptet forbereder verten for klargjøring. Noen av jobbene som utføres er å installere et grunnleggende Python-miljø, analysere AWS-koder, skrive disse til Ansible host-vars-filen og velge passende Ansible-spillbok for nodeslag.

Ansible

Til slutt forsynes noden med Ansible. Jeg vil ikke gå inn i Ansible ettersom det er nok andre ressurser på Internett. Det er ikke noe spesielt her, bortsett fra at man vanligvis konfigurerer en ekstern server med Ansible, men i vårt tilfelle konfigurerer vi den lokale serveren.

Registration Tower

Vi bruker et Registration Tower i stedet for en Bootnode for å starte nettverket. EVs registrerer sine IP-adresser ved instantiering med registreringsnoden, og en liste over statiske noder oppnås før aktivering av tjenesten.

Fordelen med å bruke et slikt tårn er at vi kan begynne å registrere vilkårlige data, som helsestatistikk, og bidra til å lukke evalueringssløyfen.

Når en EV blir instantiert, skriver den til Registration API, det er klyngenavn, IP-adresse, indeks og forekomsttype.

Evaluering

Hovedfokuset for evaluering er å bestemme hvordan vellykket eksperimentet var. Hva vilkårene for suksess er vil bli behandlet i en annen artikkel. Imidlertid er en umiddelbar beregning for å holde øye med kostnadene.

Prisen for en t2-mikro-forekomst er 0,012 / time. Kostnaden for å kjøre 96 av disse i en time bør bare være en dollar. Dette kan bekreftes i Cost Explorer.

Videre

Denne stabelen fungerer vakkert. En enkelt kommando bringer konsekvent og feilfritt opp en fullt tilkoblet og blokk-forplantende hovedkjede. Det jeg liker best med denne stabelen er at den er ild og glemmer; Jeg kan starte klyngen, koble fra internett og gå på sjonglering. Det vil være en Mainchain klar for meg når jeg kommer tilbake.

Dette fungerer som et sterkt fundament for vårt neste trinn. Vi kan begynne å evaluere forskjellige konfigurasjoner av vårt konsensus-DNA. Vi vil modne vår nåværende enkle konsensusalgoritme og evaluere mot brutal virkelighet, i vår neste artikkel med tittelen «Distribuert innsatsstyring».

Kildekoden til EV Provisioning stack finner du her: https://github.com/unification-com/ev-provision

Bli med oss ​​på Unification Gitter: https://gitter.im/unification-com

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *