I'm struggling to set up a CI process for a web application in Azure. I'm used to deploying built code directly into Web Apps in Azure but decided to use docker this time.
In the build pipeline, I build the docker images and push them to an Azure Container Registry, tagged with the latest build number. In the release pipeline (which has DEV, TEST and PROD), I need to deploy those images to the Web Apps of each environment. There are 2 relevant tasks available in Azure releases: "Azure App Service deploy" and "Azure Web App for Containers". Neither of these allow the image source for the Web App to be set to Azure Conntainer Registry. Instead they take custom registry/repository names and set the image source in the Web App to Private Registry, which then requires login and password. I'm also deploying all Azure resources using ARM templates so I don't like the idea of configuring credentials when the 2 resources (the Registry and the Web App) are integrated already. Ideally, I would be able to set the Web App to use the repository and tag in Azure Container Registry that I specify in the release. I even tried to manually configure the Web Apps first with specific repositories and tags, and then tried to change the tags used by the Web Apps with the release (with the tasks I mentioned) but it didn't work. The tags stay the same.
Another option I considered was to configure all Web Apps to specific and permanent repositories and tags (e.g. "dev-latest") from the start (which doesn't fit well with ARM deployments since the containers need to exist in the Registry before the Web Apps can be configured so my infrastructure automation is incomplete), enable "Continuous Deployment" in the Web Apps and then tag the latest pushed repositories accordingly in the release so they would be picked up by Web Apps. I could not find a reasoble way to add tags to existing repositories in the Registry.
What is Azure best practice for CI with containerised web apps? How do people actually build their containers and then deploy them to each environment?
Just set up a CI pipeline for building an image and pushing it to a container registry.
You could then use both Azure App Service deploy and Azure Web App for Containers task to handle the deploy.
The Azure WebApp Container task similar to other built-in Azure tasks, requires an Azure service connection as an input. The Azure service connection stores the credentials to connect from Azure Pipelines or Azure DevOps Server to Azure.
I'm also deploying all Azure resources using ARM templates so I don't like the idea of configuring credentials when the 2 resources (the Registry and the Web App)
You could also be able to Deploy Azure Web App for Containers with ARM and Azure DevOps.
How do people actually build their containers and then deploy them to each environment?
Kindly take a look at below blogs and official doc which may be helpful:
Deploy an Azure Web App Container(official)
Azure DevOps: Create a Web App for Containers CI/Release pipeline for
an ASP.NET Core app
Build & release a Container Image from Azure DevOps to Azure Web App
for Containers
Related
Well, how can I create a pipeline to build and release a Docker compose, with Azure Devops through the graphical interface (GUI) I am not an expert in devops but I have this challenge in my work.
I would point you toward a great guide by microsoft, it's for java applications but you can get what you need out of it.
Solution in general:
Open the Azure Portal. Select + Create a resource and search for
Container Registry. Select Create. In the Create Container Registry
dialog, enter a name for the service, select the resource group,
location and click Review + Create. Once the validation is success
click Create.
In your CI build you need to have 2 tasks, 1 for the build/compose where you provide and another to publish the image to your Azure Container Registry. You will use the "same task" for this.
This container registry is where you store the outputs of your builds, similar to artifacts in traditional CI builds. This is where you publish your application from during a release to on-prem or cloud.
You can read more about the parameters you need to provide and the settings in details in the guide.
P.S. Here is an example on how to dockerize and existing .NETCore application.
How do you build and release your Docker compose on local?
Normally, you can copy the related docker-compose CLI and Docker CLI that you execute on local to the shell script tasks (such as Bash, PowerShell, etc.) in the pipeline you set up on Azure DevOps.
Of course, there are also the available Docker Compose task and Docker task.
I have a monolithic application that I am hosting on google cloud.
I am using cloud build that builds my docker image when I push to my repository.
Other than using Kubernetes, what other options do I have to push my latest docker image to my web instances in a rolling update to not bring my website down?
I cant' seem to find any documentation other than Kubernetes related.
I believe I should be building a instance template that has my latest docker image. Not sure how to make this happen in an automated fashion.
I have a .NET core web API and Angular 7 app that I need to deploy to multiple client servers, potentially running a plethora of different OS setups.
Dockerising the whole app seems like the best way to handle this, so I can ensure that it all works wherever it goes.
My question is on my understanding of Kubernetes and the distribution of the application. We use Azure Dev Ops for build pipelines, so if I'm correct would it work as follows:
1) Azure Dev Ops builds and deploys the image as a Docker container.
2) Kubernetes could realise there is a new version of the docker image and push this around all of the different client servers?
3) Client specific app settings could be handled by Kubernetes secrets.
Is that a reasonable setup? Have I missed anything? And are there any recommendations on setup/guides I can follow to get started.
Thanks in advance, James
Azure DevOps will perform the CI part of your pipeline. Once it is completed, Azure DevOps will push images to ACR. CD part should be done either directly from Azure DevOps (You may have to install a private agent on your on-prem servers & configure firewall etc) or Kubernetes native CD tools such as Spinnaker or Jenkins-X. Secrets should be kept in Kubernetes secrets.
My Application Structure
I am developing a tenant based application in service oriented architecture with deployment using kubernetes and Jenkins. In my application , It contains 15-20 number of microservices developing using spring boot. The each microservice need to be deploy separately for different customers. If I have 5 customer, I need to deploy 15 microservice for these 5 customer.This is the description about my tenancy model.
Deployment Planning
For this application I am planning to use kubernetes and Jenkins for deployment and implementing CI/CD pipeline.
My Findings
The nature of my application is building the images for different customer from same code by using spring cloud config server active profile functionality. Means In my docker file , I am launching the particular image by defining which is the active profile. Like the following,
java -jar -Dspring.profiles.active=<Profile_Name> dbdata-0.0.1-SNAPSHOT.jar
Here I am configuring profile in config server. So here I am using same code for creating multiple images which belongs to each customer.
Confusion
If I am following this style, how I can create and launch different images from same code repository using Jenkins? Is possible to launch multiple images using Jenkins from same code repository?
In summary, how can I understand multiple image creating and deployment as per above application structure?
As you have several microservices, it's better to use tools like Helm + Chartmuseum to simplify management of these services. In this case you will have individual release (and Kubernetes namespace) per tenant. You can use different docker images tags if different docker images per tenant is required.
As for Jenkins part, I don't see any problems (you can build any number of docker images from 1 repo):
create job to produce & upload docker image(s)
create job to produce & upload Helm chart(s)
create job(s) to deploy/update releases in Kubernetes
It's not required to build different docker images if they differ only in command line. This command line (or env variable) can be overridden in a Kubernetes resource description.
I'm asking this question here because Azure's documentation says a sample for Linux Containers is 'coming soon'. Anyone has any insight on when this tutorial might be available?
Meanwhile, I'm hoping someone can shed some light on how to effectively do this.
My use case is:
a microservices based application (say Microservices A, B, and C); each microservice should run in its own Docker container
use Visual Studio Team Services Build capability to build container images and push them to Docker Hub
use VSTS Release capability to individually deploy the microservices (containers) to a Service Fabric cluster as microservices are independently developed, that is, I don't want to update the entire application in Service Fabric, but only redeploy the changed microservice/container to the respective node(s)
There could be a custom solution for this where one can add Tasks to the Build and Release in VSTS (like Docker Build and Shell Script tasks), call some scripts to update the Application Manifest and Service Manifest to kick off the updates to the Service Fabric cluster, and so on.
Whether your containers are services in the same app or different app, you can still deploy them independently. Only changes are being applied at deployment, you don't even have to have the non-changed services in the deployment package. Look here to see an example for Service Fabric service (not in containers), but deploying containers using service manifest is conceptually the same: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-set-up-continuous-integration