Wat is Docker?

Linux-containers bestaan ​​al sinds 2008, maar ze waren niet zo bekend tot de opkomst van Docker-containers in 2013. Met opkomst van Docker-container ontstond er een enorme interesse in het ontwikkelen en implementeren van applicaties in containers. Naarmate het aantal applicaties in containers groeide tot honderden containers die op meerdere servers werden ingezet, werd het gebruik ervan complexer. Hoe coördineert, schaalt, beheert en plant u honderden containers? Hierbij kunnen Kubernetes van pas komen. Kubernetes is een open-source orkestratiesysteem waarmee u Docker-containers en -workloads kunt uitvoeren. Hiermee kunt u de operationele complexiteit beheren wanneer u overstapt op het schalen van meerdere containers die op meerdere servers zijn geïmplementeerd. De Kubernetes-engine orkestreert automatisch de levenscyclus van de container en verdeelt de applicatiecontainers over de hostinginfrastructuur. Kubernetes kan resources snel op- of afschalen, afhankelijk van de vraag. De status van de containers kan zo continu worden aangegeven, gepland, verwijderd en gemonitord.

De kernconcepten van Docker zijn images en containers. Een Docker-image bevat alles wat u nodig hebt om uw software uit te voeren: de code, een runtime (bijvoorbeeld Java Virtual Machine (JVM)), drivers, tools, scripts, bibliotheken, implementaties en meer.

Een Docker-container is een actief exemplaar van een Docker-image. In tegenstelling tot traditionele virtualisatie met een type 1- of type 2-hypervisor, wordt een Docker-container echter uitgevoerd op de kernel van het hostbesturingssysteem. Binnen een Docker-image is er geen afzonderlijk besturingssysteem, zoals is afgebeeld in Afbeelding 1.

Isolatie versus virtualisatie

Elke Docker-container heeft een eigen bestandssysteem, een eigen netwerkstack (en dus een eigen IP-adres), een eigen procesruimte en gedefinieerde resourcebeperkingen voor CPU en geheugen. Omdat een Docker-container geen besturingssysteem hoeft op te starten, start deze onmiddellijk op. Docker gaat over isolatie, d.w.z. het scheiden van de resources van een hostbesturingssysteem, in tegenstelling tot virtualisatie, d.w.z. het bieden van een gastbesturingssysteem bovenop het hostbesturingssysteem.

Incrementeel bestandssysteem

Het bestandssysteem van een Docker-image is gelaagd, met copy-on-write-semantiek. Dit maakt overname en hergebruik mogelijk, bespaart resources op de schijf en maakt incrementeel downloaden van images mogelijk.

Zoals te zien is in Figuur 2 kan een Docker-beeld met een WebLogic-implementatie gebaseerd zijn op een beeld met een Oracle WebLogic Server-domein, dat gebaseerd kan zijn op een WebLogic-beeld dat gebaseerd is op een Java Development Kit-beeld (JDK), dat op zijn beurt gebaseerd is op een Oracle Linux-basisbeeld.

Docker Registry

Hoewel Docker-images eenvoudig te bouwen zijn en ontwikkelaars dol zijn op de eenvoud en overdraagbaarheid van Docker-images, ontdekten ze al snel dat het beheren van duizenden Docker-images een hele uitdaging is. Deze uitdaging wordt opgelost door Docker Registry. Docker Registry is een standaardmethode voor het opslaan en distribueren van Docker-images. Het register is een open-source repository onder de Apache licentie.

Docker Registry helpt ook bij het verbeteren van de toegangscontrole en -beveiliging van de Docker-images die zijn opgeslagen in de repository. Het beheert de distributie van images en kan ook worden geïntegreerd met workflows voor applicatieontwikkeling. Ontwikkelaars kunnen hun eigen Docker Registry opzetten of een gehoste Docker Registry-service gebruiken, zoals Docker Hub, Oracle Container Registry, Azure Container Registry, enz.

Docker Hub is een gehoste Docker Registry die wordt beheerd door Docker. Docker Hub bevat meer dan 100.000 containerimages van softwareleveranciers, open-source projecten en de community. Docker Hub bevat software en applicaties van officiële repository's zoals NGINX, Logstash, Apache HTTP, Grafana, MySQL, Ubuntu en Oracle Linux.

