Hur Dark implementerar kod på 50 ms

Ju snabbare utvecklingsprocessen är, desto snabbare utvecklas teknologi företaget.

Tyvärr arbetar moderna applikationer emot oss - våra system måste uppdateras i realtid utan att störa eller orsaka driftstopp. Utplacering i sådana system blir en komplex uppgift och kräver avancerade kontinuerliga leveranspipeline även i små team.

Dessa pipeline har vanligtvis ett smalt användningsområde, arbetar långsamt och är inte pålitliga. Utvecklare måste först skapa dem manuellt och sedan hantera dem, och företag anställer ofta hela DevOps-team för detta.

Hastigheten på dessa pipeline avgör hastigheten på utvecklingen. För de bästa teamen tar utplacering 5–10 minuter, men i allmänhet tar allt mycket längre tid och en enda utplacering kan ta flera timmar.

I Dark tar det 50 ms. Femtio. Millisekunder.. Dark - är en omfattande lösning med ett programmeringsspråk, en redigerare och infrastruktur, skapad specifikt för kontinuerlig leverans, och alla aspekter av Dark, inklusive språket, är utformade för säker och omedelbar utplacering.

Varför är kontinuerliga leveranspipeline så långsamma?

Anta att vi har en Python-webbapplikation och vi redan har skapat en fantastisk och modern kontinuerlig leveranspipeline. För en utvecklare som arbetar med detta projekt dagligen kommer utplaceringen av en liten förändring att se ut ungefär så här:

Gör ändringar

• Skapa en ny gren i git
• Gör ändringar bakom funktionsväxlaren
• Modultestning för att kontrollera ändringarna med och utan funktionsväxlaren

Pull-begäran

• Gör commit av ändringarna
• Skicka ändringarna till det externa arkivet på github
• Pull-begäran
• CI-byggning körs automatiskt i bakgrunden
• Kodgranskning
• Ytterligare några granskningar om det behövs
• Sammanfoga ändringarna med master-grenen i git.

CI körs på master.

• Installera frontend-beroenden via npm
• Bygga och optimera HTML+CSS+JS-resurser
• Köra modulära och funktionella tester i frontend
• Installera Python-beroenden från PyPI
• Köra modulära och funktionella tester i backend
• Integreringstestning i båda ändar
• Skicka frontend-resurser till CDN
• Bygga containern för Python-programmet
• Skicka containern till registret
• Uppdatera Kubernetes-manifestet

Ersätt gammal kod med ny

• Kubernetes startar flera instanser av den nya containern
• Kubernetes väntar på att instanserna ska bli aktiva
• Kubernetes lägger till instanserna i HTTP-lastbalanseraren
• Kubernetes väntar på att de gamla instanserna ska sluta användas
• Kubernetes stoppar de gamla instanserna
• Kubernetes upprepar dessa operationer tills de nya instanserna har ersatt alla gamla

Aktivera den nya funktionens växel

• Den nya koden aktiveras endast för sig själv för att säkerställa att allt fungerar
• Den nya koden aktiveras för 10% av användarna, operativa och affärsmått övervakas
• Den nya koden aktiveras för 50% av användarna, operativa och affärsmått övervakas
• Den nya koden aktiveras för 100% av användarna, operativa och affärsmått övervakas
• Slutligen upprepar du hela proceduren för att ta bort den gamla koden och växeln

Processen beror på verktygen, språket och användningen av tjänstearkitekturer, men i stora drag ser den ut så här. Jag har inte nämnt utplaceringar med databasmigrationer eftersom det kräver noggrant planerande, men nedan förklarar jag hur Dark hanterar detta.

Det finns många komponenter här, och många av dem kan enkelt försena, krascha, orsaka temporär konkurrens eller kollapsa det fungerande systemet.

Och eftersom dessa pipeliner nästan alltid är skapade för ett specifikt fall är de svåra att lita på. Många har dagar när koden är omöjlig att distribuera, eftersom det finns problem i Dockerfile, ett av dussintals tjänster har kraschat eller den nödvändiga experten är på semester.

Värre än så är att många av dessa steg i själva verket inte gör något användbart. De var nödvändiga tidigare när vi distribuerade koden direkt till användarna, men nu har vi omkopplare för den nya koden, vilket har separerat dessa processer. Resultatet är att steget där koden distribueras (den gamla ersätts av den nya) nu har blivit en onödig risk.

Självklart är detta en mycket genomtänkt pipeline. Teamet som skapade den har inte snålat med tid och pengar för snabb distribution. Vanligtvis är distributionspipelines mycket långsammare och mindre pålitliga.

Implementering av kontinuerlig leverans i Dark

