I just deployed a web app (node.js container and mongo container) using Azure multi-container instances. It's a bit like Docker Compose but works with an Azure specific yaml file: https://learn.microsoft.com/en-us/azure/container-instances/container-instances-multi-container-yaml
Now I see that there is something called "Azure Web App for Containers". This seems to work with a real docker compose yaml file.
Other than the configuration file format, are there any other differences?
Note: I'm talking about Azure container instances, not Azure container services.
Well, azure container instances bill you only for the time container is active, while webapp bill you for the time webapp exists (so all the time). that is one of the biggest differences between those.
But overall, I'd say Azure Web App for Containers is just a shortcut to run containers on existing "stuff". I've recently learned that Azure Web App for Containers offer kubernetes capabilities, so these 2 services evolve in a slightly different directions. Azure Web App for Containers is targeted at long running stuff (always running) while ACI are aimed at scheduled\burstable\short lived workloads (similar to Azure Functions).
Found this link with MS-staff answer.
In summary
Web App for Containers
Recommended if you are already familiar with the Azure Web App environment.
Best if you have one or a few long-running containers/services that are being deployed.
Can use a custom Docker image to run your web app on an application stack that is not already defined in Azure
Azure Container Instances
"Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs"
A fast, light-weight and easy way of running containers
Billed for the time your container is active (billing is based on seconds, cores and memory)
Can start containers in Azure in seconds, without the need to provision and manage VMs.
Can also work with Kubernetes through an experimental ACI to Kubernetes connector
Currently, the fastest way to deploy containers on Azure
Based on the Azure docs, " Azure Container Instances guarantees your application is as isolated in a container as it would be in a VM."
Another difference, in addition to the other answer, is that Web App for Containers offers "slots" with which you can run multiple images on the same allocated resources to help increase utilization. As container instances bill per time used, they do not have "slots".
There is a good article about this on Microsoft Learn called: Comparing Container Apps with other Azure container options
Azure Container Instances
Azure Container Instances (ACI) provides a single pod of Hyper-V isolated containers on demand. It can be thought of as a lower-level "building block" option compared to Container Apps. Concepts like scale, load balancing, and certificates are not provided with ACI containers. For example, to scale to five container instances, you create five distinct container instances. Azure Container Apps provide many application-specific concepts on top of containers, including certificates, revisions, scale, and environments. Users often interact with Azure Container Instances through other services. For example, Azure Kubernetes Service can layer orchestration and scale on top of ACI through virtual nodes. If you need a less "opinionated" building block that doesn't align with the scenarios Azure Container Apps is optimizing for, Azure Container Instances is an ideal option.
Azure App Service
Azure App Service provides fully managed hosting for web applications including websites and web APIs. These web applications may be deployed using code or containers. Azure App Service is optimized for web applications. Azure App Service is integrated with other Azure services including Azure Container Apps or Azure Functions. When building web apps, Azure App Service is an ideal option.
Azure Web App for Containers and Azure Web App is the same service and they use an App Service Plan. The only difference is that Publish is set to Docker Container instead of Code by default.
https://azure.microsoft.com/en-us/products/app-service/web/
https://azure.microsoft.com/en-us/products/app-service/containers/#overview
From the article to see other alternatives as well:
There are many options for teams to build and deploy cloud native and containerized applications on Azure.
Azure Container Apps
Azure App Service
Azure Container Instances
Azure Kubernetes Service
Azure Functions
Azure Spring Apps
Azure Red Hat OpenShift
Azure Container Apps
Azure Container Apps enables you to build serverless microservices based on containers. Distinctive features of Container Apps include:
Optimized for running general purpose containers, especially for
applications that span many microservices deployed in containers.
Powered by Kubernetes and open-source technologies like Dapr, KEDA,
and envoy.
Supports Kubernetes-style apps and microservices with features like
service discovery and traffic splitting.
Enables event-driven application architectures by supporting scale
based on traffic and pulling from event sources like queues,
including scale to zero.
Support of long running processes and can run background tasks.
Azure Container Apps doesn't provide direct access to the underlying Kubernetes APIs. If you require access to the Kubernetes APIs and control plane, you should use Azure Kubernetes Service. However, if you would like to build Kubernetes-style applications and don't require direct access to all the native Kubernetes APIs and cluster management, Container Apps provides a fully managed experience based on best-practices. For these reasons, many teams may prefer to start building container microservices with Azure Container Apps.
You can get started building your first container app using the quickstarts.
Azure Kubernetes Service
Azure Kubernetes Service (AKS) provides a fully managed Kubernetes option in Azure. It supports direct access to the Kubernetes API and runs any Kubernetes workload. The full cluster resides in your subscription, with the cluster configurations and operations within your control and responsibility. Teams looking for a fully managed version of Kubernetes in Azure, Azure Kubernetes Service is an ideal option.
Azure Functions
Azure Functions is a serverless Functions-as-a-Service (FaaS) solution. It's optimized for running event-driven applications using the functions programming model. It shares many characteristics with Azure Container Apps around scale and integration with events, but optimized for ephemeral functions deployed as either code or containers. The Azure Functions programming model provides productivity benefits for teams looking to trigger the execution of your functions on events and bind to other data sources. When building FaaS-style functions, Azure Functions is the ideal option. The Azure Functions programming model is available as a base container image, making it portable to other container based compute platforms allowing teams to reuse code as environment requirements change.
Azure Spring Apps
Azure Spring Apps is a platform as a service (PaaS) for Spring developers. If you want to run Spring Boot, Spring Cloud or any other Spring applications on Azure, Azure Spring Apps is an ideal option. The service manages the infrastructure of Spring applications so developers can focus on their code. Azure Spring Apps provides lifecycle management using comprehensive monitoring and diagnostics, configuration management, service discovery, CI/CD integration, blue-green deployments, and more.
Azure Red Hat OpenShift
Azure Red Hat OpenShift is jointly engineered, operated, and supported by Red Hat and Microsoft to provide an integrated product and support experience for running Kubernetes-powered OpenShift. With Azure Red Hat OpenShift, teams can choose their own registry, networking, storage, and CI/CD solutions, or use the built-in solutions for automated source code management, container and application builds, deployments, scaling, health management, and more from OpenShift. If your team or organization is using OpenShift, Azure Red Hat OpenShift is an ideal option.
I want to consolidate a collection of Azure Functions and a WebAPI on the same App Service. Can't figure out the best way to go about it and be able to manage both solutions in the portal.
An App Service plan supports multiple resources deployed to it: Function apps, Api apps, Web apps, etc. There shouldn't be any issue doing this.
Each app deployed to a service plan will get its own uri and local storage, but will share the app service plan's capacity (e.g. if you have an S2 plan running on 3 instances, all of your deployed apps to that App Service plan will run on all 3 instances, utilizing the resources of the S2-based instances).
Instances of the same app share disk resources. Your different apps are isolated from each other.
You can't run them in the same site (ie, with the same URL like mysite.azurewebsites.net). Although you could use Function Proxies to forward out part of the function url namespace to the WebAPI. Your azure function and WebAPI would be 2 separate entities in the portal, similar to having 2 separate WebAPIs.
As others have said, this is possible.
For the function app, you need to choose "app service plan", not "consumption based".
You also need to have an app service plan which isn't on the Free or Shared tier. i.e. it has to be a minimum of B1 - no minutes/hour usage limits.
When I publish an api to azure from visual studio I see an existing app-service plan and also an option to create a new plan. The api I am going deploy will be used by the web application which was deployed using the existing service.
I have the following questions:
If I use the existing plan what would happen to the sites which are
already deployed using that plan?
Should I create new or use
existing?
Cost-wise which is the best option?
By using the same service plan to host the web app and the api, nothing will happen to the existing website besides you won't have any extra cost. The web apps will share the same resources.
If you create a new service plan for you api, you will have extra cost depending on the pricing tier you need.
The choice can depend on your scaling needs. If you need to define differents scaling plan for the api and the web app, it's a good idea to use two services plan, if not an unique service plan can be used.
I deployed an Azure Worker Role running OWIN into a Cloud Service for very fast HTTP serving. The Cloud Service exists in the "classic" environment at manage.windowsazure.com.
I would like to deploy the same lightweight application using the new ARM bits so it can be fully managed at portal.azure.com. I don't want to use a Web Application because that includes IIS.
What is the correct Platform-as-a-Service object to use in the ARM and the new portal that gives the same performance as an old Cloud Service Worker Role?
Thanks.
There isn't a Platform-as-a-Service object to use for this in ARM. Some Infrastructure-as-a-Service options are:
Create a regular Windows Azure Resource Manager VM in the new portal and set it up as an OWIN host.
Create an Azure Resource Manager template to deploy an OWIN host to a VM or a VM Scale Set. The template would use the custom script extension and/or DSC to do the setup. This would be a good re-usable solution, but someone would need to write the template for the first time.
The lightest weight solution would be to have the server running in a Docker container on Windows. You could then choose use the VM for other purposes running in other containers or purely as a container host. Note this only runs on only runs on Windows Server 2016 Technical Preview 3. See http://anthonychu.ca/post/web-api-owin-self-host-docker-windows-containers/
Edit -
Note that Service Fabric is the recommended PaaS solution in Azure Resource Manager. It is not a direct equivalent of PaaS v1 but a rich service for developing micro-service based applications: https://azure.microsoft.com/en-us/documentation/services/service-fabric/
Not sure what you mean by V2 (new portal? ARM?). The portal is an independent tool, so I'm guessing you mean ARM. ARM doesn't support Cloud Service deployments currently, but you can still deploy either from Visual Studio (using the same interface you've used in the past, in visual studio) or from the portal, as a "classic" resource (which, underneath, uses the classic Azure management API).
In the portal, you'll find Cloud service (classic):
Now you can add a new cloud service:
And fill out the various parameters:
When you create an Azure VM, it has to be placed into a Cloud Service (either new or existing).
Is that the exact same logical structure as an Azure Cloud Service that's created when deploying Web and Worker roles via Visual Studio?
Can I deploy Roles from VS into a Cloud Service created via VM creation? I can deploy a VM into a Cloud Service created via VS deployment? If either of those are true, how does that "free-standing" VM relate to the Role VMs? Is it just floating inside the Cloud Service independently from the Role VMs?
Thanks in advance!
This really should be on ServerFault, and the question will likely be closed, but...
Treat "cloud service" as a wrapper around either a collection of web and worker role instances or a collection of Virtual Machines, behind a single xyz.cloudapp.net namespace. Both are equivalent to the outside world (that is, accessing a service+endpoint via xyz.cloudapp.net:port). But managed differently.
Virtual Machines cannot be mixed with web/worker role instances in the same cloud service.