Bij het starten van een container haalt Docker automatisch de bijbehorende images op uit de openbare Docker Hub als deze niet lokaal beschikbaar is. U kunt uw eigen images maken en deze naar Docker Hub doorsturen in een openbare of privérepository.

Docker als een microservices-runtime

Het idee om monolithische applicaties in kleinere microservices te knippen, trekt tegenwoordig veel aandacht bij softwareontwikkelaars.

Microservices worden onafhankelijk ingezet als een proces, ze gebruiken lichtgewicht protocollen om met elkaar te communiceren en elke service is eigenaar van de gegevens. Omdat microservices een gedecentraliseerde beheeraanpak volgen, vereisen ze een hoge mate van infrastructuurautomatisering, geautomatiseerd testen, volledig geautomatiseerde CD-pijplijnen en bekwame, flexibele DevOps-teams.

Er is nog steeds veel discussie over deze architectuurstijl, maar het zou naïef zijn om te veronderstellen dat een applicatie die onderverdeeld in microservices eenvoudig kan worden bediend als een reeks processen. Om maar een paar vereisten te noemen: een microservice moet hostonafhankelijk zijn en geïsoleerd zijn op besturingssysteemniveau. Een microservice moet binnen de resourcelimieten worden uitgevoerd, moet worden op- en afgeschaald, opnieuw worden opgestart bij een fout en worden ontdekt en verbonden met andere microservices via een softwaregedefinieerde netwerklaag.

Daarom biedt het uitvoeren van een microservice in een Docker-container u een uitstekend startpunt om de meeste van deze doelen te bereiken.

Docker verandert de manier waarop we software bouwen, verzenden en uitvoeren in twee verschillende dimensies:

• Het verbetert het proces om applicaties betrouwbaar te maken van ontwikkeling tot productie.
• Het biedt een standaard image-indeling om van on-premises naar de cloud over te stappen.

In de volgende paragrafen worden beide dimensies nader toegelicht.

Het maken van een Docker-image met alle bijbehorende afhankelijkheden vormt een oplossing voor het probleem "maar het werkte voor mij op mijn ontwikkelmachine". Het belangrijkste idee is dat een Docker afb-image automatisch wordt gemaakt door een buildpijplijn vanuit een broncoderepository zoals Git en in eerste instantie wordt getest in een ontwikkelomgeving. Deze niet-wijzigbare image wordt vervolgens opgeslagen in een Docker Registry.

Zoals weergegeven in Afbeelding 4, wordt dezelfde image gebruikt voor verdere belastingstests, integratietests, acceptatietests en meer. In elke omgeving wordt dezelfde image gebruikt. Kleine maar noodzakelijke omgevingsspecifieke verschillen, zoals een JDBC-URL voor een productiedatabase, kunnen als omgevingsvariabelen of bestanden in de container worden ingevoerd.

Statistieken tonen aan dat 65% van alle huidige Docker-gebruiksdoelen in ontwikkeling is en 48% gebruikt Docker voor continue integratie.

Docker-cloud

Docker veranderde het gebruik van openbare clouds: aan de ene kant biedt een Docker-image voor het eerst in de geschiedenis een algemene pakketindeling die zowel on-premises als bij elke grote cloudprovider kan worden uitgevoerd. Docker-containers worden op een laptop op dezelfde manier uitgevoerd als op Oracle Cloud.

Aan de andere kant worden Docker-containers in elke grote publieke cloud uitgevoerd en leveren ze een belangrijke bijdrage aan het overwinnen van een oud vooroordeel over publieke clouds: afhankelijkheid van één leverancier. Elke grote cloudprovider biedt nu Docker als een PaaS.

Het tempo van Docker-releases is veel sneller dan de releasecyclus van de traditionele bedrijfssoftware. Soms roept het enorme tempo van Docker-releases, samen met de nieuwigheid van het Docker-project, zorgen op over de veiligheid en stabiliteit van Docker.

Hoewel Docker en de bijbehorende opdrachtregel, de Docker-daemon, de API en tools zoals Docker Swarm, Docker Machine en Docker Compose pas in de afgelopen drie jaar zijn ontstaan, zijn de onderliggende kernelfuncties al bijna tien jaar beschikbaar in elke Linux-kernel.