Den kontinuerliga leveransen är så viktig för Dark att vi från början satte ett mål på mindre än en sekund. Vi gick igenom alla steg i pipelinen för att ta bort överflödiga moment, och finslipade det övriga. Så här tog vi bort steg.

Jessie Frazelle (Jessie Frazelle) myntade det nya ordet deployless (utplacering utan behov av deployment) på konferensen Future of Software Development i Reykjavik.

Vi bestämde oss genast för att Dark skulle baseras på konceptet «deployless» (tack till Jessie Frazelle för neologismen). Deployless innebär att all kod omedelbart deployeras och är redo för produktion. Självklart hoppar vi inte över defekt eller ofullständig kod (säkerhetsprinciper kommer jag att beskriva nedan).

Vid presentationen av Dark blev vi ofta frågade hur vi lyckats snabba upp deployment. En märklig fråga. Folk kanske tror att vi har kommit på någon superteknologi som jämför kod, kompilerar den, paketerar i en container, startar en virtuell maskin, lanserar containern kall och allt sånt där på 50 ms. Det är osannolikt. Men vi har skapat en speciell deployment-motor som inte behöver allt det där.

Dark startar tolkar i molnet. Anta att du skriver kod i en funktion eller en HTTP- eller händelsehanterare. Vi skickar diffen till det abstrakta syntaxträdet (implementeringen av koden som vår editor och servrar internt använder) till våra servrar och kör sedan den koden när förfrågningar kommer in. Så deployment ser ut som en enkel post i databasen — ögonblicklig och elementär. Deployment sker så snabbt eftersom det inkluderar det mest grundläggande.

I framtiden planerar vi att göra Dark till en infrastruktur kompilator som kommer att skapa och köra den perfekta infrastrukturen för hög prestation och tillförlitlighet av applikationer. Omiddelbar deployment kommer självklart att vara kvar.

Säker deployment

Strukturerad editor

Koden i Dark skrivs i Dark-editorn. Den strukturerade editorn tillåter inte syntaktiska fel. I praktiken har Dark inte ens en parser. Medan du skriver text arbetar vi direkt med det abstrakta syntaxträdet (AST), precis som Paredit, Sketch-n-Sketch, Tofu, Prune och MPS.

All kod som är ofullständig i Dark har en giltig körsemantik, ungefär som typed holes i Hazel. Till exempel, om du ändrar funktionsanropet, sparar vi den gamla funktionen tills den nya är användbar.

Varje program i Dark har sin egen mening, så ofullständig kod stör inte att färdig kod fungerar.

Redigeringslägen

Du skriver kod i Dark i två situationer. Första: du skriver ny kod och är den enda användaren. Till exempel, den är i REPL, och andra användare får aldrig tillgång till den, eller det är en ny HTTP-rutt som du inte refererar till någonstans. Här kan du arbeta utan några försiktighetsåtgärder, och för tillfället fungerar du ungefär så i utvecklingsmiljön.

Den andra situationen: koden används redan. Om trafik passerar genom koden (funktioner, händelsehanterare, databaser, etc.) måste du vara försiktig. För detta låser vi all använd kod och kräver att mer strukturerade verktyg används för att redigera den. Jag kommer att berätta om strukturella verktyg nedan: funktionsswitchar för HTTP- och händelsehanterare, en kraftfull migrationsplattform för databaser och en ny metod för versionshantering för funktioner och typer.

Funktionsswitchar

Ett sätt att ta bort onödig komplexitet i Dark är att lösa flera problem med en lösning. Funktionsswitchar utför många olika uppgifter: ersättning av lokal utvecklingsmiljö, git-grenar, koddistribution och naturligtvis den traditionella långsamma och kontrollerade lanseringen av ny kod.

Skapandet och distributionen av en funktionsswitch sker i vår editor i en operation. Den skapar ett tomt utrymme för ny kod och tillhandahåller kontroller för åtkomst till både gammal och ny kod, samt knappar och kommandon för gradvis övergång till ny kod eller dess uteslutning.

Funktionsswitchar är inbyggda i Dark-språket, och även ofullständiga switchar gör sitt jobb — om villkoret i switchen inte uppfylls kommer den gamla blockerade koden att köras.

Utvecklingsmiljö

Funktionerna för switchar ersätter den lokala utvecklingsmiljön. Idag har team svårt att se till att alla använder samma versioner av verktyg och bibliotek (kodformatterare, linters, paketförvaltare, kompilatorer, preprocessorer, testverktyg, osv.). Med Dark behöver man inte installera beroenden lokalt, hantera en lokal Docker-installation eller vidta andra åtgärder för att säkerställa ensartighet mellan utvecklingsmiljön och produktionen. Med tanke på att sådan enhetlighet ändå är omöjlig, kommer vi inte ens att låtsas att vi strävar efter den.

