(AFGESCHAFT) Volledige CI/CD-pijplijn voor het implementeren van een toepassing met meerdere containers in Azure Container Service met Docker Swarm met behulp van Azure DevOps Services
Waarschuwing
Azure Container Service (ACS) wordt afgeschaft. Er worden geen nieuwe functies of functionaliteit meer aan ACS toegevoegd. Alles van de API's, portal, CLI-opdrachten en documentatie is gemarkeerd als afgeschaft.
Zie voor meer informatie de aankondiging over de afschaffing van Azure Container Service op Azure.com.
U wordt aangeraden een van de volgende Azure Marketplace-oplossingen te implementeren:
- Mesosphere DC/OS
Als u Kubernetes wilt gebruiken, raadpleegt u Azure Kubernetes Service.
Een van de grootste uitdagingen bij het ontwikkelen van moderne toepassingen voor de cloud is het continu leveren van deze toepassingen. In dit artikel leert u hoe u een CI/CD-pijplijn (volledige continue integratie en implementatie) implementeert met behulp van Azure Container Service met Docker Swarm, Azure Container Registry en Azure Pipelines-beheer.
Het doel is om deze toepassing continu te leveren in een Docker Swarm-cluster, met behulp van Azure DevOps Services. In de volgende afbeelding wordt deze pijplijn voor continue levering weergegeven:
Hier volgt een korte uitleg van de stappen:
- Codewijzigingen worden doorgevoerd in de broncodeopslagplaats (hier, GitHub)
- GitHub activeert een build in Azure DevOps Services
- Azure DevOps Services haalt de nieuwste versie van de bronnen op en bouwt alle installatiekopieën waaruit de toepassing bestaat
- Azure DevOps Services pusht elke installatiekopieën naar een Docker-register dat is gemaakt met behulp van de Azure Container Registry-service
- Azure DevOps Services activeert een nieuwe release
- In de release worden enkele opdrachten uitgevoerd met behulp van SSH op het hoofdknooppunt van het Azure-containerservicecluster
- Docker Swarm op het cluster haalt de nieuwste versie van de installatiekopieën op
- De nieuwe versie van de toepassing wordt geïmplementeerd met Docker Compose
Vereisten
Voordat u met deze zelfstudie begint, moet u de volgende taken uitvoeren:
- Een Swarm-cluster in Azure Container Service maken
- Verbinding maken met het Swarm-cluster in Azure Container Service
- Een Azure-containerregister maken
- Een Azure DevOps Services-organisatie en -project laten maken
- De GitHub-opslagplaats splitsen naar uw GitHub-account
Notitie
De Docker Swarm-orchestrator in Azure Container Service maakt gebruik van legacy standalone Swarm. Momenteel is de geïntegreerde Swarm-modus (in Docker 1.12 en hoger) geen ondersteunde orchestrator in Azure Container Service. Als u een Swarmmoduscluster in Azure wilt implementeren, gebruikt u de open-source ACS Engine, een door de community bijgedragen snelstartsjabloon of een Docker-oplossing in de Azure Marketplace.
U hebt ook een Ubuntu-computer (14.04 of 16.04) nodig waarop Docker is geïnstalleerd. Deze machine wordt gebruikt door Azure DevOps Services tijdens de Azure Pipelines-processen. Een manier om deze machine te maken, is door de installatiekopieën te gebruiken die beschikbaar zijn in de Azure Marketplace.
Stap 1: uw Azure DevOps Services-organisatie configureren
In deze sectie configureert u uw Azure DevOps Services-organisatie.
Een Linux-buildagent voor Azure DevOps Services configureren
Als u Docker-installatiekopieën wilt maken en deze installatiekopieën vanuit een Azure DevOps Services-build naar een Azure-containerregister wilt pushen, moet u een Linux-agent registreren. U hebt de volgende installatieopties:
De Docker Integration Azure DevOps Services-extensie installeren
Microsoft biedt een Azure DevOps Services-extensie om te werken met Docker in Azure Pipelines-processen. Deze extensie is beschikbaar in de Azure DevOps Services Marketplace. Klik op Installeren om deze extensie toe te voegen aan uw Azure DevOps Services-organisatie:
U wordt gevraagd om verbinding te maken met uw Azure DevOps Services-organisatie met behulp van uw referenties.
Azure DevOps Services en GitHub verbinden
Stel een verbinding in tussen uw Azure DevOps Services-project en uw GitHub-account.
Klik in uw Azure DevOps Services-project op het pictogram Instellingen op de werkbalk en selecteer Services.
Klik aan de linkerkant op Nieuw service-eindpunt>GitHub.
Als u Wilt toestaan dat Azure DevOps Services werkt met uw GitHub-account, klikt u op Autoriseren en volgt u de procedure in het venster dat wordt geopend.
Azure DevOps Services verbinden met uw Azure-containerregister en Azure Container Service-cluster
De laatste stappen voordat u toegang krijgt tot de CI/CD-pijplijn, zijn het configureren van externe verbindingen met uw containerregister en uw Docker Swarm-cluster in Azure.
Voeg in de Services-instellingen van uw Azure DevOps Services-project een service-eindpunt van het type Docker Registry toe.
Voer in het pop-upvenster dat wordt geopend de URL en de referenties van uw Azure-containerregister in.
Voeg voor het Docker Swarm-cluster een eindpunt van het type SSH toe. Voer vervolgens de SSH-verbindingsgegevens van uw Swarm-cluster in.
Alle configuratie is nu voltooid. In de volgende stappen maakt u de CI/CD-pijplijn waarmee de toepassing wordt gebouwd en geïmplementeerd in het Docker Swarm-cluster.
Stap 2: de build-pijplijn maken
In deze stap stelt u een build-pijplijn in voor uw Azure DevOps Services-project en definieert u de build-werkstroom voor uw containerinstallatiekopieën
Initiële pijplijninstallatie
Als u een build-pijplijn wilt maken, maakt u verbinding met uw Azure DevOps Services-project en klikt u op Build & Release.
Klik in de sectie Definities bouwen op + Nieuw. Selecteer de sjabloon Leeg .
Configureer de nieuwe build met een GitHub-opslagplaatsbron, controleer Continue integratie en selecteer de agentwachtrij waar u uw Linux-agent hebt geregistreerd. Klik op Maken om de build-pijplijn te maken.
Open op de pagina BuildDefinities eerst het tabblad Opslagplaats en configureer de build voor gebruik van de fork van het MyShop-project dat u in de vereisten hebt gemaakt. Zorg ervoor dat u acs-docs selecteert als de standaardvertakking.
Configureer op het tabblad Triggers de build om na elke doorvoering te worden geactiveerd. Selecteer Continue integratie en Batchwijzigingen.
De buildwerkstroom definiëren
In de volgende stappen wordt de build-werkstroom gedefinieerd. Er zijn vijf containerinstallatiekopieën om te bouwen voor de myshop-toepassing . Elke installatiekopie wordt gebouwd met behulp van het Dockerfile dat zich in de projectmappen bevindt:
- ProductsApi
- Proxy
- RatingsApi
- RecommendationsApi
- Winkelfront
U moet twee Docker-stappen toevoegen voor elke installatiekopieën, één voor het bouwen van de installatiekopieën en één voor het pushen van de installatiekopieën in het Azure-containerregister.
Als u een stap wilt toevoegen aan de build-werkstroom, klikt u op + Build-stap toevoegen en selecteert u Docker.
Configureer voor elke installatiekopieën één stap die gebruikmaakt van de
docker build
opdracht .Selecteer voor de buildbewerking uw Azure-containerregister, de actie Een installatiekopieën bouwen en het Dockerfile waarmee elke installatiekopieën worden gedefinieerd. Stel de buildcontext in als de hoofdmap dockerfile en definieer de naam van de installatiekopieën.
Zoals in het vorige scherm wordt weergegeven, start u de naam van de installatiekopieën met de URI van uw Azure-containerregister. (U kunt ook een buildvariabele gebruiken om de tag van de installatiekopieën te parameteriseren, zoals de build-id in dit voorbeeld.)
Configureer voor elke installatiekopieën een tweede stap die gebruikmaakt van de
docker push
opdracht .Voor de pushbewerking selecteert u uw Azure-containerregister, de actie Een installatiekopieën pushen voert u de naam van de installatiekopieën in die in de vorige stap is gemaakt.
Nadat u de build- en pushstappen voor elk van de vijf installatiekopieën hebt geconfigureerd, voegt u nog twee stappen toe in de build-werkstroom.
a. Een opdrachtregeltaak die gebruikmaakt van een bash-script om het BuildNumber-exemplaar in het bestand docker-compose.yml te vervangen door de huidige build-id. Zie het volgende scherm voor meer informatie.
b. Een taak waarmee het bijgewerkte Compose-bestand als build-artefact wordt verwijderd, zodat het kan worden gebruikt in de release. Zie het volgende scherm voor meer informatie.
Klik op Opslaan en geef de build-pijplijn een naam.
Stap 3: De release-pijplijn maken
Met Azure DevOps Services kunt u releases in verschillende omgevingen beheren. U kunt continue implementatie inschakelen om ervoor te zorgen dat uw toepassing op een soepele manier wordt geïmplementeerd in uw verschillende omgevingen (zoals ontwikkelen, testen, preproductie en productie). U kunt een nieuwe omgeving maken die uw Azure Container Service Docker Swarm-cluster vertegenwoordigt.
Eerste release-installatie
Als u een release-pijplijn wilt maken, klikt u op Releases>+ Release
Als u de artefactbron wilt configureren, klikt u op Artefacten>Een artefactbron koppelen. Hier koppelt u deze nieuwe release-pijplijn aan de build die u in de vorige stap hebt gedefinieerd. Hierdoor is het bestand docker-compose.yml beschikbaar in het releaseproces.
Als u de releasetrigger wilt configureren, klikt u op Triggers en selecteert u Continue implementatie. Stel de trigger in op dezelfde artefactbron. Deze instelling zorgt ervoor dat er een nieuwe release wordt gestart zodra de build is voltooid.
De releasewerkstroom definiëren
De releasewerkstroom bestaat uit twee taken die u toevoegt.
Configureer een taak om het opstelbestand veilig te kopiëren naar een implementatiemap op het Docker Swarm-hoofdknooppunt, met behulp van de SSH-verbinding die u eerder hebt geconfigureerd. Zie het volgende scherm voor meer informatie.
Configureer een tweede taak om een bash-opdracht uit te voeren en
docker-compose
opdrachten uit te voerendocker
op het hoofdknooppunt. Zie het volgende scherm voor meer informatie.De opdracht die op de master wordt uitgevoerd, gebruikt de Docker CLI en de Docker-Compose CLI om de volgende taken uit te voeren:
Meld u aan bij het Azure-containerregister (er worden drie buildvariabelen gebruikt die zijn gedefinieerd op het tabblad Variabelen )
Definieer de DOCKER_HOST variabele om te werken met het Swarm-eindpunt (:2375)
Navigeer naar de implementatiemap die is gemaakt door de voorgaande beveiligde kopieertaak en die het bestand docker-compose.yml bevat
Voer opdrachten uit
docker-compose
die de nieuwe installatiekopieën ophalen, de services stoppen, de services verwijderen en de containers maken.Belangrijk
Zoals in het vorige scherm wordt weergegeven, laat u het selectievakje Fail on STDERR uitgeschakeld. Dit is een belangrijke instelling, omdat
docker-compose
in de standaardfoutuitvoer verschillende diagnostische berichten worden afgedrukt, zoals containers die worden gestopt of verwijderd. Als u het selectievakje inschakelt, meldt Azure DevOps Services dat er fouten zijn opgetreden tijdens de release, zelfs als alles goed gaat.
Sla deze nieuwe release-pijplijn op.
Notitie
Deze implementatie omvat enige downtime omdat we de oude services stoppen en de nieuwe uitvoeren. U kunt dit voorkomen door een blauw-groene implementatie uit te voeren.
Stap 4. De CI/CD-pijplijn testen
Nu u klaar bent met de configuratie, is het tijd om deze nieuwe CI/CD-pijplijn te testen. De eenvoudigste manier om dit te testen is door de broncode bij te werken en de wijzigingen door te voeren in uw GitHub-opslagplaats. Een paar seconden nadat u de code hebt gepusht, ziet u dat er een nieuwe build wordt uitgevoerd in Azure DevOps Services. Zodra dit is voltooid, wordt een nieuwe release geactiveerd en wordt de nieuwe versie van de toepassing geïmplementeerd in het Azure Container Service-cluster.
Volgende stappen
- Zie het artikel Documentatie voor Azure Pipelines voor meer informatie over CI/CD met Azure DevOps Services.