”Det er sjovt, koden kører fint på mit system”
“Vi kan ikke teste denne nye funktion, da det ville kræve store ændringer af vores kode og produktionsinfrastruktur”
“Det er svært at samarbejde og introducere nye udviklere til workflowet, da kodebasen er blevet så stor”
“De nye ændringer af vores applikation kræver en forhåndspris på 250.000 $ i nye servere, licenser osv. og vil tage 3 måneder før platformen er klar”
Forestil dig at have en infrastruktur med dens webapps, databaser, netværkskomponenter, operativsystem, runtime-biblioteker og alle de andre ting, der udgør din applikation. Forestil dig at skulle skalere det til din kommende store salgsbegivenhed, eller de 100.000 nye brugere, der lige har tilmeldt sig dit produkt.
Nu kan du få det til at køre, som om du lige installerede Spotify på din computer. Næste, Næste og afslut, og du er godt i gang.
Det lyder smart, ikke?
Tilbage i gamle dage, da du ønskede at implementere en ny applikation, skulle du først vurdere, hvor mange ressourcer du har brug for til din applikation. Hvis din CapEx-model (Kapitalinvestering) blev beregnet forkert, skal du muligvis investere i nye servere og netværksudstyr.
Så får du infrastrukturfolkene til fysisk at opsætte de nye servere, installere den underliggende hypervisor, tilføje dem til din serverfarm, konfigurere netværk, installere operativsystemer, patche dem, oprette databaser, konfigurere backup og overvågning og SÅ kunne du begynde arbejdet at udvikle og implementere applikationen.
Der går måneder, men du er endelig klar til at gå live. Alt ser godt ud, men din helpdesk bliver pludselig bombarderet.
Den nye løsning kan ikke skaleres til de tusindvis af nye brugere. Da den er en monolitisk applikation, var den ikke designet til at kunne skalere beregning, database og netværksbelastning. Et par uger senere har du et andet problem, noget er gået i stykker. Dit team ved ikke, hvad der forårsager det. Timer efter timer med fejlfinding, og du finder rodårsagen til at være en opdatering til nogle biblioteker på serverne. Det blev ikke testet, da dit system manglede et identisk testmiljø, som ikke er tilgængeligt. Jeres team kunne ikke nemt finde kulprintet, da der ikke er nogen versionskontrol, og opdateringerne skulle manuelt afinstalleres på serverne, hvilket krævede nedetid.
Karakteren af det monolitiske design, der findes i traditionelle fysiske on-premise eller virtualiserede miljø, begrænser organisationens evne til at udføre uafhængig implementering af nye funktioner, skalere deres løsning og foretage korrekt fejlisolering. Det begrænser også de teknologier, de kan bruge.
Virtuelle maskiner har hjulpet os med at overvinde problemer med at holde ældre applikationer i live, reducere omkostningerne og forbedre vores fleksibilitet, men i takt med at verden og vores efterspørgsel bliver ved med at bevæge sig hurtigere, så skal den teknologi, vi bruger, også gøre det.
Docker er den næste udvikling inden for virtualiseringsteknologi og er en gamechanger i forhold til, hvordan organisationen kan udvikle, implementere og skalere deres applikationer.
Normalt ville du have en virtuel maskine med sit eget separate operativsystem og afhængigheder.
Hver komponent i din applikation ville ideelt set kræve deres egen virtuelle maskine, hvilket gør administration, implementering og ændringer besværlig.
I modsætning hertil kan en enkelt docker-vært køre flere forekomster af den samme eller en anden
applikation.
Det gør det ved at tage virtualiseringen et skridt tættere på applikationen, ved at lade dem dele det
samme operativsystem og kerne, men stadig tillade uafhængig konfiguration og isolering, ligesom en
virtuel maskine ville tillade.
Dette gør det muligt for en enkelt node at være vært for flere applikationer, da vi kan skære de ekstra
kopier af operativsystemet væk. Det fjerner også afhængighedslag.
Kort sagt, vi laver ikke hardwarevirtualisering, men operativsystemvirtualisering.
Derudover kræver docker ikke manuel installation af biblioteker og software, som det ville på en
virtuel maskine. Da den underliggende platform altid er den samme, kan udviklerne pakke alle deres
softwarekrav i et såkaldt docker-billede (meget som en applikation).
Et Docker-billede indeholder alle de nødvendige softwareafhængigheder, konfigurationsfiler,
biblioteker og runtime-komponenter og kode, som din applikation skal bruge. Har din applikation brug
for en specifik .NETversion? Det er ikke nødvendigt at installere det i operativsystemet, bare tilføje det til billedet.
Se det som en .MSI fil på steroider.
Når det er tid til at køre applikationen, downloader docker-værten blot den seneste version af dit
billede fra et såkaldt repository. På den måde, hvis en udvikler foretager ændringer i applikationen,
er det bare et simpelt spørgsmål om at genstarte containeren og lade den automatisk downloade
den seneste version. At gøre det på denne måde introducerer også versionskontrol for lettere
tilbagerulning.
Docker Containers er i modsætning til en traditionel opsætning, uafhæninge. Det betyder, at ingen
docker-container bør indeholde vedvarende data. Du adskiller effektivt dit såkaldte lager fra dine
computerkomponenter.
Kort sagt gør docker dig i stand til at adskille dine applikationer fra din infrastruktur, hvilket gør det
muligt at flytte din applikation, hvorhen du vil have den kører.
Docker har flere fordele, herunder:
Så antag, at vi er en udvikler, der skal oprette et nyt plugin til Atlassian Jira.
Jira Software er en del af en familie af produkter designet til at hjælpe teams af alle typer med at samarbejde. Oprindeligt var Jira designet til fejlrapportering og problemsporing. Men i dag
har Jira udviklet sig til et kraftfuldt arbejdsstyringsværktøj til alle slags use cases, lige fra krav og
testcasestyring til agil softwareudvikling.
Selvom Jira er optimeret til skyen og har brugsklare Azure-markedspladsbilleder, vil vi i dette trin
demonstrere et traditionelt on-premise dev-miljø og derefter gennemgå den samme proces, men
bruge Docker i stedet.
På vores computer starter vi med at konfigurere vores Hyper-V hypervisor (Hyper-V giver os mulighed for at køre en virtuel computer inde i vores computer. Dette kaldes virtualisering og bruges også af Docker)
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Efter en genstart skal vi downloade og installere et Linux-operativsystem. Vi skal også sikre, at vores
operativsystem understøttes i henhold til dokumentationen.
$URL = "https://releases.ubuntu.com/20.04.5/ubuntu-20.04.5-live-server-amd64.iso?_
ga=2.213486228.1663749031.1666263862-84623288.1666263862"
Invoke-WebRequest $URL -OutFile C:\Temp\Ubuntu.iso
Derefter kan vi gå videre og oprette den virtuelle maskine:
New-VM -Name Jira -MemoryStartupBytes 4GB -NewVHDPath C:\temp\Jira.vhdx
-NewVHDSizeBytes 40G
Vi skal gennemgå hele operativsysteminstallationen:
Når installationen er fuldført, skal vi opdatere vores operativsystem:
automize@jira:~$ sudo apt-get update
Lad os installere MySQL-serveren:
automize@jira:~$ sudo apt install mysql-server
Og start det:
automize@jira:~$ sudo systemctl start mysql.service
automize@jira:~$
Og konfigurer det …:
mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password
BY 'password';
automize@jira:~$ mysql_secure_installation
Securing the MySQL server deployment.
Enter password for user root:
automize@jira:~$ mysql -u root -p
mysql> ALTER USER 'root'@'localhost' IDENTIFIED WITH auth socket;
automize@jira:~$ sudo mysql_secure_installation
mysql> CREATE USER 'automize' @'localhost' IDENTIFIED WITH authentication_plugin BY
ERROR 1524 (HY000): Plugin 'authentication plugin' is not loaded
Prøv at opgradere MySQL:
automize@jira:~$ mysql_upgrade -u root -p
The mysql_upgrade client is now deprecated. The actions executed by the upgrade
client are now done by the server.
To upgrade, please start the new MySQL binary with the older data directory.
Repairing user tables is done automatically. Restart is not required after
upgrade. The upgrade process automatically starts on running a new MySQL binary
with an older data directory. To avoid accidental upgrades, please use the
--upgrade=NONE option with the MySQL binary. The option --upgrade=FORCE is also
provided to run the server upgrade sequence on demand.
It may be possible that the server upgrade fails due to a number of reasons. In
that case, the upgrade sequence will run again during the next MySQL server start.
If the server upgrade fails repeatedly, the server can be started with the
upgrade=MINIMAL option to start the server without executing the upgrade sequence,
thus allowing users to manually rectify the problem.
Debug i et par minutter mere, før du beslutter dig for at oprette en Azure SQL DB i stedet …
# Set variables for your server and database
$resourceGroupName = "myResourceGroup"
$location = "eastus"
$adminLogin = "azureuser"
$password = ""
$serverName = "mysqlserver-$(Get-Random)"
$databaseName = "mySampleDatabase"
# The ip address range that you want to allow to access your server
$startIp = "0.0.0.0"
$endIp = "0.0.0.0"
# Show randomized variables
Write-host "Resource group name is" $resourceGroupName
Write-host "Server name is" $serverName
Write-host "Creating resource group…"
$resourceGroup = New-AzResourceGroup -Name $resourceGroupName -Location
$location -Tag @{Owner="SQLDB-Samples"}
$resourceGroup
Write-host "Creating primary server…"
$server = New-AzSqlServer -ResourceGroupName $resourceGroupName -ServerName $serverName
-Location $location -SqlAdministratorCredentials $(New-Object -TypeName System.Management. Automation.PSCredential
-ArgumentList $adminLogin, $(ConvertTo-SecureString -String $password
-AsPlainText -Force))
$server
Write-host "Configuring server firewall rule…"
$serverFirewallRule = New-AzSqlServerFirewallRule -ResourceGroupName
$resourceGroupName -ServerName $serverName
-FirewallRuleName "AllowedIPs" -StartIpAddress $startIp -EndIpAddress $endIp
$serverFirewallRuleWrite-host "Creating a gen5 2 vCore serverless database…"
$database = New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName
-DatabaseName $databaseName -Edition GeneralPurpose
-ComputeModel Serverless -ComputeGeneration Gen5
-VCore 2 -MinimumCapacity 2
-SampleName "AdventureWorksLT"
$database
Download Jira Core og installer det, så filerne kan eksekveres på forhånd.
Men før det, download Chrome, fordi en fejl forhindrer os i at downloade
Linux build ved hjælp af Firefox:
Vælg og download pakken til Linux:
automize@jira:~/Downloads$ chmod a+x atlassian-jira-core-9.3.0-x64.bin
automize@jira:~/Downloads$
automize@jira:~/Downloads$ sudo ./atlassian-jira-core-9.3.0-x64.bin
[sudo] password for automize:
Unpacking JRE …
Starting Installer …
This will install Jira Core 9.3.0 on your computer.
OK [o, Enter], Cancel [c]
Installation of Jira Core 9.3.0 is complete
Your installation of Jira Core 9.3.0 is now ready and can be accessed
via your browser.
Jira Core 9.3.0 can be accessed at http://localhost:8080
Finishing installation …
automize@jira:~/Downloads$
Prøv at få adgang til Jira uden held:
Download en ældre Jira build og installer den, fordi det sandsynligvis er en fejl med den nyeste
version, sammen med den brugte Ubuntu-version.
Når du er færdig, tilgå webgrænsefladen og konfigurere den:
Konfigurer din database:
Dette er den del, hvor Jira skal indlæses, men som du kan se, så starter den slet ikke op …
Okay nok af det, lad os gøre det samme ved at bruge Docker til Desktop.
Installer docker:
Opret et volumen til Jira og download docker afbildningen af Jira:
Vi kan nu få adgang til den samme konfigurationsskærm fra vores lokale browser i stedet for inde i
vores virtuelle maskine:
For god ordens skyld er vi gået videre og oprettet en ny SQL DB til denne instans og forbundet det:
Og nu starter Jira:
Som du kunne se, var processen for at få et Jiraudviklingsmiljø op at køre betydeligt hurtigere og nemmere end at gøre det ved hjælp af traditionelle virtuelle maskiner.
Ved at bruge Docker kan udvikleren være sikker på, at applikationen fungerer på samme måde i produktionen. Selvom det er fantastisk at kunne udvikle appen lokalt, så har vi også brug for et sted at afvikle den, administrere den samt sikre den og der har Microsoft Azure din ryg.
Når den er klar til produktion, kan organisationen implementere containere til Azure ved hjælp af en række produkter, der bedst passer til deres behov for skalering, omkostninger og sikkerhed. Når det kører weboptimerede containere ved hjælp af Azure App Service Plans, generelle containere, der bruger Azure Container Apps eller store globalt spændende virksomhedsapplikationer, der bruger Azure Kubernetes Service, eller en af de 7 muligheder, Microsoft Azure er stedet at gå til.
Microsoft Azure integrerer også sin markedsledende sikkerhed og leverer rollebaseret adgangskontrol og Microsoft Defender til containere.
Ved hjælp af Docker kan organisationer begynde at bruge CI/CD-pipelines ved hjælp af Azure DevOps Services og dermed forbedre tiden til produktion ved hjælp af Azure Pipelines, gemme docker-billeder og kode i Azure Repos & Azure Container Registry og bedre samarbejde ved hjælp af Azure Boards.
Oprettelse af en ny applikation baseret på dockercontainere eller overgang fra en traditionel N-tierapp til mikrotjenester kræver hårdt arbejde og omtanke. Ikke alle virksomheder og applikationer er skabt ens, og selvom det i nogle scenarier er uoverskueligt at indføre en DevOps- og Microservices-kultur, er det for andre tilstrækkeligt at udskifte nogle dele af deres gamle komponenter.
Containere er fremtidens byggesten. Ligesom virtuelle maskiner var, da de blev introduceret. De er ikke bare et "skinnende nyt, buzzword", men er kommet for at blive ligesom skyen.
Fra at levere applikationer hurtigere, for at reducere tiden fra udvikling til implementering, til at reducere infrastruktur og omkostninger, giver containere både små og store organisationer reel forretningsværdi.
Hos Automize står vi altid klar til at hjælpe dig og din virksomhed med, at få løst jeres udfordringer med Docker, vi har vores dygtige konsulenter, som står klar til at få implementeret en løsning, som er skræddersyet til jeres behov og jeres virksomhed, du kan kontakte os her for at hør mere om, hvordan vi kan hjælpe din virksomhed.
Automize blev grundlagt med ønsket om at skabe værdi ved at drive den digitaliserings- og transformationsrejse, som alle virksomheder er på i dag. Det gør vi ved at bringe mennesker, forretning og teknologi tættere sammen. Vores udgangspunkt er det enkelte menneske, for uden mennesker er der ingen forretning, og der skal teknologi til for at drive forretningen.
Besøg Automize's website |
Kontakt os |
Book et møde med os |
"Docker er den næste udvikling inden for virtualiseringsteknologi og er en gamechanger i forhold til, hvordan organisationen kan udvikle, implementere og skalere deres applikationer.” |
"Et Docker-billede indeholder alle de nødvendige softwareafhængigheder, konfigurationsfiler,
biblioteker og runtime-komponenter og kode, som din applikation skal bruge. Har din applikation brug for en specifik .NETversion? Det er ikke nødvendigt at installere det i operativsystemet, bare tilføje det til billedet." |
"Ved hjælp af Docker kan organisationer begynde at bruge CI/CD-pipelines ved hjælp af Azure DevOps Services og dermed forbedre tiden til produktion ved hjælp af Azure Pipelines, gemme docker-billeder og kode i Azure Repos & Azure Container Registry og bedre samarbejde ved hjælp af Azure Boards." |
Er du interesseret i at høre mere, er du meget velkommen til at kontakte os på mail eller telefon. Du kan også bruge vores kontaktformular