Istället för att skapa en klonad lokal miljö skapar switcharna i Dark en ny sandlåda i produktionen som ersätter utvecklingsmiljön. I framtiden planerar vi också att skapa sandlådor för andra delar av applikationen (till exempel omedelbara kloner av databasen), även om det just nu inte verkar så viktigt.

Grenar och distributioner

Nu finns det flera sätt att införa ny kod i systemen: git-grenar, distributionssteg och funktionsswitchar. De löser ett problem i olika delar av arbetsflödet: git – i stegen före distribution, distribution – när man går från gammal kod till ny, och funktionsswitchar – för kontrollerad utrullning av ny kod.

Det mest effektiva sättet är funktionsswitchar (som dessutom är det enklaste att förstå och använda). Med dem kan man helt hoppa över de andra två metoderna. Särskilt användbart är att ta bort distribution – om vi ändå använder funktionsswitchar för att aktivera kod, så skapar steget att flytta servrar till ny kod bara onödiga risker.

Git är svårt att använda, särskilt för nybörjare, vilket begränsar det mycket, men å andra sidan har det bekväma grenar. Vi har slätat ut många av git:s nackdelar. Dark redigeras i realtid och erbjuder samarbetsmöjligheter i stil med Google Docs, så att man inte behöver skicka kod och kan göra ombasering och sammanslagningar mindre ofta.

Funktionsomkopplare ligger till grund för säker distribution. Tillsammans med omedelbara distributioner möjliggör de snabb testning av koncept i små bitar med låg risk istället för att göra en stor ändring som kan krascha systemet.

Versionshantering

För att ändra funktioner och typer använder vi versionering. Om du vill ändra en funktion skapar Dark en ny version av den. Sedan kan du anropa denna version med hjälp av en omkopplare i HTTP- eller händelsehanteraren. (Om det är en funktion djupt inne i anropsgrafen, skapas en ny version av varje funktion på vägen. Det kan verka överdrivet, men funktioner störs inte om du inte använder dem, så du märker det knappt.)

Av samma skäl versionerar vi typer. Vi har pratat om vårt typ-system i detalj. i det föregående inlägget.

Tack vare versioneringen av funktioner och typer kan du göra förändringar i applikationen stegvis. Du kan kontrollera att varje enskild hanterare fungerar med den nya versionen, du behöver inte göra alla ändringar i applikationerna på en gång (men vi har verktyg för att snabbt göra det om du vill).

Detta är mycket säkrare än att distribuera allt på en gång, vilket är vad som händer nu.

Nya versioner av paket och standardbiblioteket

När du uppdaterar ett paket i Dark, ersätter vi inte omedelbart användningen av varje funktion eller typ i hela kodbasen. Det är osäkert. Koden fortsätter att använda den version den har använt, och du uppdaterar användningen av funktionerna och typerna till den nya versionen för varje enskilt fall med hjälp av omkopplare.

Skärmdump av en del av den automatiska processen i Dark, som visar två versioner av funktionen Dict::get. Dict::get_v0 returnerade typen Any (som vi överger), medan Dict::get_v1 returnerar typen Option.

Vi tillhandahåller ofta en ny funktion i standardbiblioteket och utesluter gamla versioner. Användare med gamla versioner i koden får fortfarande tillgång till dem, men nya användare kommer inte att kunna få dem. Vi planerar att tillhandahålla verktyg för att enkelt föra användare från gamla versioner till nya med ett steg, återigen med hjälp av funktionsomkopplare.

Dark erbjuder också en unik möjlighet: eftersom vi kör din arbetskod kan vi själva testa nya versioner, jämföra utdata för nya och gamla begärningar och informera dig om förändringar. Resultatet är att uppdateringar av paket, som ofta görs i blindo (eller kräver noggranna tester för säkerhet), innebär mycket mindre risk och kan ske automatiskt.

Nya versioner av Dark

Övergången från Python 2 till Python 3 sträckte sig över ett decennium och är fortfarande en utmaning. Eftersom vi bygger Dark för kontinuerlig leverans måste vi ta hänsyn till dessa språkliga förändringar.

När vi gör små ändringar i språket skapar vi en ny version av Dark. Den gamla koden förblir i den tidigare versionen av Dark, medan den nya koden används i den nya versionen. För att växla till den nya versionen av Dark kan man använda switchar eller funktionsversioner.

Detta är särskilt användbart med tanke på att Dark har kommit nyligen. Många förändringar i språket eller biblioteket kan visa sig vara misslyckade. Gradvis versionering av språket gör att vi kan göra små uppdateringar, vilket innebär att vi kan ta vår tid och skjuta upp många beslut om språket tills vi har fler användare, vilket också ger oss mer information.