Een prominent voorbeeld van een vroege gebruiker van containertechnologie is Google. Google gebruikte Linux-containers zelfs al voordat Docker er was. Bovendien voert Google alles in een container uit. Naar schatting lanceert Google enkele miljarden containers per week.

Historie van cgroups en naamruimtes

De onderliggende Linux-kernelfuncties die Docker gebruikt, zijn cgroups en naamruimtes. In 2008 werden cgroups geïntroduceerd in de Linux-kernel op basis van werk dat eerder was gedaan door Google -¹. Cgroups beperken en verantwoorden het resourcegebruik van een set besturingssysteemprocessen.

De Linux-kernel gebruikt een naamruimte om de systeemresources van processen van elkaar te isoleren. De eerste naamruimte, d.w.z. de mount-naamruimte, werd al in 2002 geïntroduceerd.²

In het eerste deel van dit artikel werden enkele belangrijke Docker-concepten uitgelegd. In een productieomgeving is het echter niet voldoende om een ​​applicatie simpelweg in een Docker-container uit te voeren.

Voor het opzetten en gebruiken van een productieomgeving is hardware nodig om de containers uit te voeren. Software zoals Docker moeten, samen met repository's en clustermanagers, worden geïnstalleerd, geüpgraded en gepatcht. Als meerdere Docker-containers communiceren tussen hosts, moet er een netwerk worden gemaakt. Geclusterde containers moeten opnieuw worden gestart als ze niet werken. Bovendien moet een set aan elkaar gekoppelde containers net zo eenvoudig inzetbaar zijn als één logische applicatie-instance. Een voorbeeld hiervan kan een lastverdeler zijn, een paar webservers, enkele Oracle WebLogic Server instances met een beheerserver, een beheerde server en een database. Voor het beheren van containerapplicaties op schaal is een containerorkestratiesysteem zoals Kubernetes of Docker Swarm vereist. Het implementeren, beheren en bedienen van orkestratiesystemen zoals Kubernetes kan een uitdaging en tijdrovend zijn.

Om het voor ontwikkelaars gemakkelijker en efficiënter te maken om applicaties in containers te maken, bieden cloudproviders containercloudservices of CaaS (Containers as a Service) aan. Met containercloudservices kunnen ontwikkelaars en operationele teams de levenscyclus van containers op een geautomatiseerde manier stroomlijnen en beheren. Deze orkestratieservices, die doorgaans worden gebouwd met Kubernetes, maken het voor DevOps-teams eenvoudiger om containerapplicaties op grote schaal te beheren en gebruiken. Oracle Container Engine for Kubernetes en Azure Kubernetes Service zijn twee voorbeelden van populaire beheerde cloudservices voor containerorkestratie.

Oracle Container Engine for Kubernetes is een volledig beheerde, schaalbare en zeer beschikbare service die u kunt gebruiken om uw applicaties in containers in de cloud te implementeren. Gebruik Container Engine for Kubernetes (soms afgekort tot OKE) wanneer uw ontwikkelteam op betrouwbare wijze cloudapplicaties wil bouwen, implementeren en beheren.

Containers kunnen door elk soort ontwikkelaar worden verpakt. In de softwarebranche worden ontwikkelaars vaak ingedeeld op specialisatie: front-end, back-end of iets daartussenin. Hoewel je meestal verpakkingscontainers voor back-endontwikkelaars ziet, kan iedereen die bekend is met CaaS-basisconcepten succes behalen op dit specifieke gebied van de levenscyclus van softwareontwikkeling. Voordat u klaar bent om de afhankelijkheden van uw applicatie te verpakken, gaat u naar developer.oracle.com en maakt u zichzelf vertrouwd met de tools die u kunt gebruiken om uw applicatie of programma te bouwen.

Hieronder vindt u enkele bronnen voor het verkrijgen of bouwen van Docker-images voor Oracle producten. De Oracle GitHub repository voor Docker-images bevat Docker-bestanden en -voorbeelden om Docker-images te bouwen voor commerciële Oracle producten en door Oracle gesponsorde open-source projecten.

• Oracle GitHub-repository voor Docker-images
• Oracle Container Registry

Praktijktraining: Ontwikkeling met containers met Docker

• Ontwikkeling met containers met Docker in Oracle Cloud

Referenties

1. Cgroups (Wikipedia)
2. Linux-naamruimtes (Wikipedia)