Skapa den första DevOps-kedjan i fem steg för nybörjare.
DevOps har blivit en universallösning för alltför långsamma, splittrade och andra problematiska utvecklingsprocesser. Men det krävs grundläggande kunskaper om DevOps. Här kommer begrepp som DevOps-kedja att diskuteras och hur man kan skapa den i fem steg. Detta är inte en fullständig guide, utan en "skiss" som kan utökas. Låt oss börja med historien.
Min bekantskap med DevOps
En gång jobbade jag med molntjänster på Citi Group och utvecklade en IaaS-webbapplikation för att hantera Citigroup's molninfrastruktur, men jag har alltid varit intresserad av hur man kan optimera utvecklingskedjan och förbättra kulturen bland utvecklarna. Greg Lavender, vår tekniska direktör för molnarkitektur och infrastruktur, rekommenderade mig boken . Den förklarar perfekt principerna för DevOps och läses som en roman.
I tabellen på baksidan visas hur ofta företag släpper nya versioner:
Hur lyckas Amazon, Google och Netflix att släppa så mycket? Det är enkelt: de har förstått hur man skapar en nästan perfekt DevOps-kedja.
Hos oss på Citi var allt helt annorlunda, innan vi gick över till DevOps. Då hade mitt team olika miljöer, men vi gjorde leveransen till utvecklingsservern manuellt. Alla utvecklare hade tillgång till endast en utvecklingsserver baserad på IBM WebSphere Application Server Community Edition. Vid samtidig leverans kraschade servern, och vi var tvungna att ”smärtsamt” förhandla med varandra varje gång. Dessutom hade vi otillräcklig testtäckning av koden, en arbetsintensiv manuell leveransprocess och ingen möjlighet att spåra kodleveransen kopplad till någon uppgift eller kundkrav.
Det var uppenbart att något snabbt behövde göras, och jag fann en kollega med samma inställning. Vi bestämde oss för att tillsammans skapa den första DevOps-kedjan — han satte upp en virtuell maskin och Tomcat-applikationsserver, medan jag arbetade med Jenkins, integration med Atlassian Jira och BitBucket, samt kodtäckningstester. Projektet var framgångsrikt: vi automatiserade helt utvecklingskedjan, uppnådde nästan 100 % driftsäkerhet på utvecklingsservern, kunde spåra och förbättra kodtäckningen med tester, och Git-grenen kunde kopplas till leveransen och Jira-uppgiften. Och nästan alla verktyg som vi använde för att bygga DevOps-kedjan var öppen källkod.
I praktiken var kedjan förenklad, eftersom vi inte ens använde avancerade konfigurationer med Jenkins eller Ansible. Men vi lyckades. Detta kan vara en följd av principen (det vill säga 80/20-regeln).
En kort beskrivning av DevOps och CI/CD-kedjan
DevOps har olika definitioner. Precis som Agile omfattar DevOps olika discipliner. Men de flesta skulle hålla med om följande definition: DevOps är en metod eller livscykel för programvaruutveckling vars huvudprincip är att skapa en kultur där utvecklare och andra anställda arbetar "på samma våglängd", manuellt arbete automatiseras, alla sysslar med det de är bäst på, leveransfrekvensen ökar, arbetsproduktiviteten höjs och flexibiliteten ökar.
Och även om verktyg ensam inte räcker för att skapa en DevOps-miljö, är de oumbärliga. Det viktigaste av dem är kontinuerlig integration och kontinuerlig leverans (CI/CD). I kedjan finns det olika steg för varje miljö (till exempel DEV (utveckling), INT (integration), TST (testning), QA (kvalitetskontroll), UAT (användartestning), STG (förberedelse), PROD (användning)), manuella uppgifter är automatiserade, utvecklare kan producera kvalitetskod, leverera den och enkelt anpassa sig.
Denna notis beskriver hur man på fem steg skapar en DevOps-kedja, som visas på bilden nedan, med hjälp av öppenkällkodsverktyg.
Låt oss gå till saken.
Steg 1: CI/CD-plattform
Först behöver du ett CI/CD-verktyg. Jenkins är ett öppet CI/CD-verktyg skrivet i Java med MIT-licens, som var starten för populäriseringen av DevOps-rörelsen och som de facto blivit standard för CI/CD.
Och vad är Jenkins? Tänk dig att du har en magisk kontrollpanel för olika tjänster och verktyg. Själva CI/CD-verktyget, som Jenkins, är värdelöst, men tillsammans med olika verktyg och tjänster blir det allsmäktigt.
Förutom Jenkins finns det många andra öppna verktyg, välj valfritt.
Så här ser DevOps-processen ut med CI/CD-verktyg
Du har ett CI/CD-verktyg på localhost, men det finns inte mycket att göra än så länge. Låt oss gå vidare till nästa steg.
Steg 2: versionshantering
Det bästa (och antagligen enklaste) sättet att verifiera magin i CI/CD-verktyget är att integrera det med ett versionhanteringsverktyg (source control management, SCM). Varför behövs versionhantering? Anta att du bygger en applikation. Du skriver den i Java, Python, C++, Go, Ruby, JavaScript eller vilket annat språk som helst. Det du skriver kallas källkod. Först, särskilt om du arbetar ensam, kan du spara allt i en lokal katalog. Men när projektet växer och fler personer ansluter sig behöver du ett sätt att dela ändringar i koden, samtidigt som du undviker konflikter vid sammanslagning av ändringar. Dessutom behöver du ett sätt att återställa tidigare versioner utan att använda säkerhetskopior och använda copy-paste-metoden för kodfiler.
Och här behövs SCM. SCM sparar koden i arkiv, hanterar dess versioner och koordinerar den bland utvecklare.
Det finns många SCM-verktyg, men Git har förtjänat sin plats som de facto-standard. Jag rekommenderar att använda just det, även om det finns andra alternativ.
Så här ser DevOps-pipelinen ut efter att ha lagt till SCM.
CI/CD-verktyget kan automatisera uppladdning och nedladdning av källkod samt samarbete i teamet. Inte dåligt? Men hur gör vi nu detta till en fungerande applikation, älskad av miljarder användare?
Steg 3: verktyg för automatisering av byggen
Allt går som det ska. Du kan ladda upp koden och registrera ändringar i versionshanteringssystemet, samt bjuda in vänner att arbeta med dig. Men du har fortfarande ingen applikation. För att det ska bli en webbapplikation måste den kompileras och paketeras för distribution eller köras som en körbar fil. (Ett tolkat programmeringsspråk, som JavaScript eller PHP, behöver inte kompileras.)
Använd ett verktyg för automatisering av byggen. Vilket verktyg du än väljer kommer det att bygga koden i rätt format och automatisera städning, kompilerande, testning och distribution. Det finns olika byggverktyg beroende på språk, men oftast används följande alternativ med öppen källkod.
Utmärkt! Nu ska vi lägga till konfigurationsfilerna för automationsverktyget i versionshanteringssystemet så att CI/CD-verktyget kan samla dem.
Det verkar som om allt är i ordning. Men vart ska vi nu rulla ut allt detta?
Steg 4: webbapplikationsserver
Så, du har en paketerad fil som kan köras eller distribueras. För att applikationen verkligen ska vara användbar måste den ha någon form av tjänst eller gränssnitt, men du behöver ha någonstans att placera allt detta.
Webbapplikationen kan placeras på en applikationsserver. Applikationsservern tillhandahåller en miljö där programlogiken kan köras från paketet, rendera gränssnittet och öppna webbservicer via socket. Du behöver en HTTP-server och några andra miljöer (till exempel en virtuell maskin) för att installera applikationsservern. Låt oss tänka oss att du hanterar allt detta under processen (även om jag kommer att berätta om containrar senare).
Det finns flera öppna applikationsservrar.
Vi har redan fått en nästan fungerande DevOps-kedja. Bra jobbat!
I princip kan du stanna här, men du kan klara dig själv längre fram, det är värt att nämna kodens kvalitet.
Steg 5: Testtäckning
Testning tar mycket tid och kraft, men det är bättre att upptäcka fel tidigt och förbättra koden för att glädja slutanvändarna. För detta ändamål finns det många öppna verktyg som inte bara testar koden utan också ger råd om hur den kan förbättras. De flesta CI/CD-verktyg kan kopplas till dessa verktyg och automatisera processen.
Testning är uppdelad i två delar: testningsramverk för att skriva och utföra tester, och verktyg med förslag på hur man kan förbättra kodens kvalitet.
Testningsramverk
Verktyg med förslag på kvalitet
De flesta av dessa verktyg och ramverk är skrivna för Java, Python och JavaScript eftersom C++ och C# är proprietära (även om GCC har öppen källkod).
Vi har tillämpat testtäckningsverktyg, och nu borde DevOps-pipelinen se ut som på bilden i början av guiden.
Extra steg
Containrar
Som jag nämnde kan applikationsservern placeras på en virtuell maskin eller server, men containrar är mer populära.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
För containrar används vanligtvis Docker och Kubernetes, även om det finns andra alternativ.
Läs artiklar om Docker och Kubernetes på :
Verktyg för automatisering av programvara
Vår DevOps-kedja är inriktad på samarbetsinriktad byggnation och leverans av applikationer, men med DevOps-verktyg kan man göra andra intressanta saker också. Till exempel kan man använda verktyg för "infrastruktur som kod" (IaC), som även kallas automatiseringsverktyg för middleware. Dessa verktyg hjälper till att automatisera installation, hantering och andra uppgifter för middleware. Till exempel kan ett automatiseringsverktyg ta applikationer (webbapplikationsserver, databas, övervakningsverktyg) med korrekta konfigurationer och distribuera dem på applikationsservern.
Här är några alternativ för öppna automatiseringsverktyg för middleware:
Mer information finns i artiklarna på :
Och nu då?
Detta är bara toppen av isberget. DevOps-kedjan kan mycket mer. Börja med ett CI/CD-verktyg och se vad mer som kan automatiseras för att förenkla ditt arbete. Glöm inte de för effektivt samarbete.
Här är några fler bra artiklar om DevOps för nybörjare:
Och dessutom kan man integrera DevOps med öppna verktyg för agile:
Källa: habr.com