Databasmigrationer

För säker databasmigration finns det en standardformel:

• Omarbeta koden för att stödja nya och gamla format
• Omvandla alla data till det nya formatet
• Ta bort gammal åtkomst till data

Som ett resultat fördröjs databasmigrationen och kräver mycket resurser. Gamla scheman samlas på hög, eftersom även enkla uppgifter som att ändra namnet på en tabell eller kolumn inte är värda den insats som krävs.

Dark har en effektiv plattform för databasmigration, som (vi hoppas) kommer att förenkla processen så mycket att du slutar att vara rädd för den. Alla datalager i Dark (lagringssätt för nyckel-värde-par eller permanenta hash-tabeller) har en typ. För att flytta ett datalager tilldelar du helt enkelt en ny typ och en rollback- och redo- funktion för att omvandla värden mellan de två typerna.

Åtkomst till datalager i Dark sker via versionshanterade variabelnamn. Till exempel kommer datalager Users ursprungligen att kallas Users-v0. När en ny version med en annan typ skapas, ändras namnet till Users-v1. Om data sparas via Users-v0 och du får åtkomst till dem via Users-v1, tillämpas funktionerna för återställning. Om data sparas via Users-v1 och du får åtkomst till dem via Users-v0, tillämpas funktionen för bakåtkompatibilitet.

Skärmen för databas-migrering med namnen på fälten från den gamla databasen, uttrycken för återställning och bakåtkompatibilitet samt instruktioner för att aktivera migreringen.

Använd funktionsväxlar för att dirigera anrop till Users-v0 i version Users-v1. Detta kan göras en HTTP-hanterare i taget för att minska riskerna, och växlarna fungerar för enskilda användare så att du kan kontrollera att allt fungerar som förväntat. När det inte finns några användare kvar i Users-v0 kommer Dark att konvertera alla återstående data i bakgrunden från det gamla formatet till det nya. Du kommer knappt att märka det.

Testning

Dark är en funktionell programmeringsspråk med statisk typning och oföränderliga värden, vilket gör testytan betydligt mindre jämfört med objektorienterade språk med dynamisk typning. Men tester måste fortfarande genomföras.
I Dark kör redigeraren automatiskt enhetstester i bakgrunden för redigerad kod och kör dessa tester som standard för alla funktionsväxlar. I framtiden vill vi använda statiska typer för att automatiskt utföra fuzzing av koden för att hitta buggar.

Dessutom kör Dark din infrastruktur i produktion, vilket öppnar upp för nya möjligheter. Vi sparar automatiskt HTTP-anrop i Dark-infrastrukturen (för närvarande sparar vi alla anrop, men vi planerar att gå över till sampling). Vi testar ny kod med dem och kör enhetstester, och om du vill kan du enkelt konvertera intressanta anrop till enhetstester.

Vad vi har tagit bort

Eftersom vi inte har någon distribution, men har funktionsväxlar, blir cirka 60% av distributionspipeline överflödig. Vi behöver ingen git-grenar eller pull-förfrågningar, bygga backend-resurser och containrar, skicka resurser och containrar till register eller distribuera steg i Kubernetes.

Jämförelse mellan en standard pipelinemodell för kontinuerlig leverans (vänster) och Dark leverans (höger). I Dark leverans består av 6 steg och en cykel, medan den traditionella versionen omfattar 35 steg och 3 cykler.

I Dark består distributionen av endast 6 steg och 1 cykel (stegen som upprepas flera gånger), medan den moderna pipelinemodellen för kontinuerlig leverans består av 35 steg och 3 cykler. I Dark körs tester automatiskt, och det ser du inte ens; beroenden installeras automatiskt; allt som rör git eller Github behövs inte längre; bygga, testa och skicka Docker-containrar behövs inte; distribution till Kubernetes behövs inte längre.

Till och med de återstående stegen i Dark har blivit enklare. Eftersom funktionerna kan hanteras med ett enda kommando behöver man inte gå igenom hela distributionspipeline igen för att ta bort gammal kod.

Vi har förenklat kodleveransen så mycket som möjligt, minskat tid och risker i den kontinuerliga leveransen. Dessutom har vi betydligt förenklat uppdatering av paket, databas-migreringar, testning, versionhantering, installation av beroenden, lika villkor mellan utvecklings- och produktionsmiljöer samt snabba och säkra uppgraderingar av språkversioner.

Jag svarar på frågor om detta på HackerNews.

För att få veta mer om Dark-enheten, läs artikeln om Dark, följ oss på Twitter (eller på mig) eller anmäla dig till beta-versionen och få meddelanden om kommande inlägg. Om du åker till StrangeLoop i september, kom till vår lansering.

Källa: habr.com